適合已匯入設定，卻遇到測試逾時或網頁無法開啟的使用者。先確認本機代理入口是否正常，再檢查遠端連接埠、傳輸與 TLS，最後核對路由和 DNS。以下以 Windows 上的 v2rayN 為例，每次只調整一項，並透過記錄檔和同一筆請求判斷結果，避免把測速失敗直接當成節點故障。
一、先分清測試逾時與連線失敗
「逾時」只表示某項操作未能在指定時間內完成，無法單憑這點判斷故障位置。延遲測試、訂閱更新和瀏覽器連線是三種不同的請求路徑：訂閱伺服器無法開啟，不代表已匯入的節點不能使用；測試網址回應慢，也不表示所有網站都無法開啟。
| 遇到的情況 | 優先確認 | 下一步 |
|---|---|---|
| 只有延遲測試逾時 | 實際網頁能否開啟、測試網址是否連得上 | 使用固定網址發送代理請求 |
| 瀏覽器無法開啟，核心沒有請求記錄 | 系統代理、本機監聽連接埠、瀏覽器代理擴充功能 | 先測試本機代理入口 |
| 記錄檔顯示遠端連線逾時 | 節點網域解析、遠端連接埠、目前使用的網路 | 檢查遠端連線狀態 |
| 只有部分網站無法連線 | 路由比對、目標網站與 DNS | 查看該網域的連線記錄 |
測試前記下目前的節點備註、用戶端版本、使用的核心和測試時間。v2rayN 是用戶端介面，實際建立連線的是核心；介面能開啟，不代表核心已成功啟動。可在「說明」→「關於」查看版本；不同版本的選單名稱可能略有差異，請以本機顯示為準。
二、校正系統時間，建立最基本的測試環境
本機日期或時間不準，可能影響憑證效期判定，也可能導致 VMess 的時間驗證失敗。VLESS 不使用相同的時間驗證機制，但使用 TLS 時仍會檢查憑證時間。先同步日期與時間，不要把所有驗證錯誤都歸咎於通訊協定。
-
同步時間
在 Windows 11 開啟「設定」→「時間與語言」→「日期與時間」，啟用「自動設定時間」，再於「其他設定」中按一下「立即同步」。同時確認日期和時區；只變更顯示時區無法修正錯誤的系統時鐘。
-
固定使用節點
在 v2rayN 節點清單中按右鍵點選目標項目，選擇「設為活動伺服器」。排查期間固定使用這項設定，暫時不要自動切換，避免前後兩次請求實際連到不同伺服器。
-
簡化連線入口
先關閉 v2rayN 主畫面的「啟用 TUN」，並退出其他會接管流量的代理或 VPN 程式。這麼做是為了減少變因；完成本機代理測試後，再單獨測試 TUN。
-
重現一次問題
開啟記錄區，記下目前時間，只造訪一個固定網址。保留這次請求附近的錯誤記錄；不要連續切換十幾個節點後，再從混雜的記錄中猜測原因。
三、檢查系統代理與本機監聽連接埠
先在 v2rayN「設定」→「參數設定」中查看本機監聽連接埠相關設定，確認實際連接埠和通訊協定。以下以 127.0.0.1:10808 的 SOCKS 入口為例，並非所有版本或安裝方式都使用這個連接埠。如果本機設定不同，指令也要一併修改。
在 Windows PowerShell 中執行以下兩條指令。第一條查看監聽狀態和處理程序 ID；第二條直接透過本機 SOCKS 發出請求，排除應用程式是否讀取系統代理的差異。example.com 僅為範例測試網站；若單次請求失敗，請換另一個已知正常的網址交叉測試。
netstat -ano | findstr ":10808"
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 15 -I https://example.com/- 沒有 LISTENING：檢查核心是否已啟動，以及連接埠是否設定錯誤；不要只看用戶端視窗是否仍開著。
- 有監聽，但 PID 不熟悉：在「工作管理員」→「詳細資料」中核對 PID。IPv4 和 IPv6 出現多筆監聽不一定代表衝突，重點是確認連接埠由哪個處理程序使用。
- 指令收到 HTTP 回應，但瀏覽器連線失敗：優先檢查系統代理和瀏覽器擴充功能。即使回傳 301、403 等狀態，也表示已收到 HTTP 回應，但不代表目標網站的所有功能都能正常使用。
- 本機連線立即遭拒：先修正監聽位址、連接埠或核心啟動問題；目前還沒有證據能判定遠端節點故障。
指令執行成功後，在 v2rayN 底部的「系統代理」選單選擇「自動設定系統代理」，再用瀏覽器重試。在 Windows「設定」→「網路和網際網路」→「Proxy」中，核對代理位址和連接埠；此處的連接埠應對應用戶端的 HTTP 或混合入口，不能任意填入僅支援 SOCKS 的連接埠。
結論：先確認本機代理入口正常
明確指定本機代理的請求成功，但瀏覽器仍失敗時，先修正應用程式使用的代理入口；不要繼續修改節點的 UUID、TLS 或傳輸路徑。
四、從記錄檔辨別 DNS、拒絕連線與逾時
確認本機代理入口正常後，再查看核心連線遠端時發生的錯誤。以下是常見記錄片段，實際前後文會因核心和系統而異。單看一行錯誤只能判斷大致方向，還要比對對應的目標位址和時間。
no such host
原因：相關網域解析失敗，可能是節點網域，也可能是目標網站網域。
解決方式：先確認記錄中的網域是哪一個，再核對拼字和本機 DNS；不要一看到解析失敗就直接更換整個節點。
connection refused
原因：連線遭到明確拒絕，常見原因是目標連接埠沒有服務監聽，或遭到主動拒絕。
解決方式：核對遠端連接埠和服務狀態；若錯誤位址是本機迴路位址，請回頭檢查本機監聽。
i/o timeout
原因：某次網路讀寫未能在期限內完成，可能與網路連線、防火牆、伺服器負載或後續交握有關。
解決方式：先確認錯誤發生在連線建立還是交握階段，再換另一個網路使用相同設定進行比對；不要只憑這行記錄就判定帳號失效。
address already in use
原因：核心要繫結的本機位址和連接埠已被其他監聽程序占用。
解決方式：使用 PID 找出占用連接埠的程式，關閉重複執行的程序，或修改本機連接埠並同步調整應用程式的代理設定。
若已知道伺服器位址和連接埠，可使用 PowerShell 的 Test-NetConnection 檢查 TCP 連線。例如以下僅示範指令格式，example.com:443 並非你的節點；實際診斷時，請改成訂閱服務提供方給的伺服器位址和連接埠。
Test-NetConnection -ComputerName example.com -Port 443TcpTestSucceeded: True 只能證明已建立 TCP 連線，不能證明 TLS、VMess 或 VLESS 驗證成功。若使用以 UDP 為基礎的傳輸方式，這項 TCP 檢查也無法驗證其資料通道。如果相同設定在手機熱點可用、在目前網路卻失敗，請優先排查網路限制；仍須參考伺服器記錄，避免只憑一次網路比對就下定論。
五、逐項核對傳輸與 TLS 設定
遠端連接埠可以連線，但交握失敗時，請開啟節點編輯視窗，逐項比對服務提供方的原始設定。不要以為連接埠是 443 就一定要啟用 TLS，也不要為了消除錯誤而任意關閉憑證驗證。
| 檢查項目 | 必須一致的設定 | 常見誤解 |
|---|---|---|
| 通訊協定與驗證 | VMess 或 VLESS、UUID，以及設定要求的其他驗證欄位 | 只改通訊協定名稱，卻保留另一種通訊協定的欄位 |
| 位址與連接埠 | 伺服器位址、遠端監聽連接埠 | 把本機 10808 填成遠端連接埠 |
| WebSocket | 傳輸方式、路徑、Host | 漏掉路徑開頭的斜線，或把 Host 誤當成 SNI |
| gRPC | 傳輸方式、serviceName，以及伺服器要求的 TLS 設定 | 把 serviceName 當成 WebSocket 路徑，任意加上斜線 |
| TLS | 是否啟用、serverName/SNI、憑證信任與有效期限 | 將連線位址改成 IP 後，也把 SNI 一併改成 IP |
| REALITY | 配套的 serverName、公鑰、shortId、指紋與 flow 等設定要求 | 當成一般 TLS，混用不同設定的參數 |
x509: certificate has expired or is not yet valid
原因：憑證效期檢查失敗，可能是本機時間錯誤，也可能是伺服器憑證已過期。
解決方式：先同步系統時間；若時間正確仍然失敗，請服務提供方確認憑證部署和續約狀況。
websocket: bad handshake
原因：WebSocket 升級交握未收到預期回應，常見原因是路徑、Host 或反向代理規則不相符。
解決方式：依照原始設定還原路徑和 Host，並請伺服器端檢查對應網站的轉發規則。
VMess、VLESS 是代理通訊協定，WebSocket、gRPC 是傳輸方式，TLS 則是安全層，三者不能互相替代。更新訂閱後若欄位看起來不完整，請優先重新匯入經服務提供方確認的設定，並核對目前使用的核心是否支援該組合；不要手動拼湊不同節點的參數。
六、最後檢查路由、DNS 與 TUN
同一個節點能連上部分網站時，通常更需要留意分流設定，而不是像「所有請求都失敗」那樣直接判定節點故障。v2rayN 底部的路由選擇和系統代理是兩回事：系統代理決定應用程式將請求送往何處，核心路由則決定收到請求後要使用哪個出口。若應用程式繞過本機代理入口，修改核心規則也不會生效。
- 先查看比對結果：造訪無法連線的網域，查看記錄中是否出現該請求，以及實際使用代理還是直連。必要時可暫時提高記錄層級，重現問題後再恢復，避免長時間記錄過多瀏覽資訊。
- 暫時進行單一變因比對：選擇會將測試流量導向代理出口的路由預設，再執行相同請求。若恢復正常，再核對原有規則的順序和比對範圍，不必長期保留測試預設。
- 分清兩種解析：節點伺服器網域的解析會影響能否建立連線；目標網站網域的解析則會影響網站存取與流量分流。修正其中一種，不代表另一種也正常。
- 檢查規則資源：
geosite是網域集合，geoip是 IP 位址集合。資源缺漏或規則引用錯誤可能導致載入失敗；請先查看核心啟動記錄，再考慮更新相關資源。
確認本機代理正常後，再啟用「啟用 TUN」，測試不讀取系統代理的應用程式。TUN 通常會接管虛擬網卡、路由和 DNS，也可能需要相應權限。若啟用後立即斷網，先關閉 TUN 並確認網路恢復，再檢查權限、其他 VPN 的路由和虛擬網卡衝突；不要同時修改傳輸設定。
結論：使用相同請求隔離 TUN 問題
相同節點透過明確指定的本機代理可正常使用，只有啟用 TUN 後失敗時，應檢查虛擬網卡、路由和 DNS 接管，而不是先更換遠端通訊協定。
七、常見問題與停止排查的時機
延遲測試全部逾時，但網頁能開啟，還需要換節點嗎？
暫時不用。先確認網頁確實透過代理連線，再檢查測試網址、測試方式和逾時設定。使用同一個網址重複確認實際連線狀況，不要只憑單次測試結果判斷連線狀態。
訂閱更新逾時，需要啟用透過代理更新嗎？
先確認訂閱網址有效，以及目前是否有可用代理。若無法直連訂閱網站，但透過代理可存取，再選擇相應的代理更新方式；若所有節點都無法使用，強制透過代理更新可能陷入循環。
電腦可以連線，Android 上同一組設定卻不行？
先讓兩台裝置使用相同網路，再核對時間、活動設定和記錄。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，設定是否受支援須以各自的核心為準；依賴 Xray 特定功能的設定，不能只因分享連結成功匯入就認定相容。
把逾時從 5 秒改成 30 秒就能修好嗎？
這只能讓較慢的回應有更多時間完成，無法修正錯誤的連接埠、驗證欄位或憑證。請先用固定的等待上限進行前後比對；若請求最後仍失敗，就繼續確認記錄中的失敗階段。
若本機連接埠正常、設定已與來源核對、系統時間正確，而同一節點在兩個不同網路下仍於相同階段失敗，就可以停止反覆調整。此時向服務提供方提供已遮蔽敏感資訊的時間、核心版本、錯誤片段和遠端連接埠測試結果，比繼續隨機更換 DNS 更有效。
- 保留一筆失敗請求的完整時間線，不要傳送整份私人設定。
- 說明失敗發生在本機監聽、遠端連線、TLS 交握，還是目標網站存取階段。
- 排查完成後，還原原本的路由、記錄層級和所需的代理模式。