V2Ray 執行日誌怎麼看？常見錯誤訊息與逐步排查方法

一、先確認日誌來源：分開查看用戶端提示與核心錯誤

v2rayN 是桌面圖形介面用戶端，連線由所選核心處理。視窗中的訂閱更新、速度測試、系統代理設定提示，可能與 Xray 連線日誌出現在相近位置，但屬於不同層級的事件。排查前先記下目前使用的節點、核心、代理入口和操作時間；只有確認是 Xray 輸出，才依 Xray 的設定欄位解讀。不能因為用戶端名稱含有 V2Ray，就認定底層使用的核心一定相同。

桌面版可先在 v2rayN 主視窗的日誌或資訊區查看啟動輸出，再到「設定」→「參數設定」尋找日誌相關選項。不同介面配置的選項名稱可能不同，請以目前用戶端顯示為準。Android 上，v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；請從各自的日誌入口查看輸出，不要直接套用另一款用戶端的設定路徑。

1. 先查看啟動階段：確認設定載入、規則資源載入及本機連接埠監聽是否成功。若啟動階段已失敗，先不要測試遠端網站。
2. 縮小觀察範圍：記下目前時間，停止重複測速和背景批次請求，只發出一次可穩定重現的連線。
3. 保留前後文：複製首次失敗前後的相關日誌；若日誌包含連線識別碼，優先追蹤同一識別碼，不要把交錯的多條連線混在一起。
4. 保留錯誤原因鏈：看到多層 failed to 時，連同後續的底層原因一起閱讀，不要只截取最外層的訊息。

二、認識日誌層級與格式：先看時間，再看連線階段

Xray 錯誤日誌常見層級有 debug、info、warning、error；設定中的 none 可關閉相應的日誌輸出。排查時可暫時提高至 info，若資訊仍不足，再短暫使用 debug；完成後請還原原本設定，避免長時間記錄大量連線細節。存取日誌與錯誤日誌用途不同，提高錯誤日誌層級不代表會自動啟用存取日誌。

2026/11/03 10:15:20 [Info] [123456789] proxy/socks: TCP Connect request to tcp:example.com:443

這是已去識別化的格式示意，並非本站實測結果。時間用於比對操作，[Info] 表示層級，數字可作為追蹤同一連線的線索，proxy/socks 表示處理模組，最後的位址則是該筆訊息相關的目標。實際格式會因核心和輸出設定而異，不代表每一行都會包含相同欄位。

沿著這條流程逐層確認：看到本機入口的接收紀錄，只能證明應用程式已將請求交給核心；看到路由選取某個出站，也不代表遠端握手已成功。存取日誌中的 accepted 通常表示請求已被接收處理，並不代表網頁已完整載入。EOF 或 context canceled 也可能是瀏覽器取消請求所致，請綜合判斷是否每次都失敗、發生階段及前後文。

• 啟動後立即停止：優先檢查設定語法、監聽連接埠、資源檔案和目錄權限。
• 有入口，卻沒有預期的出站：檢查路由命中的標籤、直連規則和預設出站。
• 已開始連線，之後才失敗：進一步區分網域解析、TCP 連線、TLS 握手和協定參數。

三、連線逾時與拒絕連線：別只看 timeout

先確認錯誤中的位址是節點伺服器，還是最後要連線的網站。若代理出站無法連上伺服器，請確認節點位址和連接埠；若直連出站無法連上目標，則應檢查直連網路或分流規則。若主機名稱有多種位址紀錄，也要確認實際嘗試的是 IPv4 還是 IPv6，避免把單一路徑無法連線誤判為所有連線都不可用。

Windows 可使用以下指令測試 TCP 是否可連線。網域和連接埠僅供文件示範，實際操作時請換成自己獲授權使用的節點位址和連接埠。請在裝置允許的網路環境中測試；輸出結果只反映 TCP 層狀態，不會驗證 VMess、VLESS 或 TLS 參數。

Test-NetConnection -ComputerName example.com -Port 443

• TCP 測試也失敗：檢查位址是否已過期、連接埠是否正確、目前網路是否限制連線，以及伺服器是否正常監聽。
• TCP 連線成功，但核心仍失敗：繼續檢查握手、傳輸方式、驗證參數及伺服器端相關日誌，不要立即判定節點正常。
• 只有部分網站連線失敗：比較這些請求使用的出站、解析結果和目標類型，優先排查路由差異。

四、憑證驗證失敗：檢查時間、名稱與信任鏈

TLS 錯誤表示連線已進入相應的握手階段，但不同憑證錯誤的處理方式並不相同。使用一般 TLS 憑證驗證的連線中，伺服器位址可以和用於憑證名稱驗證的 serverName 不同，但必須符合伺服器的部署設定。不能隨意填入任何可連線的網域，也不要把其他安全模式的參數直接套用到 TLS 設定。

如果系統日期正確、設定也沒有變更，卻突然出現未知簽發機構錯誤，請留意目前網路是否啟用了 HTTPS 檢查，或伺服器憑證鏈是否剛調整過。請依照組織的網路規範處理憑證信任，不要為了消除錯誤而任意匯入不明根憑證。

五、連接埠占用：先讓本機入口正常監聽

出現 address already in use 時，應先排除本機監聽衝突。常見原因包括用戶端重複啟動、舊的核心程序尚未結束，或其他程式使用了相同的位址和連接埠。在 Windows 上，相近問題可能顯示為 Only one usage of each socket address。此時修改遠端節點無法解決本機連接埠衝突。

這些數字用來區分連接埠所屬的層級，不代表必須統一修改設定：本機代理連接埠由用戶端設定決定，節點連接埠由伺服器部署決定，DNS 也可能使用加密傳輸，而非傳統連接埠。請以日誌實際顯示的監聽位址和連接埠為準；綁定 127.0.0.1 與綁定所有網路介面的可存取範圍不同，不要為了排錯就直接擴大監聽範圍。

# Windows PowerShell：查看範例連接埠的監聽程序
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux：查看 TCP 監聽項目與程序資訊
ss -ltnp 'sport = :10808'

# macOS：查看範例連接埠的 TCP 監聽狀態
lsof -nP -iTCP:10808 -sTCP:LISTEN

六、規則檔案與 DNS：區分啟動失敗和解析失敗

如果日誌包含 failed to load geosite、failed to load geoip，或出現指向 geosite.dat、geoip.dat 的檔案錯誤，請優先檢查規則資源，不要反覆更換節點。引用 geosite: 或 geoip: 的規則需要相應資料；檔案不存在、讀取權限不足、資料格式不相容或引用的分類不存在，都可能導致設定載入失敗。

1. 確認失敗路徑：依照日誌中的實際路徑尋找檔案。不同用戶端和安裝方式使用的資料目錄不同，不要預設資源一定放在程式執行檔旁邊。
2. 檢查資源來源：優先使用用戶端提供的規則資源更新功能，並確認下載內容不是錯誤頁面；請保留原檔，以免覆寫後無法還原。
3. 確認分類名稱：有檔案不代表包含所有分類。請確認路由規則引用的分類確實存在於目前的資源中。
4. 重新啟動並查看啟動日誌：確認資源載入成功、核心開始監聽後，再測試連線。手動編輯產生的設定檔也可能在下次啟動時被用戶端覆寫。

系統解析和核心內建 DNS 可能使用不同路徑。系統指令能成功解析，不代表核心選用的 DNS 出站也能運作；反過來，瀏覽器自行採用的解析方式也可能繞過核心 DNS。可先用系統解析指令確認節點網域，再檢查核心日誌中的 DNS 伺服器、請求網域及失敗階段。尤其要留意，若解析節點位址需要依賴尚未建立的代理通道，可能形成啟動依賴循環。

七、複測與求助：一次只改一項，提供完整線索

排錯的目標不是讓日誌完全沒有警告，而是找到能穩定解釋故障的原因。每一輪只修改一項設定，例如先修正 TLS 名稱，再重新啟動核心並重複相同請求；不要同時更換節點、DNS、路由模式和傳輸方式，否則即使恢復正常，也無法判斷是哪項設定生效。

• 啟動檢查：核心沒有立即結束，本機入口已成功監聽，規則資源也已載入完成。
• 入口檢查：發出一次請求後，日誌應能對應到該請求；若沒有紀錄，請確認應用程式使用了正確的代理位址和連接埠。
• 出站檢查：請求使用預期的出站，撥號和握手不再反覆出現同類錯誤。
• 應用程式檢查：實際開啟原先無法使用的頁面或功能；TCP 測試成功或測速有結果，都不能取代完整的應用程式驗證。
• 還原設定：關閉臨時啟用的偵錯層級，撤銷不再需要的測試設定，並保留這次的修改紀錄。

若仍需要協助，請提供作業系統平台、用戶端與核心的實際版本、故障發生時間、重現步驟，以及同一次連線前後的日誌。版本資訊請從目前用戶端或核心的啟動輸出確認，不要只依安裝套件名稱推測。提交前請遮蔽訂閱網址、驗證識別資訊、密碼、私密金鑰及其他敏感參數；保留錯誤類型、連接埠、發生階段，以及已一致去識別化的位址關係。