v2rayN 執行記錄怎麼看：常見錯誤訊息與定位方法

先分清 v2rayN 記錄中的三層資訊

v2rayN 視窗中的資訊不全都是錯誤。客戶端本身負責訂閱、介面狀態、系統代理與核心程序管理；Xray 或 V2Fly 核心負責連線、協定、DNS 與路由；存取記錄則描述某個目標位址經過哪條出站路徑。三類內容可能依時間交錯顯示，只盯著最後一行，很容易把上游結果誤認為根本原因。

在 v2rayN 7.x 介面中，可以先查看主視窗下方的資訊區域；需要調整記錄詳細程度時，進入「設定」→「參數設定」，尋找記錄層級、存取記錄或核心輸出相關選項。不同小版本的標籤名稱可能略有差異，但應優先使用客戶端介面提供的選項，不要直接修改執行期間產生的設定檔，因為客戶端下次啟動核心時可能會重新產生。

一次代理請求通常會依序經過應用程式、本機監聽、路由判斷、協定封裝與遠端連線。記錄中的錯誤位置越前面，就越應先檢查本機連接埠與代理設定；錯誤位置越後面，就越要核對伺服器位址、連接埠、傳輸方式、TLS 與使用者身分參數。

一筆記錄應該從哪裡開始讀

先看時間，再看層級與模組，最後沿著錯誤鏈從末尾往前讀。許多 Xray 記錄會用多個大於號串起呼叫關係，前半段說明哪個模組回報失敗，最後一段往往最接近底層原因。例如同一行同時出現「failed to process outbound traffic」與「i/o timeout」時，真正應優先處理的是連線逾時，而不是籠統的出站處理失敗。

目標位址也很重要。若錯誤目標是訂閱網域，問題發生在訂閱更新；若目標是節點伺服器位址，問題位於代理連線建立階段；若記錄顯示節點已連線，但某個網站網域解析失敗，則需要檢查 DNS 或路由規則。不要因為一次訂閱更新失敗，就直接判定所有已匯入節點都無法使用。

2026/08/02 14:21:08 [Warning] transport/internet/tcp:
failed to dial TCP > dial tcp 203.0.113.10:443: i/o timeout

2026/08/02 14:21:24 [Info] proxy/http:
request to tcp:example.com:443 accepted [proxy]

上方第一段表示連線至節點範例位址的 443 連接埠建立 TCP 連線時逾時，檢查方向應是節點位址、連接埠、本機網路與遠端可達性。第二段中的 accepted 只表示本機 HTTP 代理已接收應用程式請求，不代表目標網頁已成功回傳；還要繼續查看同一秒之後是否出現代理出站失敗。

rejected、timeout 與 invalid user 分別代表什麼

關鍵字只能判斷故障範圍，不能脫離上下文直接得出唯一答案。同一個 timeout 可能來自節點連接埠無法連線，也可能來自 DNS 查詢或目標網站回應；同一個 rejected 可能是路由主動拒絕，也可能是伺服器拒絕協定請求。複製錯誤時，至少保留前後各兩行、時間戳記、模組名稱與完整錯誤鏈。

為什麼 invalid user 不能只檢查 UUID

VMess 和 VLESS 都使用使用者識別碼，但兩者不是可互換的協定。匯入時若錯誤辨識協定類型，即使 UUID 字元完全一致，伺服器仍不會依預期處理請求。舊版 VMess 設定還可能涉及額外參數，而目前設定通常應以最新訂閱內容為準，不建議憑記憶手動拼接。

還要確認錯誤來自目前選取的節點。訂閱更新後，清單中可能同時保留舊群組與新群組；名稱相近不代表設定相同。可以先記下目前節點備註，在伺服器清單中確認選取的列，再啟動一次只造訪單一網頁的測試，避免其他背景請求打亂記錄。

• 確認協定類型是 VMess 還是 VLESS，不要依連接埠號碼猜測協定。
• 核對 UUID 的字元、連字號，以及開頭和結尾是否混入空格。
• 更新對應的訂閱群組，確認沒有繼續選取舊節點副本。
• 檢查系統日期、時間與時區，明顯偏差可能影響握手與驗證。
• 重新啟動核心後再測試，避免舊連線繼續佔用觀察期間。

從錯誤反推具體設定項目

有效的排查應維持單一變數：每次只修改一項設定，修改後清空記錄，或記住目前記錄末尾的時間，再發起相同的測試請求。如果同時更換節點、DNS、路由模式與本機連接埠，即使恢復連線，也無法知道真正起作用的是哪一步，之後遇到同類問題仍難以定位。

建議先選擇一個已知可正常開啟的普通網頁作為固定目標，關閉會持續連網的下載器與同步程式，然後記錄四項資訊：目前節點、系統代理狀態、本機連接埠、測試時間。切換設定後等待約 15 秒，觀察是否產生相同錯誤；連續重複三次仍出現在同一階段，才將其視為穩定故障處理。

1. 確認核心是否已啟動。若先出現設定解析錯誤或本機連接埠監聽失敗，暫時不必檢查遠端節點，因為請求尚未離開本機。
2. 確認應用程式是否進入本機代理。造訪網頁後完全沒有 accepted 或目標網域記錄，應檢查系統代理、瀏覽器代理設定，或應用程式是否遵循系統設定。
3. 確認路由動作。目標被送往 direct、proxy 還是 blocked，決定下一步要檢查直連網路、節點出站，還是阻擋規則。
4. 確認節點連線階段。依序檢查網域解析、TCP 連線、TLS 握手與協定驗證，不要跳過前一階段，直接修改後一階段的參數。
5. 使用第二個節點進行對照。在相同網路、相同應用程式與相同路由下只切換節點，可以區分客戶端通用設定與單一節點設定問題。

記錄正常但網頁仍無法開啟時該檢查什麼

記錄中出現 accepted，只能證明請求已到達本機代理。若隨後顯示 proxy 且沒有明顯錯誤，但網頁仍無法開啟，應繼續檢查 DNS 回應、瀏覽器本身的代理策略與目標網站連線。部分瀏覽器可能使用獨立 DNS 機制，命令列工具也不一定會自動讀取系統代理，因此「一個應用程式能用、另一個不能用」通常不代表節點整體故障。

在 Windows 上開啟 v2rayN 的系統代理後，遵循系統設定的桌面應用程式會使用相應代理；手動設定代理的程式仍需填寫客戶端目前的監聽位址與連接埠。若本機混合連接埠顯示為 10808，就應使用介面中的實際值，不要因為舊教學提到 10809 就直接照填。連接埠不一致時，v2rayN 記錄可能完全沒有對應的請求。

路由規則也會造成表面上的「連線成功但無法存取」。例如目標網域命中 direct，而目前網路無法直連該目標，核心不會自動將失敗請求改送代理；命中 blocked 時則會依規則阻擋。查看存取記錄中的出站標籤，比反覆切換系統代理更快。

不同平台與核心的記錄如何對照

在 Windows、macOS 與 Linux 上使用桌面版時，介面呈現可能因版本不同而略有差異，但排查順序相同：先看客戶端是否成功啟動核心，再看本機監聽、路由動作與代理出站。Android 上的 v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心，記錄措辭可能不同，但 TCP、DNS、TLS、驗證與路由等階段仍可逐一對應。

不要要求另一個核心逐字呈現某個核心的完整錯誤句式。例如某個版本顯示 context deadline exceeded，另一個版本在相同情境下可能只顯示 timeout；真正需要比較的是錯誤發生在解析、連線，還是驗證階段。訂閱包含 VLESS 等設定時，也應確認目前客戶端與核心版本支援相應的設定欄位。

提供記錄給他人時應保留哪些內容

故障記錄應包含客戶端版本、核心類型、作業系統、問題發生時間、選用協定、錯誤前後數行，以及已嘗試的步驟。伺服器位址、UUID、訂閱位址與其他驗證資訊不應直接公開，可替換為一致的去識別化標記，但要保留連接埠、協定、傳輸方式與錯誤結構，否則無法判斷所處階段。

平台：Windows
客戶端：v2rayN 7.x
核心：Xray
現象：開啟系統代理後網頁逾時
重現時間：14:21:08
目前協定：VLESS
節點位址：server.example
節點連接埠：443
關鍵錯誤：dial tcp server.example:443: i/o timeout
已嘗試：更新訂閱、切換另一個節點、維持其他設定不變

記錄分析的核心不是收集越多文字越好，而是建立時間線：使用者做了什麼、請求進入哪一層、在哪個階段停止、修改哪一項後結果改變。依照這條線索處理，rejected 會落到路由或遠端拒絕，timeout 會落到具體連線階段，invalid user 會落到協定與身分參數，排查範圍就不會在所有設定之間反覆跳轉。