適合遇到節點逾時、網頁無法開啟、核心啟動失敗或訂閱更新異常的 v2rayN 使用者。閱讀後可以分辨介面日誌、核心日誌與存取日誌，依時間、目標位址、出站標籤和錯誤結尾擷取線索，再將 timeout、rejected、invalid user、connection refused、連接埠被佔用等紀錄轉換為具體檢查項目。
先分清 v2rayN 中的三類日誌
排查前不要只截取帶有紅色文字的那一行。v2rayN 負責設定管理、訂閱更新、系統代理與核心程序調度，真正建立 VMess、VLESS 等連線的通常是 Xray 核心。兩層程式記錄的對象不同，同一個故障可能先在核心日誌中顯示連線失敗，之後才在介面日誌中呈現測試逾時。
v2rayN 7.x 的具體按鈕名稱會隨小版本調整，但資訊通常可從主視窗下方的日誌區域、系統匣選單中的日誌入口，以及程式目錄內的日誌檔案找到。先記下目前使用的 v2rayN 版本、核心版本、節點名稱與故障發生時間，再查看前後 10 至 30 秒的紀錄。
| 日誌來源 | 主要內容 | 適合排查的問題 |
|---|---|---|
| 介面執行日誌 | 訂閱更新、延遲測試、設定檔產生、核心啟動與結束 | 訂閱解析失敗、檔案讀寫失敗、核心反覆結束 |
| 核心錯誤日誌 | DNS、路由、入站監聽、出站撥號、TLS 與協定交握 | 節點逾時、參數不相符、憑證名稱錯誤、連接埠被佔用 |
| 存取日誌 | 來源位址、目標網域或 IP、匹配的出站、accepted 或 rejected | 判斷請求是否進入核心、是否命中直連或代理規則 |
讀取順序應沿著請求路徑推進。瀏覽器未進入本地入站時，問題多半在系統代理或應用程式代理設定；請求已進入卻被規則送往錯誤出站時，應檢查路由；出站已選定節點但撥號逾時，再檢查網路、網域解析、位址與連接埠。這比看到 timeout 就立即更換協定有效得多。
設定日誌等級並保留一次完整重現
日常使用建議先保留 warning 或 info 等級。warning 較安靜，適合觀察明確失敗；info 會補充入站、路由與出站過程，更適合首次排查。debug 記錄更密集，可能快速產生較大的日誌檔案，只應在問題難以重現或一般等級缺少上下文時短暫開啟。
在 v2rayN 7.x 中可先開啟「設定」→「參數設定」，檢查日誌相關選項；部分小版本會將核心日誌設定放在「設定」→「參數設定」→「Core 類型設定」附近。若介面名稱不同，請以目前版本中包含 log、日誌等級或存取日誌字樣的項目為準。修改後應重新啟動核心，否則舊程序可能仍沿用原設定。
- 記下目前時間，例如 14:32:10，關閉同時執行的下載工作與測速工作。
- 清除介面中的舊顯示，或在日誌末尾標記時間，避免把昨天的錯誤誤當成本次故障。
- 選擇一個節點並重新啟動核心，等待 3 至 5 秒，確認本地入站監聽已完成。
- 只執行一個動作，例如開啟一個網頁、測試一次真實連線延遲，或更新一次訂閱。
- 發生故障後立即停止重複點擊，保留錯誤前後至少 20 行紀錄。
- 恢復原本的日誌等級，再依時間戳將介面日誌與核心日誌對齊。
2026/06/25 14:32:11 [Info] transport/internet/tcp: dialing TCP to tcp:198.51.100.24:443
2026/06/25 14:32:16 [Warning] transport/internet: failed to dial outbound
2026/06/25 14:32:16 [Error] proxy/vless/outbound: failed to find an available destination
2026/06/25 14:32:16 [Error] common/retry: dial tcp 198.51.100.24:443: i/o timeout這組範例中最後一行是直接錯誤，第一行則提供目標 IP、連接埠與開始時間。兩者相差 5 秒，表示連線在遠端交握前就卡在 TCP 撥號階段。此時應優先檢查位址可達性、防火牆與連接埠，而不是先修改 UUID、流量控制或傳輸路徑。
結論：先用 info 重現一次
如果 warning 只留下最後的 timeout，請暫時將等級調至 info 並單次重現；只有 info 仍看不到請求進入、路由選擇或撥號目標時，才短暫使用 debug。
常見錯誤原文、原因與修復方向
錯誤訊息通常由多層原因串接而成，前半段說明失敗發生在哪個模組，最末尾的 caused by 或冒號後短句更接近直接原因。不要只搜尋第一個 failed，應從整段末尾往前閱讀，再結合目標位址、連接埠與出站標籤判斷。
錯誤：failed to find an available destination
原因與解法：核心嘗試候選目標後仍未建立連線。這一行通常只是上層彙總，請繼續查看緊接其後的 timeout、connection refused 或 DNS 錯誤；核對節點位址與連接埠，再測試本機能否解析該網域。
錯誤：dial tcp 198.51.100.24:443: i/o timeout
原因與解法：在限定時間內未完成 TCP 連線，常見於網路無法到達、連接埠遭封鎖、遠端未回應或解析到錯誤位址。先確認本機一般網路正常且系統時間準確，再核對訂閱中的伺服器位址與 443 連接埠。
錯誤：context deadline exceeded
原因與解法：某項操作超過等待期限，可能發生在訂閱下載、DNS 查詢、節點測試或出站連線中。先查看上一行指出的操作對象；訂閱失敗時檢查訂閱網址與代理更新設定，節點連線失敗時檢查目標網路。
錯誤：connectex: No connection could be made because the target machine actively refused it
原因與解法：目標主機明確拒絕連線，通常表示對應連接埠沒有服務監聽，也可能是位址或連接埠填寫錯誤。與 timeout 不同，這表示網路路徑大概率已抵達目標；應優先核對連接埠與伺服器運作狀態。
錯誤：proxy/vless/encoding: invalid user
原因與解法：驗證身分未被對端接受，常見於 UUID 複製不完整、訂閱已更新但本機仍使用舊節點，或用戶端與伺服器設定不一致。先更新訂閱並重新選擇節點，再逐項核對 UUID、協定類型與相關驗證參數。
錯誤：rejected proxy/vmess/encoding: invalid user
原因與解法：VMess 使用者身分或時間條件未通過。先讓系統自動同步日期、時間與時區，再確認節點來自目前有效的訂閱；若多台裝置同時回報同一節點錯誤，需請設定提供者核對使用者資訊。
錯誤：rejected by rule
原因與解法：請求命中了阻擋路由，不代表節點本身離線。查看同一筆存取紀錄中的網域、連接埠與規則標籤，檢查是否被廣告阻擋、私人位址或自訂規則誤攔；必要時將目標加入明確的代理或直連規則。
錯誤：listen tcp 127.0.0.1:10808: bind: Only one usage of each socket address is normally permitted
原因與解法：本地 10808 連接埠已被另一個程序佔用，新核心無法監聽。完全結束重複執行的 v2rayN 或舊核心程序；也可以在「設定」→「參數設定」中改用未被佔用的連接埠，隨後同步修改瀏覽器或應用程式的代理連接埠。
錯誤：remote error: tls: handshake failure
原因與解法：TLS 交握遭遠端拒絕，常見於伺服器名稱、傳輸層設定或遠端憑證設定不一致。核對匯入訂閱後的 serverName、傳輸方式與連接埠，不要只靠關閉憑證相關檢查來掩蓋參數錯誤。
錯誤：no such host
原因與解法：節點網域未解析出位址，可能是網域拼寫錯誤、DNS 暫時故障或本機網路受限。複製節點位址並檢查是否含有空格，使用系統網路診斷確認解析結果，更換可用 DNS 後重新啟動核心再試。
日誌中的 accepted 也不等同於最終存取成功。它通常只表示請求已被某個入站接收，或已交給指定出站。如果 accepted 後繼續出現遠端重設、TLS 失敗或 DNS 錯誤，仍需沿著同一時段繼續往下讀。反過來，若完全找不到該請求，應回到系統代理、瀏覽器代理或 TUN 設定，檢查流量是否進入 v2rayN。
從症狀到日誌線索的固定排查順序
相同的頁面現象可能對應不同層級。網頁持續轉圈可能是本地連接埠未啟動，也可能是節點撥號逾時；延遲測試有數值但網頁無法開啟，則可能是測試方式與實際存取路徑不同。固定順序的價值在於每一步只排除一層，不會同時修改協定、DNS、路由與系統代理。
第一步：確認基礎環境
- 關閉系統代理後瀏覽一般網站，確認本機網路本身可用。
- 在系統日期與時間設定中開啟自動同步，VMess 等驗證流程對時間偏差相當敏感。
- 記錄 v2rayN 版本與目前核心版本，不要用舊日誌解釋升級後的新問題。
- 更新訂閱時確認連結複製完整，並檢查訂閱是否仍在有效期內。
第二步：確認核心是否真正啟動
切換節點後觀察是否出現設定檔產生、核心啟動與本地監聽資訊。若核心啟動後立即結束，先處理 bind、設定語法、檔案權限或核心檔案錯誤。只有日誌明確顯示本地連接埠開始監聽，系統代理才有可連線的入口。
第三步：確認請求是否進入本地連接埠
常見的本地 SOCKS 連接埠為 10808，部分設定會將 HTTP 連接埠設為 10809，也可能使用混合連接埠。這裡不能只套用常見數字，應以 v2rayN 目前「設定」→「參數設定」中顯示的連接埠為準。瀏覽器、命令列工具與系統代理必須連線至同一個實際監聽連接埠。
| 可見現象 | 先找的日誌 | 優先處理方式 |
|---|---|---|
| 核心一啟動就結束 | bind、failed to start、設定載入錯誤 | 釋放連接埠或還原有效設定 |
| 日誌中完全沒有網頁請求 | 本地入站監聽與存取日誌 | 檢查系統代理與應用程式代理連接埠 |
| 請求顯示 rejected | 網域、目標連接埠、路由標籤 | 修正規則順序或匹配條件 |
| 請求進入後出現 i/o timeout | 出站位址、IP、連接埠 | 檢查節點可達性與訂閱參數 |
| 只有部分網域失敗 | DNS 結果與分流出站 | 比較成功與失敗網域的規則命中結果 |
第四步：一次只修改一個變數
如果同時更換節點、修改 DNS、切換路由模式與調整連接埠，即使連線恢復也無法確認真正原因。建議先保留原節點，只修正日誌指出的一項；重新測試仍失敗後再進入下一層。每次測試間隔 3 至 5 秒，讓舊核心結束並讓新設定完成載入。
結論：錯誤結尾決定第一個檢查項目
timeout 先查網路可達性，connection refused 先查監聽連接埠，invalid user 先查身分參數，rejected by rule 先查路由；不要把四類錯誤都歸結為節點速度問題。
常見日誌疑問與具體處理方式
日誌排錯並不是追求完全沒有 warning。網路切換、已關閉的瀏覽器連線與應用程式取消請求都可能留下警告，關鍵在於錯誤時間是否與可見故障一致、是否能穩定重現，以及是否集中指向同一個目標與同一個出站。
日誌刷得很快，應該從哪裡開始看？
先停止測速與批次訂閱更新，記下目前秒數，只存取一次失敗目標。接著從該時間點往下找第一條 Warning 或 Error，並保留它前面的撥號位址、路由標籤與入站紀錄。
看到 timeout 就代表節點失效了嗎？
不能直接下結論。使用同一個網路測試另外兩個有效節點；若都在約 5 秒後逾時，優先檢查本機網路或出口限制。只有單一位址持續逾時而其他節點正常時，才較接近該節點位址或連接埠的問題。
延遲顯示正常，網頁為什麼仍然無法開啟？
先確認測試類型。基礎 TCP 延遲只檢查連接埠連通性，真實連線延遲則更接近完整代理路徑。再查看網頁請求是否進入 10808 或目前實際使用的連接埠，以及存取日誌最後選擇的是 proxy、direct 還是 block 出站。
訂閱更新提示 context deadline exceeded 怎麼辦？
檢查訂閱網址是否完整，再到訂閱群組設定確認是否需要透過代理更新。若必須透過代理，先連線至一個已驗證可用的節點；同時查看錯誤中失敗的是 DNS 查詢、TCP 連線還是下載讀取。
修改連接埠後仍提示 address already in use？
完全結束 v2rayN 並確認舊核心程序已經結束，再重新啟動。檢查新連接埠是否也被其他程式佔用，同時更新系統代理與手動設定應用程式中的連接埠；只修改核心連接埠會導致應用程式繼續連線至舊入口。
整理可重現資訊後繼續排查
複雜故障需要將環境、操作與日誌放在一起。單獨提供一句 failed to dial outbound 通常不足以判斷，因為它可能由 DNS、TCP、TLS、驗證或路由中的任一層觸發。整理時應優先保留能夠重現問題的最小資訊集合。
- 用戶端資訊：v2rayN 的完整版本號與 Xray 核心版本。
- 執行環境：Windows 版本、目前網路類型、是否剛從其他網路切換。
- 設定類型：VMess 或 VLESS、TCP 或 WebSocket 等傳輸方式，不附上驗證內容。
- 重現操作：例如啟動核心後等待 5 秒，開啟一次指定類型的網頁。
- 預期與實際結果：預期正常載入，實際在 10 秒後逾時或立即遭拒絕。
- 日誌範圍：故障前 10 秒至故障後 10 秒，包含第一筆異常與最底層原因。
- 對照結果：同一網路下其他節點是否正常，關閉系統代理後一般網路是否正常。
完成一次修復後，使用相同目標與相同操作重新測試。若原本的 invalid user 消失但出現 TLS handshake failure，表示驗證層已經通過，排查可以繼續朝傳輸與 TLS 參數推進；這並非修復無效，而是更深一層的錯誤開始顯現。
如果錯誤隨機出現，應比較至少三次紀錄的耗時與目標。每次都在約 5 秒或 10 秒時到達 timeout，通常是固定逾時機制觸發；耗時從幾十毫秒到數秒大幅波動，則更應關注網路封包遺失、DNS 結果變化或節點負載。保留具體時間差，比只描述「偶爾很慢」更有判斷價值。
結論：用時間線取代錯誤截圖
將核心啟動、請求進入、規則命中、出站撥號與最終錯誤依秒排列，通常能直接看出故障停在哪一層；一張只包含最後一行的截圖會遺失最關鍵的前因。