v2rayN 節點逾時無法連線怎麼排查：依序完成這六步

v2rayN 顯示「逾時」時，問題不一定出在節點伺服器。測速操作、Xray 核心、遠端連接埠、傳輸握手、本機監聽連接埠和系統代理分屬不同層級，其中任何一層中斷，都可能表現為網頁無法開啟或測試結果逾時。反覆切換節點，往往只會掩蓋真正的問題。

更穩妥的做法是依固定順序縮小範圍：先排除本機時間問題，再確認訂閱資料，接著檢查基礎網路與遠端連接埠，然後處理本機連接埠和核心啟動，再核對協定參數，最後確認流量是否確實進入 v2rayN。這個順序先處理成本低、影響範圍大的項目，也能避免系統代理尚未確認前反覆修改節點設定。

第一步：校準本機時間、時區與同步狀態

VMess、TLS、REALITY 等連線流程都涉及時間判斷。系統時間偏差過大時，VMess 請求可能因時間窗口不符而遭拒絕；TLS 憑證也可能被本機判定為尚未生效或已經過期。這類問題通常表現為所有節點同時異常，尤其容易出現在系統從睡眠喚醒、主機板斷電、虛擬機暫停後恢復，或曾手動調整時區的裝置上。

先確認工作列時間是否正確，再進入系統的日期與時間設定，確認時區與所在地一致，並執行一次立即同步。只把時鐘手動調到「看起來差不多」並不可靠；即使分鐘正確，日期、年份或時區錯誤同樣會影響握手。同步完成後，應退出並重新啟動 v2rayN，讓新建立的連線使用校準後的時間。

這個階段可重點觀察以下日誌描述。不同核心版本的文字可能略有差異，但含義相近：

invalid user
authentication failed
certificate has expired
certificate is not yet valid
TLS handshake error
rejected common/drain

invalid user 不只代表 UUID 輸入錯誤。在 VMess 情境中，本機時間偏差也可能導致驗證失敗。若多個原本可用的 VMess 節點在同一時間出現相同錯誤，應優先檢查時間，而不是逐一編輯節點。若日誌明確提示憑證日期範圍異常，還要同時核對系統日期與時區，不要立刻關閉傳輸安全設定。

第二步：確認訂閱有效、更新成功，且目前節點來自最新群組

訂閱網址可以儲存，不代表其中的節點資料仍然有效。常見情況包括訂閱授權到期、更新請求遭拒、訂閱內容為空、伺服器更換連接埠，以及更新後仍選取舊群組中的同名節點。此時 v2rayN 主介面看似仍有伺服器記錄，但記錄本身可能已經失效。

先確認目前選取的訂閱群組，再對目標訂閱執行更新。觀察更新結果是否明確顯示新增、刪除或更新伺服器，不要只看清單是否仍有內容。若更新後伺服器數量、連接埠或節點名稱發生變化，應重新選取該群組內的節點並設為目前伺服器。舊記錄與新記錄名稱相同時，單靠名稱無法判斷目前使用的是哪一筆。

訂閱更新失敗時，日誌或提示區域常見的關鍵字包括：

subscription update failed
unauthorized
forbidden
not found
timeout
empty subscription
failed to parse

unauthorized 或 forbidden 通常表示訂閱授權狀態或網址參數已失效；not found 表示請求路徑可能已變更；failed to parse 則表示回傳內容不是用戶端預期的訂閱資料。若更新操作本身逾時，應先透過目前的直連網路確認訂閱網域是否能解析與存取。不要將完整訂閱網址貼到公開日誌或公開頁面，因為網址中可能包含存取憑證。

如果只有某一個節點逾時，而同一訂閱下的其他節點可以連線，通常表示訂閱已成功匯入，問題更可能出在該節點的遠端連接埠或參數。若整個群組同時失效，則應優先確認訂閱狀態與伺服器端變更通知。手動修改訂閱節點只能用於暫時驗證；下次更新可能覆蓋變更，因此最終參數仍應由訂閱來源保持一致。

第三步：分開檢查網域解析、遠端連接埠與目前網路

節點位址通常是網域或 IP，連線前至少要進行兩項基礎檢查：網域能否解析出位址，以及目標 TCP 或 UDP 連接埠能否從目前網路抵達。延遲測試顯示逾時，只能表示測試鏈路未在限定時間內完成，不能直接證明協定設定錯誤。

如果節點使用網域，可先查詢解析結果。Windows 可使用：

nslookup node.example.net

macOS 或 Linux 同樣可以使用 nslookup；若系統具備相應工具，也可以用 dig 查看記錄。若查不到位址、回傳明顯錯誤，或不同網路下的結果差異很大，應先處理 DNS。請注意，直接在瀏覽器開啟節點網域並不是可靠的測試，因為 VMess、VLESS 等服務連接埠通常不會提供一般網頁。

網域可以解析後，再檢查遠端 TCP 連接埠。Windows PowerShell 可執行：

Test-NetConnection node.example.net -Port 443

macOS 或 Linux 可執行：

nc -vz node.example.net 443

命令中的網域與連接埠應替換為節點的實際值。若 TCP 檢查成功，只能證明遠端連接埠可以建立基礎連線，不能證明 UUID、TLS、WebSocket 路徑或 REALITY 參數正確。若檢查持續逾時，可能是遠端服務未監聽、目前網路限制該連接埠、防火牆丟棄連線，或節點位址解析到無法抵達的位置。

切換網路是一項很有價值的對照測試。例如，同一台裝置、同一個節點、同一份設定，在另一個連線網路下立即恢復，表示用戶端設定本身大致可用。排查重點應轉向原網路的 DNS、連接埠政策、路由路徑或閘道設定。反之，如果在多個網路下都於相同階段失敗，就應繼續檢查本機核心與節點參數。

第四步：檢查本機連接埠占用與 Xray 核心啟動結果

v2rayN 需要在本機監聽 SOCKS、HTTP 或混合代理連接埠。若連接埠已被另一個程序占用，Xray 核心可能啟動失敗，或 v2rayN 介面仍在執行但本機應用程式無法連線代理。常見日誌包括 address already in use、failed to listen、bind 和 permission denied。

先在 v2rayN 設定中查看目前的本機監聽連接埠，再確認是哪個程序占用了該連接埠。以下命令以 10808 為例，實際檢查時應替換為介面中的連接埠。

Windows：

netstat -ano | findstr :10808

macOS：

lsof -nP -iTCP:10808 -sTCP:LISTEN

Linux：

ss -lntp | grep 10808

如果占用程序不是目前由 v2rayN 啟動的核心，應先結束衝突程式，或在 v2rayN 中改用未被占用的本機連接埠。修改連接埠後，還要同步更新手動設定代理位址的瀏覽器、下載工具或終端機環境變數。只修改 v2rayN 連接埠而保留應用程式中的舊連接埠，會造成「核心正常、應用程式仍然逾時」的另一個問題。

若連接埠沒有衝突，但日誌顯示核心設定載入失敗，應確認錯誤發生在啟動階段還是連線階段。啟動階段出現 failed to load config、unknown field、failed to create server，通常表示產生的設定包含目前核心不認得的欄位，或連接埠、檔案權限、路由規則存在問題。此時先還原近期修改過的自訂設定，再重新啟動核心。

也可以觀察本機連接埠是否真的進入監聽狀態。v2rayN 啟動核心後，連接埠檢查應能看到對應程序；停止核心後，該監聽應消失。若介面操作與連接埠狀態不一致，先完整退出 v2rayN，確認殘留核心程序已結束，再重新開啟。不要同時啟動多個 v2rayN 執行個體，否則它們可能爭用相同的連接埠與系統代理設定。

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

遠端連接埠可以連線，但 Xray 日誌在握手階段報錯時，最常見的原因是用戶端參數與伺服器端不一致。節點名稱和伺服器位址相同，不代表其他欄位可以沿用。協定、安全層、傳輸方式和驗證欄位必須視為整體進行核對。

VMess 需要重點檢查伺服器位址、連接埠、使用者 ID、安全設定和傳輸方式。現代 VMess 設定通常使用 AEAD，相關參數應以訂閱提供的資料為準。VLESS 除了位址、連接埠和使用者 ID，還要核對加密欄位、傳輸安全與 flow。使用 XTLS Vision 的設定通常會出現 xtls-rprx-vision，用戶端 flow 必須與伺服器端設定一致，不能因為另一個 VLESS 節點可以連線就直接複製。

傳輸層還包含一組容易遺漏的配對欄位：

• WebSocket：核對路徑、Host、TLS 狀態和伺服器名稱。路徑中的斜線、大小寫與附加查詢內容都可能影響匹配。
• gRPC：核對 serviceName、傳輸安全和伺服器名稱。serviceName 不是一般網頁路徑，不能隨意互換。
• TCP：確認標頭類型及相關欄位與伺服器端一致。一般 TCP 與帶有特定偽裝標頭的設定不是同一組參數。
• TLS：核對 SNI、憑證網域和是否允許不安全憑證。正常部署應使用與憑證相符的伺服器名稱。
• REALITY：核對伺服器名稱、公鑰、shortId、指紋與 flow。任一欄位缺少或複製不完整，都可能導致握手失敗。

核對參數時，建議將目前節點與訂閱原始記錄逐欄比較，而不是靠記憶重新建立。先確認協定，再確認位址與連接埠，接著檢查驗證欄位，最後處理傳輸與安全層。一次只修正一項差異並重新連線，便能判斷具體是哪一項造成失敗。

如果同一台伺服器上有多個不同協定的入口，也不能互換連接埠。某個連接埠對 TCP 測試有回應，只表示該處有服務，不代表它正在接收目前選擇的 VMess 或 VLESS 設定。將 VLESS 參數傳送到 VMess 入口，或將 WebSocket 設定傳送到一般 TCP 入口，通常都會在握手階段遭到中斷。

第六步：確認系統代理、路由模式與應用程式流量已進入 v2rayN

前五步確認的是「核心能否連線節點」。最後一步確認的是「應用程式是否將流量交給核心」。節點延遲測試成功但瀏覽器仍無法開啟網頁時，通常應優先檢查系統代理、應用程式代理設定和路由規則，而不是繼續更換節點。

使用系統代理模式時，確認 v2rayN 已執行設定系統代理的操作，並檢查系統代理位址是否指向本機回環位址及目前的監聽連接埠。若先前修改過連接埠，系統設定中可能仍保留舊值。重新設定一次系統代理後，關閉並重新開啟目標應用程式，避免應用程式繼續使用啟動時讀取的舊代理設定。

部分程式遵循系統代理，部分程式使用自身的網路設定，還有一些命令列工具需要個別設定 HTTP 或 SOCKS 代理。判斷方式是進行對照：先用明確遵循系統代理的瀏覽器測試，再查看目標程式的代理設定。若瀏覽器可用而單一程式逾時，節點與 v2rayN 核心通常已正常運作，問題在於該程式的代理設定。

使用 TUN 模式時，應確認 TUN 已成功啟動，並查看日誌中是否有建立介面、寫入路由或權限相關錯誤。permission denied、failed to create interface、operation not permitted 通常表示虛擬介面或路由尚未建立。此時即使節點設定正確，流量也不會依預期進入核心。修復權限與介面啟動問題後，再檢查 DNS 是否由目前的 TUN 設定接管。

路由分流也會造成「某些網站逾時、另一些正常」的現象。v2rayN 將請求交給 Xray 後，Xray 會依照由上到下的規則選擇直連、代理或阻斷出口。若目標網域提前符合直連規則，而目前網路無法直連該目標，就會表現為特定網站逾時；若符合阻斷規則，則會直接失敗。排查時可以暫時切換到較簡單的全域代理進行測試，以判斷問題來自節點還是路由規則。確認原因後應恢復原模式並修正規則順序，不要長期依賴測試模式。

DNS 同樣會受到路由模式影響。網域解析得到無法抵達的位址、DNS 請求未進入預期出口，或應用程式啟用了獨立的安全 DNS，都可能讓連線繞過既定路徑。若日誌完全看不到目標網域對應的請求，表示流量可能尚未進入 v2rayN；若能看到請求但最終使用 direct 或 block 出口，則應檢查分流規則；若明確進入代理出口後才逾時，則回到第三步與第五步，繼續核對遠端路徑與握手參數。

最後一次完整複測

1. 關閉正在進行網路請求的應用程式，排除舊連線對結果的干擾。
2. 重新啟動 v2rayN，確認核心啟動成功且本機連接埠處於監聽狀態。
3. 選取已核對參數的節點，執行一次延遲測試並查看對應日誌。
4. 重新設定系統代理，或確認 TUN 介面與路由已建立。
5. 開啟目標應用程式，只發出一個測試請求，觀察日誌是否出現該網域或目標位址。
6. 根據日誌中的出口、錯誤階段與耗時，判斷故障位於應用程式、本機代理、路由或遠端節點。

完成六步後，問題通常會歸入幾個明確結論：所有節點因本機時間或本機連接埠異常而同時失效；某個訂閱群組已經到期；目前網路無法抵達遠端連接埠；單一節點的協定參數不匹配；或節點連線正常，但應用程式未經由系統代理與路由。此時採取對應措施，比無序重裝或大量修改節點更容易保留有效設定。