用戶端顯示「已連線」，只代表核心已啟動或本機代理連接埠已在監聽，並不表示目標網站、節點伺服器與遠端出站都能連通。真正有助於排查的資訊通常藏在日誌末端：請求從哪個入站進入、符合哪條路由、連線哪個位址失敗，以及失敗發生在網域名稱解析、TCP 建立連線、TLS 交握還是使用者驗證階段。
本文適合正在使用 v2rayN、v2rayNG 或 v2flyNG 排查連線問題的使用者。閱讀後，你可以分辨存取日誌與錯誤日誌、辨識常見英文錯誤所對應的環節，並透過連接埠測試、時間核對、DNS 比對與最小化路由逐步縮小故障範圍。
先分清存取日誌、錯誤日誌與用戶端輸出
V2Ray 或 Xray 核心處理一次請求時，會經過本機應用程式、入站代理、路由比對、出站協定與遠端目標等多個環節。不同類型的日誌，能回答的問題也不同。只盯著一行紅色文字，容易把結果當成原因；正確做法是先確認這行日誌屬於哪一類，再沿著時間相近的上下文閱讀。
| 日誌類型 | 主要內容 | 適合回答的問題 | 常見特徵 |
|---|---|---|---|
| 存取日誌 | 來源、目標位址、連接埠與選用的出站 | 請求是否進入核心，路由將它送往何處 | 常見 accepted、tcp、udp、網域與連接埠 |
| 錯誤日誌 | 連線、交握、驗證、解析與設定異常 | 請求在哪個處理階段失敗 | 常見 failed、rejected、timeout、invalid |
| 用戶端輸出 | 核心啟動、設定產生、訂閱更新與連接埠狀態 | 用戶端是否成功啟動核心，設定是否能被讀取 | 包含核心版本、設定路徑、監聽連接埠與結束狀態 |
存取日誌中出現目標網域，只能證明請求已抵達本機核心。接著若緊跟著 failed to dial，問題仍發生在出站連線。相反地，點擊網頁後完全沒有新增存取紀錄，應先檢查系統代理、瀏覽器代理或分應用程式規則，而不是立刻修改節點參數。
在 v2rayN、v2rayNG 與 v2flyNG 中找到有效日誌
排查前先固定情境：選擇一個節點，記下目前時間，關閉會持續連網的下載工具，再開啟一次固定頁面。這樣能減少背景請求造成的雜訊。日誌層級建議先使用 warning 或 info；debug 會產生大量連線細節，適合在一般資訊不足時短時間開啟。
-
確認目前使用的核心
在 v2rayN 7.x 開啟「設定」→「參數設定」→「Core 類型」，記錄目前設定使用的是 Xray 還是 v2fly。協定能力與錯誤措辭可能因核心不同而有所變化。
-
開啟資訊面板
回到 v2rayN 主視窗查看底部資訊區域，先執行一次「重新啟動服務」，確認能看到核心啟動、設定載入與本機連接埠監聽紀錄。
-
重現單次請求
讓日誌視窗保持可見，只開啟一次目標頁面。若本機 HTTP 連接埠為 10809，應先確認日誌中是否出現發往目標網域的請求。
-
查看 Android 日誌
在 v2rayNG 1.9.x 或 v2flyNG 主介面連線至節點後，開啟右上角選單中的「日誌」。先清除舊內容，再回到目標應用程式重現一次。
-
短時間提高日誌層級
warning 未提供完整的失敗鏈時，再將日誌層級調整為 info 或 debug，重新啟動核心後重現問題。記錄完成後恢復原本層級，避免日誌持續快速增加。
如果用戶端介面只顯示簡化輸出，也可以在自訂設定中明確指定日誌檔案。以下是通用結構示意，路徑需要改成目前帳戶具有寫入權限的目錄。修改後必須重新載入設定，否則看到的仍是舊程序輸出。
{
"log": {
"access": "D:/v2ray-logs/access.log",
"error": "D:/v2ray-logs/error.log",
"loglevel": "warning"
}
}日誌檔案未產生時，優先檢查目錄是否存在、程序是否具有寫入權限，以及用戶端是否覆寫自訂的 log 設定。不要為了取得更多資訊而一次修改協定、DNS、路由與連接埠；變數同時改變後，即使連線恢復，也無法判斷究竟是哪一步生效。
讀懂一則錯誤的結構：從最後一層往前追
V2Ray 與 Xray 的錯誤經常由多個模組逐層包裝，一則日誌中可能連續出現 transport、proxy、common 與 internet 等模組名稱，並以大於號串起呼叫鏈。閱讀時先掌握時間、目標位址與最末端原因，再往前確認它屬於哪個協定或傳輸階段。
2026/06/02 10:18:42 [Warning] transport/internet/websocket:
failed to dial WebSocket > transport/internet:
failed to dial to (wss://node.example:443/path):
dial tcp 203.0.113.20:443: i/o timeout| 片段 | 可以確定的事實 | 下一步檢查 |
|---|---|---|
| 10:18:42 | 錯誤發生時間 | 與剛才的重現操作對照，排除背景中的舊請求 |
| websocket | 正在建立 WebSocket 傳輸 | 核對傳輸類型、路徑、Host 與 TLS 設定 |
| 203.0.113.20:443 | 網域已取得位址，並嘗試連線至 443 連接埠 | 測試目前網路是否能與該位址及連接埠建立 TCP 連線 |
| i/o timeout | 未能在規定時間內完成網路操作 | 檢查節點線上狀態、線路封包遺失、防火牆與網路出口 |
這個範例中已出現數值位址，因此「本機完全無法解析該節點網域」不是首要方向。末端是 TCP 連線逾時，尚未進入 VMess 或 VLESS 使用者驗證。此時反覆修改 UUID 通常不會改變結果，應先確認 443 連接埠是否可連通。
如果末端原因是 connection reset by peer，表示連線建立後遭遠端或中間設備主動重設；如果是 connection refused，通常表示目標主機可連線，但對應連接埠沒有服務監聽，或遭策略明確拒絕。timeout、reset 與 refused 代表的網路狀態不同，不能一概歸結為「節點失效」。
failed to dial、rejected 與 invalid user 分別該查什麼
常見錯誤應按最末端原因分類，而不是只搜尋最外層的 failed to process outbound traffic。外層文字往往只是「出站處理失敗」的總結，真正決定排查方向的是最後幾段。以下列出常見原文與優先處理方式。
錯誤：failed to dial WebSocket
原因與解法：WebSocket 傳輸未能建立。先看末端是 timeout、refused、TLS 還是 bad handshake，再逐項核對位址、連接埠、傳輸路徑、Host 與 TLS 開關，不要只改其中一個欄位反覆嘗試。
錯誤：dial tcp: i/o timeout
原因與解法：TCP 連線未能在逾時期限內完成。改用另一個網路測試一次，檢查節點連接埠是否在線；若晚間持續逾時 8 至 15 秒、其他時段正常，還要考慮線路壅塞與封包遺失。
錯誤：connect: connection refused
原因與解法：位址通常已可連通，但目標連接埠明確拒絕連線。核對訂閱中的連接埠是否已更新，確認伺服器監聽連接埠與用戶端一致，並檢查連接埠轉送或防火牆規則。
錯誤：connection reset by peer
原因與解法：現有連線遭遠端或鏈路設備重設。先減少變數，關閉額外傳輸選項並測試同一節點的基本設定；如果只在特定網路出現，改用另一個網路比對，即可快速區分伺服器與本機鏈路問題。
錯誤：connection rejected
原因與解法：請求遭入站、出站或遠端策略拒絕。讀取 rejected 前後的模組名稱與目標連接埠；若同一節點的所有目標都遭拒絕，檢查驗證參數；若只有單一網域遭拒絕，則檢查路由阻擋規則。
錯誤：invalid user
原因與解法：VMess 等驗證資訊未獲伺服器接受。重新從訂閱更新節點，核對 UUID 是否完整，並將系統時間設為自動同步；VMess 對明顯的時間偏差很敏感，日期、時區或分鐘差異都要檢查。
錯誤：failed to find an available destination
原因與解法：核心沒有取得可用的目標位址，常見於網域解析失敗或位址清單全部不可用。檢查節點位址拼寫，切換 DNS 後重新啟動核心，並觀察日誌中是否再次出現 IPv4 或 IPv6 位址。
錯誤：context deadline exceeded
原因與解法：某個操作超過上下文規定的等待時間。結合前一行判斷是 DNS、TCP、TLS 還是訂閱請求逾時；單獨這句資訊不足，至少必須保留前後各 10 行。
錯誤：address already in use
原因與解法：本機監聽連接埠已被另一個程序占用。結束重複啟動的用戶端，或修改 SOCKS、HTTP 入站連接埠；更換連接埠後也要同步更新系統代理，避免系統仍指向舊的 10808 或 10809。
VLESS 本身不採用 VMess 的時間驗證機制，因此看到 invalid user 時，應先確認實際使用的協定與日誌所屬節點。訂閱中可能同時包含 VMess、VLESS 等多種節點，使用者目前選取的項目才是這次日誌的上下文。
依請求鏈逐層定位，避免同時修改所有設定
一個請求從瀏覽器到遠端目標至少會經過五層。最有效的方法是從離自己最近的一層開始驗證，每次只確認一個事實。上一層未通過前，先不要調整下一層的參數。
- 驗證系統代理。開啟 v2rayN 後確認系統代理處於預期模式。瀏覽網頁時日誌完全沒有新增紀錄，表示請求可能沒有進入 127.0.0.1 的本機代理連接埠。
- 驗證本機監聽。以用戶端狀態列顯示的數值為準。常見設定會使用 SOCKS 10808、HTTP 10809，但連接埠可以由使用者修改，不能只依教學中的預設值判斷。
- 驗證路由結果。暫時切換至較簡單的全域代理進行測試。如果全域模式可用而規則模式失敗，請重點檢查網域規則、IP 規則、block 出站與最終比對順序。
- 驗證節點連線。日誌出現目標節點位址後，觀察失敗發生在 DNS、TCP、TLS、WebSocket、gRPC 還是使用者驗證階段。
- 驗證目標差異。多個常見網站都失敗，比較像節點或本機鏈路問題；只有單一網域失敗，則優先查看 DNS 結果、路由比對與目標網站本身的狀態。
本機連接埠可以使用 curl 進行最小請求測試。以下分別透過 HTTP 代理連接埠 10809 與 SOCKS 連接埠 10808 請求本站，請替換為用戶端顯示的實際連接埠。10 秒上限有助於區分快速拒絕與持續逾時。
curl --proxy http://127.0.0.1:10809 https://v2help.com -I --max-time 10
curl --proxy socks5h://127.0.0.1:10808 https://v2help.com -I --max-time 10若指令立即提示無法連線至 127.0.0.1，問題在本機監聽或連接埠填寫；若本機連接埠可連線，但約 10 秒後逾時，應回到核心日誌查看遠端連線；若能收到 HTTP 回應標頭，而瀏覽器仍無法開啟，請重點檢查瀏覽器代理覆寫、擴充功能設定，或系統代理是否遭其他程式改寫。
DNS、路由與時間問題在日誌中的典型表現
DNS 問題不只表現為「網域不存在」。同一個節點網域可能回傳 IPv4 與 IPv6，不同網路對兩類位址的可達性也不同。日誌反覆嘗試某個 IPv6 位址並逾時，而切換至 IPv4 後恢復，表示解析本身成功，但目前網路通往該位址族的路徑不可用。
日誌顯示 no such host，應該先改什麼？
先核對節點位址是否含多餘空格或錯誤字元，再切換用戶端 DNS 設定並重新啟動核心。若訂閱剛更新，重新選取節點，避免目前執行中的實例仍引用舊設定。
只有部分網站失敗，但節點測試正常？
將路由模式暫時切換至全域代理後重新測試。全域模式可用時，查看存取日誌中的 outboundTag，確認失敗網域是否誤進 direct 或 block 出站。
invalid user 偶爾出現，重新連線又恢復？
先開啟系統自動設定時間與時區，手動觸發一次時間同步，再重新連線。接著更新訂閱，排除伺服器已更換 VMess 使用者資訊、而本機仍保留舊節點的可能性。
訂閱更新逾時和節點逾時是一回事嗎？
不是。訂閱更新是用戶端取得設定的請求，節點連線則是核心出站。查看日誌來源與目標位址；必要時先連線至可用節點，再在訂閱設定中啟用透過代理更新。
Android 在背景切回應用程式後才出現大量錯誤？
先確認 v2rayNG 或 v2flyNG 的連線狀態，再檢查系統省電策略是否暫停背景網路。將用戶端加入省電白名單後，連續鎖定螢幕 10 分鐘進行一次對照測試。
路由誤判通常具有明顯的「選擇性」：某些網域始終正常，某些網域每次都進入 direct 或 block。存取日誌中的出站標籤比錯誤日誌更重要。修改規則後要重新啟動或重新載入設定，並確認新請求的時間戳記已經變更。
時間問題主要影響需要時間驗證的認證流程。檢查的不只是時鐘顯示，還包括日期、時區與自動同步狀態。即使螢幕上的小時數看起來正確，錯誤時區搭配手動設定時間，仍可能造成實際時間偏差。
整理日誌時應保留哪些內容，哪些資訊需要隱藏
向他人描述問題時，完整環境比單獨截取 failed 更有價值。至少寫明用戶端名稱與版本、使用的核心、節點協定、問題出現時間、是否所有節點都失敗、目前網路類型，以及執行過哪些對照測試。這樣可以避免重複詢問，也能判斷錯誤是否來自同一次操作。
- 保留：錯誤發生時間、日誌層級、模組名稱、錯誤鏈、目標連接埠、傳輸類型與本機監聽連接埠。
- 保留：v2rayN 7.x、v2rayNG 1.9.x 等用戶端版本範圍，以及 Xray 或 v2fly 核心類型。
- 隱藏：完整訂閱網址、UUID、密碼、驗證字串、節點網域與可識別個人網路的資訊。
- 說明：節點位址可替換為 node.example，但連接埠、協定、TLS 開關與路徑是否一致，應明確寫出。
- 附上：重現步驟與結果，例如「全域模式成功，規則模式失敗」或「HTTP 10809 可連線，遠端 443 逾時」。
日誌排查的核心不是記住所有英文，而是辨識失敗發生在哪一層。沒有存取紀錄先查代理入口；出現 no such host 先查 DNS；出現 timeout、refused 或 reset 先查網路與連接埠；進入 TLS 或傳輸交握後再核對對應參數；出現 invalid user 才回頭檢查驗證資訊與時間同步。
完成一次修改後，應使用相同目標、相同節點與相同測試方式重新重現，並比較新舊日誌。只有控制變數，才能確認問題確實解決，而不是暫時繞過，或被另一個背景請求掩蓋。