本文適合已匯入節點，但遇到無法連線、網頁無法開啟或偶發斷線的使用者。重點不是逐字翻譯整份日誌，而是先記下故障時間，再從入站監聽、路由比對與遠端出站三個階段找出第一筆異常，最後透過單一變數測試確認原因。
先找到真正有用的執行日誌
v2rayN、v2rayNG 與 v2flyNG 都會顯示用戶端狀態，但介面通知不等於核心執行日誌。像是「啟動成功」、「測試完成」等提示，只能表示操作已執行；要判斷請求卡在哪個步驟，應查看包含時間、日誌層級、連線目標與錯誤鏈的核心輸出。
以 v2rayN 7.x 為例，可以先查看主介面的「資訊」區域；需要調整記錄範圍時，進入「設定」→「參數設定」，尋找核心日誌等級相關選項。v2rayNG 1.10.x 可從側邊選單進入「日誌」，日誌等級通常位於「設定」中的進階選項。不同小版本的名稱可能略有差異，但應選擇核心日誌，而不是只查看訂閱更新提示。
記錄日誌前先進行一次乾淨重現
- 停止正在進行的下載、測速與背景同步，減少無關連線。
- 清空目前的日誌，或記住開始測試時的精確時間。
- 啟動目標節點，等待核心狀態穩定後，再開啟一個明確的網址或應用程式功能。
- 在 30 秒內重現問題並立即停止操作，保存故障前後約 20 至 50 行日誌。
- 記下使用的節點、系統代理狀態、TUN 狀態與本機連接埠，但不要公開分享完整訂閱網址、UUID、密碼或存取權杖。
依入站、路由、出站讀取錯誤鏈
一個請求通常先由瀏覽器或其他應用程式發出，經由本機 SOCKS、HTTP 或 TUN 入站進入核心，接著比對路由規則，最後由代理節點或直連出口傳送。日誌中的錯誤經常由多層資訊串接而成，最外層描述「處理失敗」，最內層才接近原始原因。
閱讀時不要只搜尋最後一個 error。先查看相同時間附近是否出現新的連線，再沿著由外到內的錯誤鏈尋找 dial、lookup、authentication、routing、bind 等關鍵字。第一筆異常比之後大量出現的取消訊息更有診斷價值。
第一段：入站是否收到請求
如果點開網頁後日誌完全沒有新增連線，問題多半尚未進入核心。此時請檢查系統代理是否開啟、瀏覽器是否使用獨立代理、應用程式是否忽略系統代理，以及本機位址與連接埠是否一致。v2rayN 常見本機連接埠為 10808，但升級、移轉設定或手動修改後，應以「設定」→「參數設定」中顯示的實際值為準。
- 日誌出現來自
127.0.0.1的連線：應用程式已到達本機入站。 - 完全沒有新記錄：優先檢查應用程式代理設定與系統代理狀態。
- 出現
bind或address already in use：本機監聽連接埠已被其他程序占用。 - SOCKS 用戶端連到 HTTP 連接埠：可能出現協定版本錯誤，或連線立即遭到拒絕。
第二段與第三段：規則選中了哪個出口
入站正常後，繼續確認請求被送往代理、直連還是阻斷出口。路由規則順序錯誤時，節點本身可能完全正常，但目標網域被較早的直連或阻斷規則攔截。接著再檢查出站撥號：網域解析、伺服器連接埠、傳輸方式、TLS 參數與使用者驗證都發生在這個階段。
| 觀察位置 | 典型現象 | 優先檢查 |
|---|---|---|
| 入站 | 沒有連線記錄或監聽失敗 | 系統代理、10808 連接埠、協定類型 |
| 路由 | 請求進入了錯誤的出口 | 規則順序、網域分類、直連與阻斷規則 |
| 出站 | 撥號逾時、驗證失敗 | 伺服器位址、連接埠、UUID、傳輸與 TLS |
| 回傳階段 | 已連線但很快中斷 | 遠端回應、網路切換、閒置連線關閉 |
rejected、timeout 與 invalid user 分別代表什麼
同一個問題在 V2Ray 與 Xray 核心、不同傳輸方式及不同版本中，可能使用略有差異的措辭。判斷時應掌握核心動作：rejected 表示某一層明確拒絕連線，timeout 表示在規定時間內未完成操作，invalid user 則直接指向驗證資訊不相符。
錯誤：rejected
原因與解法：拒絕可能發生在本機入站、路由阻斷或遠端伺服器端。先閱讀 rejected 後方的模組名稱；若同時出現 blocked，請檢查路由規則；若緊接著出現 authentication 或 invalid user，則核對節點驗證參數。
錯誤：connection timeout
原因與解法：核心未能在限定時間內建立連線。先確認伺服器位址與連接埠，再分別測試目前網路與另一個可用網路；只有單一節點逾時時，優先處理節點參數或遠端可達性。
錯誤：dial tcp: i/o timeout
原因與解法：TCP 撥號未能及時完成，常見原因包括目標位址無法連線、連接埠沒有回應或網路路徑不穩定。不要先修改 UUID，應先檢查位址、連接埠與基礎網路。
錯誤：invalid user
原因與解法：伺服器端無法辨識用戶端提交的使用者資訊。VMess 或 VLESS 節點應核對 UUID、附加驗證參數及訂閱更新時間，確認沒有混用舊節點與新設定。
錯誤：failed to find an available destination
原因與解法：出站找不到可用目標，可能是位址解析失敗、目標清單為空，或前面的撥號全部失敗。檢查節點位址拼寫與 DNS 結果，再重新啟動核心測試。
錯誤：context canceled
原因與解法：目前操作已被上層取消，常見於切換節點、停止核心或前面的連線已經失敗。這通常是後續結果，應向前尋找更早出現的 timeout、rejected 或驗證錯誤。
錯誤：address already in use
原因與解法：預計監聽的本機連接埠已被占用。退出重複執行的用戶端，或在「設定」→「參數設定」中更換未被占用的本機連接埠，例如從 10808 改為其他可用連接埠，然後同步更新應用程式代理設定。
不要把所有 rejected 都視為節點失效
日誌中可能同時包含廣告網域、區域網路探索、系統連線檢查與使用者主動存取。某條阻斷規則依預期拒絕請求時，也會出現 rejected 類型的訊息。只有當錯誤時間與目標操作一致，且相關網域或 IP 正是本次存取對象時，才應將其列為主要線索。
- 只有單一網域失敗、其他網站正常：檢查該網域的路由分類與 DNS 結果。
- 所有代理請求都逾時：檢查節點位址、伺服器連接埠與目前網路。
- 所有節點都提示連接埠占用：處理本機入站，不必逐一修改節點。
- 更新訂閱後突然出現 invalid user：確認用戶端實際啟用的是更新後的節點。
用單一變數測試縮小故障範圍
有效排查仰賴可重複的對照。一次同時修改 DNS、連接埠、傳輸方式與路由規則，即使恢復連線，也無法知道是哪項變更生效。更穩妥的做法是保留原始設定副本，每輪只修改一個變數，並以相同目標重新測試。
- 確認本機入站：啟動核心後，檢查是否成功監聽實際設定的連接埠，並觀察瀏覽器請求是否進入日誌。
- 確認節點選擇：在用戶端主介面重新選擇目標節點，避免修改了某個節點，實際使用的卻是另一個節點。
- 暫時簡化路由：在明確了解設定影響的前提下，使用基本代理規則重新測試，判斷是否由複雜分流造成誤判。
- 核對出站參數：逐項比較伺服器位址、連接埠、VMess 或 VLESS 類型、UUID、傳輸方式、TLS 與伺服器名稱。
- 更換網路進行對照：保持節點與用戶端設定不變，只切換網路；若錯誤從持續逾時變為正常連線，問題較可能出在目前的網路路徑。
- 還原並驗證：找到原因後還原其他暫時設定，再連續存取三個常用目標，觀察至少 2 分鐘是否出現重複錯誤。
一個連接埠占用的完整判斷流程
假設 v2rayN 啟動後網頁完全無法存取，日誌最先出現的是本機監聽錯誤，而不是遠端撥號錯誤。此時應先處理 10808 連接埠，不應更換節點或修改傳輸參數。典型日誌可能接近以下形式：
failed to start inbound
listen tcp 127.0.0.1:10808: bind: address already in use先完全退出重複執行的用戶端程序，再重新啟動。若仍顯示占用，可在「設定」→「參數設定」中選擇其他未占用的本機連接埠，並讓瀏覽器或系統代理使用相同連接埠。修改後，日誌應先出現監聽成功，再出現來自本機的連線記錄；只有請求進入核心後，才需要繼續檢查路由與出站。
常見日誌現象的具體處理方式
有些故障不會只對應一段錯誤文字，而是呈現「有連線記錄但網頁沒有回應」、「剛啟動正常，幾分鐘後逾時」等組合現象。以下依使用者最常遇到的描述提供第一輪操作，完成後仍應回到故障時間附近核對日誌。
日誌一直捲動，怎麼找到剛才那次失敗？
先清空日誌，關閉背景下載，只開啟一個測試網頁。記下點擊時間，接著在 30 秒內的記錄中搜尋目標網域、timeout、rejected、failed 或 error。
顯示啟動成功，但瀏覽器沒有任何新日誌？
檢查 v2rayN 的系統代理狀態，以及瀏覽器是否設定了獨立代理。若手動填寫代理，位址應為 127.0.0.1，連接埠必須與用戶端目前的設定一致。
只有一個節點出現 connection timeout？
保持網路不變，切換到另一個已知可用的節點測試。其他節點正常時，核對故障節點的伺服器位址、連接埠與傳輸參數，並更新訂閱後重新選擇節點。
切換節點後出現大量 context canceled？
切換節點會終止舊連線，這類記錄通常不需要單獨處理。等待新核心穩定後重新測試，並尋找新時間區段中較早出現的撥號或驗證錯誤。
v2rayNG 顯示已連線，但應用程式仍然逾時？
從側邊選單開啟日誌，確認目標應用程式的請求是否出現。沒有記錄時，檢查系統的連線授權與應用程式本身的代理設定；有記錄時，依路由與出站階段繼續定位。
如何區分 DNS 問題與節點問題
如果日誌出現網域解析失敗，而直接使用已知 IP 的其他請求正常，問題較可能出在 DNS。若節點伺服器本身使用網域名稱，解析失敗會直接阻止出站撥號；若只有目標網域解析失敗，還需檢查 DNS 分流與網域規則。不要看到 timeout 就立即認定是 DNS，因為連接埠無法連線同樣會造成逾時。
- 出現
lookup、no such host：優先檢查 DNS 設定與節點位址拼寫。 - 已解析出 IP，接著
dial tcp逾時：重點檢查連接埠與網路路徑。 - TCP 已連線，接著出現驗證錯誤：核對 UUID、協定類型與伺服器端參數。
- 只有特定網域走錯出口：檢查路由規則順序與 GeoSite 資料是否及時更新。
路由資料過舊可能導致網域分類與預期不一致，但通常不會造成 invalid user。將錯誤與處理範圍對應起來，可以避免無關變更：驗證錯誤檢查使用者參數，監聽錯誤檢查本機連接埠，解析錯誤檢查 DNS，規則比對錯誤檢查路由。
保存一份可供複查的故障記錄
偶發斷線最難處理，因為重新啟動後可能暫時恢復。與其只截取最後一筆錯誤，不如保存一份結構化記錄，讓下次重現時可以直接比較。記錄應涵蓋用戶端、核心、網路環境、節點類型、故障時間與第一筆異常。
| 記錄項目 | 範例寫法 | 用途 |
|---|---|---|
| 用戶端與版本 | v2rayN 7.x | 判斷選單位置與預設行為 |
| 核心類型 | Xray 或 V2Ray | 解釋日誌用詞差異 |
| 本機入站 | 127.0.0.1:10808 | 確認應用程式是否連到正確連接埠 |
| 協定與傳輸 | VLESS 與 TCP | 限定驗證與傳輸的檢查範圍 |
| 重現時間 | 14:32:10 至 14:32:40 | 從大量日誌中定位請求 |
| 第一筆異常 | dial tcp: i/o timeout | 區分根因與後續連鎖錯誤 |
向設定維護者提交問題時，可以提供上述環境資訊與經過遮蓋的錯誤片段。應刪除訂閱網址、UUID、密碼、權杖、完整伺服器位址及個人存取的網域。保留時間、模組名稱、錯誤類型與連接埠，即可支援大多數判斷。
- 先複製原始文字，再遮蓋敏感資訊，避免截圖截斷關鍵上下文。
- 保留錯誤前後至少 10 行，並註明執行了哪些操作。
- 說明問題是可穩定重現還是偶發，以及切換網路或節點後的對照結果。
- 修復後重複相同操作，確認原錯誤不再出現，而不是只看介面顯示「已連線」。