本文適合已匯入訂閱，但遇到節點逾時、網頁無法開啟或連線不穩定的使用者。先分清用戶端日誌與核心日誌，再依照請求時間、目標位址、出站標籤與最終錯誤逐層檢查，就能判斷問題較接近系統代理、本機連接埠、DNS、節點參數，還是遠端伺服器。
先分清用戶端日誌、access 與 error
排查前先確認目前查看的日誌屬於哪一層。v2rayN 和 v2rayNG 負責管理訂閱、節點、系統代理與核心程序；Xray 或 v2fly 核心負責實際接收連線、執行路由並建立出站。用戶端介面顯示「啟動成功」，只代表核心程序已啟動，不表示某個節點一定能連線。
access 會記錄請求經過哪個入站、存取了什麼目標，以及最後選擇哪個出站。它適合用來回答「請求是否進入核心」和「網域由哪條規則處理」等問題。看到一筆 access 記錄，通常表示瀏覽器或應用程式已將流量送至本機代理連接埠。
error 更接近故障原因，常見內容包括網域解析失敗、連線逾時、連接埠遭占用、協定握手失敗與遠端主動中斷連線。日誌層級通常有 debug、info、warning 與 error。日常使用維持 info 即可；需要重現疑難問題時，再暫時切換至 debug，因為 debug 會快速產生大量記錄。
| 日誌來源 | 主要內容 | 優先檢查的問題 |
|---|---|---|
| 用戶端日誌 | 設定產生、核心啟動、訂閱更新、系統代理切換 | 核心檔案、設定格式、程序狀態與訂閱網址 |
| access 日誌 | 請求目標、入站標籤、路由結果與出站標籤 | 應用程式是否進入代理、分流規則是否符合預期 |
| error 日誌 | 連線、解析、握手、傳輸與監聽失敗 | 本機連接埠、DNS、節點參數、網路與遠端狀態 |
在 v2rayN 與 v2rayNG 中取得有效日誌
日誌只有與一次明確操作對應起來才有價值。開始前先停止連續測速、自動更新訂閱與背景下載，避免數十個並行請求混在一起。接著選擇一個節點，開啟日誌視窗，只重現一次問題。例如只存取一個確定可用的 HTTPS 頁面，或只執行一次實際連線測試。
以 v2rayN 7.x 為例，可先在主介面確認目前使用的伺服器，再進入「設定」→「參數設定」→「Core 類型」，檢查所選核心與目前設定相符。接著回到主介面的日誌區域查看啟動資訊。若要提高記錄詳細程度，可在參數設定中找到日誌層級，將 info 暫時改為 debug，儲存後重新啟動核心。
-
確認目前使用的節點
在 v2rayN 主清單中查看目前使用的伺服器，記下位址、連接埠與協定。常見遠端連接埠包括 443、8443，以及服務提供者指定的其他連接埠，不能用本機監聽連接埠取代。
-
重新啟動核心
儲存設定後執行一次「重新啟動服務」。先確認日誌出現設定載入與本機監聽成功，再存取網頁，避免把舊程序留下的記錄當成本次結果。
-
單次重現
開啟一個網頁或執行一次連線測試，等待 10 至 15 秒後停止操作。若同時測試 20 個節點，會產生多組 timeout，很難確認哪一筆對應目前節點。
-
複製上下文
從第一筆目標請求開始，連同後續 10 至 20 行一起儲存。不要只截取最後一行，因為最後的 context canceled 往往只是前一個連線失敗後的清理結果。
在 v2rayNG 中，可從側邊選單進入「日誌」查看運行記錄。v2rayNG 使用 Xray 核心時，日誌會同時包含 Android 端的啟動資訊與核心輸出。排查時重點尋找目前節點名稱、目標網域、出站標籤以及失敗發生的時間，不必從第一行開始逐字閱讀。
預設本機 SOCKS 連接埠常使用 10808，HTTP 連接埠常使用 10809，但實際值應以用戶端目前設定為準。如果其他應用程式手動填寫了 127.0.0.1:10809，而用戶端已改為 10811，應用程式請求根本不會進入目前核心，此時 error 日誌可能完全沒有對應記錄。
2026/07/15 14:32:10 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/15 14:32:12 from 127.0.0.1:53142 accepted tcp:example.com:443 [socks -> proxy]
2026/07/15 14:32:22 [Warning] app/proxyman/outbound: failed to process outbound traffic
2026/07/15 14:32:22 [Warning] common/retry: all retry attempts failed這組記錄表示本機 10808 已開始監聽，來自 53142 臨時連接埠的請求也進入 SOCKS 入站，並被送往名為 proxy 的出站。問題發生在建立出站連線之後，因此排查重點應轉向節點位址、遠端連接埠、網路可達性與協定參數，而不是繼續切換瀏覽器代理設定。
依照一筆請求的鏈路閱讀日誌
一筆代理請求通常會經過應用程式、本機入站、路由判斷、代理出站與遠端目標等階段。日誌中的順序不一定逐行嚴格對應，因為多個連線可能並行執行；但同一時間範圍內出現的目標網域、連線識別與出站標籤，仍能協助還原路徑。
第一步查看是否有 accepted。如果重新整理網頁後完全沒有新的 access 記錄，通常是系統代理未開啟、應用程式不讀取系統代理，或應用程式填寫了錯誤的連接埠。v2rayN 中還要區分「啟動核心」與「設定系統代理」：前者只會讓本機連接埠開始監聽，後者才會將支援系統代理的應用程式流量導向該連接埠。
第二步查看目標是否正確。日誌可能顯示 tcp:example.com:443，也可能顯示解析後的 IP。連接埠 443 通常對應 HTTPS，連接埠 80 通常對應 HTTP。如果存取網頁時，日誌中只有區域網路位址或完全無關的網域，應先關閉其他背景應用程式，再單獨重現一次。
第三步查看方括號中的路由結果。例如 [socks -> proxy] 表示請求從 socks 入站進入，並交由 proxy 出站；[socks -> direct] 表示規則讓它直接連線。若目標原本應透過代理，卻進入 direct，應檢查目前路由模式、網域規則與規則順序，而不是修改 VMess 或 VLESS 節點參數。
- 沒有 access 記錄：檢查系統代理狀態、本機監聽位址與應用程式使用的連接埠。
- 進入 direct 後失敗：檢查路由分流是否將目標誤判為直接連線。
- 進入 proxy 後 timeout：檢查節點位址、遠端連接埠、本機網路與伺服器狀態。
- 很快出現握手錯誤：對照訂閱中的協定、安全類型、傳輸方式、Host、路徑與 SNI。
- 成功連線後頻繁中斷：觀察是否只有特定網路、特定節點或大量傳輸時才會觸發。
常見錯誤訊息的含義與處理順序
一段 error 日誌通常包含多層包裝資訊。外層可能只寫 failed to process outbound traffic，真正原因通常位於後面的 caused by、dial、lookup 或 handshake 附近。閱讀時從末端的具體原因往前回看，比只搜尋第一行更有效。
錯誤：context canceled
原因與解法：目前請求被上層取消，常見於切換節點、重新啟動核心、關閉頁面或前一個連線失敗後的清理。先往上查看同一時間前 5 至 20 行；如果剛執行過重新啟動且之後連線正常，這筆記錄通常不需要單獨處理。
錯誤：i/o timeout
原因與解法：在規定時間內未完成連線或讀寫。先確認一般網路可用，再核對節點位址與遠端連接埠，接著更換同一訂閱中的另一個節點測試。多個節點同時逾時時，更應檢查本機網路、系統時間與 DNS。
錯誤：connection refused
原因與解法：目標主機明確拒絕了對應連接埠的連線，可能是遠端服務未監聽、連接埠填寫錯誤，也可能是本機應用程式連線至尚未啟動的 10808 或 10809。根據日誌中的目標 IP 判斷拒絕發生在本機還是遠端。
錯誤：failed to find an available destination
原因與解法：核心無法取得可用目標，通常與節點網域解析失敗或目標設定異常有關。檢查伺服器位址是否含有空格或多餘字元，切換至可用的 DNS 後重新啟動核心，再觀察是否出現更具體的 lookup 錯誤。
錯誤：rejected
原因與解法：請求遭路由規則、協定檢查或目標策略拒絕。先查看同一行附近的出站標籤與原因；若顯示進入 block 出站，應調整路由規則；若伴隨 invalid request 或驗證資訊錯誤，則從有效訂閱重新匯入節點參數。
錯誤：EOF
原因與解法：連線對端在預期資料傳輸完成前關閉連線。偶爾發生一次可能只是網頁取消請求；若每次連線同一節點都立即出現，應核對 VMess 或 VLESS 的傳輸方式、TLS、安全設定、Host、路徑與 SNI。
rejected 不能一概理解為節點失效。例如路由設定將廣告網域送入 block 出站時，拒絕就是預期行為。判斷它是否屬於故障，必須同時查看目標網域與出站標籤。如果只有某個遭規則封鎖的請求出現 rejected，而主要頁面已正常載入，就不需要更換節點。
context canceled 也經常是結果而非原因。使用者在測速尚未完成時切換節點，舊連線會被取消；用戶端重新啟動核心時，正在進行的 DNS 查詢與出站連線也會結束。只有在沒有任何手動操作，且每次請求都被取消時，才需要繼續檢查程序反覆重啟、自動重新整理設定或網路切換。
從日誌縮小到 DNS、連接埠、參數或遠端狀態
發現錯誤後不要同時修改多個設定。一次只驗證一個假設，才能確認哪項操作真正有效。建議先確認本機鏈路，再確認網域解析，接著比較多個節點，最後才逐項檢查協定參數。直接刪除全部設定重新匯入，可能暫時恢復，卻會失去排查線索。
如果日誌出現 lookup、no such host 或無法取得目標位址，優先檢查 DNS。先確認節點伺服器位址沒有複製錯誤，再比較網域節點與 IP 節點的表現。只有網域節點失敗而 IP 節點可用時，DNS 線索才更明確；若所有節點都失敗，還要檢查本機網路與核心啟動狀態。
| 觀察結果 | 較可能的範圍 | 下一步驗證 |
|---|---|---|
| 10808 監聽失敗 | 本機連接埠遭占用 | 結束舊程序或改用未被占用的連接埠，重新啟動後確認 listening 記錄 |
| 沒有新的 access 記錄 | 系統代理或應用程式代理設定 | 核對應用程式填寫的 127.0.0.1 與實際 HTTP、SOCKS 連接埠 |
| 多個網域節點都 lookup 失敗 | DNS 或目前網路 | 切換至穩定網路並重新解析，避免同時修改節點協定參數 |
| 只有一個節點持續 timeout | 節點連接埠或遠端服務 | 使用同一訂閱中的其他節點比對，確認是否為單一節點問題 |
| 所有節點立即握手失敗 | 系統時間或參數不相容 | 同步系統時間，再重新更新訂閱並核對傳輸參數 |
| proxy 成功但特定網域走 direct | 路由分流 | 檢查網域規則、規則優先順序與目前代理模式 |
連接埠問題需要區分本機連接埠與遠端連接埠。本機 10808、10809 用於應用程式連線至用戶端；節點的 443、8443 等連接埠用於核心連線至伺服器。若日誌寫著無法監聽 127.0.0.1:10808，應處理本機連接埠占用；若寫著連線至某個伺服器位址的 443 逾時，修改本機 SOCKS 連接埠通常沒有作用。
協定參數問題通常表現為 TCP 已連線，但握手很快失敗。VMess 需要正確的使用者識別、傳輸方式與安全設定；VLESS 需要正確的使用者識別、傳輸層參數，以及與伺服器端一致的 TLS 或其他安全設定。WebSocket 情境還要核對路徑與 Host，使用 TLS 時則要核對 SNI。最穩妥的做法是更新有效訂閱，不要憑猜測自行補寫參數。
幾個容易誤判的日誌問題
日誌中出現 warning，不代表所有連線都失敗。瀏覽器開啟頁面時會並行請求圖片、指令碼、統計網址與背景介面，其中某個次要請求逾時，主頁面仍可能正常。判斷影響範圍時，應同時觀察目標網域、失敗次數與實際頁面狀況。
日誌一直出現 timeout，是訂閱失效了嗎？
先停止批次測速，只選擇一個節點存取一個頁面。若該節點失敗，再測試同一訂閱中的第二個節點。只有多個節點在同一網路下都逾時，才繼續檢查訂閱有效性、本機網路、系統時間與 DNS。
出現 context canceled 要換節點嗎？
先查看出現前是否切換節點、重新啟動服務或關閉測試頁面。如果有這些操作，它多半是連線清理資訊。若沒有手動操作，則往前尋找首次出現的 timeout、EOF 或程序退出記錄。
核心顯示啟動成功，網頁為什麼無法開啟？
檢查重新整理網頁時是否產生 access 記錄。沒有記錄就核對系統代理與 10808、10809 等實際監聽連接埠；有記錄則繼續查看請求進入 direct、proxy 還是 block 出站。
只有一個網站無法開啟要怎麼查？
清除目前日誌後只存取該網站，記錄目標網域與出站標籤。若它被送入 direct，可暫時調整對應網域規則進行驗證；若進入 proxy 後失敗，再檢查 DNS 結果與目標網站的連線記錄。
v2rayN 能用，v2rayNG 卻逾時怎麼辦？
不要直接判定節點故障。先確認兩端使用同一份最新訂閱與同一個節點，再比較網路環境、系統時間、Xray 核心版本、傳輸參數與 DNS 設定。不同網路下的結果不能直接互相替代。
另一個常見誤區是只看延遲測試。延遲數值能反映一次探測所需的時間，但無法完整驗證實際代理鏈路。某節點顯示 180 毫秒，不代表它的協定握手、TLS 參數與網頁傳輸一定正常；反過來，某種測試方式逾時，也不一定代表實際連線無法使用。最終應以實際存取結果與對應日誌為準。
完成排查後，將 debug 日誌層級恢復為 info，並保留一份簡短結論。例如「本機 10808 正常監聽，access 進入 proxy，兩個節點都在連線至遠端 443 後約 10 秒 timeout」。這樣的記錄比「用戶端不能用」更容易在下次遇到類似問題時快速比對。