適用於 v2rayNG 已匯入節點，卻遇到連線逾時、實際連線測試失敗或瀏覽器無法連線的情況。先保留原有設定，用同一節點比較不同網路，再檢查時間、訂閱、傳輸與憑證，最後確認伺服器監聽狀態與日誌。每次只調整一項，避免把連接埠無法連線、驗證失敗和 DNS 問題混為一談。
一、先判斷逾時發生在哪個階段
v2rayNG 是 Android 用戶端，本文依使用 Xray 核心的設定進行排查。介面上的連線圖示表示本機服務已啟動，不代表遠端節點已完成握手。節點清單中的 TCP 測試、實際連線測試和瀏覽器連線，驗證的層級各不相同，不能互相取代。
先在主畫面選取目標節點並啟動服務，再從選單開啟「日誌」，重現一次失敗並記下時間。選單名稱可能因版本而異；測試入口通常位於主畫面選單。保存錯誤訊息時，請保留前後幾行，但遮蔽訂閱網址、使用者識別資訊和密碼。
| 觀察結果 | 代表的情況 | 下一步 |
|---|---|---|
| TCP 測試失敗 | 目標位址與 TCP 連接埠目前無法連線；不適用於判斷純 UDP 傳輸 | 檢查網路、網域解析與連接埠 |
| TCP 成功，實際連線失敗 | 連接埠有回應，但代理握手或測試請求未完成 | 核對協定、TLS 與傳輸欄位 |
| 實際連線成功，特定應用程式失敗 | 測試目標可連線，不代表所有應用程式都會經過代理 | 檢查個別應用程式代理、路由與應用程式本身的設定 |
| 訂閱更新失敗 | 取得訂閱內容的請求失敗 | 單獨排查訂閱網址，不要直接判定節點已失效 |
二、本機網路：用同一節點比較 Wi-Fi 與行動網路
先停止 v2rayNG，確認瀏覽器能連線至平時可直接存取的網站。公共 Wi-Fi 可能需要先登入系統跳出的驗證頁面；未完成驗證時，通常也無法建立代理連線。接著保持節點與設定不變，分別使用 Wi-Fi 和行動網路啟動服務測試。
- 只有 Wi-Fi 連線失敗：檢查路由器的網路狀態、驗證頁面與該網路的 DNS。若行動網路正常，暫時不要修改節點的 UUID、密碼或傳輸路徑。
- 兩種網路都連線失敗：換用另一個已知可用的節點進行比較。若所有節點都同時失敗，優先檢查本機 VPN 狀態、時間和 DNS；若只有一個節點失敗，繼續核對該節點設定。
- 啟動後立即停止：檢查 Android 的 VPN 授權提示，並停止其他占用系統 VPN 連線的服務。啟動失敗與遠端連線逾時是兩種不同問題。
- 只有鎖定螢幕後才中斷：在系統「設定」→「應用程式」→「v2rayNG」→電池相關選項中允許背景執行。各廠牌的設定路徑不盡相同，請以實際介面為準。
也請檢查系統「設定」→「網路和網際網路」→「VPN」中的「一律開啟 VPN」及「封鎖未使用 VPN 的連線」選項。若殘留舊 VPN 設定，連用來比對的直接連線請求也可能遭到封鎖。測試結束後請還原原本的安全設定，不要為了排查而長期關閉必要防護。
三、系統時間與訂閱：先排除過期設定
在 Android「設定」→「系統」→「日期與時間」中啟用自動設定時間與時區；部分裝置會將此選項放在「更多設定」。確認日期與時間正確後，停止並重新啟動 v2rayNG。時間有誤可能影響憑證效期判定，也可能造成 VMess 驗證失敗。
訂閱連結能開啟，不代表節點仍然有效。登入訂閱服務提供者的管理頁面，確認效期、流量額度和節點異動公告。在 v2rayNG「訂閱群組設定」中確認來源網址，再返回主畫面更新訂閱；不同版本的指令可能顯示為「更新訂閱」或「更新目前群組訂閱」。
- 更新前先保留原有設定紀錄，更新後重新選取節點，避免繼續測試已被取代的舊項目。
- 如果必須透過代理才能存取訂閱網址，請改用另一個確實可用的節點更新；用故障節點更新同一個來源，容易陷入循環。
- 檢查匯入結果是否包含伺服器位址、連接埠、協定與驗證欄位。若連結開啟後顯示登入頁面或錯誤頁面，就不是有效的訂閱內容。
- 不要把完整訂閱網址交給不熟悉的線上轉換網站。網址通常包含存取憑證，排查時也應視同憑證妥善保管。
四、傳輸參數：分別核對位址、連接埠、Host 與路徑
在節點清單中點選目標項目的編輯圖示，逐項比對伺服器或服務提供者給出的原始參數。不要只因節點名稱標示某種傳輸方式，就認定編輯頁面的設定一定相符。伺服器位址決定連線目標；連接埠決定要連到哪個入口；傳輸類型則決定後續如何建立通道。
以上是協定連接埠的基本知識，不代表建議設定。節點原本使用其他連接埠時，不能只把用戶端改成 443；伺服器監聽、防火牆與轉送入口都必須相互配合。DNS 能解析出位址，也不代表節點連接埠可連線。
- WebSocket：核對傳輸類型、Host 與路徑。路徑的大小寫、開頭斜線及查詢參數都必須符合伺服器要求。反向代理轉送設定錯誤也會造成握手失敗。
- gRPC：核對服務名稱與服務提供者要求的相關選項，不要把 WebSocket 路徑直接填入服務名稱欄位。
- 協定驗證：VMess、VLESS 的使用者識別資訊，以及 Trojan、Shadowsocks 的密碼，都必須與伺服器端設定相符。更換傳輸方式無法修正錯誤的憑證。
- 網域解析：若日誌顯示節點網域解析失敗，先檢查本機的解析流程。暫時以伺服器確認過的 IP 進行比對時，仍須保留正確的 TLS 伺服器名稱。
結論：TCP 可連線後，再檢查握手參數
若同一位址與連接埠在兩種網路下都無法建立 TCP 連線，先檢查監聽狀態與網路路徑；若 TCP 已連線但代理請求失敗，再逐項核對驗證、傳輸與 TLS。不要同時更換 DNS、連接埠和路徑。
五、TLS 與日誌：依錯誤訊息判斷連線階段
TLS 伺服器名稱通常用於 SNI 與憑證名稱驗證，不等同於 WebSocket 的 Host，也不一定與實際連線的位址相同。三者可能一致，但不能只因名稱相似就互相替換。使用 REALITY 的節點還須核對伺服器提供的公鑰、short ID 與伺服器名稱，不要像一般 TLS 節點一樣任意修改。
錯誤訊息：i/o timeout
原因與處理方式：某個網路讀寫步驟超過等待時間；單看這一行無法判斷故障層級。請查看前文中的目標位址與操作階段，再比較不同網路和伺服器同期的日誌。
錯誤訊息：connection refused
原因與處理方式：目標主機或中間設備主動拒絕連線；請核對連接埠、確認伺服器程序正在監聽，並檢查是否有主動拒絕連線的規則。
錯誤訊息：no such host
原因與處理方式：網域解析未取得可用結果；確認錯誤訊息中的對象是節點網域還是存取目標，再檢查拼字、DNS 設定與該網域的解析紀錄。
錯誤訊息：x509: certificate has expired or is not yet valid
原因與處理方式：憑證效期與目前時間不符；先校正手機時間。若問題仍未解決，請伺服器管理員檢查憑證是否已續期，以及實際載入的憑證。
錯誤訊息：websocket: bad handshake
原因與處理方式：伺服器未傳回預期的 WebSocket 升級回應；請核對路徑、Host 與反向代理轉送規則，並依回應狀態碼進一步排查。
六、伺服器端：確認監聽狀態、允許規則與轉送路徑
使用他人提供的節點時，請將故障時間、網路類型、用戶端版本及已隱去敏感資訊的錯誤訊息提供給維護人員。若自行維護伺服器，先確認服務正在執行，再檢查系統防火牆、雲端安全性群組、容器連接埠對應與反向代理。用戶端逾時不一定會留下伺服器應用程式日誌：流量尚未到達程序時，應用程式自然不會有紀錄。
以下是 Linux 伺服器端的唯讀排查指令。先列出實際服務單元；只有確認部署使用名為 xray 的 systemd 服務時，才執行後兩個指令。若部署使用容器或其他服務名稱，請檢查對應的程序與容器日誌。
ss -lntp
ss -lnup
systemctl list-units --type=service --all
systemctl status xray --no-pager
journalctl -u xray --since "10 minutes ago" --no-pager- 核對實際監聽的連接埠與位址。後端只監聽
127.0.0.1，並由同一台主機上的反向代理接入，可能是正常部署方式；若用戶端要直接連到該後端，就需要設定相符的對外入口。 - 逐層檢查雲端安全性群組與主機防火牆。允許規則必須符合實際協定與目標連接埠，不能只看規則名稱。
- 檢查網域的 A 與 AAAA 紀錄。若解析結果指向舊位址，或 IPv6 入口尚未設定妥當，應修正對應紀錄或網路設定，不要反覆重新安裝用戶端。
- 用手機發起一次測試，同時查看入口與後端日誌。入口收到請求、後端卻沒有請求時，應優先檢查反向代理；後端收到請求但驗證失敗時，請核對使用者憑證。
七、常見問題與排查收尾
延遲數值正常，為什麼網頁還是打不開？
先確認數值來自 TCP 測試還是實際連線測試。TCP 測試只能證明連接埠有回應；實際連線測試也只會驗證指定的測試目標。啟動服務後查看瀏覽器請求日誌，再檢查個別應用程式代理是否排除了瀏覽器，以及路由是否將目標送往預期的輸出端。
訂閱更新一直逾時，需要刪除所有節點嗎？
先保留現有設定，檢查訂閱網址與效期。如果無法直接取得訂閱內容，請改用另一個可用節點嘗試更新；如果服務提供者已更換網址，只要修改對應群組即可。清除節點無法解決訂閱伺服器無法連線的問題。
同一個節點在電腦上能用，手機卻不能用？
先讓兩台裝置連上同一個網路，再比對 v2rayN 與 v2rayNG 中的伺服器位址、連接埠、傳輸、SNI 與驗證欄位。確認兩邊測試的是同一份設定，而不是名稱相同的舊節點，並記下各自的核心版本。欄位相容性問題應依具體錯誤訊息處理。
把連線逾時時間調長，就能恢復連線嗎？
只有在連線確實能完成握手、但耗時較長時，增加等待時間才可能有幫助。對端未監聽、憑證錯誤或憑證不符，都不會因此恢復。先查看日誌確認失敗階段，不要把延長等待時間誤當成修復。
最後保留一份排查紀錄：用戶端與核心版本、測試時間、網路類型、節點是否已更新、首次錯誤訊息，以及每次調整的項目。還原無效的變更後再測試。提供這些資訊給維護人員，能協助定位問題，也能避免下次故障時從頭猜起。基本連線與路由概念可繼續參閱疑難排解和進階設定。