VPN 已連線卻沒生效？檢查出口 IP 與 DNS的完整方法

VPN 連線後，先別只看用戶端的「已連線」提示。這通常只能代表用戶端已與遠端節點完成通訊，無法單獨證明瀏覽器、下載工具與其他應用程式的流量都經過線路。要確認是否真正生效，需依序核對出口 IP、DNS 解析路徑、系統路由與應用程式分流。

最可靠的排查方式不是反覆切換節點，而是保留連線前的基準結果，再與連線後對照。出口 IP 改變，代表至少部分流量已改道；DNS 查詢來源符合預期，表示網域解析沒有繼續沿用原本的網路；不同應用程式得到一致結果，才能進一步確認系統接管範圍。

先定義「生效」：連線狀態不等於流量接管

用戶端建立連線後，通常還要將代理設定、虛擬網路介面或路由規則寫入系統。建立通訊與接管流量是兩個不同階段：前者讓用戶端能連到節點，後者決定哪些封包進入這條線路。如果系統規則未成功寫入、被其他網路工具覆蓋，或目前模式只接管部分應用程式，就可能出現「顯示連線成功，但存取結果沒有變化」。

不同用戶端的接管方式也不一樣。系統代理模式主要影響遵循系統代理設定的應用程式；虛擬網卡模式通常能涵蓋更多應用程式，但仍可能受分流規則、區域網路繞過及應用程式自身網路實作影響。瀏覽器也可能啟用獨立代理或加密 DNS，導致它與系統其他應用程式的表現不一致。

因此，「生效」最好拆成三個判斷：檢測頁面看到的出口已變更；網域解析沒有暴露到不符合預期的解析路徑；需要接管的應用程式確實命中代理或通道路由。只符合其中一項時，可以說線路部分運作，但還不能結束排查。

檢查出口 IP：先保留基準，再連線複測

出口 IP 是網站看到的請求來源位址。未連線時，通常由目前接入的網路提供；線路接管後，檢測頁面應看到節點或其上游出口。檢查時應在同一個瀏覽器、同一個檢測頁面完成前後比較，避免不同網站資料庫的判定標準造成干擾。

1. 中斷用戶端連線，關閉瀏覽器中的獨立代理擴充功能，開啟可信任的 IP 查詢頁面，記錄位址、國家或地區，以及網路業者。
2. 連線至目標節點，等待用戶端狀態穩定，接著在原頁面執行強制重新整理，不要只查看先前開啟的分頁內容。
3. 比較位址是否變更，並確認地理位置是否與所選線路的大致出口區域一致。資料庫可能有更新延遲，因此地區名稱只能作為輔助判斷，位址變化更直接。
4. 改用其他瀏覽器或系統內建的網路工具重複請求。如果結果不同，應優先檢查瀏覽器代理、快取、擴充功能與分流規則。

• ✅ 連線前後使用相同網路與相同檢測頁面，減少變數。
• ✅ 重新整理頁面後重新讀取結果，不依賴舊分頁或截圖。
• ✅ 同時記錄位址與業者資訊，不只查看國旗或地區文字。
• ❌ 不要用「某個網站能開啟」取代出口 IP 驗證。
• ❌ 不要在連續切換多個節點後混合比較結果。

如果位址完全沒有變化，先確認目前模式是否為規則分流。某些規則會讓 IP 檢測網站直連，而目標網站仍經過線路，這不一定代表連線故障。可以暫時切換至全域接管模式進行診斷；驗證完成後，再恢復原本的分流設定。全域模式適合定位問題，不一定適合作為長期設定。

如果瀏覽器出口已變更，但命令列工具或其他應用程式沒有變化，通常表示目前使用的是系統代理模式，而後者沒有讀取系統代理。反過來，如果系統工具已改道，只有瀏覽器仍維持原出口，則應檢查瀏覽器內建代理、擴充功能與安全 DNS 設定。

檢查 DNS：辨識解析路徑與瀏覽器差異

存取網域之前，裝置需要先將網域解析為可連線的位址，這通常由 DNS 完成。如果網頁流量經過線路，但網域查詢仍發往原網路提供的解析服務，就可能出現 DNS 洩漏。這裡的「洩漏」是路徑描述：解析請求走了與預期不同的網路，不等於帳號資料或網頁正文被直接公開。

檢查 DNS 時，可以使用可信任的解析檢測頁面，分別在中斷與連線狀態下觀察解析服務提供者是否變化。不要只看伺服器顯示在哪個城市，因為解析服務可能採用就近調度，地理資料庫也可能延遲更新。更有價值的是服務提供者、網路歸屬，以及連線前後的差異。

系統目前的設定也可以透過本機命令輔助查看。這些資訊反映裝置所知的解析設定，不一定等於瀏覽器最終使用的解析路徑，因此適合搭配網頁檢測結果，而不是互相取代。

Windows
ipconfig /all
nslookup example.com

macOS
scutil --dns
nslookup example.com

Linux
resolvectl status
nslookup example.com

為什麼瀏覽器與系統檢測結果不同

現代瀏覽器可能啟用安全 DNS，直接向瀏覽器指定的解析服務傳送查詢。此時系統命令顯示的是作業系統設定，但瀏覽器檢測頁面看到的卻是另一條路徑。若要確認用戶端是否接管系統 DNS，可以暫時關閉瀏覽器獨立的安全 DNS，再重新測試；若關閉後結果恢復一致，差異來自瀏覽器設定，而非節點本身。

另一個常見原因是快取。作業系統、瀏覽器與應用程式都可能保留已解析過的網域結果。切換線路後立即造訪熟悉的網站時，應用程式可能繼續使用快取位址，沒有發起新的 DNS 查詢。較穩妥的方式是清除瀏覽器網路快取，或查詢先前未造訪過的網域，再觀察檢測結果。

分應用驗證：找出究竟是哪個應用程式沒有經過線路

確認瀏覽器正常後，下一步應檢查實際需要使用的應用程式。不同應用程式可能採用不同的網路堆疊：有些遵循系統代理，有些只讀取應用程式內的代理，有些直接建立連線，還有些使用不易被傳統代理模式接管的資料報傳輸。因此，同一台裝置上出現「網頁正常、用戶端異常」並不罕見。

驗證時可以先在用戶端連線記錄中觀察應用程式請求是否命中規則。如果用戶端支援連線清單，查看目標網域或程序被標記為代理、直連還是拒絕。沒有連線記錄時，可以採用對照法：保持節點不變，分別在系統代理模式與虛擬網卡模式下測試同一個應用程式。如果只有虛擬網卡模式有效，表示該應用程式大致沒有遵循系統代理。

1. 關閉其他可能修改網路設定的代理、過濾或封包擷取工具，只保留目前的用戶端運作。
2. 在瀏覽器中確認出口 IP 已變更，證明節點與基本連線可用。
3. 開啟目標應用程式，執行會產生新網路請求的操作，避免讀取離線快取。
4. 查看用戶端連線記錄或規則命中結果，確認該應用程式被分配至代理還是直連。
5. 暫時切換接管模式後再次測試。如果結果隨模式改變，應針對應用程式調整規則，而不是反覆更換訂閱。

為什麼分流規則會造成「半生效」

規則分流會依據網域、位址範圍、應用程式程序或規則集合決定路徑。其目的通常是讓本地服務直連，讓跨境存取進入國際線路，但規則不一定能辨識所有請求。某個網站也可能同時呼叫登入、圖片、API 與媒體網域；如果主頁命中代理，而 API 網域被判定為直連，就會出現頁面能開啟、登入失敗或內容載入不完整的情況。

排查這類問題時，先用全域接管完成對照。如果全域模式正常，節點、協定與訂閱通常沒有根本故障，問題更可能出在規則。接著恢復規則模式，從用戶端記錄找出直連的相關網域，再將需要的網域加入代理規則。不要直接將所有未知網域長期設定為代理，否則會失去分流本身的意義。

協定、訂閱與線路類型分別會影響什麼

Shadowsocks、VMess、Trojan、VLESS 與 TUIC 等協定，負責決定用戶端與節點之間如何傳輸資料。協定成功握手，只代表這段連線已建立；流量是否進入協定連線，仍取決於系統代理、虛擬網卡與分流規則。因此，「協定已連線」和「應用程式已經過線路」不能畫上等號。

訂閱連結用於向用戶端提供節點與設定。匯入訂閱後，用戶端通常會將遠端內容儲存至本機。伺服器更新節點不代表本機清單已同步；當節點名稱存在但設定過期時，可能出現連線失敗、握手異常，或連線後無法存取。排查前應先在用戶端執行訂閱更新，再重新選擇節點，不要只重複匯入同一份舊內容。

還要區分協定與線路承載方式。直連表示裝置直接存取節點入口，路徑受本地網路與國際鏈路影響較大；中轉會先到中轉入口，再轉交給後續節點；IEPL 專線通常用於描述特定的跨境承載路徑。這些因素會影響路由與穩定性，但不會取代用戶端的系統接管。即使選擇中轉或 IEPL 線路，如果應用程式被分流為直連，流量仍不會自動進入該線路。

典型故障：看似連線成功卻沒有改道

系統代理被其他工具覆蓋

瀏覽器擴充功能、網路過濾工具、開發除錯代理與其他用戶端，都可能改寫系統代理。後啟動的工具往往會覆蓋先前設定，關閉時也可能沒有恢復原狀。處理時應退出其他相關工具，在系統網路設定中確認代理位址由目前的用戶端管理，然後中斷並重新連線。

虛擬網卡權限或路由寫入失敗

首次啟用虛擬網卡模式時，系統通常需要使用者確認網路擴充功能或管理權限。如果授權未完成，用戶端仍可能顯示節點已連線，但系統路由並未真正切換。可以查看用戶端記錄是否出現介面建立、路由寫入或權限錯誤，並在系統網路設定中確認對應的網路擴充功能已獲允許。

區域網路與本機位址被繞過

用戶端通常會讓區域網路位址保持直連，以便繼續存取印表機、路由器與本機儲存空間。這是常見設計，不代表線路失效。但如果目標服務使用內網網域、企業內部 DNS 或特殊位址範圍，繞過規則可能使解析與存取走向不同於預期的路徑，需依實際網路調整。

系統時間不準確

部分加密協定依賴正確的系統時間完成憑證或握手驗證。裝置時間明顯偏差時，連線可能反覆建立、立即中斷，或用戶端介面短暫顯示已連線卻無法傳輸。應先啟用系統自動校時，再重新連線測試。

切換網路後保留舊路由

裝置從有線網路切換至無線網路，或從一個存取點切換至另一個存取點後，用戶端可能仍保留與舊介面相關的路由。此時最簡單的處理順序是中斷線路、等待系統完成網路切換，確認一般網頁可以直接存取，再重新連線用戶端。

完整排查順序：從最少變更開始

遇到問題時，建議依照下列清單逐項執行。這個順序會先驗證基礎網路，再驗證訂閱與節點，最後才修改系統接管和分流設定，能避免在原始網路已異常時誤判用戶端。

• ✅ 中斷線路後，確認目前網路本身可以正常解析網域並存取網頁。
• ✅ 在中斷狀態記錄出口 IP 與 DNS 檢測結果，作為基準。
• ✅ 更新訂閱，重新選擇目前可連線的節點。
• ✅ 連線後強制重新整理檢測頁面，核對出口 IP 是否變更。
• ✅ 檢查 DNS 服務來源，並留意瀏覽器獨立的安全 DNS 設定。
• ✅ 使用其他瀏覽器或應用程式交叉測試，判斷問題是否僅限於單一程式。
• ✅ 查看連線記錄與規則命中情況，確認目標請求不是直連。
• ✅ 暫時使用全域接管進行對照，接著恢復並修正規則。
• ✅ 檢查系統網路擴充功能、虛擬網卡權限與殘留代理設定。
• ❌ 不要同時更換網路、協定、節點與 DNS，否則無法定位變數。

如果出口 IP 與 DNS 都符合預期，但特定網站仍無法使用，問題可能不在「線路是否生效」這一層。目標網站可能依據帳號地區、瀏覽器快取、定位權限或內容分發策略判斷存取區域。此時繼續更換系統 DNS 往往幫助有限，應分別清除網站資料、檢查帳號區域與應用程式權限，並確認網站的相關網域都命中同一組規則。

如果所有檢測都維持原本的網路結果，則回到用戶端接管層：確認系統代理是否已寫入、虛擬網卡是否取得權限，以及路由是否被其他工具覆蓋。若只有節點無法建立連線，再查看協定記錄、訂閱更新時間與目前網路的相容性。將「節點無法連線」與「節點已連線但流量未被接管」分開處理，通常比不斷切換設定更有效。