適合已匯入設定，但遇到無法連線或連線時好時壞的使用者。先確認日誌來自客戶端還是核心，再依序檢查本機監聽、網域名稱解析、遠端連線、TLS 與協定參數。本文整理錯誤訊息對照、Windows 檢查指令及可重複操作的重現步驟，重點是找出問題發生在哪一層，而不是看到紅字就把所有設定都改掉。
先分清客戶端日誌、存取日誌與錯誤日誌
v2rayN 是桌面客戶端，負責管理設定、啟動核心及設定系統代理等操作；實際處理連線的是所選用的核心。Android 上的 v2rayNG 主要使用 Xray 核心，v2flyNG 則使用 V2Fly 核心。客戶端介面的異常提示與核心連線錯誤並非同一回事：訂閱下載失敗，不代表目前的代理連線一定無法使用；核心尚未啟動，也無法靠修改瀏覽器 DNS 解決。
開始排查前，先記下客戶端版本、實際使用的核心名稱與版本。兩種核心的錯誤訊息格式及支援的設定範圍可能隨版本變動，不要直接貼上另一種核心的完整設定。以下依錯誤訊息的含義說明；範例中的位址、連接埠及文字片段僅供參考，不代表特定版本的完整輸出格式。
| 日誌來源 | 主要記錄內容 | 優先檢查項目 |
|---|---|---|
| 客戶端日誌 | 更新訂閱、啟動程序、產生設定 | 執行環境、檔案權限、訂閱請求 |
| 核心存取日誌 | 收到的目標請求、入站與出站資訊 | 應用程式請求是否進入核心、分流結果 |
| 核心錯誤日誌 | 解析、撥號、握手及設定異常 | 最底層原因及其目標位址 |
存取日誌出現 accepted，通常表示本機入站已收到請求，但不代表遠端連線已完成，更不代表網頁已收到完整回應。反過來說，沒有看到存取日誌，也可能只是尚未啟用存取日誌，不能立刻認定應用程式繞過了代理。
日誌層級怎麼選？先用 warning，再短暫開啟 debug
Xray／V2Fly 常見的錯誤日誌層級有 debug、info、warning、error、none。設為 warning 通常會保留警告與錯誤；設為 debug 則會提供更多除錯資訊；none 會停用錯誤日誌輸出。存取日誌有獨立設定，不應與錯誤日誌層級混為一談。
-
確認核心
在 v2rayN 的啟動資訊中記下核心名稱、版本與啟動結果，確認目前執行的是預期的核心，而不只是查看節點使用 VMess 或 VLESS。
-
調整層級
v2rayN 常見的設定路徑為「設定」→「參數設定」→「Core: 基礎設定」→「日誌等級」。不同版本可能調整分類或名稱，請以目前介面為準。暫時選擇 debug 後儲存並重新啟動核心。
-
重現一次問題
記下系統時間，只開啟一個要測試的網址。收集該時間點前後約 10 秒的連續日誌，不要同時執行速度測試、更新訂閱或開啟多個網頁。
-
還原設定
重現問題後，將層級還原為 warning，並視需要關閉存取日誌。分享日誌前，請遮蔽訂閱網址、使用者識別資訊、驗證資料與私人網域，保留錯誤類型及必要的連接埠資訊。
使用自訂核心設定時，日誌區段可採用以下形式。這只是頂層 log 設定片段，並非可獨立執行的完整設定；客戶端產生的設定可能在下次啟動時被覆寫，建議優先透過客戶端介面修改。
{
"log": {
"loglevel": "debug"
}
}沿著連線流程讀日誌：先找出失敗對象，再看最底層原因
這是用來說明排查順序的示意圖，並非所有請求都會嚴格依照這個時間順序執行。路由可能會提早觸發 DNS 解析，直連出站也可能不經過代理伺服器。閱讀日誌時，請一併確認請求目標、選用的出站及實際撥號位址，避免將「目標網站無法連線」誤判為「代理伺服器連接埠不通」。
以下是簡化的錯誤鏈。外層訊息表示代理請求未能完成，內層的 dial tcp 才指出 TCP 連線失敗。203.0.113.10 是文件範例位址，443 是範例遠端連接埠，請勿直接用作實際節點設定。
proxy: failed to process outbound traffic
transport/internet: failed to open connection
dial tcp 203.0.113.10:443: i/o timeout- 先核對時間：只檢查這次重現問題的時間範圍，避免將上次切換節點時留下的錯誤，誤認為目前的問題。
- 再核對請求：若日誌附有連線識別碼，請用相同識別碼串起相關資訊；多個並行請求的相鄰行，不一定屬於同一條連線。
- 最後查看原因：逐層展開錯誤鏈，找出解析失敗、連線遭拒、逾時或憑證驗證失敗等具體原因。
判斷方向：先確認失敗環節，不要先換協定
如果最底層原因仍是遠端 TCP 連線逾時，請先測試位址與連接埠。在 TCP 連線尚未建立前，修改 VMess 使用者識別碼或 VLESS 參數通常無法解決問題。
常見錯誤訊息解析：連線遭拒、逾時、解析失敗與連接埠衝突
同一個關鍵字可能出現在不同層。尤其是 connection refused：連線至本機 127.0.0.1:10808 遭拒，與連線至遠端伺服器 443 遭拒，排查方向完全不同。以下列出常見的原始錯誤片段；具體前綴與系統錯誤描述可能有所差異。
錯誤：connection refused
原因：連線遭到明確拒絕，常見情況是目標連接埠沒有服務在監聽，也可能是防火牆主動拒絕連線。
處理方式：先確認日誌中的目標 IP 與連接埠；若是本機位址，檢查核心是否已啟動；若是遠端位址，則核對節點連接埠及伺服器端的監聽狀態。
錯誤：i/o timeout
原因：某次網路讀寫超過期限，可能發生在 TCP 建立連線、握手或後續資料傳輸階段。光憑這兩個詞，無法判定節點已失效。
處理方式：查看錯誤前面的操作名稱與位址；若發生於 dial 階段，檢查網路路徑與連接埠；若連線建立後才逾時，則檢查握手參數及遠端回應。
錯誤：no such host
原因：目前的解析流程未能取得該網域的有效解析結果，可能與拼字錯誤、缺少 DNS 記錄或解析器行為有關。
處理方式：先檢查節點網域的拼字，再使用系統 DNS 工具確認解析結果；若核心使用獨立 DNS，也要檢查核心 DNS 是否可連線及相關規則。
錯誤：address already in use
原因：本機監聽位址與連接埠已被其他程序占用，或同一個程式重複啟動。
處理方式：查出占用連接埠的程序並關閉重複執行的個體；若要變更入站連接埠，也必須同步調整應用程式的代理設定，不能只修改核心端。
錯誤：failed to find an available destination
原因：核心找不到可用的連線目標。這是概括性的錯誤，可能同時伴隨解析失敗、位址無法連線或多次撥號失敗。
處理方式：繼續查看後續的巢狀錯誤，依實際的解析或撥號原因排查，不要只憑這一行就判定是 DNS 故障。
TLS 握手失敗：核對憑證名稱、系統時間與傳輸參數
TLS 錯誤通常表示連線已進入安全握手階段，但不保證連到的是正確服務。連接埠錯誤、轉送設定不符或中間設備干擾，都可能使客戶端收到非預期的資料。如果設定使用其他安全機制，也不能直接套用一般 TLS 憑證故障的處理方式。
| 錯誤片段 | 含義 | 檢查方式 |
|---|---|---|
x509: certificate has expired or is not yet valid | 憑證有效期限與本機時間不符 | 校正系統日期、時間與時區，再檢查伺服器憑證的有效期限 |
x509: certificate is valid for | 憑證涵蓋的名稱與預期名稱不符 | 核對 serverName／SNI 與憑證網域 |
tls: first record does not look like a TLS handshake | 收到的資料不像預期的 TLS 記錄 | 確認遠端連接埠是否提供 TLS，並檢查反向代理入口 |
EOF 或 connection reset by peer | 資料流結束或連線遭重設，原因不只一種 | 依發生階段，核對傳輸類型、路徑、Host 與伺服器日誌 |
伺服器位址與 serverName 不一定相同：前者決定連線目的地，後者則用於 TLS 名稱驗證及 SNI。使用 WebSocket 時，路徑與 HTTP Host 也各有用途；連到正確的 IP，不代表這些欄位都已設定相符。VMess、VLESS 的身分識別參數也應與伺服器端一致，不能只看到 EOF 就判定是哪個欄位填錯。
Windows 排查範例：分別測試本機 10808 與遠端 443
以下假設客戶端設定中的本機 HTTP 或混合入站連接埠為 10808，遠端伺服器連接埠為 443。這只是明確的排查範例，不一定與你的預設設定相同。執行前，務必將連接埠與網域改成實際設定值；example.net 是文件中的範例網域，並非可用節點。
# PowerShell：查看本機連接埠是否正在監聽
Get-NetTCPConnection -LocalPort 10808 -State Listen
# 檢查系統 DNS 解析結果
Resolve-DnsName example.net
# 檢查指定的遠端 TCP 連接埠
Test-NetConnection -ComputerName example.net -Port 443
# 僅適用於已確認提供 HTTP 代理的本機入站
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/- 本機沒有監聽：先檢查核心啟動日誌、設定解析錯誤或連接埠衝突。此時反覆切換瀏覽器代理設定沒有幫助。
- 遠端 TCP 測試失敗：表示這次測試未能建立該 TCP 連線，仍需區分是位址、網路、防火牆或伺服器監聽問題；此指令不會測試 UDP。
- 遠端 TCP 測試成功：只能證明該連接埠可建立 TCP 連線，無法證明 TLS、VMess／VLESS 驗證或傳輸設定正確。
- 指令測試成功但瀏覽器失敗：優先檢查瀏覽器是否使用相同的代理入口，以及系統代理、擴充功能或應用程式的獨立代理設定。
如果本機連接埠只提供 SOCKS 入站，請改用 curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/。其中 socks5h 會將目標網域交由代理端解析，有助於與本機的解析路徑區分；但這不代表所有 DNS 請求都會自動以相同方式轉送。執行指令測試時，也要對照日誌時間，避免將其他背景程式的連線誤認為測試結果。
結論：一次只變更一個變數
先固定節點、目標位址與代理入口，再逐項驗證。每次只修改一項設定並重複相同請求，才能判斷改善是來自連接埠、DNS 還是握手參數，而非剛好切換了網路路徑。
日誌排查常見問題與求助資訊整理
日誌一直出現 warning，是否代表所有連線都失敗了？
不一定。背景應用程式重試或探測請求遭取消，也會留下警告。先暫停批次速度測試，只造訪一個目標並記下時間，再依目標位址或連線識別碼找出同一請求的相關日誌。
已開啟系統代理，日誌裡卻沒有瀏覽器請求？
先確認已啟用存取日誌，再核對系統代理指向的連接埠是否與客戶端入站一致。使用明確指定代理的 curl 指令進行比對；有些程式不會讀取系統代理，不能只看開關狀態就判斷代理接管範圍。
訂閱更新逾時，但已選取的節點仍能瀏覽網頁？
請將取得訂閱視為獨立的 HTTP 請求來排查。確認更新操作是使用直連還是代理、訂閱服務是否可連線，並檢查訂閱連結是否有效。排查更新失敗時，不要先刪除仍可使用的節點設定。
Android 連線後逾時，為什麼沒有 Windows 的連接埠資訊？
v2rayNG、v2flyNG 的 VPN 接管流程與桌面系統代理不同。請先在應用程式內查看日誌，記下核心版本、網路類型及故障時間；再核對節點網域、連接埠與安全設定，不要直接套用桌面端的本機入站連接埠。
整理求助資訊時，保留錯誤前後連續的日誌內容，比只截取單行更有幫助。可以依照以下清單記錄，先在本機儲存已去除敏感資訊的副本，再分享必要內容。訂閱連結通常包含存取權杖，即使沒有標示密碼，也不應公開。
- 作業系統類型、客戶端版本、實際使用的核心名稱與版本。
- 故障發生的確切時間，以及當時使用的是系統代理還是 TUN。
- 重現步驟、目標類型、是否每次都會發生，以及更換網路後的情況。
- 已去除敏感資訊的完整錯誤鏈、本機與遠端連接埠，以及上述指令的測試結果。
- 最近一次變更，例如更新設定、更換核心、調整 DNS 或切換網路。
最終目標不是讓所有日誌都不再出現，而是確保同一個請求的每一層都有可驗證的結果。若要進一步核對 DNS、入站與路由欄位，請參閱設定大全；若啟動或執行環境問題尚未解決，請先依照疑難排解檢查基本條件，再繼續分析網路連線。