排查目標：將「無法連線」的問題定位在本機監聽、流量入口、節點設定、時間與交握，或遠端網路其中一層。本文主要以 Windows 版 v2rayN 說明操作方式，並補充 Android 上 v2rayNG 與 v2flyNG 的檢查差異。每次只變更一項條件，並以相同請求重新測試，避免同時更換節點、路由和 DNS，導致無法判斷是哪項設定生效。
步驟一：確認本機代理連接埠正在監聽
本機入口：用戶端視窗開啟，不代表代理核心已經啟動。v2rayN 負責設定與管理，實際連線則由選用的核心處理；如果核心載入設定失敗或連接埠遭占用，即使瀏覽器已填入代理位址，也無法將請求送往節點。先查看用戶端記錄中的啟動結果，再確認監聽連接埠。
檢查連接埠：開啟 v2rayN「設定」→「參數設定」，查看本機監聽位址、連接埠及對應的入站類型。介面上的分組名稱可能因版本而異。以下以 127.0.0.1:10808 的 SOCKS 入站為例；10808 並非所有安裝環境都固定使用的數值，也不是伺服器端連接埠，執行前請換成實際監聽的數值。
netstat -ano | findstr ":10808"- 沒有輸出：確認實際使用的連接埠是否不同、核心是否已結束，以及記錄中是否出現設定解析或啟動失敗訊息。不要先改瀏覽器設定，試圖補救根本不存在的監聽服務。
- 出現 LISTENING：查看該行末尾的 PID，並在「工作管理員」→「詳細資料」確認所屬程序。連接埠可能已被其他程式占用，不能只憑數字相同就認定運作正常。
- 監聽位址不同：
127.0.0.1是 IPv4 回送位址；只有[::1]監聽，不代表 IPv4 回送連線一定可用。測試位址應與監聽位址一致。
錯誤：bind: address already in use
原因：準備使用的本機位址與連接埠已遭占用，常見情況包括重複啟動，或其他代理程序仍在執行。
解決方式：依 PID 確認占用程序，關閉重複執行的程式，或變更本機監聽連接埠；重新啟動核心後，也要同步更新應用程式的代理設定。
Android 差異：v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；請先確認應用程式已啟動連線，並取得系統 VPN 授權。Android 的 VPN 流量接管與 Windows 系統代理並非相同入口，不宜直接套用 Windows 的連接埠檢查結論。
步驟二：區分系統代理、應用程式代理與 TUN
流量路徑：系統代理只會影響遵循該設定的應用程式；TUN 則透過虛擬網卡接管流量。瀏覽器能開啟網頁、其他程式卻無法連線，不一定是節點故障；反過來說，用戶端延遲測試成功，也不代表瀏覽器已經使用代理。
隔離測試：先記下原本的系統代理與 TUN 狀態，暫時關閉 TUN，再使用明確指定 SOCKS 代理的指令發出請求。這麼做可排除「應用程式是否遵循系統代理」的不確定因素，但仍會受到用戶端內部路由規則影響。若要確認代理出站狀況，也應查看記錄中實際選用的出站方式。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raymark.com/參數說明：socks5h 會將目標網域交由代理端處理，不能據此判定本機 DNS 一定正常；10 秒是連線階段的逾時上限，20 秒是整個請求的逾時上限，兩者僅為本次診斷設定，不是網路效能標準。即使收到 403 或 405，也表示已收到 HTTP 回應，不應再將問題歸類為連線逾時。
-
記錄入口狀態
記下 v2rayN 的監聽連接埠、選取的節點、系統代理狀態與 TUN 狀態，並保留失敗時的原始條件。
-
明確指定代理測試
關閉 TUN 後執行上方指令；若連線本機時便遭拒絕，請回到步驟一檢查連接埠及 SOCKS 入站類型。
-
還原系統代理設定
明確指定代理的測試成功後，在 v2rayN「系統代理」中選擇「自動設定系統代理」，再查看 Windows「設定」→「網路和網際網路」→「Proxy」中的狀態是否與用戶端一致。
-
單獨測試 TUN
確實需要 TUN 時再啟用，並依用戶端提示確認權限與網卡狀態。如果只有 TUN 無法運作，請優先檢查路由、DNS 及其他 VPN 的衝突，不要立刻修改節點參數。
判斷方式：明確指定代理測試成功，先檢查應用程式入口
明確指定代理的請求成功，但瀏覽器仍無法連線時，請先檢查瀏覽器擴充功能、應用程式專屬代理及系統代理位址。此時更換伺服器，無法解決本機入口未生效的問題。
步驟三：核對訂閱設定與實際使用的節點
設定來源：訂閱更新成功只表示已取得並解析設定，不保證每個節點都有效；更新失敗也不代表現有節點立刻失效。先確認目前選取的節點屬於哪個訂閱群組、是否仍是更新前的舊項目，再確認服務提供者是否變更過位址、連接埠或驗證資訊。
核心差異：在 v2rayN 中應確認目前實際呼叫的核心及其記錄；Android 上的 v2rayNG 與 v2flyNG 並非僅名稱不同的同一個程式。Xray 與 v2fly 支援的協定擴充功能及欄位並不完全相同，設定能匯入介面，不代表核心一定能完整執行。使用 VLESS、REALITY 等設定時，尤其要確認核心是否支援。
| 檢查項目 | 核對內容 | 常見誤判 |
|---|---|---|
| 伺服器位址與連接埠 | 核對節點位址與伺服器監聽連接埠；443 僅為常見設定範例 | 將本機的 10808 填成遠端連接埠 |
| 協定與驗證 | VMess、VLESS 類型及相應的使用者識別碼等欄位 | 只確認節點名稱相同，忽略驗證資訊已更新 |
| 傳輸參數 | 核對實際使用的 TCP、WebSocket 或 gRPC 等傳輸方式及必要欄位 | 傳輸設定不一致，卻只調整 DNS |
| TLS 參數 | 核對是否啟用 TLS、伺服器名稱及憑證要求 | 誤以為 TCP 連接埠可連線，就代表交握設定正確 |
| 路由出站 | 確認測試請求選用預期的代理，而非直連或遭封鎖 | 將目標網站直連失敗誤判為節點逾時 |
更新方式：在 v2rayN「訂閱群組」中對應群組執行更新，完成後重新選取節點並檢查記錄。如果目前版本提供透過代理與不透過代理更新兩種方式，請依訂閱網址實際可連線的狀況選擇；若唯一節點已失效，繼續依賴該節點下載訂閱可能形成循環失敗。訂閱網址與完整節點設定都屬於敏感資訊，排查截圖請遮蔽驗證欄位。
步驟四：同步系統時間並辨識 TLS 交握失敗
時間的影響：系統時間明顯不準，可能導致憑證被判定為尚未生效或已過期，也可能影響 VMess 的時間相關驗證。VLESS 不適用 VMess 的時間驗證說明，但啟用 TLS 時仍會檢查憑證有效期限。只修改時區顯示，並不等於修正系統實際時間。
- Windows：開啟「設定」→「時間與語言」→「日期與時間」，啟用「自動設定時間」，按一下「立即同步」，並確認同步結果。
- Android：在系統設定中搜尋「日期和時間」，啟用自動設定時間；實際選單位置依裝置系統而異。
- 同步後：重新發出一次測試請求，並查看同一時間的核心記錄。若仍出現憑證錯誤，請繼續核對憑證有效期限與伺服器名稱。
錯誤：x509: certificate has expired or is not yet valid
原因：憑證有效期限與目前系統時間不符，可能是本機時間錯誤，也可能是伺服器憑證確實需要更新。
解決方式：先同步本機時間；若時間正確但仍出現錯誤，請由伺服器維護者檢查憑證及部署狀態。
錯誤：x509: certificate signed by unknown authority
原因：憑證鏈無法連結至受信任的根憑證，可能是缺少中繼憑證、使用私有憑證，或本機信任存放區有問題。
解決方式：核對伺服器憑證鏈及預期的簽發機構；私有憑證應透過可信管道設定信任，不要以略過驗證取代修復。
SNI 核對：連線位址與 TLS 伺服器名稱可以不同，但必須符合伺服器部署和憑證要求，不能隨意填入一個可連線的網域。不要將 allowInsecure 當成解決逾時的開關；略過憑證驗證既無法修復 TCP 連線問題，也無法修正錯誤的傳輸路徑，還會降低身分驗證的安全性。
步驟五：檢查伺服器連線狀況與遠端監聽
遠端測試：確認前四步的本機入口、流量接管與設定無誤後，再測試節點位址的目標連接埠。以下是 Windows PowerShell 指令，執行時請輸入實際節點位址與連接埠，不要輸入完整訂閱網址。此測試只檢查 TCP 連線，無法驗證帳號、TLS、WebSocket 路徑或 gRPC 服務名稱。
$nodeHost = Read-Host "輸入節點伺服器位址"
$nodePort = [int](Read-Host "輸入節點伺服器連接埠")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed- TcpTestSucceeded 為 True：本次測試使用的位址與連接埠可以建立 TCP 連線。接下來檢查 TLS、驗證、傳輸參數及伺服器記錄，不應據此宣稱節點完全正常。
- TcpTestSucceeded 為 False：可能與位址解析、服務未監聽、防火牆、安全性群組或網路封包遺失有關。請結合解析出的遠端位址及錯誤訊息判斷，不能只憑此結果認定服務已停止。
- Ping 失敗但 TCP 成功：目標可能不回應 ICMP。不要以 Ping 失敗取代代理連接埠測試，也不要把 Ping 成功當成代理服務正常的證明。
- 涉及 UDP：TCP 測試無法說明 UDP 是否可用；網頁請求成功，也不代表所有依賴 UDP 的應用程式都能正常運作。
錯誤：i/o timeout
原因：某次網路讀寫未能在期限內完成；必須搭配前後記錄，判斷問題發生在連線至節點、TLS 交握，還是存取目標服務的階段。
解決方式：保留同一請求前後的記錄，對照遠端位址及發生階段，再分別檢查連接埠、交握或目標服務；不能只憑這一行就改用其他 DNS。
網路對照：保持節點、目標位址和測試指令不變，只將本機網路切換至手機熱點後重新測試。如果結果不同，應優先檢查原網路的出口限制、DNS 回應及 IP 位址類別差異；這仍不足以證明限制的確切原因。若網域同時有 IPv4 與 IPv6 位址，請記下實際使用的位址，不要只比較網域名稱。
伺服器端協作：若有管理權限，請檢查程序是否執行、預期連接埠是否正在監聽、防火牆與安全性群組是否允許連線，以及憑證和反向代理設定是否一致。若沒有權限，請提供維護者失敗時間及時區、協定與傳輸類型、已遮蔽敏感資訊的記錄及連接埠測試結果；不要公開使用者識別碼、訂閱網址或其他驗證資料。
判斷方式：連接埠可連線後，轉而檢查交握與設定
TCP 測試成功但代理請求仍持續失敗時，請將下一輪排查範圍限縮至 TLS、協定驗證、傳輸參數及實際出站記錄；一再增加等待時間，通常只會延後遇到同一個錯誤。
重新測試：使用相同請求確認修復範圍
重新測試標準：完成一項變更後，重新執行步驟二的明確指定代理請求，再測試實際使用的瀏覽器或應用程式。明確指定代理的測試成功，只涵蓋這條請求路徑，不能取代對系統代理、TUN、DNS 及其他應用程式的個別驗證。用戶端顯示的延遲測試結果也有其測試目標與方法，不能據此判定所有應用程式都能正常使用。
- 記錄變更：留下變更項目、測試時間、選取的節點及相關記錄，避免下次遇到問題時得從頭排查。
- 還原設定：依實際需求恢復 TUN 與系統代理，撤銷暫時性調整，不要保留關閉憑證驗證等規避設定。
- 縮小範圍：若只有一個網站無法使用，請檢查該目標的路由與回應狀態；若只有一個應用程式出問題，請檢查其專屬代理及流量類型。
- 保留依據：修復前後應使用相同目標、相同入口及相同逾時參數測試，不要將單次成功描述為長期穩定。
後續設定：想了解系統代理、TUN 與分流規則的關係，請參閱進階用法；若尚未完成初次設定，請先依照教學建立可重複驗證的連線，再逐步加入路由與 DNS 設定。