V2Ray 執行日誌怎麼看：connection refused 等常見錯誤的意義與排查步驟

先確認日誌記錄的是哪一段連線

一次代理請求並不是由客戶端直接把網頁交給遠端節點。以 v2rayN 常見的本機 SOCKS 連接埠 127.0.0.1:10808 為例，瀏覽器或其他應用程式會先連線到本機入站，核心接著解析節點網域、建立 TCP 或 UDP 連線、完成 TLS 或 REALITY 握手，最後執行 VMess、VLESS 等協定驗證。任何一段失敗，都可能在介面中顯示為「連線失敗」。

因此不要只截取日誌末尾的一個單字。先找到點選「測試延遲」、開啟網頁或啟動設定時對應的時間點，再向上閱讀 10 至 30 行。重複出現的 retry、failed to process outbound traffic 通常只是上層彙總，真正原因多半位於前面的 dial、lookup、handshake 或 authentication 行。

存取日誌用來確認請求是否進入核心，常見內容包括目標網域、目標連接埠、入站標籤與選取的出站標籤。錯誤日誌則說明連線在哪個步驟中斷。若存取日誌完全沒有新增記錄，應先檢查系統代理、TUN 或應用程式本身的代理設定；若存取日誌已出現目標位址，而錯誤日誌接著回報撥號失敗，則應把重點放在節點位址、連接埠與網路路徑。

設定日誌等級並保留有效上下文

日誌等級通常分為 debug、info、warning、error 與 none。日常執行使用 warning 或 error 可減少輸出；排查連線問題時先切換至 info，仍無法確認握手參數或路由命中情況時，再暫時使用 debug。排查完成後應恢復原本的等級，避免日誌檔案持續增長。

以 v2rayN 7.x 為例，先透過「設定」→「參數設定」→「Core 類型」確認目前節點使用的是 Xray 核心還是 V2Fly 核心，再在主介面的日誌區域查看核心重新啟動後的輸出。切換日誌等級或 Core 類型後，需要停止並重新啟動目前的設定，舊程序不會自動套用新參數。

1. 固定測試時間

   清空或記住目前日誌末尾的時間，在 10 秒內只執行一次「測試真實連線延遲」或開啟一次測試頁面。

2. 確認核心類型

   在 v2rayN 7.x 開啟「設定」→「參數設定」→「Core 類型」，核對節點實際使用的核心，避免讀取錯誤程序的日誌。

3. 提高日誌等級

   先使用 info 重現一次；只有在看不到路由、握手或 DNS 細節時，才改用 debug。

4. 重新啟動核心

   停止目前服務後重新啟動，確認新日誌中出現監聽 127.0.0.1:10808 或實際設定連接埠的資訊。

5. 儲存完整片段

   保留錯誤前後各 10 至 30 行，並同時記錄節點協定、傳輸方式、連接埠與重現操作。

如果需要直接檢查產生的核心設定，可以查看頂層的 log 物件。以下範例會將錯誤與存取記錄寫入標準輸出，具體檔案位置由客戶端接管；手動修改客戶端產生的暫存設定，可能在下次啟動時被覆寫，因此應優先使用客戶端設定。

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "info"
  }
}

Android 端的 v2rayNG 1.10.x 與 v2flyNG 操作方式相同：啟動目標設定後，從主介面選單進入日誌檢視頁面，再立即重現問題。系統可能限制背景程序；若切換應用程式後日誌停止更新，應讓客戶端保持在前景完成一次測試，不要直接把「沒有新日誌」判定為節點正常。

依錯誤原文定位網路與連接埠問題

connection refused 表示 TCP 連線已抵達某個位址，但目標連接埠主動拒絕連線。這與單純逾時不同：拒絕通常很快回傳，常見原因是伺服器程序未監聽該連接埠、連接埠填寫錯誤、網域解析到錯誤主機，或本機入站連接埠被誤當成遠端連接埠使用。

context deadline exceeded 表示操作超過截止時間，可能發生在 DNS 查詢、TCP 建立連線、TLS 握手或等待遠端回應的階段。僅憑這句訊息無法判定節點失效，應查看前一行是否帶有具體目標，例如 dial tcp、lookup 或 TLS handshake。

判斷逾時位置時可以比較耗時。區域網路內的連接埠衝突通常在啟動後 1 秒內出現；遠端連接埠拒絕也常在幾百毫秒至數秒內回傳；連續等待約 10 秒後才出現 deadline exceeded，則更像是網路路徑丟包、防火牆靜默丟棄封包，或握手階段沒有回應。這個時間差不能單獨下定論，但能協助安排排查順序。

處理 invalid user 與握手驗證錯誤

invalid user、invalid account 或驗證失敗類訊息，通常表示網路連線已進入協定處理階段，但客戶端提交的身分資訊與伺服器設定不一致。VMess 主要核對 UUID、伺服器時間與節點是否已停用；VLESS 則主要核對 UUID、加密欄位、Flow 與安全方式。複製節點時多出一個空格，也可能導致驗證參數失效。

VMess 對系統時間較為敏感。桌面或 Android 裝置時間偏差過大時，即使位址與連接埠正確，也可能無法完成驗證。先開啟系統自動設定日期、自動設定時間與自動時區，再重新啟動客戶端。不要只在介面中手動把分鐘調到接近值，時區與秒級偏差同樣需要校正。

使用 WebSocket、gRPC 或 REALITY 時，除了驗證參數之外，還要核對傳輸層設定。WebSocket 常見錯誤包括路徑不一致、Host 不匹配與回傳 HTTP 404；gRPC 需要核對 serviceName；REALITY 則需要核對 serverName、公鑰、shortId 與指紋。位址可連通只代表 TCP 路徑存在，不代表這些欄位正確。

• VMess：檢查 UUID、alterId、加密方式、系統時間、傳輸類型與 TLS 設定。
• VLESS：檢查 UUID、Flow、傳輸類型、安全方式與伺服器名稱。
• WebSocket：檢查 path 與 Host，路徑中的斜線及大小寫應與伺服器一致。
• gRPC：檢查 serviceName，避免將節點備註或網域填入此欄位。
• REALITY：檢查 serverName、公鑰、shortId、指紋與 Flow 的組合，不要只修改其中一個欄位後直接重複使用。

區分節點故障、訂閱問題與路由分流

同一訂閱中的所有節點同時失敗時，應優先檢查本機環境、訂閱更新結果、DNS 與系統時間；只有單一節點失敗，則更可能是該節點的位址、連接埠或帳號狀態發生變化。若節點測試可用但特定網站無法開啟，應將重點轉向路由規則、DNS 分流與目標網站連線，而不是反覆重新匯入訂閱。

路由問題的典型特徵是日誌中已出現目標網域，但選用了不符合預期的出站標籤。例如應經由代理的網域被送往 direct，或區域網路位址被送往代理出站。修改規則後必須重新載入設定，再次查看同一目標對應的出站標籤，不能只看客戶端狀態圖示。

訂閱更新成功只代表客戶端取得了訂閱回應，不代表訂閱中的每個節點都能連線。更新後應查看節點數量、更新時間與關鍵欄位是否變化。如果更新後清單為空，先檢查訂閱群組的篩選條件；若仍保留舊節點，則確認客戶端是否更新了正確的訂閱群組。

依固定順序完成最後排查

有效排錯依賴正確順序，而不是不斷嘗試隨機設定。先確認核心是否成功監聽本機連接埠，再確認請求進入入站，接著檢查 DNS、遠端撥號、傳輸握手與協定驗證。只有前一階段通過，下一階段的日誌才具備分析價值。

例如日誌先出現 accepted tcp:example.com:443，接著出現節點位址的 connection refused，表示應用程式到本機入站的鏈路已正常，不必繼續調整系統代理。此時應集中核對遠端節點連接埠。反過來，如果點選網頁後日誌完全沒有新增存取記錄，就應先檢查瀏覽器或系統是否確實指向 127.0.0.1:10808。

1. 檢查監聽

   啟動客戶端後確認日誌沒有 address already in use，並看到本機入站連接埠成功監聽。

2. 檢查請求

   開啟固定測試頁面，確認存取日誌出現目標網域與 443 連接埠；沒有記錄就檢查系統代理或應用程式代理。

3. 檢查解析

   搜尋 lookup、no such host 與節點網域，確認 DNS 回傳了可用位址。

4. 檢查撥號

   根據 refused、timeout 或 unreachable，區分連接埠拒絕、鏈路逾時與網路無法連線。

5. 檢查握手

   核對 TLS、REALITY、WebSocket 或 gRPC 參數，再檢查 VMess、VLESS 驗證欄位。

6. 恢復等級

   問題定位完成後，將 debug 恢復為 warning 或原本的設定，並重新啟動核心。

向他人提供排查資訊時，應包含客戶端名稱與版本系列、核心類型、節點協定、傳輸方式、錯誤發生時間與完整日誌片段。帳號憑證、訂閱位址、UUID、公鑰以外的私密連線資訊應先做必要遮蔽，但不要刪除錯誤前後的階段標記、目標連接埠與出站標籤。