V2Ray 已連線卻無法開啟網頁？12 項逐步排查清單

先確認問題發生在哪一層

客戶端顯示已連線，只能代表介面已將啟動指令提交給核心，無法證明瀏覽器流量已進入代理，也無法證明遠端節點已完成握手。完整請求至少會經過應用程式、系統代理或 TUN、路由判斷、代理出站與 DNS 解析。任一環節失敗，表面上都可能只是「網頁一直轉圈」。

開始前先固定測試條件：關閉正在下載的工作，只保留一個瀏覽器視窗，選擇一個確認可存取的一般 HTTPS 網站進行測試。不要同時切換節點、路由模式與 DNS；一次只修改一個變數，修改後重新載入同一頁面並記錄結果。

判斷問題範圍時，可以進行兩組對照。第一組是在關閉系統代理後存取本地網路，再開啟系統代理存取同一個位址；第二組是在原節點與另一個確認可用的節點之間切換。如果所有節點都失敗，較可能是本機入口、路由或 DNS 問題；如果只有一個節點失敗，應優先核對該節點的狀態與設定欄位。

第一層：本機設定的 3 項檢查

本機層負責將應用程式流量送入核心。最常見的問題是系統代理未啟用、監聽連接埠被其他程式佔用，或瀏覽器保留了獨立代理設定。以 v2rayN 7.x 為例，客戶端啟動後應同時確認核心狀態與系統代理狀態，而不是只看工作列圖示。

1. 第 1 項：檢查系統代理是否確實啟用。 在 v2rayN 主視窗確認系統代理模式不是「清除系統代理」。接著進入 Windows 的「設定」→「網路和網際網路」→「代理」，檢查手動代理是否指向本機位址。常見監聽位址為 127.0.0.1，連接埠應以 v2rayN 目前的日誌或「設定」→「參數設定」中的本機連接埠為準。舊設定常見 SOCKS 連接埠為 10808、HTTP 連接埠為 10809，升級或移轉設定後不能假定連接埠維持不變。
2. 第 2 項：確認核心正在監聽對應連接埠。 Windows 可在 PowerShell 中測試本機連接埠。若結果中的 TcpTestSucceeded 為 False，表示瀏覽器即使寫入代理位址，也沒有可接收連線的本機程序。先完全退出 v2rayN，再重新啟動；若仍然失敗，請檢查日誌中的連接埠佔用資訊，並在「設定」→「參數設定」中改用未被佔用的連接埠。
3. 第 3 項：排除應用程式自行覆寫代理設定。 某些瀏覽器或開發工具可以使用獨立代理位址。若系統代理為 127.0.0.1:10809，應用程式卻仍指向已停用的 127.0.0.1:7890，請求就不會進入目前的核心。將應用程式代理改為「使用系統代理」，重新啟動應用程式後再測試；命令列工具還應檢查環境變數中是否殘留舊的 HTTP 或 SOCKS 代理值。

Test-NetConnection 127.0.0.1 -Port 10808
Test-NetConnection 127.0.0.1 -Port 10809

Android 裝置使用 v2rayNG 或 v2flyNG 時，本機入口由系統 VPN 介面接管。若點選連線後狀態很快恢復為未連線，請先停止其他正在佔用系統 VPN 介面的網路工具，再重新授權連線。若狀態維持連線但只有個別應用程式失敗，應檢查該應用程式是否被加入「分應用程式代理」的繞過清單。

第二層：節點狀態與握手參數的 3 項檢查

本機連接埠正常後，下一步是判斷節點能否建立 TCP、TLS 或其他傳輸層連線。延遲測試不是最終可用性的證明，但能快速區分「位址完全無法連線」與「握手後請求失敗」。測試時也應同時確認測試類型：只有 ICMP 延遲、TCP 延遲或實際連線延遲其中一種結果，都不能取代完整的網頁請求。

4. 第 4 項：測試節點位址與連接埠的連通性。 在 v2rayN 節點清單中選取目前節點，執行實際連線延遲測試。一般家庭網路中，測試值可能是幾十至數百毫秒；若連續 3 次顯示逾時，且日誌停留在連線伺服器階段，應核對伺服器網域與連接埠。可以暫時將逾時門檻設為 5000 毫秒後再測試，避免將高延遲誤判為完全無法連線。
5. 第 5 項：校準系統時間並檢查 TLS 握手。 TLS 憑證驗證依賴裝置時間。系統時間偏差幾分鐘，就可能被判定為憑證尚未生效或已過期。Windows 請進入「設定」→「時間與語言」→「日期與時間」，開啟自動設定時間並立即同步；Android 裝置請進入系統日期與時間設定，啟用網路提供的時間。同步後完全停止核心，再重新連線。
6. 第 6 項：逐一核對節點設定欄位。 VMess 應重點檢查位址、連接埠、使用者 ID、傳輸方式、TLS 與路徑；VLESS 另需核對 flow、安全類型、伺服器名稱，以及 Reality 相關的公鑰參數是否由節點設定提供。WebSocket 路徑中的斜線、gRPC serviceName 的大小寫、TLS 伺服器名稱都必須完全一致。不要依協議名稱自行補填欄位，應以伺服器端實際設定或最新訂閱內容為準。

第三層：路由分流的 3 項檢查

節點握手成功但網頁仍無法開啟時，路由規則就是重點。V2Ray 與 Xray 核心會根據網域、IP、連接埠、網路類型與入站標籤選擇出站。若某條規則將目標誤送至直連或阻斷出站，介面仍會顯示連線正常，因為節點本身並未斷線。

7. 第 7 項：切換至最簡單的代理模式進行對照。 暫時將路由切換為全部經由代理的測試模式，重新開啟失敗網站。若立即恢復，表示節點與本機入口正常，問題集中在分流規則。測試結束後再恢復原本模式，逐條檢查命中規則，不要長期依賴對照模式掩蓋規則錯誤。
8. 第 8 項：檢查 GeoIP 與 GeoSite 資料是否遺失或過時。 自訂規則常引用 geoip:cn、geosite:cn 或其他分類集合。資料檔案遺失時，核心可能提示規則載入失敗；資料長期未更新時，新網域可能落入預設規則。v2rayN 可在主介面的檢查更新功能中更新 Geo 檔案，完成後重新啟動核心，並確認日誌沒有資源載入錯誤。Android 端應使用客戶端提供的資料更新入口，更新後重新連線。
9. 第 9 項：檢查網域嗅探與規則優先順序。 如果瀏覽器請求先被解析成 IP，而規則只依網域比對，目標可能繞過預期的出站。啟用網域嗅探後，核心可從 HTTP Host 或 TLS Server Name 中還原網域以進行路由，但部分區域網路服務不適合嗅探。先確認失敗網站在日誌中顯示的是網域還是 IP，再調整嗅探設定。自訂規則通常按由上至下的順序比對，寬泛的直連規則不應放在更具體的代理規則之前。

網域規則：domain:example.com
後綴規則：domainSuffix:example.com
完整比對：full:service.example.com
連接埠範圍：80,443
預設動作：proxy / direct / block

第四層：DNS 解析的 3 項檢查

DNS 故障常見的表現是節點有延遲、IP 位址可以連線，但網域網頁無法開啟。也可能出現首頁能開啟、圖片與登入介面逾時，因為不同子網域回傳了不同位址。排查時要區分「節點伺服器網域解析」與「存取目標網域解析」：前者失敗會阻止節點建立連線，後者則發生在節點已連線之後。

10. 第 10 項：確認 DNS 伺服器本身可連線。 若設定使用只能透過代理存取的解析服務，卻將 DNS 查詢路由至直連，查詢會持續逾時。反過來，本地域名若全部送往遠端解析，也可能取得不適合目前網路的位址。先暫時使用系統 DNS 進行對照；恢復後再分別設定本地查詢與代理查詢的出站路徑，並觀察日誌中的查詢耗時。一般查詢通常應在幾十至數百毫秒內回傳，連續超過 2000 毫秒應視為異常。
11. 第 11 項：清除快取並核對 FakeDNS 的使用範圍。 瀏覽器、系統與核心可能各自快取解析結果。修改 DNS 後若未重新啟動相關程序，測試仍可能使用舊位址。Windows 可先關閉瀏覽器，執行系統 DNS 快取清除，再重新啟動 v2rayN。使用 TUN 與 FakeDNS 時，應確認虛擬位址池只用於對應的流量鏈路；如果應用程式取得虛擬位址後繞過 TUN 直連，連線必然失敗。
12. 第 12 項：檢查 IPv4 與 IPv6 的回傳結果。 某些網路可以解析 AAAA 記錄，卻沒有穩定的 IPv6 出口；瀏覽器會先嘗試無法連線的位址並等待逾時。若日誌顯示目標優先透過 IPv6 連線，且每次都在數秒後回退至 IPv4，可以暫時將網域策略調整為優先 IPv4 進行對照。確認問題後，再修復本機 IPv6 網路，或保留適合目前環境的查詢策略，不應將所有解析問題都歸因於節點。

依結果縮小問題範圍並完成複測

完成 12 項檢查後，不要只以「某個首頁能開啟」作為恢復標準。至少測試一個一般 HTTPS 頁面、一個包含多個子網域資源的頁面，並執行一次訂閱更新。桌面端還應重新啟動瀏覽器；Android 端應斷開後再重新連線一次，確認系統代理或 VPN 介面能穩定重建。

如果本機連接埠可用、多個節點的實際連線測試正常、全域代理可以存取，而原本的分流模式失敗，問題即可明確歸入路由層。如果節點網域無法解析，或日誌在建立連線前就出現 lookup 錯誤，應先處理引導 DNS。如果只有單一節點在不同網路下都握手失敗，則應核對該節點的設定與服務狀態。

• 本機層通過標準：應用程式使用正確入口，核心監聽連接埠存在，日誌能看見新請求進入。
• 節點層通過標準：伺服器位址可連線，系統時間準確，VMess 或 VLESS 欄位與實際設定一致。
• 路由層通過標準：失敗網域命中預期出站，Geo 資料成功載入，規則優先順序沒有被寬泛規則覆蓋。
• DNS 層通過標準：節點網域與目標網域都能在合理時間內回傳目前網路可連線的位址。