v2rayN 執行日誌解析：常見錯誤原因與故障排除方法

本文重點

網頁無法開啟時，先確認本機是否成功監聽，再查看請求有沒有進入核心，最後判斷問題出在 DNS 解析、遠端連線還是通訊協定交握。本文以 Windows 上的 v2rayN 與 Xray 核心為例，說明連接埠檢查指令、常見錯誤及單次請求重現方式，適合已匯入節點、想找出問題所在層級的使用者。

一、先分清用戶端提示與核心日誌

v2rayN 是管理用戶端，Xray 才是實際處理連線的核心。訂閱下載失敗或介面設定無法儲存，可能是用戶端這一層的問題；監聽連接埠、路由選擇、連線至節點及 TLS 交握，則主要要看核心輸出。用戶端能啟動，不代表核心已成功監聽；清單中有節點，也不代表節點能建立連線。

開始排查前，先記下 v2rayN 與 Xray 各自的版本號。可在「說明」→「關於」查看用戶端版本，並從核心啟動輸出記錄 Xray 版本。不同桌面介面的選單配置可能不同；本文以「設定」→「參數設定」中的項目名稱作為查找依據，不會將特定版本的預設連接埠視為所有版本通用的固定值。

本機監聽接收請求路由比對遠端連線通訊協定交握

沿著這個流程反向縮小範圍：本機連線遭拒時，先別急著更改節點密碼；若已出現節點位址但撥號逾時，就別只檢查瀏覽器設定；憑證錯誤表示流程已進入 TLS 驗證階段，但不代表代理通訊協定驗證已成功。

二、日誌等級與單行記錄的閱讀方式

Xray 常見的錯誤日誌等級有 debug、info、warning、error，另有 none 可用來關閉這類日誌。設為 warning 時，通常不會顯示較低等級的 info 與 debug。存取日誌則是另一種記錄，不能簡單視為 info 錯誤日誌。

等級	主要用途	使用建議
debug	查看更詳細的連線與處理流程	僅在重現問題期間短暫啟用
info	確認啟動、連線處理等一般事件	適合作為初步排查的起點
warning	查看異常連線與可能的設定問題	搭配目標請求判斷影響範圍
error	找出較嚴重的執行錯誤	優先確認是否影響啟動或監聽

以下是簡化的存取記錄示意，並非實測結果。日誌日期格式、連線識別碼及出站標籤會依核心版本與產生的設定而異。方括號中的標籤是設定名稱，不能只憑名稱判定實際路由正確。

2026/10/03 10:20:31 from tcp:127.0.0.1:52134 accepted tcp:example.com:443 [socks -> proxy]

127.0.0.1:52134 是發起連線的本機來源，其中 52134 通常是臨時連接埠，不是要填入瀏覽器的代理監聽連接埠。
example.com:443 是這次請求的目標。排查時要區分目標網站位址與節點伺服器位址。
accepted 表示已接收傳入請求，不能據此斷定遠端連線成功或網頁已載入完成。
有連線識別碼時，沿用同一識別碼追蹤相關記錄；沒有識別碼時，則依時間與目標位址比對前後記錄。

結論：先找出同一次請求，再查看最內層原因

針對一次失敗的請求，保留前後約 10～20 行記錄，沿著錯誤鏈查看最後的系統錯誤或 TLS 錯誤。只截取最外層的 failed to process，通常不足以判斷該修改哪個設定。

三、連接埠占用：確認核心是否真正啟動

如果核心一啟動就退出，或視窗反覆出現啟動訊息，請優先搜尋 bind、address already in use。連接埠衝突發生在本機，通常無法透過更換訂閱或遠端節點解決。以下英文片段是常見錯誤關鍵字，實際輸出可能會包含多層錯誤前綴。

錯誤：address already in use

原因：準備監聽的本機位址與連接埠已被其他程序占用。

解法：找出占用連接埠的程序，關閉重複執行的用戶端；若確實需要同時執行，請為兩個程式設定不同的監聽連接埠。

錯誤：Only one usage of each socket address

原因：Windows 回報通訊端繫結衝突，常見原因是舊的核心程序仍在執行。

解法：在工作管理員確認程序所屬程式，關閉對應程式後重新啟動 v2rayN；不要直接結束不熟悉的系統程序。

先到「設定」→「參數設定」查看本機監聽連接埠。假設介面顯示 10808，請在 Windows 終端機執行以下兩個指令；第二個指令中的 4321 只是第一個指令輸出最末欄查到的 PID，請替換為實際數字。

netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 4321"

請留意本機位址欄與 LISTENING 狀態，不要只因搜尋結果中出現 10808 就認定連接埠遭占用。關閉用戶端後，若連接埠仍由其他程序監聽，才需要繼續確認程序所屬程式。連接埠恢復正常後，重新啟動核心並查看是否仍有繫結錯誤。

四、逾時與連線遭拒：區分 DNS 解析和遠端網路

「逾時」只表示某個階段未能在期限內完成，不代表節點一定失效。先確認錯誤涉及本機連接埠、節點伺服器還是目標網站，再查看發生於 DNS 解析、TCP 撥號，或連線建立後的讀寫階段。

錯誤：lookup … no such host

原因：這次 DNS 查詢未取得可用結果，查詢對象可能是節點網域，也可能是目標網站網域。

解法：先確認日誌中的網域拼寫正確，再檢查負責這次查詢的 DNS 設定；不能只因瀏覽器可以解析，就排除核心端的問題。

錯誤：dial tcp … i/o timeout

原因：TCP 撥號未能及時完成，可能與伺服器沒有回應、網路封包遺失、防火牆或位址選擇有關。

解法：確認節點位址與連接埠，改用其他網路或可用節點進行單一變因測試，並記錄是否只有同一台伺服器連線失敗。

錯誤：connection refused

原因：連線遭到明確拒絕，常見原因是對應連接埠沒有服務在監聽，或網路設備主動拒絕連線。

解法：若目標是 127.0.0.1，請檢查本機監聽狀態；若目標是節點伺服器，請確認遠端連接埠，並向服務提供者確認服務狀態。

在 Windows 上可用以下指令檢查節點的 TCP 連接埠是否可連通。這裡的網域僅供說明，執行前請替換成節點設定中的實際伺服器位址，連接埠也要與節點設定一致。此測試是從目前系統網路發出的 TCP 探測，不是完整的代理連線測試。

Test-NetConnection -ComputerName node.example.com -Port 443

TcpTestSucceeded : True 只能證明這次 TCP 連線成功，無法驗證 UUID、TLS、REALITY 或傳輸層設定。
結果為 False 時，請搭配另一個網路對相同連接埠進行測試；單次失敗無法確定是哪一段連線遭到阻擋。
節點位址解析成功，不代表目標網站的 DNS 一定正常；兩者可能使用不同的解析路徑。
速度測試與網頁瀏覽可能使用不同目標及路由，請以失敗網頁對應的日誌為準。

五、交握失敗：確認 TLS 與節點參數

TCP 可連通但仍無法使用時，再檢查交握階段。VLESS 與 VMess 是代理通訊協定，TLS 是安全傳輸的一部分，WebSocket、gRPC 等則是傳輸方式；這些設定彼此相關，但不能互相取代。選對通訊協定並填妥連接埠，只完成了部分設定。

錯誤：x509: certificate has expired or is not yet valid

原因：憑證有效期限與目前時間不符，可能是憑證已過期，也可能是裝置日期或時間有誤。

解法：先在 Windows「設定」→「時間與語言」→「日期與時間」同步時間；若時間正確但仍出現錯誤，請服務端檢查憑證有效期限。

錯誤：x509: certificate is valid for …, not …

原因：用於驗證的伺服器名稱與憑證涵蓋的網域不相符。

解法：依服務提供者的設定確認 TLS 伺服器名稱或 serverName，不要隨意將節點 IP 填作憑證網域。

錯誤：websocket: bad handshake

原因：WebSocket 升級請求未收到預期回應，常見原因是路徑、Host 或反向代理設定不相符。

解法：逐一確認 WebSocket 路徑、Host、TLS 開關與連接埠；路徑的大小寫與斜線都要保留，不要只更換 UUID。

如果只看到 EOF 或 connection reset by peer，只能判斷連線提前中止，不能據此認定密碼錯誤。伺服器主動關閉、代理通訊協定參數不符或中間網路重設，都可能出現類似情況。請先確認完整參數，再比較同一節點在其他網路上的結果。

確認伺服器位址、連接埠、通訊協定與使用者識別碼，避免手動編輯時將 VLESS 參數套用到 VMess 節點。
確認 TLS 伺服器名稱與傳輸層設定；WebSocket 的 Host 和 TLS 的 serverName 是不同欄位，請勿混填。
使用 REALITY 時，請依原始設定確認公鑰、shortId、serverName 等參數，不要套用一般憑證錯誤的處理方式。
建議先重新匯入服務提供者提供的有效節點設定，再逐項比對，避免多次手動修改後無法追蹤差異。

結論：遇到交握錯誤先核對參數，不要先關閉驗證

憑證名稱或有效期限異常時，請先修正時間、serverName 或伺服器端憑證。關閉憑證驗證只會掩蓋真正問題，不適合當成日常設定。

六、透過單次請求重現問題

排查時最容易踩的陷阱，就是同時更換 DNS、修改路由、更換節點並啟用 TUN。即使之後恢復正常，也無法判斷是哪項修改奏效。以下流程每次只使用一個節點、一個目標及一種流量接管方式，方便比較變更前後的差異。

記錄目前狀態

記下用戶端與核心版本、目前使用的節點、路由模式、本機連接埠及 TUN 是否啟用。先保留原始設定，以免排查時失去可還原的基準。
調整日誌等級

前往「設定」→「參數設定」，找到「日誌等級」，暫時改為 info；若資訊仍不足，再改用 debug。儲存後重新啟動核心，並確認啟動記錄已更新。
固定流量入口

先關閉 TUN，在主畫面選擇「系統代理」→「自動設定系統代理」，並使用遵循系統代理設定的瀏覽器進行測試。若要測試指定代理連接埠，請勿將測試結果與自動接管混在一起。
重現一次

關閉自動重新整理頁面與背景下載，記下目前時間，只開啟一次無法連線的網址。複製該時間附近的啟動、請求與錯誤記錄，不要只截取最後一行。
單一變因比對

只更換節點或只更換網路，再開啟相同網址。問題排除後，將日誌等級恢復原值，並確認系統代理與 TUN 已回到預期狀態。

若要排除瀏覽器代理設定的影響，可使用以下指令。此指令假設 10808 是目前實際啟用的 SOCKS 監聽連接埠，最長等待 15 秒；若連接埠不同，請先修改指令。socks5h 會將目標網域交由代理端解析，但不會決定核心內部採用哪種 DNS 策略。

curl.exe --proxy socks5h://127.0.0.1:10808 --max-time 15 --head https://example.com/

收到 HTTP 狀態碼，表示這次請求至少取得了 HTTP 回應；即使狀態碼是 403 或 405，也應與連線逾時分開處理。如果指令成功但瀏覽器失敗，請優先檢查瀏覽器個別的代理設定、擴充功能及系統代理接管；若兩者都在相同階段失敗，再沿著核心錯誤鏈繼續排查。

七、常見問題與分享日誌前的處理

節點延遲測得到數值，為什麼網頁還是打不開？

先確認執行的是 TCP 延遲測試，還是真正的連線測試。TCP 建立連線無法驗證完整代理路徑；在主畫面選取節點，按右鍵查看「測試伺服器真實連線延遲」結果，再對照失敗網頁的日誌，確認目標、路由與交握階段。

沒有錯誤訊息，也完全沒有請求記錄，該怎麼辦？

先確認日誌等級與存取日誌是否已啟用。使用指定 SOCKS 連接埠的 curl 指令重現問題，再與瀏覽器測試結果比較；只有瀏覽器請求未進入核心時，才檢查「系統代理」→「自動設定系統代理」及瀏覽器本身的代理設定。

訂閱更新逾時，需要按照節點交握錯誤排查嗎？

先確認失敗的是訂閱下載還是節點連線。前往「訂閱群組」檢查訂閱網址與目前的更新方式；若需要透過代理下載訂閱，請先確認已有可用節點，再選擇透過代理更新。訂閱下載錯誤不能直接證明清單中的所有節點都已失效。

日誌偶爾出現 EOF，需要立刻更換節點嗎？

不必只憑這一筆記錄下結論。先確認同一時間的網頁是否真的載入失敗；關閉頁面或取消連線也可能伴隨連線結束記錄。只有錯誤穩定地對應到目標請求時，才繼續比較節點參數與網路狀況。

請別人協助排查前，需要隱藏哪些資訊？

請移除完整訂閱網址、存取權杖、UUID、密碼、私鑰及個人瀏覽記錄。保留錯誤關鍵字、時間順序、通訊協定與傳輸類型、連接埠，以及替換後仍一致的主機名稱；在公開討論區請勿附上整份原始設定。

有效的問題描述不必很長：寫清楚版本、系統、流量接管方式、失敗目標類型、重現時間，以及更換節點或網路後是否有變化。保留錯誤鏈結構比截圖範圍更重要。連接埠未監聽就處理本機啟動問題，遠端撥號失敗就檢查網路連通性，進入交握階段後再核對參數，依序排查就不必反覆回到起點。