看懂 Xray 核心日誌：常見錯誤訊息與排查方法

先確認日誌來源，再看請求在哪個階段中斷

v2rayN 是圖形化用戶端，Xray 則是實際處理代理流量的核心。訂閱下載失敗、介面啟動異常與代理連線失敗，不一定會出現在同一份日誌中。看到「服務已啟動」，只代表啟動流程進行到某個階段，不能據此判斷節點驗證成功，更不能確認目標網頁已可連線。

先查看啟動輸出中的核心名稱與版本，再確認目前節點實際使用的核心。v2rayNG 使用 Xray；v2flyNG 使用 V2Fly，兩者支援的欄位範圍並不完全相同。尤其是 VLESS、REALITY 相關問題，應以目前執行中的核心為準，不要只看用戶端安裝包版本。

這個流程是閱讀日誌的順序，不代表所有傳輸方式都嚴格分成六個獨立階段。例如，有些協定會將驗證與交握合併處理，目標網域也可能由伺服器端解析。排查時要確認錯誤中的位址是本機監聽位址、節點位址，還是最終目標位址。同樣是 443 埠，所在階段不同，排查方向也不同。

啟用日誌：送出一筆請求，建立可重現的紀錄

日常使用 warning 通常就足夠；需要觀察連線過程時，先使用 info，資訊不足再短暫切換至 debug。Xray 的 loglevel 可設定為 debug、info、warning、error、none。這是錯誤日誌的層級設定；是否記錄存取日誌，則取決於 access 設定。提高日誌層級並不會自動修復連線。

1. 確認核心

   在 v2rayN 主畫面的執行資訊中查看啟動輸出，記下實際呼叫的核心名稱與版本。如果輸出中完全沒有核心啟動紀錄，請先處理啟動失敗，不要直接排查遠端節點。

2. 調整層級

   在 v2rayN 中前往「設定」→「參數設定」，找到「日誌層級」並改為 info；在 v2rayNG 中則前往側邊選單的「設定」→「日誌層級」。不同版本的選單分類與譯名可能不同，若找不到，請先確認用戶端版本，不要直接套用其他核心的設定。

3. 重新啟動並重現問題

   儲存後重新啟動代理服務，確認新設定已生效。關閉會持續重新整理的網頁，只開啟一個固定的測試網址，記下操作時間，並保留該時間點前後約 10 秒的日誌。

4. 還原層級

   找出原因後，請將層級還原為 warning。分享日誌前，請遮蔽帳號識別資訊、訂閱網址、節點位址與瀏覽網域；保留時間順序、協定名稱、埠號與完整錯誤鏈。

使用自訂 Xray 設定時，可參考下方的日誌片段。這只是設定中的一個欄位，並非可直接執行的完整設定。若由用戶端產生設定，應透過用戶端選項修改；直接編輯暫存檔可能會在下次啟動時被覆寫。

{
  "log": {
    "loglevel": "info"
  }
}

failed to dial：沿著錯誤鏈找出真正的失敗位置

failed to dial 表示某次撥號或建立連線失敗，通常只是上層的概括訊息。後面的 lookup、connection refused、i/o timeout 才更接近實際原因。先讀完整條錯誤訊息，再決定要調整 DNS、埠號或路由；不要一看到 dial 就重新填寫 UUID。

例如，錯誤明確指出連往節點的 TCP 443 連線逾時，此時還沒有足夠證據指向 VLESS 使用者驗證。反過來說，若已連上節點，但後續讀取目標位址失敗，就不能只檢查本機至節點的連線。位址、階段與時間都要一併判讀。

TLS handshake 與 invalid user：分別檢查安全層與驗證層

TLS 交握錯誤通常出現在連線進入安全協商之後，但不一定是憑證問題。一般 TLS 節點應檢查 serverName、憑證鏈、系統時間與傳輸設定；VLESS + REALITY 則還要確認公鑰、shortId、serverName 與伺服器設定。這兩類節點不能一概套用「停用驗證」的做法。

invalid user 通常會在伺服器入站驗證日誌中提供較直接的線索，實際用詞則會因協定與版本而異。用戶端有時只會看到 EOF 或連線關閉。若能查看伺服器端日誌，請依時間對照兩端紀錄，確認 UUID 是否一致、該使用者是否已載入，以及埠號是否連到預期的入站。使用 VMess 時也要檢查系統時間；VLESS 則不要套用 VMess 的 alterId 設定。

• VLESS + TLS：確認 UUID、傳輸類型、埠號、serverName，以及伺服器要求的 flow。若使用 WebSocket，還要確認路徑與 Host，不能拿 TCP 節點的參數來代替。
• VLESS + REALITY：確認 UUID、伺服器端對應的公鑰資訊、shortId、serverName、指紋與 flow。不同用戶端的欄位名稱可能不同，請對照同一份節點參數。
• 系統時間：在 Windows 前往「設定」→「時間與語言」→「日期與時間」同步時間；在 Android 的系統「設定」中搜尋「日期與時間」，並啟用自動設定時間。各廠牌的選單分類可能不同。

context canceled：先判斷是不是請求本身遭到取消

context canceled 表示該操作所屬的執行脈絡已取消。關閉分頁、瀏覽器先建立連線後又放棄使用、切換節點或重新啟動核心，都可能產生這類紀錄。它不等於「節點一定失效」，也不能單獨證明 DNS 或憑證異常。

本機埠號與路由：先確認請求真的進入代理

若核心啟動後立刻出現 address already in use 或 Windows 的 Only one usage of each socket address，請優先處理本機監聽衝突。先確認是否還有另一個用戶端執行個體在運作，再檢查佔用埠號的程序。修改代理埠號後，也要同步更新瀏覽器的手動代理與系統代理設定，不能只改用戶端中的設定。

以下以 Windows 本機埠號 10808 為例。指令僅用於檢查埠號佔用狀況，未確認前不要結束其他程式的 PID。埠號並非固定預設值，請替換為目前設定中實際監聽的埠號。

netstat -ano | findstr :10808

若該埠號提供 SOCKS 入站，可用下方指令明確透過代理送出一次請求。在 Windows 使用 curl.exe 可避免部分終端機將 curl 名稱視為別名；socks5h 會將目標網域交由代理端解析，而非先由 curl 在本機解析。若入站只提供 HTTP 代理，請改用相應的 HTTP 代理參數，不要直接照抄 SOCKS 指令。

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

• 本機就拒絕連線：確認代理服務正在執行、監聽埠號正確，且入站協定相符；此時請求還沒連到遠端節點。
• 請求已進入，但選錯出站：查看路由標籤與符合的規則。若目標被分配至直連，即使節點本身正常，也可能無法開啟網頁。
• 指令成功、瀏覽器失敗：比較瀏覽器實際使用的代理設定、擴充功能控制方式、個別 DNS 設定與測試指令的解析路徑。
• 只有部分網域連不上：各保留一個可用與不可用的範例，比較網域規則、解析結果與出站設定，不要立刻更換所有設定。

整理排錯紀錄：每次只修改一個變數

有效的排錯紀錄不需要貼上幾千行日誌。記下核心版本、問題發生時間、操作入口與一條完整錯誤鏈，比只說「連不上」更容易判斷原因。如果一次同時修改 DNS、flow、埠號與傳輸設定，即使偶然恢復，也很難知道是哪項修改有效；下次遇到問題仍得從頭排查。

1. 說明環境：作業系統、用戶端版本、實際核心版本，以及目前使用的是系統代理、應用程式手動代理還是 TUN。
2. 說明預期：例如「請求應透過 SOCKS 10808 進入，再由指定的 VLESS 出站連線至測試網址」，不要只寫「已連線」。
3. 保留前後脈絡：提供啟動完成紀錄、送出請求的時間，以及前後約 10 秒的日誌；保留完整巢狀錯誤，不要只截取最後一行。
4. 記錄單次修改：每輪只修改一項，重新啟動後重複相同測試。若無效，先還原原值再進行下一項。
5. 最後再次確認：將日誌層級還原為日常設定，確認瀏覽器與測試指令都符合預期；更多基礎操作可參考用戶端使用教學。

閱讀 Xray 日誌的關鍵是找出失敗的界線：本機沒有監聽，就先修正本機設定；節點位址無法解析，就先檢查解析；TCP 已連線但交握失敗，再檢查安全與傳輸參數；驗證後才出錯，就繼續檢查目標存取。將錯誤放回整個請求流程中判讀，比反覆調整單一關鍵字相關的參數更可靠。