v2rayN 的日誌分 GUI 與核心兩層,核心日誌又按載入、握手、路由三段排列。文中說明兩類日誌的開啟路徑與檔案位置、六條常見錯誤原文的含義與處理方式,以及從時間戳追到出站節點的五步排查順序,適合連線失敗、訂閱更新失敗、路由規則未生效三類情境。
日誌分兩層:GUI 日誌與核心日誌
先說結論:v2rayN 裡看得到的日誌有兩份。GUI 日誌記錄介面動作,包括啟動與結束核心、切換節點、更新訂閱、開關系統代理;核心日誌記錄每條連線從入站到出站的完整鏈路。連線類問題若只看 GUI 日誌,通常只會看到「啟動成功」這類記錄,失敗原因不在這裡。
日誌入口在主介面底部的「日誌」頁籤,可在 GUI 日誌與核心日誌之間切換。GUI 日誌同時會寫入程式目錄下的 guiLogs 子目錄,依日期命名;核心日誌預設只輸出到介面,需要更細的規則命中與網域解析記錄時,到「設定」→「參數設定」把日誌等級(loglevel)從 warning 調到 info 或 debug,排查完再調回 warning。
| 記錄層 | 開啟位置 | 主要記錄內容 | 適用情境 |
|---|---|---|---|
| GUI 日誌 | 在「日誌」頁籤切到 GUI 一側 | 核心啟動與結束、訂閱更新、節點切換、系統代理開關 | 判斷是介面操作失敗還是連線失敗 |
| 核心日誌 | 同一頁籤切換到核心日誌 | 入站接收、路由判定、出站撥號、錯誤堆疊 | 定位連線失敗發生在哪一段 |
| 日誌檔案 | 程式目錄 guiLogs 子目錄,依日期命名 | GUI 日誌的歷史留存 | 軟體重新啟動後回看上一次的啟動記錄 |
三份記錄裡,排查連線問題主要看核心日誌;GUI 日誌的作用是確認核心到底有沒有起來。如果 GUI 日誌裡連啟動記錄都沒有,後面的分析都沒有意義,先解決核心啟動失敗的問題。
核心日誌的三段結構:載入、握手、路由
一條正常的請求在核心日誌裡會留下四到六行記錄,依時間順序分屬三段:載入段是核心讀取設定、監聽本機連接埠;握手段是入站收到請求、站開始撥號;路由段是規則判定與最終出站結果。定位故障的第一步,是判斷錯誤落在哪一段。
2026/07/02 09:14:02 [Info] infra/conf/serial: Reading config: config.json
2026/07/02 09:14:02 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/02 09:14:31 [Info] [4821937461] proxy/vless/inbound: received request for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] app/dispatcher: default route for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] transport/internet/tcp: dialing TCP to tcp:node.example.net:443
2026/07/02 09:14:32 [Info] [4821937461] proxy/vless/outbound: tunnelling request to tcp:example.com:443方括號裡的數字是請求 ID,同一條連線的所有日誌共用同一個 ID。日誌刷新很快時不必逐行讀,直接搜尋其中一個 ID,就能把一條鏈路的記錄串起來。
| 段 | 典型日誌行 | 說明 |
|---|---|---|
| 載入 | Reading config、listening TCP on 127.0.0.1:10808 | 核心讀取設定並監聽本機連接埠;這一行缺失表示核心沒有起來 |
| 握手 | received request for tcp:...、dialing TCP to tcp:... | 入站收到請求、出站開始撥號;只有前者沒有後者,問題在路由判定或本機網路 |
| 路由 | default route for、tunnelling request to | 規則判定結果與最終出站;出現 direct 表示命中直連規則 |
三段裡最容易被忽略的是路由段。目標網域被規則判給直連時,日誌裡不會出現出站撥號行,也不會報錯,表現是頁面一直轉圈;這種情況要回到「路由設定」檢查規則順序,而不是換節點。
六條常見錯誤原文對照
以下六條是核心日誌裡出現頻率最高的錯誤原文,依從入站到出站的順序排列。每條給出原因與處理方式,原文可直接複製到日誌視窗的搜尋框裡定位。
錯誤:address already in use
原因與解法:本機監聽連接埠被占用。v2rayN 預設使用 10808(SOCKS)與 10809(HTTP),其他代理工具或沒結束乾淨的核心行程占用同一個連接埠就會出現這條。先在「工作管理員」結束殘留行程,或在「設定」→「參數設定」把本機監聽連接埠改成 20808 後重新啟動核心。
錯誤:failed to find an available destination
原因與解法:出站伺服器位址解析不到結果。節點位址拼字錯誤、DNS 解析失敗或被污染都會觸發。先在「參數設定」的 DNS 設定裡換成 1.1.1.1 或 223.5.5.5 後重新啟動核心;仍報錯就把節點位址換成 IP 再試一次,以區分是網域解析問題還是位址本身寫錯。
錯誤:dial tcp ...: i/o timeout
原因與解法:出站連線在逾時時間內沒有收到回應。先確認伺服器位址與連接埠可達:同一節點在其他網路下能否連通。逾時只集中在個別節點就直接換節點;所有節點都逾時,再檢查本機防火牆是否放行 v2rayN 與核心行程。
錯誤:tls: first record does not look like a TLS handshake
原因與解法:傳輸層設定與伺服器不符,常見於伺服器端沒開 TLS 而用戶端開了,或兩邊參數不一致。把節點分享連結重新匯入一次,確認「傳輸協定」與「傳輸層安全」兩項與伺服器實際設定一致,不要手動拼接這兩項的值。
錯誤:rejected proxy/vless: invalid user
原因與解法:UUID 或密碼與伺服器端登記值不一致。訂閱更新後出現這條,多半是伺服器端換了 UUID 而本機還在用舊值;重新複製分享連結或重新匯入訂閱即可,其餘設定不用動。
錯誤:connection reset by peer 或 EOF
原因與解法:連線建立後被對端主動斷開。伺服器端行程重新啟動、協定參數不符、鏈路上有中間設備干預都會產生這條。先用同一組設定換一個節點驗證:換節點就正常表示是單一節點的問題,所有節點都斷才需要回到設定層檢查。
結論:先分段,再對照關鍵字
同一句 i/o timeout,出現在出站撥號行之後是伺服器或鏈路問題,出現在核心啟動階段則要查本機網路與 DNS。對照關鍵字之前,先用請求 ID 確認這條錯誤屬於哪一段。
排查順序:從時間戳到出站節點
日誌量大時逐行讀沒有效率。依下面五步走,每一步只回答一個問題,通常兩三分鐘就能鎖定失敗位置。
- 對齊時間戳。在日誌裡搜
failed或error,記下那一行的時間;往上翻到同一秒或前一到兩秒,找到同一請求 ID 的最後一條正常記錄。故障就發生在這兩行之間。 - 確認流量有沒有進核心。搜
received request:完全沒有這一行,表示請求根本沒到 v2rayN,先檢查系統代理開關、瀏覽器代理外掛,以及系統代理連接埠是否與本機監聽連接埠(預設 10808 / 10809)一致。 - 看路由判定結果。搜
default route與direct:目標被判給直連時,日誌裡不會出現出站撥號行,表現是連不上但不報錯,要回到「路由設定」調整規則順序。 - 看出站結果。
dialing TCP to後面緊接的那條錯誤就是根因,直接對照上一節的六條原文處理;撥號成功但隨後出現EOF,把該節點標記為不可用。 - 固定變數重現一次。只留一個失敗目標,關掉自動更新訂閱與延遲測速,重現一次後立即停止,再清空日誌重來。這樣日誌量會從幾千行降到幾十行,後面每一步判斷都不再靠猜。
結論:能重現的日誌才有用
把失敗目標固定成一個網域、重現一次、只截取該請求 ID 的完整鏈路,通常不超過 30 行;翻幾千行歷史日誌的命中率遠低於這一步。
日誌排查的常見疑問
以下五個問題來自實際使用的回饋,答案都落到具體操作上。
日誌裡全是 Info,是不是哪裡出問題了?
不是。Info 是正常連線記錄,只有 Warning 與 Error 需要處理;把日誌等級調回 warning 只是讓輸出變短,不會改變連線結果。
日誌刷太快,根本看不清怎麼辦?
先關掉自動更新訂閱與延遲測速,固定一個目標網域重現一次;排查結束後把日誌等級從 debug 調回 warning,減少無效輸出。
換了三個節點還是同一個錯誤?
錯誤位置決定換節點有沒有用:入站段與路由段的錯誤換節點無效,只有出站段的逾時、EOF 類錯誤才值得換節點驗證。
日誌裡出現真實網域和 IP,正常嗎?
正常,核心會記錄每條連線的目標位址。把日誌發給別人之前,先替換掉自己的伺服器位址和目標網域。
訂閱更新失敗,核心日誌裡什麼都沒有?
訂閱更新走 GUI 層,應該看 GUI 日誌而不是核心日誌;也可以先連上任一可用節點,再在訂閱設定裡勾選「透過代理更新」重試。