適合已匯入節點，卻遇到連線逾時或網頁無法開啟的使用者。先用命令確認本機代理是否收到請求，再檢查應用程式流量是否進入核心，最後核對節點參數與遠端連接埠。每次只變更一項設定並重新測試，便能分辨問題出在本機設定、協定交握或伺服器，避免一味認定節點失效。
一、先判斷逾時發生在哪個環節
v2rayN 是用來管理設定、啟動核心及設定系統代理的桌面用戶端，實際連線則由選用的核心負責。能開啟介面、成功更新訂閱，不代表代理連線已正常；下載訂閱與瀏覽目標網站也可能使用不同的網路路徑。排查時應觀察一筆實際請求，而不只是查看節點清單中的狀態。
先固定一個節點、一個目標網址和一種測試方式。暫停批次測速與自動切換，記下問題發生的時間。如果只有用戶端的測試結果顯示逾時，但瀏覽器仍可正常使用，先確認測試網址能否透過該節點連線；測試目標無法連線，不代表所有網站都無法使用。
- 所有節點都連不上：先檢查本機連接埠、核心啟動狀態與系統代理，不要立刻逐一修改節點。
- 只有一個節點連不上：在相同測試條件下，核對該節點設定、遠端連接埠與伺服器狀態。
- 只有一個應用程式無法使用：確認該應用程式是否遵循系統代理，以及是否另行設定代理或 DNS。
- 只有部分網站無法連線：進一步檢查路由規則、網域解析與目標網站限制，不要直接重裝用戶端。
二、本機連接埠：確認核心正在監聽
先在 v2rayN 的「設定」→「參數設定」中核對本機監聽連接埠與代理類型。不同版本的介面欄位位置可能不同，請以目前的設定與啟動記錄為準。以下以 127.0.0.1:10808 的混合入站為例；若實際使用獨立的 HTTP 或 SOCKS 入站，請換成相應連接埠，不要將範例數字視為所有版本的固定預設值。
Windows 可在 PowerShell 中執行以下命令。第一個命令檢查是否有連接埠正在監聽，第二個命令則用來查出結果中的處理程序編號所屬程式。只有出現 LISTENING 才表示連接埠正在監聽；只有連線記錄、沒有監聽記錄，不能算通過。
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 1234"第二個命令中的 1234 是範例處理程序編號，執行前請替換成第一個命令結果最後一欄的實際編號。macOS 和 Linux 可使用以下命令檢查；Linux 若未安裝 lsof，可改用 ss。
lsof -nP -iTCP:10808 -sTCP:LISTEN
# Linux 的另一種檢查方式
ss -lntp 'sport = :10808'- 沒有監聽：查看核心啟動記錄，排除設定載入失敗、缺少核心或權限錯誤，再重新啟用節點。
- 連接埠遭其他程式占用：先確認是哪個處理程序占用，再關閉衝突程式或更換入站連接埠；更換後也要同步更新應用程式的代理設定。
- 監聽位址不一致：若只監聽 IPv6 迴路位址，透過 IPv4 的
127.0.0.1存取可能會失敗，請確認位址與入站設定一致。
三、系統代理：以明確指定代理的請求排除問題
確認本機監聽正常後，先略過系統代理設定，直接向代理連接埠送出請求。Windows 請使用 curl.exe，避免部分 PowerShell 環境中同名別名造成行為差異；macOS、Linux 則使用 curl。以下的 example.com 僅為測試目標範例，命令中的連接埠必須與你使用的入站設定一致。
# Windows：僅適用於支援 HTTP 的入站
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
# macOS / Linux：僅適用於支援 SOCKS5 的入站
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.comsocks5h 表示將目標網域交由代理解析。這兩個命令分別測試不同的入站協定；僅支援 SOCKS 的連接埠不能使用 HTTP 代理語法。若收到 HTTP 回應標頭，表示請求已抵達能夠回應的一端；若回傳 403 等狀態碼，還需檢查網站的存取政策，不應將其視為連線逾時。
-
核對代理連接埠
在 v2rayN 的「設定」→「參數設定」中核對本機入站連接埠與類型，再執行相應的明確代理命令。
-
啟用系統代理
在 Windows 的 v2rayN 系統匣選單中選取「系統代理」→「自動設定系統代理」，啟用代理接管後重新開啟瀏覽器測試。
-
檢查系統設定
在 Windows 開啟「設定」→「網路和網際網路」→「Proxy」，確認位址與連接埠和用戶端設定一致，並檢查是否有其他程式反覆改寫設定。
-
排除應用程式設定覆蓋
檢查瀏覽器代理擴充功能與應用程式本身的網路設定，暫時停用獨立代理設定，只保留一種流量接管方式後重新測試。
結論：明確指定代理後可連線，先修正應用程式入口
如果命令執行成功，瀏覽器仍無法連線，先處理瀏覽器代理、系統代理與應用程式 DNS 設定之間的差異。此時更換節點通常無法解決流量根本沒有進入本機代理的問題。
在 macOS 可前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理」檢查設定。Linux 的系統代理是否影響特定程式，取決於桌面環境與應用程式的實作方式。命令列工具也不一定會讀取桌面代理設定，因此可能需要明確指定參數，或使用該工具支援的代理環境變數。
四、用戶端記錄：查看失敗階段，別只看最後一行
重新送出一次請求，同時查看 v2rayN 的記錄區或目前版本提供的記錄視窗。保留請求前後相鄰的幾行，尤其是入站位址、目標位址、路由出站與最內層錯誤。外層的「連線處理失敗」通常只是摘要，真正原因可能藏在後續的 DNS、TCP 或 TLS 錯誤中。
bind: address already in use
原因：程式嘗試繫結的本機位址與連接埠已遭占用。
解決方法：查出占用的處理程序並確認用途，排除衝突後重新啟動核心；若變更了連接埠，也要更新系統代理設定。
connect: connection refused
原因：連線遭到主動拒絕，常見情況是該連接埠沒有服務在監聽，也可能是裝置或防火牆主動拒絕連線。
解決方法：先確認錯誤中的位址屬於本機還是遠端，再檢查相應一端的監聽狀態與拒絕規則。
i/o timeout
原因：相關網路讀寫未能在期限內完成，單看這句錯誤無法判斷是節點失效還是目標網站沒有回應。
解決方法：參考前後相鄰的記錄，確認卡在解析、連線還是傳輸階段，再分別測試節點連接埠與目標網站。
x509: certificate has expired or is not yet valid
原因：憑證有效期限檢查未通過，可能是本機時間不準，也可能是伺服器憑證已過期。
解決方法：先同步系統日期與時間；若時間正確仍出現錯誤，請伺服器管理者檢查憑證及憑證鏈。
錯誤文字會因系統和核心而異，以上列出的是常見錯誤片段，並非每個版本都會逐字輸出完整記錄。如果核心已啟用存取記錄，卻找不到相應請求，優先檢查應用程式入口；若未啟用存取記錄，單憑「沒有看到請求」不能斷定流量未進入。
五、節點設定：逐項核對協定與傳輸參數
遠端連接埠能建立 TCP 連線，不代表代理驗證和傳輸交握一定成功。VMess、VLESS、Trojan、Shadowsocks 使用不同的驗證與安全機制；傳輸層、TLS 與協定名稱也不是同一類設定。只修改協定下拉選單，無法將節點轉換成另一種協定。
| 檢查項目 | 核對內容 | 修正方向 |
|---|---|---|
| 位址與連接埠 | 伺服器網域、IP、伺服器監聽連接埠 | 確認與服務提供者提供的資訊一致；不要將本機的 10808 填入節點遠端連接埠 |
| 協定與驗證 | VMess/VLESS 的 UUID、Trojan 的密碼、Shadowsocks 的加密方法與密碼 | 重新匯入完整設定，避免手動輸入時多出空格或漏掉字元 |
| 傳輸設定 | TCP、WebSocket 等傳輸類型，以及相應的路徑、Host | 逐項確認與伺服器設定相符；路徑大小寫及開頭的斜線也必須一致 |
| TLS 設定 | 是否啟用 TLS、伺服器名稱、憑證網域 | 依照伺服器要求填寫，並區分連線位址與 TLS 伺服器名稱 |
| 核心支援能力 | 所選核心是否支援節點所需的協定、傳輸方式與安全設定 | 查看實際啟動的核心及錯誤提示，不要只憑用戶端名稱推斷支援能力 |
訂閱有更新時，先透過「訂閱群組」中的更新功能取得最新設定，再確認目前使用的節點是否仍是舊資料。不要為了測試連線而任意刪除 TLS 伺服器名稱或關閉憑證驗證，這可能掩蓋設定錯誤並降低連線安全性。VMess 驗證也需要合理的系統時間，因此同步時間是基本檢查，不是只有憑證錯誤時才需要處理。
- Windows：前往「設定」→「時間與語言」→「日期與時間」，檢查是否自動設定時間並執行同步。
- macOS：前往「系統設定」→「一般」→「日期與時間」，確認時間來源及目前時間。
- Android：使用 v2rayNG 或 v2flyNG 時，也應檢查系統時間、節點欄位與連線記錄；桌面端的系統代理步驟不能直接套用到 Android 的 VPN 流量接管方式。
六、伺服器連線狀態：區分連接埠、交握與轉送
確認本機監聽、應用程式入口與節點欄位都沒有問題後，再測試目前網路能否連上遠端。Windows 可在 PowerShell 執行以下命令。範例中的 example.com 和 443 必須替換成你自己的節點伺服器位址與實際連接埠；直接執行範例並不能證明節點可用。
Test-NetConnection -ComputerName example.com -Port 443查看 TcpTestSucceeded 的結果。若為 True，只表示 TCP 連線已建立，不代表 UUID、密碼、TLS、WebSocket 路徑或伺服器轉送設定正確。若為 False，則需進一步檢查位址解析、伺服器監聽狀態、安全性群組與防火牆。若使用以 UDP 為基礎的傳輸方式，這項 TCP 測試也不能取代相應協定的檢查。
- 確認解析結果：使用
nslookup example.com檢查伺服器網域；先將範例替換成自己的節點網域，再確認結果符合伺服器部署情況。若有多個 IPv4、IPv6 位址，請分別留意實際連線使用的位址。 - 檢查監聽狀態：自行架設的 Linux 伺服器可使用
ss -lntp查看 TCP 監聽；UDP 服務則可使用ss -lnup。監聽位址、連接埠及處理程序應與部署設定相符。 - 檢查入口規則：雲端平台的安全性群組和系統防火牆都必須允許實際的伺服器連接埠及相應協定。不要長期關閉所有防火牆來代替問題排查。
- 檢查交握路徑：若使用反向代理，請繼續核對網域、TLS 憑證、轉送路徑與後端服務狀態；入口連接埠開放不代表後端運作正常。
- 檢查伺服器對外連線：若交握成功但無法存取目標，請檢查伺服器 DNS、對外連線、路由政策及目標網站的回應。
結論：使用同一節點進行網路對照測試
保持節點、裝置與目標網站不變，只換到另一個可信任的網路重新測試。如果只有特定網路失敗，優先檢查該網路的網域解析、IPv6 路徑與出口限制；若不同網路都在相同階段失敗，再集中檢查節點與伺服器。
ping 使用的 ICMP 可能遭伺服器或中間網路封鎖，因此 ping 不通不能單獨證明代理連接埠無法連線；反過來說，ping 有回應也不代表代理驗證成功。不要用單一測試結果取代整條連線路徑的驗證。
七、修正後重新測試，並保留可用基準
完成修改後，沿用原本的請求路徑重新檢查一次：先確認監聽狀態，再執行明確指定代理的命令，最後測試實際使用的應用程式。每次只修改一項設定，並記錄修改前後的錯誤是否有所變化。如果錯誤從連線逾時變成驗證失敗，代表排查已進入不同階段，不要立刻撤銷所有修改、從頭開始。
- 確認結果可重現：對同一個目標重複送出請求，確認記錄中不再出現相同故障。
- 確認路由：觀察請求實際走代理還是直接連線，避免將直連成功誤認為節點已恢復。
- 還原正常設定：結束暫時啟用的除錯記錄，移除不再需要的代理覆寫，並保留必要的防火牆規則。
- 保留求助資料：記下用戶端版本、核心類型與版本、節點協定、失敗階段、原始錯誤訊息及網路對照結果，但不要附上驗證憑證。
仍找不到原因時，可繼續查看故障排查說明；若尚未確認匯入、啟用與系統代理設定，請先依照快速入門教學建立一組可重現的基本設定，再回頭檢查記錄，通常比同時更換節點、DNS 和核心更容易找出問題。