這套檢查順序適合已在 v2rayN、v2rayNG 與 v2flyNG 匯入節點，但延遲測試顯示逾時、啟動後網頁無法開啟，或日誌持續出現連線錯誤的情況。排查時先確認本地網路，再核對時間、訂閱、協定參數與伺服器狀態；每完成一層就重新測試一次，可以更快判斷問題出在哪個環節。
第一類：先確認本地網路與代理入口
「節點逾時」只表示用戶端未在規定時間內取得預期回應，不能直接證明節點已失效。請求從瀏覽器傳到遠端伺服器，中間還會經過系統代理、本地監聽埠、V2Ray 或 Xray 核心、DNS、路由器與目前網路。任何一段未連通，都可能在用戶端呈現逾時。
第一步先完全退出用戶端，再用瀏覽器開啟兩個平時可直接存取的網站。如果一般網站也無法開啟，應先恢復本地網路，例如重新連線路由器、切換至另一條可用網路，或確認是否需要登入驗證的公共網路頁面。此時反覆更新訂閱不會改變結果，因為訂閱請求本身也需要可用的基礎網路。
基礎網路正常後啟動用戶端，但暫時不要只看系統匣圖示。以 v2rayN 7.x 為例，應觀察主視窗底部或日誌區域是否顯示核心已啟動，並檢查目前選取的伺服器。常見的本地監聽埠是 SOCKS 的 10808 和 HTTP 的 10809，不同版本與個人設定可能有所不同，應以「設定」→「參數設定」中顯示的埠號為準。埠號被其他程式占用時，核心可能啟動失敗，但系統代理仍可能指向舊埠。
關閉舊進程
退出 v2rayN 後開啟工作管理工具，確認先前的 V2Ray 或 Xray 核心進程已結束，再重新啟動用戶端，避免舊進程持續占用本地埠。
核對監聽埠
進入「設定」→「參數設定」，記下本地 SOCKS、HTTP 或混合代理埠號；再檢查瀏覽器或其他應用程式填寫的埠號是否與用戶端一致。
重設系統代理
先選擇清除系統代理，再重新啟用系統代理。這個動作可以修正用戶端異常退出後遺留的舊位址與舊埠。
切換本地網路
在條件允許時切換至另一條網路測試同一節點。若原網路連續三次逾時，而另一條網路能在 1 至 3 秒內完成連線，問題更可能出在原網路或路由設備。
第二類：校準系統時間與時區
VMess 的驗證流程依賴時間，裝置時鐘偏差過大時可能直接驗證失敗。使用 TLS 的 VMess、VLESS 或其他設定也會檢查憑證有效時間。裝置日期、時區或自動校時異常，既可能導致節點連線失敗，也可能讓訂閱頁面出現憑證時間錯誤。
即使時間看起來只差一分鐘，也值得處理。日常建議讓裝置自動取得時間與時區，不要只手動修改畫面上顯示的小時數。尤其在更換時區、系統長時間休眠、主機板時鐘異常或路由器阻擋時間同步後，顯示時間可能與實際標準時間不一致。
Windows
開啟「設定」→「時間與語言」→「日期與時間」，啟用自動設定時間與自動設定時區，然後按一下立即同步。完成後退出並重新啟動 v2rayN。
macOS
開啟「系統設定」→「一般」→「日期與時間」，啟用自動設定日期與時間，並確認目前時區與所在地一致。
Android
開啟系統「設定」中的日期與時間選項，啟用自動設定時間與自動設定時區，然後完全停止並重新開啟 v2rayNG 或 v2flyNG。
校時後應重新啟動用戶端核心，而不是只再次執行延遲測試。已建立的失敗連線、DNS 快取與舊工作階段可能仍留在進程中。若校時前所有節點都失敗，校時後多個不同地區的節點同時恢復，通常可以確認根因在裝置時間，而非訂閱中的某一台伺服器。
錯誤：x509: certificate has expired or is not yet valid
原因與解法：TLS 憑證可能確實已過期，也可能是裝置日期偏離實際時間。先同步系統時間與時區；若只有一個節點持續報錯，再請服務端維護方檢查憑證。
錯誤：invalid user
原因與解法：驗證資訊未被服務端接受，VMess 情境應先校準時間，再核對 UUID、alterId 與訂閱內容是否完整，避免直接修改多個參數而失去排查線索。
結論：全部節點同時失敗，先檢查裝置共通條件
同一台裝置上的多個獨立節點在同一時間全部逾時，應優先檢查網路、系統時間、本地埠與核心狀態；單一遠端伺服器同時故障無法解釋這種一致現象。
第三類：檢查訂閱是否有效且確實更新
訂閱網址能加入用戶端，不代表其中的節點會一直有效。訂閱可能已到期、流量額度用完、存取憑證變更，也可能已產生新節點，但用戶端仍在使用上次快取的清單。更新訂閱與測試節點是兩個動作：前者取得設定，後者才會嘗試連線設定中的伺服器。
在 v2rayN 中，可從「訂閱群組」選擇對應群組，再執行更新全部訂閱。若目前代理已無法使用，優先嘗試「不透過代理」更新，避免用戶端使用失效節點請求新的訂閱內容。更新完成後查看節點數量、伺服器位址與更新時間是否變化，不要只看到「更新完成」四個字就結束檢查。
確認訂閱可存取
在基礎網路正常的前提下重新更新訂閱，觀察用戶端提示的是成功、HTTP 錯誤、解析失敗還是連線逾時。不同結果對應的處理方向並不相同。
查看群組內容
確認更新的是目前正在使用的訂閱群組。多個群組並存時，舊節點可能仍保留在清單中，名稱相似也容易選錯。
重新選擇節點
更新後從新清單中選擇伺服器，並明確設為使用中的伺服器。只更新清單不代表目前使用項目已自動切換至新設定。
測試三個節點
選擇不同位址或不同地區的三個節點，各測試兩次。只有一個失敗通常是單一節點問題；三個都在接近的時間逾時，則繼續檢查參數或服務狀態。
錯誤：unexpected EOF
原因與解法：訂閱回應或遠端連線在完成前被關閉。先重新取得訂閱；若更新成功但連線時仍出現此錯誤，再檢查傳輸層參數與服務端狀態。
錯誤：failed to parse config
原因與解法：匯入內容不符合目前用戶端或核心預期的設定格式。刪除剛匯入的異常副本，重新更新訂閱，並確認沒有把網頁網址、說明文字或截斷內容當成節點設定。
錯誤：failed to find an available destination
原因與解法：出站目標未能建立可用連線，常見線索包括伺服器網域解析失敗或路由沒有可用出站。檢查節點位址拼寫、DNS 設定與使用中的出站後重新啟動核心。
第四類：逐項核對協定、傳輸與 TLS 參數
節點位址與埠號可連通，不代表協定參數正確。VMess、VLESS 的身分欄位不同，TCP、WebSocket、gRPC 等傳輸方式也不能互相替代。只要 UUID、埠號、傳輸類型、路徑、服務名稱、TLS 開關或伺服器名稱有一項不匹配，連線就可能逾時、立即被關閉，或在交握階段失敗。
排查時不要憑經驗把埠號統一改成 443，也不要看到 WebSocket 就隨意填寫路徑。埠號 443 常用於 TLS，但服務端完全可以監聽其他埠號；WebSocket 的 Host 與 Path、gRPC 的 serviceName 都必須與服務端設定一致。從訂閱匯入的設定通常應保持原樣，只有取得明確參數後才逐項修正。
| 檢查項目 | VMess | VLESS | 常見錯誤表現 |
|---|---|---|---|
| 使用者識別碼 | UUID，現代設定的 alterId 通常為 0 | UUID，部分設定還包含 flow | 驗證失敗、連線後立即關閉 |
| 傳輸方式 | 需符合 TCP、WebSocket 或其他既定方式 | 需符合 TCP、WebSocket、gRPC 等既定方式 | 交握逾時、unexpected EOF |
| TLS 參數 | 核對 TLS 開關與伺服器名稱 | 核對 TLS、伺服器名稱及訂閱提供的安全參數 | TLS handshake timeout、憑證名稱錯誤 |
| 附加欄位 | WebSocket 通常需要核對 Host 與 Path | gRPC 通常需要核對 serviceName | 伺服器回傳拒絕或持續等待 |
還要確認用戶端使用的核心能夠處理該設定。v2rayN 可在「設定」→「參數設定」→「Core 類型」查看或調整所用核心；具體選單文字會隨版本略有不同。包含 VLESS 特定功能的設定通常應交由相容的 Xray 核心處理。在 Android 上，v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，不能假設兩者支援的所有設定欄位完全相同。
如果設定來自訂閱，最穩妥的比對方式是保留原節點，再複製一份用於單項修改。每次只修改一個欄位並重新啟動核心。例如先核對埠號，再核對傳輸類型，接著檢查 TLS 與伺服器名稱。一次同時修改 UUID、路徑、埠號與 TLS，即使恢復連線，也無法知道真正的錯誤在哪裡。
錯誤：TLS handshake timeout
原因與解法：TCP 可能已連通，但 TLS 交握未在時限內完成。核對伺服器名稱、TLS 開關、埠號與系統時間，再切換網路以排除連線路徑干擾。
錯誤：dial tcp: i/o timeout
原因與解法：用戶端建立 TCP 連線時未及時收到回應。檢查伺服器位址、埠號、本地網路與防火牆；若只有該位址失敗，再判斷遠端埠號是否已停止監聽。
錯誤：connection refused
原因與解法：目標主機明確拒絕連線，通常表示位址可達但該埠號沒有對應服務，或入口規則主動拒絕。核對埠號後聯絡服務維護方確認監聽狀態。
結論：逾時與拒絕連線要分開處理
i/o timeout 比較像請求未及時得到回應，而 connection refused 表示目標明確拒絕。前者先檢查網路路徑與位址，後者優先核對埠號及服務端監聽狀態。
第五類：用交叉測試判斷服務端狀態
完成前四層後，如果基礎網路正常、時間準確、訂閱剛更新且參數一致，就需要判斷遠端伺服器是否正在維護、埠號是否停止監聽，或線路是否只對某一網路無法連線。此時不應繼續隨機修改用戶端設定，而應建立可比較的測試結果。
最有價值的比對包含三個維度：同一台裝置更換節點、同一節點更換網路、同一訂閱更換裝置。一次只改變一個條件。例如同一台 Windows 裝置上，節點 A 連續三次逾時超過 10 秒，而同群組的節點 B 與 C 都能在 2 秒內開啟網頁，證據更偏向節點 A；若 A、B、C 在目前網路都失敗，換網路後全部恢復，則更偏向原本的網路路徑。
- 只有一個節點失敗：保留日誌中的時間、伺服器位址與錯誤類型，等待服務端恢復或使用同一訂閱中的其他節點。
- 同一地區節點集中失敗：可能是該組入口或線路異常，先切換不同位址測試，不要反覆重新安裝用戶端。
- 所有節點只在一條網路失敗：檢查路由器、DNS、網路存取限制與防火牆策略，並使用另一條網路重新測試。
- 所有裝置都無法使用同一訂閱：確認訂閱有效期、流量狀態與服務通知，避免繼續修改每台裝置的本地埠號。
- 只有一台裝置失敗：回頭檢查本地監聽、系統代理、時間與核心設定，重點比較它與正常裝置的差異。
查看日誌時，應關注第一次失敗，而不是只看後面重複出現的連鎖錯誤。v2rayN 的執行資訊通常會記錄目標位址、連線階段與核心回傳內容；v2rayNG 與 v2flyNG 也可以在日誌區域查看最近的連線結果。先清除或記住目前的日誌位置，再發起一次存取，可以減少舊紀錄干擾。
錯誤：context deadline exceeded
原因與解法：某個操作超過核心或用戶端設定的等待期限，單憑這一行無法確定根因。向上查看同一次請求較早出現的 DNS、TCP 或 TLS 錯誤，再依對應階段處理。
錯誤：context canceled
原因與解法：連線工作被上層取消，常見於切換節點、重新啟動核心或前序連線失敗後的清理流程。若它緊接在更具體的錯誤後面，應以前面的錯誤作為主要線索。
錯誤：network is unreachable
原因與解法：系統目前沒有通往目標網路的可用路徑。檢查裝置是否連網、路由器是否正常、網路介面是否切換，並確認沒有殘留的代理或虛擬網路設定影響路由。
整套順序可以概括為：先確認裝置能正常連網，再讓系統時間可靠；接著確認訂閱確實更新，核對節點協定參數；最後才透過多節點、多網路與多裝置的比對判斷服務端。這樣做的價值不是增加操作步驟，而是避免在本地網路故障時重建訂閱，也避免在遠端維護時反覆修改正確的用戶端設定。