代理已連線卻無法開啟網頁？DNS、路由規則與系統代理逐項排查清單

用戶端顯示「已連線」、延遲測試出現數字，並不代表瀏覽器流量已完整通過代理鏈路。一次網頁存取至少會經過網域解析、路由比對、入站監聽、出站連線和系統應用程式接管等環節。任何一環設定錯誤，都可能出現用戶端看似正常、網頁卻持續載入或直接報錯的情況。

排查時不要同時修改節點、DNS、路由和系統設定。一次變更多個變數，即使網路恢復，也很難確認真正原因。較穩妥的順序是先驗證節點本身，再檢查 DNS，接著縮減路由規則，最後確認系統代理或 VPN 接管狀態。每完成一步，都使用同一個測試網頁重新測試並記錄結果。

先確認「已連線」究竟代表什麼

v2rayN、v2rayNG 或 v2flyNG 顯示執行狀態，通常只能代表本機核心已啟動，或本機代理入口已建立。這不能單獨證明遠端節點可連線，也不能證明瀏覽器正在使用該入口。延遲測試同樣有其限制：部分測試只量測與伺服器的連線時間，實際網頁請求還會受到協定交握、網域解析、路由規則和遠端出口狀態影響。

先將現象分成以下幾類。不同現象對應的檢查重點不同：

第一步：檢查節點是否真正可用

節點是整條鏈路的上游。節點失效時，反覆調整本機 DNS 或路由通常沒有作用。最有效的驗證方式不是只看延遲，而是使用同一個用戶端切換到另一個已知可用的節點，再執行實際網頁存取。如果新節點立即恢復，問題大多集中在原節點或其參數。

逐項核對節點資訊

1. 檢查位址和連接埠。確認伺服器位址沒有多餘空格，連接埠是有效數字，且匯入後沒有被手動改錯。
2. 檢查協定類型。VMess 與 VLESS 是不同協定，不能只保留位址和連接埠後互換。用戶端顯示的協定必須與節點原始設定一致。
3. 檢查使用者識別資訊。UUID、使用者 ID 等驗證欄位必須完整。複製過程中缺少字元，會導致交握失敗。
4. 檢查傳輸參數。TCP、WebSocket、gRPC 等傳輸方式，以及 Host、路徑、serviceName 等欄位，都需要與伺服器端設定相符。
5. 檢查安全參數。啟用 TLS 或 REALITY 的 VLESS 節點，需要正確的伺服器名稱、公鑰、短識別碼等參數。參數缺失時，本機核心可能仍能啟動，但遠端交握無法完成。
6. 檢查裝置時間。系統日期、時間和時區明顯錯誤時，憑證驗證及部分協定驗證可能失敗。先啟用系統自動校時，再重新連線。

如果節點來自訂閱，先更新一次訂閱，再確認目前選取的節點仍然存在。訂閱位址回傳空內容、節點遭移除或舊設定長期未更新，都可能讓用戶端繼續保留一筆已失效的記錄。更新後不要只看節點數量，應重新選取節點並執行一次實際連線測試。

第二步：判斷是否為 DNS 解析故障

瀏覽器存取網域時，必須先將網域解析為位址。DNS 查詢失敗時，代理核心可能處於執行狀態，但網頁會顯示「找不到伺服器」「無法解析位址」或長時間停留在連線階段。若只有網域存取失敗，而已建立的連線或直接使用位址的服務仍有回應，DNS 應列為首要檢查項目。

先做最小化判斷

• 觀察錯誤訊息中是否出現網域解析、名稱解析或 DNS 相關提示。
• 切換到另一個節點後重新測試。如果所有節點都出現相同的網域錯誤，本機 DNS 設定更值得懷疑。
• 暫時恢復用戶端預設 DNS 設定，停用自行新增的複雜分流解析規則。
• 確認 DNS 查詢使用的出口可連線。指定代理查詢時，代理節點必須先能連線；指定直連查詢時，本地網路必須允許存取該解析服務。

DNS 與路由存在先後依賴。路由規則如果按 IP 比對，核心可能需要先解析網域；但 DNS 查詢本身又需要選擇直連或代理出口。設定中同時存在多套 DNS、網域分流和位址分流時，很容易形成「解析結果決定路由，路由又影響解析」的複雜鏈路。故障排查階段應先減少策略數量，確認基礎解析可用後，再逐項恢復。

快取也是常見干擾因素。用戶端更換 DNS 後，瀏覽器、作業系統和代理核心可能仍保留舊的解析結果。修改設定後，應完全關閉再重新啟動用戶端，並重新開啟瀏覽器。僅重新整理網頁未必會觸發新的 DNS 查詢。

DNS 結果正常仍無法開啟網頁，該怎麼辦

解析成功只代表取得了位址，不表示該位址一定能透過目前的出口存取。某個網域可能回傳多個 IPv4 或 IPv6 位址，而本地網路、節點出口或路由規則只對其中一部分有效。若日誌顯示解析完成，但接著連線逾時，可以暫時使用較簡單的位址策略，或關閉自訂的 IPv6 優先設定進行對照測試。確認問題後，再根據實際網路能力選擇位址族策略。

第三步：排除路由規則誤攔與走錯出口

路由規則負責決定一條連線走代理、直連還是攔截。規則通常由上到下比對，命中後便不再檢查後續規則。範圍過大的直連規則若放在前面，可能讓原本應走代理的網站直接連線；範圍過大的攔截規則，則會讓請求在本機被終止。

使用「全域代理」進行對照測試

在已確認節點可用的前提下，可以短時間切換到全域代理模式。如果全域模式能開啟網頁，而規則模式不能，問題基本上位於路由設定。此時不需要繼續修改節點參數，應集中檢查規則順序、比對範圍與出站標籤。

檢查路由時，請重點查看以下項目：

1. 是否存在兜底出口。未命中任何規則的流量需要有明確的預設出口，不能指向不存在的出站標籤。
2. 規則順序是否合理。精確網域和小範圍規則通常應放在寬泛規則之前，避免過早命中。
3. 網域與位址條件是否混用。按位址比對可能觸發 DNS 解析，解析策略會影響最終結果。
4. 攔截範圍是否過大。測試期間暫時停用最近新增的攔截項目，逐條恢復並重新測試。
5. 直連規則是否涵蓋目標。若目標網域或解析位址被列入直連範圍，網頁可能繞過代理並連線失敗。
6. 出站標籤是否一致。規則中的 outboundTag 必須與實際出站設定中的標籤完全對應。

排查用決策順序：
1. 節點實際存取是否成功
2. 全域代理是否成功
3. 規則模式是否失敗
4. 查看目標網域命中的規則
5. 確認該規則指向 proxy、direct 還是 block
6. 調整一條規則後立即重新測試

故障期間不要一次匯入多份規則集。不同規則來源可能包含相互覆蓋的網域與位址範圍。先使用用戶端預設規則完成驗證，再新增一份自訂規則並進行測試。透過這種增量方式，可以準確找出是哪條規則改變了出口。

第四步：確認系統代理或 VPN 接管已生效

代理核心啟動後，應用程式流量還需要進入它的本機入站連接埠。桌面端通常透過系統代理、應用程式內代理或其他接管方式完成；安卓端的 v2rayNG 與 v2flyNG 通常透過 VPN 模式接管裝置流量。本機核心執行與流量接管是兩個獨立狀態，不能只看啟動按鈕。

v2rayN 桌面端檢查

• 確認已選取目前要使用的節點，而不是只啟動了用戶端視窗。
• 確認系統代理模式已開啟，並檢查作業系統代理設定中是否出現相應的本機位址和連接埠。
• 若瀏覽器曾手動填寫代理，先改回「使用系統代理」或清除舊連接埠，避免瀏覽器繼續連線到已失效的本機連接埠。
• 檢查其他代理程式是否佔用了相同連接埠。發生連接埠衝突時，核心日誌通常會出現監聽失敗或位址已被佔用。
• 退出用戶端後，確認系統代理已正確還原，再重新啟動。異常退出可能留下舊代理位址，導致所有請求繼續傳送到不存在的連接埠。

v2rayNG 與 v2flyNG 安卓端檢查

• 啟動連線後，確認系統狀態列存在 VPN 連線狀態，並允許用戶端建立 VPN。
• 查看分應用程式代理設定。目標瀏覽器或應用程式若被排除，其流量便不會進入代理。
• 暫時關閉省電限制或背景活動限制進行測試，避免系統在鎖定螢幕或切換應用程式後停止核心程序。
• 若裝置同時存在其他 VPN 連線，先中斷其他連線再測試。系統通常不會讓兩條 VPN 接管鏈路同時正常運作。
• 從一個網路切換到另一個網路後，主動中斷並重新連線，讓核心重新建立底層連線。

「瀏覽器可以上網，但某個軟體不行」通常不是節點整體失效。部分軟體不讀取系統代理，部分應用程式有自己的代理設定，還有一些連線使用 UDP。此時應先確認該應用程式是否被接管、是否允許 UDP，以及路由中是否針對其目標位址設定了不同出口。

第五步：從日誌定位失敗發生在哪一層

前四步仍未定位問題時，應開啟用戶端日誌，並清除舊日誌後重新存取一次測試網頁。這樣可以減少歷史記錄干擾。請關注請求發生時新增的幾行，而不是只看核心啟動階段的資訊。

日誌中「沒有請求」本身就是重要結果。若存取網頁時日誌沒有新增任何入站記錄，表示問題發生在核心之前，應回到系統代理或 VPN 接管環節檢查。若能看到入站請求，但沒有成功出站，則繼續判斷是 DNS、路由還是節點交握失敗。透過「請求是否進入」和「出站在哪一步停止」這兩個問題，可以快速縮小範圍。

最終排查清單：依順序逐項勾選

1. 確認一般網路連線本身可用，裝置能存取本地網路允許的頁面。
2. 同步系統日期、時間與時區。
3. 更新訂閱，重新選取節點，不要沿用已移除的舊記錄。
4. 切換至少一個已知可用的節點，透過實際網頁存取進行驗證。
5. 核對 VMess 或 VLESS 協定、位址、連接埠、UUID、傳輸與安全參數。
6. 恢復用戶端預設 DNS，重新啟動用戶端與瀏覽器後再測試。
7. 暫時切換至全域代理。全域模式可用時，集中檢查路由規則。
8. 檢查規則順序、直連範圍、攔截範圍和出站標籤。
9. 桌面端確認系統代理位址與本機監聽連接埠一致。
10. 安卓端確認 VPN 已建立，目標應用程式未被分應用程式規則排除。
11. 檢查是否存在本機連接埠衝突或另一條 VPN 連線。
12. 清除日誌後重現一次問題，根據新日誌定位失敗層級。

完成排查後，應將暫時切換的全域模式恢復為日常所需的路由模式，再逐項恢復自訂 DNS、規則集和分應用程式設定。每恢復一項都執行一次存取測試。如此既能保留原有分流需求，也能明確找出哪項設定會再次觸發故障。

如果重新匯入節點後仍持續出現驗證或交握錯誤，而其他節點正常，通常需要更新該節點的完整參數；如果所有節點在同一網路下都逾時，但更換網路後恢復，則應檢查目前網路對目標位址、連接埠或協定流量的限制。將問題限定為「單一節點」「單一裝置」或「單一網路」之一，後續處理會更直接。