如何確認 VPN 是否正常運作？查 IP、查 DNS 的新手完整指南

確認 VPN 是否正常運作，不能只看客戶端裡的綠色圖示。更可靠的方式，是先記錄未連線時的出口 IP 與 DNS 解析結果，連線後再重複檢查，最後分別驗證瀏覽器、桌面軟體及其他需要連網的應用程式。只有出口路徑、網域解析和目標應用程式的流量都符合預期，才能表示目前設定確實正常運作。

這套檢查不要求你懂複雜的網路指令。新手先完成基本比對，就能找出大多數問題；如果初步結果互相矛盾，再進一步排查分流、系統代理、TUN 模式與 DNS 設定。重點是一次只變更一個條件，避免同時更換路線、協定和規則，最後無法判斷是哪項設定造成影響。

建立檢查基準：先查看未連線狀態

要判斷路線是否改變網路路徑，需要一個可比較的起點。先完全中斷客戶端連線，關閉瀏覽器中可能單獨啟用的代理擴充功能，再開啟新的隱私視窗。透過搜尋引擎查詢「我的 IP」，記錄頁面顯示的出口位址、網路服務提供者與大致地區。不同檢測頁面的資料庫更新時間可能不同，因此地區名稱不必完全一致，重點是出口位址與網路歸屬是否改變。

接著查詢目前的 DNS 解析結果。DNS 會將網站網域名稱轉換成可連線的位址，與網頁最後使用的出口鏈路並不是同一件事。未連線時，解析請求可能由本地網路、作業系統指定的解析器，或瀏覽器內建的安全 DNS 處理。記錄檢測頁面顯示的解析服務歸屬，稍後再與連線後的結果比較。

建立基準時，也應記下目前使用的網路環境，例如固定寬頻、公共網路或共享熱點。切換網路本身就可能改變出口 IP 與 DNS；如果中斷連線與連線後使用的是不同網路，比對結果便失去意義。完成記錄後再連線 VPN，等待客戶端狀態穩定，然後重新開啟檢測頁面。不要只重新整理舊分頁，因為舊頁面可能保留快取或既有連線。

✅ 中斷客戶端連線後，記錄原始出口 IP、網路歸屬與大致地區。
✅ 記錄未連線狀態下的 DNS 解析服務歸屬。
✅ 維持相同的本地網路環境，再進行連線後的複測。
✅ 使用新的隱私視窗，減少快取、擴充功能與舊連線造成的干擾。
✅ 每次只調整路線、協定或模式其中一項，再重新檢查。

基本判斷： 連線前後出口 IP 明顯改變，而且網路歸屬與所選路線方向相符，表示瀏覽器網頁流量很可能已經經過遠端出口；這仍不是完整結論，還需要繼續核對 DNS 與其他應用程式。

檢查出口 IP：確認網頁流量走向

出口 IP 是外部網站看到的請求來源。連線路線後，如果檢測頁面仍顯示與基準完全相同的出口位址，常見原因不一定是節點失效，而是目前瀏覽器沒有採用客戶端提供的代理路徑。此時先檢查客戶端執行模式：系統代理模式通常只接管遵循系統代理設定的程式；TUN 或虛擬網卡模式則會在更底層接管符合規則的網路流量。

如果出口位址已經改變，但地區與所選路線不一致，也不要立刻下結論。IP 地理資料庫可能延遲更新，同一個位址在不同檢測網站上可能顯示鄰近地區或舊的機房資料。更具參考價值的是網路歸屬、多個查詢結果呈現的共同方向，以及實際目標服務看到的地區。單一頁面顯示異常時，可以清除網站資料、重新開啟瀏覽器，再更換檢測來源交叉確認。

瀏覽器也可能透過 WebRTC 建立即時通訊連線。檢測頁面看到額外的本地網路位址，不等同於公開出口洩漏；本地位址通常無法由網際網路直接路由。真正需要注意的是頁面是否暴露與基準一致的公開出口。若出現這種情況，應先確認瀏覽器是否繞過系統代理，或客戶端規則是否將即時通訊流量設為直連。

檢測結果	可能含義	下一步
連線前後出口 IP 相同	瀏覽器可能未進入代理路徑，或目前網域被規則設定為直連	檢查系統代理、TUN 模式與分流命中記錄
出口 IP 改變，網路歸屬符合路線	目前網頁請求已從遠端出口發出	繼續檢查 DNS 與其他應用程式
出口 IP 改變，地區標籤不一致	可能是地理資料庫資料更新延遲	比較網路歸屬，並使用不同來源複核
一般網頁有變化，特定網站沒有變化	分流規則、快取或網站本身的地區判定可能介入	查看規則記錄，並清除該網站資料後複測

系統代理與 TUN 模式的差異

系統代理更像是一份提供應用程式讀取的轉送設定。瀏覽器通常會遵循它，但部分遊戲、命令列工具、更新程式和自行實作網路堆疊的軟體可能完全忽略。TUN 模式透過虛擬網路介面處理流量，涵蓋範圍通常更廣，也更適合驗證不讀取系統代理的應用程式。不過，TUN 模式仍會執行路由與分流規則，並不代表所有連線都會無條件進入遠端路線。

在桌面平台上，管理員權限、防火牆策略與其他網路工具可能影響虛擬介面的建立。行動平台的客戶端通常透過系統提供的 VPN 介面接管流量，但作業系統的省電策略、個別應用程式設定或永遠開啟設定，仍可能改變實際行為。檢查時應以目標應用程式的結果為準，而不是根據客戶端介面推斷涵蓋範圍。

檢查 DNS 解析：辨識解析路徑偏差

DNS 洩漏通常是指網頁流量已從遠端出口發出，但網域解析請求仍由本地網路可見的解析器處理。它不一定會導致網頁無法開啟，卻會讓解析路徑與預期不一致，也可能造成地區判定衝突。檢查時連線路線並開啟 DNS 檢測頁面，觀察解析服務歸屬是否仍與未連線基準相同。

如果結果沒有改變，先判斷瀏覽器是否啟用了獨立的安全 DNS。現代瀏覽器可以自行將解析請求傳送至指定服務，這條路徑可能繞過客戶端的一般 DNS 設定，但仍可能經過 VPN 出口。此時「解析服務名稱沒有改變」不能單獨證明流量洩漏，需要結合出口 IP、瀏覽器設定與客戶端連線記錄判斷。

另一種常見情況是客戶端使用遠端 DNS，但分流規則要求先在本地解析網域，再根據結果決定直連或代理。這種設計不一定錯誤，卻可能讓本地解析器看到查詢。若希望解析與遠端路線保持一致，應檢查客戶端是否支援代理 DNS、遠端解析或加密 DNS，並確認規則比對是在合適的解析階段進行。

瀏覽器安全 DNS 為什麼會干擾判斷

瀏覽器安全 DNS 會將網域查詢封裝在加密連線中。若瀏覽器遵循系統代理，這條加密連線可能仍經過遠端路線；若瀏覽器為該請求選擇直連，則會形成另一條路徑。因此，排查期間可以暫時讓瀏覽器跟隨系統 DNS，完成基準比對後再恢復原本設定。這麼做只是為了減少變數，不代表安全 DNS 與 VPN 不能同時使用。

作業系統也可能快取先前的解析結果。剛切換路線時，瀏覽器造訪熟悉的網站未必會立即發出新的 DNS 請求，檢測頁面卻可能顯示新的解析器。若要驗證特定網域，應關閉相關應用程式，等待舊連線結束，再使用新的隱私視窗造訪。若客戶端提供連線記錄，可查看網域請求最後命中了哪條規則，以及採用了哪條解析路徑。

DNS 判斷： 出口 IP 已改變，但 DNS 結果仍穩定指向本地網路使用的解析路徑時，應檢查瀏覽器安全 DNS、客戶端遠端解析設定與規則順序；僅看到熟悉的公共解析服務名稱，還不足以判定設定失敗。

逐一驗證應用程式：避免瀏覽器正常、軟體直連

瀏覽器檢測通過，只能表示瀏覽器的網頁請求符合預期。桌面聊天工具、同步程式、下載器、遊戲與命令列工具可能各自採用不同的網路方式。最穩妥的做法是關閉目標應用程式，連線路線後重新啟動，再透過應用程式本身的網路診斷、客戶端連線記錄或目標服務的工作階段資訊確認出口。

如果客戶端支援連線記錄，可以先清除舊記錄，再開啟目標應用程式執行一次明確的連網操作。記錄通常會顯示目標網域或位址、命中的規則、採用直連或代理，以及選取的節點。這比單純觀察網頁更直接：如果記錄沒有出現目標連線，應用程式可能繞過了目前的接管方式；如果記錄明確顯示 DIRECT，應檢查規則，而不是反覆更換節點。

完全退出準備驗證的應用程式，避免重複使用連線前建立的長連線。
連線目標路線，並確認客戶端沒有持續重新連線或出現驗證錯誤。
清除或標記客戶端記錄的目前位置。
重新開啟應用程式，只執行一次容易辨識的連網操作。
查看記錄中的網域、規則命中與出站方式。
若顯示直連，檢查分流規則；若沒有記錄，改用 TUN 模式後再測試。

為什麼不同客戶端會得到不同結果

Windows 與 macOS 上的代理客戶端通常同時提供系統代理與 TUN 模式，但虛擬介面權限和 DNS 接管方式並不相同。Linux 客戶端更常依賴明確的路由、環境變數或透明代理設定，終端程式是否讀取代理環境也需要個別確認。行動平台通常由系統統一顯示 VPN 狀態，但個別應用程式排除、背景限制與系統網路切換仍會影響連線。

瀏覽器擴充功能只處理瀏覽器內部流量，不會自動接管其他應用程式。反過來，某些瀏覽器也可能設定自己的代理或安全 DNS，因而與系統設定產生差異。排查時應先釐清使用的是瀏覽器擴充功能、系統代理還是 TUN 接管，再選擇相應的檢測方法。

核對訂閱與協定：連線成功仍可能沒有可用轉送

將訂閱連結匯入客戶端後，通常會產生節點、協定參數與名稱等設定。匯入成功只代表客戶端讀懂了訂閱內容，不代表目前節點一定能建立完整的資料轉送。訂閱到期、節點設定更新、客戶端核心版本不相容，或系統時間明顯偏差，都可能造成節點可見但連線異常。遇到這類問題，應先更新訂閱，再查看客戶端提供的具體錯誤，而不是連續點選連線。

Shadowsocks 是加密代理協定，常見客戶端會將它作為本地代理或 TUN 出站使用。VMess 與 VLESS 通常由支援相應核心的客戶端管理，兩者的設定欄位與傳輸層參數不能混用。Trojan 通常將連線建立在 TLS 之上，憑證名稱與系統時間會影響握手。Hysteria2 與 TUIC 主要依據 QUIC 的思路處理傳輸，對 UDP 網路品質與本地網路策略較為敏感。協定顯示「已連線」後，仍應透過出口 IP 與應用程式記錄驗證實際轉送。

直連、中轉與 IEPL 專線描述的是路線路徑，不等於代理協定本身。直連是從本地直接連線至遠端節點；中轉會先進入中間入口，再轉往出口；IEPL 專線通常用來描述具備專用承載特徵的國際鏈路。無論使用哪種路線，客戶端最終仍需透過某種協定建立工作階段，並由分流規則決定應用程式請求的走向。路線名稱不能取代實際檢測。

檢查記錄
未連線：記錄出口 IP 與 DNS 歸屬
已連線：記錄所選路線與執行模式
瀏覽器：出口是否改變，DNS 是否符合預期
目標應用程式：記錄是否出現，規則採用代理還是直連
調整項目：每次只修改路線、協定、模式或規則其中一項
複測：關閉舊連線後重新開啟應用程式

處理常見的假連線：看似連上但流量未經轉送

最常見的假連線來自規則模式。客戶端與節點工作階段正常，但目標網站被規則判定為直連，因此狀態列一直顯示已連線，檢測頁面卻仍看到原始出口。切換至全域代理可作為短暫的診斷手段：如果全域模式下出口立即改變，表示節點與協定基本可用，問題更可能出在規則集、規則順序或網域解析階段。確認原因後，應恢復適合日常使用的分流設定。

另一類問題是舊連線沒有中斷。瀏覽器、聊天軟體與同步工具會長時間維持連線，切換路線後可能繼續沿用原本的路徑。完全退出應用程式再重新開啟，比不斷重新整理頁面更有效。系統休眠與網路切換也可能留下狀態不一致，此時先中斷客戶端連線，等待網路恢復，再重新連線並建立新的測試工作階段。

多個網路工具同時執行也會造成路由競爭。例如瀏覽器擴充功能、系統代理工具、虛擬網卡客戶端與安全軟體都可能修改請求路徑。排查時保留一個主要客戶端，暫時停用其他代理入口，再從出口 IP 開始複測。尚未確認基本路徑前，不要同時修改防火牆、DNS、協定與訂閱設定。

✅ 客戶端記錄沒有持續出現握手、驗證或逾時錯誤。
✅ 連線後的出口 IP 與未連線基準不同。
✅ DNS 解析路徑符合目前客戶端與瀏覽器設定。
✅ 目標應用程式的連線出現在記錄中，並命中預期的出站規則。
✅ 關閉應用程式重新開啟後，結果仍能穩定重現。
✅ 切回日常分流模式後，再進行一次完整複測。

什麼時候該更換路線，什麼時候該更換協定

如果客戶端根本無法與節點建立工作階段，記錄持續顯示握手或傳輸錯誤，可以先更換同類路線，判斷是否只是單一節點的問題。若多個節點在目前網路下都無法連線，而更換另一種協定後恢復，才有理由進一步檢查目前網路對該傳輸方式的支援。如果工作階段正常、出口也已改變，只是特定應用程式直連，應優先檢查接管模式與規則；更換協定通常無法解決規則未命中的問題。

如果網頁能開啟但使用體驗不穩定，應先區分是 DNS 解析慢、建立連線慢，還是持續傳輸不穩。頻繁更換協定會重設測試條件，也可能掩蓋真正原因。保留相同的測試目標，在相同網路環境下依序更改路線或協定，並記錄每次結果，會比憑感覺切換更可靠。

最終確認標準：結果必須能重複

檢測頁面只顯示一次不同的 IP，只能證明當時那次請求經過了不同出口。完整確認還應包括 DNS 路徑符合設定、目標應用程式出現在客戶端記錄中，以及重新開啟應用程式後結果仍然一致。對於依賴地區判定的網站，還要清除舊工作階段與網站資料，因為帳戶資料、快取和瀏覽器位置權限都可能參與判定，不能把所有地區提示都歸因於 VPN。

完成排查後，建議保留一份簡短記錄：使用的客戶端模式、路線、協定、DNS 設定、規則模式與最終結果。下次網路環境變化時，可以從已驗證的設定開始，不必重新猜測。如果問題只出現在某個應用程式，記下該應用程式是否支援系統代理、是否需要 TUN 接管，以及記錄命中的規則，通常就能快速重現原因。

結論： 要判斷 VPN 是否真正正常運作，必須同時查看客戶端工作階段、出口 IP、DNS 解析與目標應用程式的規則命中情況。綠色連線狀態只是起點；連線前後有基準可比，而且重新開啟應用程式後結果仍能重現，才是可靠的確認方式。