適合已匯入節點,卻遇到網頁無法開啟、連線逾時或核心啟動失敗的 v2rayN 使用者。先保留一次失敗請求的完整錯誤鏈,再依序檢查本機監聽、流量接入、DNS、遠端連接埠與協定交握。本文說明日誌等級設定、常見英文錯誤訊息及 Windows 本機測試指令,避免把所有問題都歸咎於「節點失效」。
1. 開啟執行日誌,重現一次問題
v2rayN 是圖形用戶端,實際建立代理連線的是它啟動的核心。用戶端介面異常、核心啟動失敗、單一連線失敗,分別屬於不同層面的問題。查看日誌時,先確認目前選取的節點、核心類型及故障發生時間;分析時不要混入切換不同節點期間的錯誤訊息。
-
記錄目前設定
在主畫面記下用戶端版本、目前節點的協定與傳輸方式,再前往「設定」→「參數設定」查看本機監聽連接埠。桌面介面與傳統介面的設定分類可能不同,請以目前版本實際顯示的內容為準。
-
啟用診斷日誌
前往「設定」→「參數設定」,找到核心的「日誌等級」設定;部分版本會放在「Core:基礎設定」分類。使用 Xray 時先選
info,資訊不足時再暫時改為debug,儲存後重新啟動核心,讓設定生效。 -
單次重現問題
展開主畫面底部的執行資訊或日誌區域,記下目前時間。暫停批次測速,只保留一個節點,並開啟一次無法瀏覽的網站。複製該時間點前後的日誌,不要只截取最後一行。
-
還原日誌等級
排查完成後,將等級還原為
warning或原本的值。若有啟用日誌檔案記錄,也請確認儲存位置與檔案大小;診斷日誌可能記錄瀏覽的網域、本機位址及出口標記。
Xray 常見的日誌等級包括 debug、info、warning、error 和 none。等級會控制記錄的詳細程度,不會改變連線策略。只選 error 可能會漏掉有用的連線過程;長時間啟用 debug 則會增加記錄量,也更容易暴露瀏覽相關資訊。
2. 看懂錯誤鏈:先看位址,再找根本原因
一則日誌通常包含多層錯誤訊息。例如,最外層描述「處理連線失敗」,中間一層表示「找不到可用目標」,最裡層才是連線遭拒或逾時。排查時先確認錯誤鏈涉及哪個位址,再找出最具體的系統錯誤;不要一看到 failed 就修改協定。
| 日誌線索 | 實際含意 | 下一步 |
|---|---|---|
127.0.0.1:10808 | 本機回送位址與連接埠,常見於應用程式連線至本機代理。 | 檢查監聽狀態,確認應用程式設定的連接埠。 |
dial tcp | 正在嘗試建立 TCP 連線。 | 確認後方的位址屬於節點伺服器還是目標網站。 |
lookup、no such host | 網域名稱解析階段發生問題。 | 檢查錯誤訊息中的網域、DNS 路徑與回傳結果。 |
accepted | 核心已接受一筆入站請求。 | 繼續查看對應的出站結果;這不代表遠端連線已成功。 |
direct、proxy | 可能是目前設定中的出站標記。 | 對照實際路由設定;標記名稱並非固定標準。 |
以下是用來說明閱讀順序的簡化片段,並非實際測試紀錄。內容表示本機 TCP 連接埠拒絕連線;僅憑這則資訊,無法判斷遠端節點的品質。
dial tcp 127.0.0.1:10808: connectex: No connection could be made because the target machine actively refused it.
判斷重點:依位址確認排查對象
錯誤指向回送位址時,先檢查本機監聽;指向節點伺服器時,再檢查遠端連接埠。先確認連線的兩端,再決定是否需要修改節點參數。
3. 常見錯誤訊息與逐項處理方式
不同核心或作業系統可能會以略有差異的英文措辭呈現同一個問題。以下列出常見錯誤片段;比對時請保留前後文,尤其是位址、連接埠、傳輸類型及憑證名稱。若只有一則警告,但服務正常,不必立即修改設定;只有在錯誤反覆出現且確實造成故障時,才有診斷價值。
錯誤:connection refused
原因:目標位址拒絕連線,常見原因是該連接埠沒有服務在監聽,也可能是防火牆主動拒絕連線。
解決方式:先確認位址;若是本機連接埠,檢查核心是否啟動;若是遠端連接埠,確認訂閱中的伺服器與連接埠,並請伺服器管理者確認服務是否正在監聽。重試無法取代連接埠檢查。
錯誤:i/o timeout
原因:某次讀取或寫入未能在期限內完成,可能發生在 TCP 建立連線、TLS 交握或後續資料傳輸階段。
解決方式:依據 dial、read、write 判斷發生階段;固定使用同一個節點,換個網路重新測試。不要只憑逾時就認定密碼錯誤,也不要一味延長逾時時間。
錯誤:failed to handshake
原因:交握階段失敗,但這只是概括描述;後續的憑證、驗證、EOF 或逾時資訊,才會指出具體原因。
解決方式:依照伺服器要求逐項確認協定、TLS、SNI、傳輸方式及驗證參數;使用 REALITY 時,也要確認公鑰、shortId、serverName 與用戶端的支援情況。
錯誤:bind: Only one usage of each socket address
原因:Windows 上準備繫結的本機位址與連接埠已被其他監聽程序占用,常見於重複啟動程式。
解決方式:找出正在監聽的程序後,關閉重複執行的程式,或更換本機連接埠;若變更連接埠,也要同步更新瀏覽器、終端機及手動設定的代理位址。
錯誤:no such host
原因:網域名稱解析未取得可用結果,可能是網域拼字錯誤、DNS 回傳不存在,或查詢路徑異常。
解決方式:先區分節點網域與目標網站網域。確認拼字及訂閱更新結果,再檢查相應的 DNS 設定;不要直接將所有網域換成 IP,否則可能導致 TLS 名稱比對失敗。
錯誤:x509: certificate has expired or is not yet valid
原因:憑證有效期限檢查失敗,可能是伺服器憑證過期,也可能是本機日期與時間不正確。
解決方式:先同步系統時間,再請伺服器管理者檢查憑證續期與憑證鏈。不要把停用憑證驗證當成長期解決方案。
錯誤:failed to find an available destination
原因:這通常是目標連線失敗的外層摘要,不一定是 DNS 問題;內部錯誤也可能包含連線遭拒、逾時或位址無法連線。
解決方式:展開完整錯誤鏈,找出最具體的 lookup、dial tcp 或系統錯誤,再依照相應項目處理;不要一看到這句就直接更換 DNS。
EOF 與 connection reset by peer 也不能單獨證明驗證失敗。它們表示對端關閉或重設連線,原因可能是傳輸參數不符、伺服器策略、連線重複使用或中間的網路設備。若只在關閉網頁時偶爾出現,而新請求正常,建議先觀察;若每次交握都發生,再比對伺服器日誌。
4. 從本機連接埠到遠端設定,依序縮小範圍
以下使用 Windows PowerShell,並假設本機代理確實在 127.0.0.1:10808 上監聽。這只是範例數字,並非所有版本的固定值。請先前往「設定」→「參數設定」,確認本機監聽連接埠與入站類型;系統代理、獨立 HTTP 連接埠和混合連接埠不能憑印象互換。
第一層:確認本機是否有程序在監聽
Get-NetTCPConnection -LocalPort 10808 -State Listen
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
第一個指令用來查看監聽紀錄與 OwningProcess;找不到紀錄時會提示沒有符合的物件。第二個指令中的 TcpTestSucceeded : True 只表示本機 TCP 連接埠可連線,不代表 SOCKS 協定交涉或遠端代理已成功。若要確認程序身分,請在 Get-Process -Id 後接上查到的程序編號,以免誤關其他服務。
第二層:明確透過代理發出請求
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com/
此指令要求該連接埠支援 SOCKS5。socks5h 會將目標網域交由代理端解析,避免 curl 先在本機解析目標網域;核心實際如何解析,仍取決於其 DNS 與路由設定。example.com 是示範目標,並非節點伺服器。收到 HTTP 回應標頭,表示這次目標請求已完成相應連線流程,但不代表所有網站都正常。
- 指令立即拒絕連線:回頭檢查本機連接埠與監聽程序,不必先修改遠端參數。
- 本機連接埠可連線,但請求逾時:查看相同時間點的核心日誌,確認 DNS、節點位址與交握錯誤。
- 指令成功,瀏覽器失敗:檢查瀏覽器的個別代理設定、系統代理及代理例外清單。
- 只有一個網站無法連線:換另一個目標交叉測試,並檢查該網域的路由規則、DNS 結果及目標服務狀態。
第三層:區分路由設定與遠端連線狀態
系統代理決定願意遵循該設定的應用程式如何接入;路由分流則決定核心收到流量後使用哪個出口。為了隔離問題,可暫時切換成會將測試目標送往代理出口的路由模式,測試完成後再還原原設定。若要測試節點連接埠,請將 Test-NetConnection 的電腦名稱與連接埠改為節點詳細資料中的實際值;TCP 連線成功只代表連接埠可連線,不會驗證 VLESS、VMess 或 Trojan 的驗證與交握。
判斷重點:明確代理測試成功後,再檢查系統接入
如果 curl 的明確代理請求成功,但瀏覽器仍無法連線,請保持節點參數不變,先檢查系統代理與瀏覽器設定。這樣可避免在遠端連線已可使用的情況下引入新的變數。
5. 交握失敗時,確認協定與傳輸參數
成功匯入訂閱只表示用戶端已讀取設定,不代表伺服器仍可連線,也不保證目前的核心支援其中所有欄位。更新訂閱後,先確認選取的是更新後的項目;不要使用舊節點,卻拿新訂閱的內容來比對排查。
| 設定組合 | 優先確認項目 | 常見錯誤修改 |
|---|---|---|
| VMess | 使用者 ID、伺服器驗證設定、本機時間、傳輸設定。 | 未確認伺服器要求,就修改驗證欄位。 |
| VLESS + REALITY | 使用者 ID、公鑰、shortId、serverName、flow 及核心支援情況。 | 直接複製其他節點的公鑰或 flow。 |
| Trojan + TLS | 密碼、伺服器位址、連接埠、SNI、憑證鏈。 | 停用憑證驗證,藉此掩蓋網域或憑證錯誤。 |
| WebSocket 傳輸 | 路徑、Host、TLS 設定及反向代理設定。 | 把路徑的大小寫或結尾斜線當成無關資訊。 |
| gRPC 傳輸 | serviceName、TLS 設定、反向代理的 HTTP/2 支援。 | 只修改節點連接埠,未檢查反向代理。 |
傳輸方式與代理協定屬於不同層:VLESS 不會自動代表 REALITY,TLS 也不等於 WebSocket。請以伺服器完整設定為準,不要因為用戶端下拉選單有某個選項,就任意把節點改成另一種組合。排查時一次只修改一個欄位,重現同一個請求並記錄結果。
6. 常見問題與分享日誌前的檢查
延遲測試有數值,為什麼網頁還是無法開啟?
TCP 延遲只反映特定連接埠的連線建立情況,不一定包含協定驗證與網站瀏覽。請先用上方的明確代理請求重新測試,再比對該時間點的核心日誌;不要用單一延遲數值取代完整連線流程的驗證。
訂閱更新逾時,就表示節點一定故障嗎?
下載訂閱與連線至節點是不同的請求。先到「訂閱群組」檢查訂閱網址是否已過期,再確認更新時使用直連還是代理。若透過代理更新,必須先有可用節點;分享日誌時,請勿公開完整訂閱網址。
瀏覽器正常,命令列和遊戲卻連不上?
部分應用程式不會讀取系統代理設定。可先在命令列明確指定代理進行驗證;其他應用程式則要確認是否支援代理。考慮使用 TUN 前,先檢查權限、路由與 DNS,避免同時變更接入方式和節點設定,導致無法比較。
已經啟用 debug,為什麼還是找不到問題?
先減少背景請求,固定使用一個節點和一個目標,只重現一次。保留完整錯誤鏈,並記下用戶端版本、核心版本、系統版本及發生時間;必要時請伺服器管理者依相同時間範圍檢查伺服器日誌。
向他人求助時,應保留排錯所需的結構,同時刪除敏感資料。使用者名稱、訂閱權杖、節點驗證資訊,以及不必要的瀏覽紀錄都不應公開。只貼一張「逾時」截圖,通常無法判斷問題出在哪一層;一小段已遮蔽敏感資訊的完整錯誤鏈,比整頁捲動日誌更有用。
- 保留環境資訊:用戶端版本、核心版本、系統版本,以及是否啟用系統代理或 TUN。
- 保留重現資訊:故障時間、目標類型、是否每次都發生,以及更換網路後的結果。
- 保留設定結構:協定、傳輸方式、是否啟用 TLS 或 REALITY,以及錯誤涉及本機還是遠端。
- 移除機密資料:完整訂閱連結、UUID、密碼、私鑰及含權杖的查詢參數;無關的完整伺服器位址也可以遮蔽。
最後依原順序重新測試:核心成功啟動、本機連接埠可連線、明確代理請求有回應、日常使用的應用程式能如預期接入。四項都通過後,再還原一般路由設定與日誌等級。依照這個順序排查,比同時更換 DNS、連接埠和協定更容易得到可驗證的結論。