節點逾時無法連線的排查順序：訂閱、時間、連接埠與協定參數逐項檢查

節點顯示逾時，不代表協定本身失效。同樣是紅色的延遲結果，可能源於訂閱仍保留舊位址、系統時間誤差、網域解析失敗、本機監聽連接埠衝突，也可能是傳輸層參數與伺服器不一致。直接反覆切換節點，會把這些原因混在一起，日誌也會被大量重複請求覆蓋。

更穩定的做法是固定排查順序，每輪只變更一個變數，並記錄用戶端版本、測試時間、網路類型與核心日誌。本文適用於桌面版 v2rayN，以及 Android 上使用 Xray 核心的 v2rayNG、使用 v2fly 核心的 v2flyNG。選單名稱可能隨小版本調整，但訂閱、時間、連接埠、網路與協定五個層面的判斷仍然一致。

先確認逾時發生在哪個環節

一次代理連線至少會經過應用程式、本機代理監聽、路由規則、遠端網路連線與協定握手。瀏覽器只顯示「連線逾時」，無法說明是哪個環節失敗。應先開啟用戶端日誌，再發起一次可重現的請求。例如關閉其他下載工作，只造訪一個固定網頁，並保留請求前後 30 秒的日誌。

延遲測試也要區分類型。TCP 探測只能表示遠端位址與連接埠能否建立連線，不代表 VLESS 或 VMess 握手成功；實際延遲會經過完整代理鏈，更接近真實使用情況。若 TCP 延遲為 86 ms，而實際延遲持續顯示逾時，應優先檢查協定、安全層與傳輸參數，而不是先修改本機 DNS。

第一步：更新訂閱並確認節點仍有效

訂閱是節點參數的來源。伺服器更換網域、入口連接埠、UUID、傳輸路徑或安全層後，本機的舊節點可能仍留在清單中，但連線會持續逾時。排查時不要只看節點名稱是否相同，還應查看訂閱最後更新時間，並確認更新後的節點數量、位址與連接埠是否有所變化。

在 v2rayN 中先進入「訂閱群組」→「訂閱群組設定」，確認訂閱位址完整且群組已啟用；返回主介面後選擇「訂閱群組」→「更新全部訂閱（不透過代理）」。如果目前網路無法直接取得訂閱，再連線至一個已確認可用的節點，改用「更新全部訂閱（透過代理）」。兩種方式擇一完成測試，避免連續操作覆蓋錯誤現場。

1. 記錄舊狀態

   記下節點數量、訂閱更新時間與目前選取的節點。例如記錄為 24 個節點、最後更新時間為 2026-05-27 21:10，方便判斷更新是否確實完成。

2. 更新訂閱

   開啟「訂閱群組」→「更新全部訂閱（不透過代理）」。等待完成提示，不要在更新過程中結束用戶端或切換網路。

3. 檢查變化

   比較更新前後的位址、連接埠與節點總數。若數量由 24 變為 21，先使用新清單，不要從舊備份還原已移除的節點。

4. 單一節點重新測試

   選取一個新節點，重新啟動核心後測試三次。每次間隔 5 秒；若三次都逾時，再繼續檢查時間與網路，不要批次修改協定。

第二步：校準系統時間並檢查網域解析

VMess 的驗證依賴時間視窗，TLS 憑證驗證也依賴系統日期。裝置時間誤差數分鐘時，一般網頁可能仍能開啟，但代理握手會失敗。先開啟系統自動設定日期、時間與時區，再立即觸發一次同步。建議將誤差控制在 30 秒內；超過 90 秒就應先校正時間，不要繼續調整節點參數。

時間準確後再檢查 DNS。若節點位址是網域，本機必須先將其解析為可連線的 IP。可在終端機執行系統內建的查詢指令，觀察是否回傳位址及回應耗時。連續三次查詢都超過 2000 ms，或交替出現解析失敗，表示問題發生在協定握手之前。

• 確認系統日期、時區與日光節約時間規則符合所在地設定，不能只查看工作列上的小時與分鐘。
• 電腦暫停後恢復時應重新同步時間；長時間休眠後，時間服務可能尚未完成校準。
• 更換網路後重新解析節點網域，避免繼續使用已失效的本機快取結果。
• 若訂閱位址可以開啟，但節點網域無法解析，請分別記錄兩個網域的查詢結果，不要將它們視為同一項故障。

nslookup node.example.net

預期觀察：
Address: 203.0.113.20
首次回應：42 ms
連續查詢：皆回傳同一組有效位址

第三步：檢查本機連接埠、核心狀態與防火牆

節點參數正確，也必須先由本機核心成功監聽代理連接埠。v2rayN 常見設定會使用 SOCKS 連接埠 10808，並從該連接埠衍生 HTTP 連接埠 10809；實際數值應以「設定」→「參數設定」中的本機監聽設定為準。如果瀏覽器填寫 10809，而用戶端已改成 20809，請求就不會進入目前的核心。

連接埠衝突通常發生在舊核心尚未結束、另一個用戶端仍在執行，或系統從休眠恢復後留下殘留程序。關閉 v2rayN 視窗不一定代表背景程序已結束，應從系統匣執行結束，再重新啟動。排查期間只保留一個用戶端與一個核心執行個體，避免多個程式同時修改系統代理設定。

1. 確認核心正在執行

   查看主介面底部狀態與日誌。啟動後應出現監聽成功訊息；若日誌在一秒內結束，先處理核心啟動錯誤。

2. 核對監聽連接埠

   進入「設定」→「參數設定」，記錄 SOCKS 連接埠 10808 與 HTTP 連接埠 10809。瀏覽器或其他應用程式必須填寫相應類型的連接埠。

3. 釋放衝突連接埠

   完全結束其他代理用戶端與殘留核心，再重新啟動 v2rayN。若 10808 仍被占用，可改為 20808，並同步調整 HTTP 連接埠與應用程式設定。

4. 檢查防火牆

   確認目前核心程式允許在正在使用的網路類型下通訊。測試完成後恢復原有安全策略，不要長期放寬無關程式的入站權限。

正常監聽範例：
SOCKS listening on 127.0.0.1:10808
HTTP listening on 127.0.0.1:10809

衝突範例：
failed to listen TCP on 127.0.0.1:10808
bind: address already in use

第四步：使用另一個網路區分線路與節點故障

訂閱、時間與本機連接埠都正常後，應在不修改節點參數的前提下切換網路。可以將家用寬頻與行動熱點作為兩組對照：同一節點、同一用戶端、同一測試位址，各執行三次實際延遲測試。只變更網路入口，才能判斷問題是否集中在目前線路。

例如家用網路三次結果都逾時，行動熱點則分別為 118 ms、126 ms、121 ms，表示節點設定至少可以完成握手，排查重點應轉向家用網路的 DNS、路由或防火牆。如果兩種網路都在約 10 秒後逾時，則更可能是遠端連接埠無法連線或協定參數不一致。

第五步：逐項核對協定與傳輸參數

只有前四個層面都通過後，才需要進入節點編輯介面。先確認協定類型是 VLESS 還是 VMess，再逐項比對伺服器提供的參數。UUID 是驗證識別碼，不應憑經驗改寫；連接埠必須與入口監聽一致；TCP、WebSocket、gRPC 等傳輸方式不能互換。TLS、REALITY 等安全層也必須與伺服器設定相符。

WebSocket 情境要檢查 Host 與路徑，路徑中的斜線和大小寫都可能影響路由。gRPC 要核對服務名稱。TLS 情境通常還要檢查伺服器名稱，也就是 SNI；連線位址可以是 IP，但憑證驗證使用的名稱仍需符合伺服器要求。REALITY 設定則要核對伺服器名稱、公鑰與短 ID，不能直接套用一般 TLS 欄位。

不同用戶端上的重新測試要點

桌面版 v2rayN 適合直接查看核心啟動、監聽與出站日誌。排查前可在「說明」→「關於」記錄用戶端版本，並在日誌開頭記錄核心版本，例如用戶端 7.x 與 Xray-core 25.x。版本號不是故障結論，但有助於判斷同一設定是否能在不同核心環境中重現。

Android 上的 v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。將同一份訂閱分別匯入兩個不同核心的用戶端，只適合確認設定相容性，不應在同一輪測試中同時修改傳輸參數。切換行動網路與無線網路後，要重新執行連線測試，因為系統分配的 DNS 與出口路徑可能已經改變。

完成修復後的驗證順序

找到原因後不要只驗證一次。先重新啟動核心，確認本機連接埠監聽成功；再執行三次實際延遲測試；接著開啟一般網頁與需要代理的目標位址；最後等待 10 分鐘再測試一次。短時間內偶然成功，可能只是 DNS 快取或線路切換尚未穩定。

建議將最終結果記錄為「用戶端與核心版本、網路類型、節點協定、修復項目、三次延遲」。例如：v2rayN 7.x、Xray-core 25.x、家用寬頻、VLESS over WebSocket with TLS、修正 SNI，三次結果為 92 ms、95 ms、91 ms。這類記錄比「重新安裝後就好了」更適合下次沿用。

1. 重新啟動核心

   確認日誌中 10808 與 10809 都已成功監聽，且啟動後沒有連接埠衝突或設定解析錯誤。

2. 執行三次測試

   每次間隔 5 秒。三次實際延遲的差值若低於 50 ms，表示目前連線狀態相對穩定。

3. 驗證應用程式流量

   檢查瀏覽器、系統代理與個別設定的應用程式，確認它們使用的代理類型與連接埠和用戶端一致。

4. 保留有效記錄

   儲存錯誤時間、關鍵日誌與修復項目，不要將已失效的訂閱參數儲存為長期設定。