適合遇到 v2rayN 測試逾時、啟用代理後網頁無法開啟，或更換節點仍無法連線的使用者。先分別以直連和明確指定代理的方式，檢查本機網路與用戶端，再核對節點參數、傳輸設定及伺服器監聽狀態。每次只調整一項，並保留對應記錄，避免把連接埠遭占用、DNS 故障和遠端無法連線混為一談。
先釐清：測試逾時還是實際連線失敗
「節點逾時」並非完整的診斷結果。TCP 連線測試只確認能否連上遠端連接埠；實際代理延遲測試還會受到代理協定、測試網址和請求逾時設定影響。清單顯示逾時，不一定代表所有網站都無法瀏覽；顯示延遲數值，也不代表憑證、路由和所有應用程式都正常。
先選定一個節點作為目前使用的設定，再開啟固定的 HTTPS 網址。不要同時切換節點、路由模式和 DNS。記下故障發生的時間（精確到分鐘），並查看同一時間的核心記錄；只截取節點清單，通常無法判斷連線卡在哪個階段。
- 所有節點都逾時：優先檢查本機網路、核心是否啟動、本機連接埠和共用設定；同一來源提供的節點也可能同時受到伺服器故障影響。
- 只有一個節點無法連線：優先比對該節點的伺服器位址、連接埠、傳輸方式和遠端狀態，不要一開始就重設整套用戶端。
- 瀏覽器無法連線，但明確指定代理的請求成功：著重檢查系統代理、瀏覽器代理擴充功能和路由，不要繼續修改節點認證資料。
- 只有一個測試網址無法連線：換成已知可連線的目標再次測試，確認是測試網站異常還是節點異常。
第一步：關閉代理，確認本機網路與 DNS
在 v2rayN 工作列通知區的「系統代理」選單中選擇「清除系統代理」，並關閉 TUN 模式。暫時退出其他會接管網路的工具，避免流量仍經過虛擬網卡。接著開啟平常可直接連線的網站；若此時也無法開啟，請先處理 Wi-Fi 登入、閘道器或電信業者連線問題。
-
恢復直連
清除系統代理並關閉 TUN 後，重新開啟瀏覽器。若瀏覽器設有獨立代理，也要改回使用系統設定；只關閉用戶端主視窗並不足夠。
-
檢查網路位址
在 Windows 終端機執行
ipconfig，查看目前網路介面卡的 IPv4 位址和預設閘道器。若出現169.254.x.x且沒有可用閘道器，請先重新連線，或排查 DHCP 問題。 -
檢查 DNS 解析
執行下方的 DNS 指令。先確認一般網域名稱可正常解析，再對節點實際使用的網域名稱執行相同檢查；若節點填的是 IP 位址，此步驟不會檢查節點位址解析。
-
更換網路測試
使用手機熱點對同一個節點再測試一次。若只有原本的網路無法連線，請優先排查該網路的 DNS、對外連線政策和路由，不必急著重新安裝用戶端。
ipconfig
nslookup example.comexample.com 僅用於示範指令格式，並非節點伺服器。解析成功只表示取得了位址，不代表能連上該位址上的服務。也不要因為 ping 沒有回應，就認定節點已離線：遠端可能封鎖 ICMP，但 TCP 服務仍正常運作。
第二步：檢查核心、本機連接埠與系統代理
恢復基本網路連線後，啟動用戶端並選定節點。前往 v2rayN「設定」→「參數設定」，檢查本機監聽設定與目前使用的核心；不同桌面版本的子頁面名稱可能不同，請以實際欄位為準。先確認記錄中沒有設定載入失敗，再檢查系統代理；不要直接改用 TUN 來掩蓋一般代理模式的問題。
以下以本機 SOCKS 入口 127.0.0.1:10808 為例，實際連接埠請以目前設定為準。有些設定使用混合入口，有些則另外設定 HTTP 入口；舊設定中也可能看到 10809。不能只憑連接埠數字判斷協定，更不要把 SOCKS 連接埠誤填為 HTTP 代理。
netstat -ano | findstr :10808
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- 先檢查監聽狀態：
netstat輸出中的LISTENING代表有程序正在監聽，最後一欄是 PID；若沒有輸出，請先確認核心是否已啟動，以及連接埠是否曾經變更。 - 再確認程序：在工作管理員的「詳細資料」中，依 PID 確認程序所屬項目。若發現連接埠遭其他程式占用，先確認用途，再關閉對應程式或變更本機監聽連接埠；不要任意結束系統程序。
- 明確指定代理：範例中的
socks5h會透過 SOCKS 代理端解析目標網域；節點伺服器本身的網域仍可能需要由本機解析。--noproxy ""用來清除這次請求的直連例外設定。 - 判讀回應結果：收到 HTTP 回應，表示這次代理請求的目標連線路徑已有回應，即使狀態碼是 403 或 405；仍須依目標網站的政策判斷。20 秒逾時只是這次診斷設定的上限，並非軟體預設值。
結論：明確指定代理成功後，再檢查流量接管方式
若這個指令收到回應，但瀏覽器仍無法連線，請先保留節點參數不變，啟用「系統代理」→「自動設定系統代理」，再檢查瀏覽器擴充功能和系統代理例外設定。若明確指定代理的請求也失敗，請繼續檢查記錄與遠端連線，不要反覆開關系統代理。
第三步：核對節點參數，不要猜測或自行補欄位
開啟故障節點的編輯視窗，逐項比對服務端提供的原始設定。VMess 和 VLESS 是不同協定，不能只改協定名稱就互相轉換。訂閱只是分發設定的方式；訂閱更新成功不代表節點可用、帳戶有效或遠端服務正常。
| 核對項目 | 檢查內容 | 常見誤解 |
|---|---|---|
| 伺服器與連接埠 | 逐字核對網域名稱或 IP，以及遠端監聽連接埠 | 把本機的 10808 當成伺服器連接埠；或把所有遠端連接埠都改成 443 |
| 協定與身分資料 | 核對 VMess / VLESS、使用者識別碼及伺服器要求的相關欄位 | 複製時漏掉字元，或混用不同節點的身分資料與位址 |
| 傳輸方式 | 核對實際設定的 TCP、WebSocket 或 gRPC 等傳輸方式 | 以為傳輸方式只是顯示名稱，可以任意切換 |
| 安全設定 | 核對 TLS 或 REALITY，以及對應的伺服器名稱和專用欄位 | 把 REALITY 當成一般 TLS，只填入網域名稱就儲存 |
| 路由與輸出 | 確認測試目標實際使用預期的輸出，而非直連或阻擋規則 | 以為選定目前使用的節點後，所有請求都會經過該節點 |
若剛更新訂閱，先確認目前使用的是更新後的項目。名稱重複容易選到舊設定；可在保留原設定的前提下，為測試項目加上容易辨識的備註。不要將完整分享連結、使用者識別碼或訂閱網址貼到公開討論區；提供故障資訊時，只保留協定、傳輸方式、錯誤文字及已去識別化的位址。
第四步：根據記錄判斷 TLS 與傳輸層錯誤
先在用戶端記錄區找到這次請求的時間，再判斷錯誤發生於網域解析、TCP 建立連線、TLS 交握，還是傳輸連線建立階段。以下列出常見錯誤片段，不同核心顯示的前後文可能不同；單獨出現 context deadline exceeded 只能表示逾時，還要查看前面正在執行哪項操作。
錯誤：dial tcp: lookup
原因：常見於節點網域解析失敗，完整記錄通常還會包含網域名稱與 DNS 錯誤資訊。
處理方式：先用 nslookup 檢查相同網域，再核對用戶端 DNS 與目前網路；修復後重新測試一次，並查看新記錄。
錯誤：connect: connection refused
原因：連線遭到明確拒絕，可能是目標連接埠沒有監聽、防火牆主動拒絕，或本機代理入口根本沒有啟動。
處理方式：先確認錯誤位址是 127.0.0.1 還是遠端位址；本機問題檢查監聽狀態，遠端問題請管理員檢查服務與防火牆。
錯誤：i/o timeout
原因：某個網路讀寫階段超過時限，可能與封包遺失、封包遭靜默丟棄，或遠端遲遲沒有回應有關。
處理方式：根據前後文確認逾時發生的階段，再換一個網路交叉測試；不要只憑這一行就認定密碼錯誤或伺服器離線。
錯誤：x509: certificate has expired or is not yet valid
原因：本機時間不準，或伺服器憑證確實不在有效期限內。
處理方式：先在 Windows「設定」→「時間與語言」→「日期與時間」中校正時間，再請管理員檢查憑證有效期限。
錯誤：websocket: bad handshake
原因：WebSocket 升級回應不符合預期，常見原因包括路徑、Host、反向代理轉送設定或目標服務不符。
處理方式：依服務端設定核對 WebSocket 路徑和 Host，並檢查反向代理是否將該路徑轉送至正確的後端。
TLS 的 SNI 是交握時使用的伺服器名稱；WebSocket 的 Host 則是 HTTP 請求欄位，兩者用途不同。伺服器位址、SNI 和 Host 有時相同，有時則須依部署需求分別填寫，不能一律照著網址列的內容替換。gRPC 還須核對 serviceName，並確認中間代理支援 HTTP/2；路徑和名稱的大小寫也應保持一致。
第五步：檢查伺服器監聽狀態與入口防火牆
確認前面的本機與參數檢查都通過後，再由具備權限的管理員檢查伺服器。一般訂閱使用者不必尋找伺服器登入憑證；只要向服務提供者提供故障時間、使用的網路、節點備註和已去識別化的記錄即可。以下指令適用於 Linux 伺服器，請在具備相應權限的環境中執行。
sudo ss -lntp
sudo systemctl status xray --no-pager
sudo journalctl -u xray --since "20 minutes ago" --no-pager範例假設服務單元名稱為 xray。只有部署時確實使用這個名稱，才能直接執行；使用 V2Ray 或自訂服務單元的環境，應替換成實際的單元名稱。服務顯示正在執行，不代表目標連接埠一定存在；應從 ss 輸出同時確認監聽位址、連接埠和所屬程序。
- 確認入口連接埠：若用戶端實際使用 TCP 443，就檢查對外入口的 TCP 443；只允許 UDP 443 並不足夠。其他連接埠則依實際設定檢查。
- 區分前端與後端：使用反向代理時，對外的 443 可能由反向代理監聽，而核心只監聽迴圈位址上的後端連接埠。這種架構本身正常，不應直接將所有後端連接埠開放至公網。
- 檢查兩層防火牆：雲端平台的安全性群組和伺服器防火牆都必須允許實際入口；只修改其中一層，仍可能發生逾時。
- 檢查 DNS 位址記錄：若網域設有 A 和 AAAA 記錄，請分別核對 IPv4、IPv6 的監聽狀態與連線能力，避免其中一個位址正常、另一個卻無法連線。
- 檢查服務記錄：搜尋連接埠繫結失敗、設定解析失敗、使用者驗證失敗和憑證載入錯誤。若記錄中沒有請求資訊，也要確認請求是否停在前置反向代理。
結論：使用相同節點跨網路比對
同一節點在手機熱點可用、原本的網路無法連線時，先保留伺服器設定，繼續排查原網路的連線路徑；若多個網路都無法連線，且伺服器沒有監聽入口，應優先恢復遠端服務。若連接埠可連線，但代理請求失敗，則回頭檢查協定、驗證方式與傳輸層記錄。
節點逾時常見問題與重新測試記錄
所有節點都逾時，應該先重新安裝 v2rayN 嗎？
先不用。依序確認直連網路、核心記錄、本機監聽狀態和明確指定代理的請求。若同一來源的所有節點都無法連線，而其他已知可用的設定正常，請聯絡該來源確認服務狀態。重新安裝無法修復遠端服務停機或錯誤的訂閱參數。
TCP 測試顯示有延遲，為什麼網頁還是打不開？
TCP 建立連線成功，不代表後續驗證、TLS 和應用程式請求也正常。使用前面的 curl.exe 指令測試完整請求，再查看同一時間的記錄；若完整請求成功，只需修正系統代理、瀏覽器設定或路由，不要修改遠端連接埠。
啟用 TUN 後才無法上網，該如何恢復？
先關閉 TUN 並清除系統代理，確認直連恢復正常。接著使用一般系統代理測試節點；確認成功後，再單獨啟用 TUN，檢查權限、虛擬網卡、DNS 和路由接管設定。不要同時啟用多套網路接管工具。
同一節點在 Android 可用，桌面版卻逾時？
先讓兩台裝置連上同一個網路，並確認伺服器、連接埠和傳輸欄位相同。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；不同核心對特定設定的支援並不完全相同。桌面版還需要檢查實際選用的核心、本機連接埠和系統時間。
修復後，使用相同目標連續請求 3 次，記錄每次是否收到回應，再恢復日常使用的路由與應用程式設定。單次成功無法排除間歇性故障；持續失敗也不能只靠延長逾時時間解決。測試記錄應保留網路類型、目前使用的節點、核心類型、故障階段和本次變更，但不要記錄認證資料。
- 基本網路：關閉流量接管後能否直連，節點網域能否正常解析。
- 本機入口：實際監聽位址、連接埠與程序是否相符。
- 完整請求：明確指定代理的請求是否收到回應，瀏覽器結果是否一致。
- 遠端證據：服務是否正在監聽，記錄能否對應測試時間。