VPN 如何檢查是否生效：出口 IP、DNS 與應用程式逐一驗證教學
顯示已連線，不代表流量真的經過代理。本文教你檢查出口 IP、DNS 與個別應用程式，並整理常見的連線異常情況。
VPN 是否生效怎麼檢查？可靠的做法是比對連線前後的出口 IP、DNS 解析路徑及目標應用程式的連線紀錄。用戶端顯示「已連線」，只代表某個連線環節已建立，不能證明瀏覽器、命令列工具和其他應用程式都依預期經過代理。
先釐清預期：只有國際網站要經過代理，還是希望裝置的大部分網路連線都進入隧道？採用分流模式時，中國大陸網站仍顯示本地出口，可能是正常情況。接下來依「先確認模式，再測試實際連線」的順序檢查，不必一開始就反覆切換節點。
先確認代理模式與測試範圍
系統代理通常會提供代理入口給遵循系統設定的應用程式，不代表整台裝置的流量都由它接管。瀏覽器可能使用系統代理，命令列工具則可能需要另外設定。TUN 或系統 VPN 隧道會透過虛擬網路介面處理流量，但仍可能受到排除應用程式、目的位址規則及路由設定影響。
規則模式會決定哪些目的地直連、哪些經過代理，以及哪些遭到拒絕。用戶端中的「全域」也要依實際運作方式理解：它可能只讓進入代理核心的請求統一選擇出口，不一定能接管原本未進入核心的應用程式。
| 目前方式 | 檢查重點 | 無法直接據此判斷的事項 |
|---|---|---|
| 系統代理 | 目標應用程式是否遵循系統代理設定，以及是否符合略過清單 | 瀏覽器可用，不代表命令列工具也可用 |
| TUN／系統 VPN 隧道 | 隧道權限、路由、排除的應用程式及不同位址族的處理方式 | 出現 VPN 圖示，不代表所有請求都進入隧道 |
| 規則分流 | 測試網域符合的規則與實際出口 | 本地網站顯示本地 IP，不代表連線失敗 |
| 應用程式內的獨立代理 | 應用程式自訂的代理位址與連線紀錄 | 系統設定正確，不代表應用程式設定也正確 |
出口 IP：比對連線前後的實際請求
出口 IP 是目標網站所看到的請求來源，不是裝置在區域網路中的位址。系統網路設定顯示的本地位址，無法用來判斷國際線路是否生效。請使用可信賴的公網 IP 查詢網站，並在相同瀏覽器與網路環境下比對連線前後的結果。
- 先暫停敏感操作、中斷用戶端連線，並記下查詢頁面顯示的公網 IP 與網路歸屬。不要同時切換無線網路，以免前後基準失去可比性。
- 連上目標線路，確認目前使用的模式與規則。重新載入查詢頁面，必要時開啟新的無痕視窗，避免舊頁面內容造成誤判。
- 比對出口是否改變，並查看用戶端連線紀錄中該查詢網域的處理結果。如果紀錄顯示直連，先確認規則如何運作，不要立刻判定線路失效。
- 接著開啟實際要使用的服務，查看該服務對應的連線紀錄。查詢網站與目標服務可能符合不同規則，前者成功不能取代對後者的驗證。
地區資料庫可能更新較慢，也可能將同一個出口標示在不同地區。節點名稱與查詢頁面的地區標籤不一致時，應綜合 IP 歸屬、線路說明和實際存取結果判斷，不能只看地圖位置就下結論。
也要留意 IPv4 與 IPv6。某些查詢頁面可能只顯示其中一種位址，另一類連線仍可能經過本地網路。若用戶端提供相關設定，請確認支援範圍與路由處理方式；單一位址有所變化，不能證明另一類位址也經過隧道。
DNS檢查：分開確認解析路徑與連線路徑
DNS 會將網域名稱轉換成可連線的位址。網頁請求經過代理，不代表網域解析也一定走相同路徑。反過來說，解析器顯示位於本地地區，也不能單憑這點認定發生洩漏：公用解析服務可能使用就近入口，查詢頁面顯示的也可能是遞迴解析器的出口位置。
這裡所說的「DNS 洩漏」，是指解析請求偏離明確設定的保護範圍，例如原本預期由隧道內的解析機制處理，卻仍由本地網路的解析器收到。判斷時應一併檢視設定、用戶端紀錄與測試結果，而不是只看國家或地區名稱。
- 先檢查用戶端的 DNS 設定。確認直連網域與代理網域是否採用不同的解析策略、是否啟用 DNS 接管，以及設定是否已成功載入。
- 接著檢查瀏覽器的安全 DNS。瀏覽器內建的加密 DNS 可能獨立於系統解析器運作。加密只代表解析傳輸受到保護，不代表請求一定經過目前的代理。
- 使用可信賴的 DNS 檢測網站。比對連線前後出現的解析服務，並核對預期設定。檢測網站只能觀察這次瀏覽器測試，無法涵蓋所有應用程式。
- 最後排除快取影響。變更解析設定後，舊快取和既有連線可能仍在使用。重新啟動目標應用程式，或依照系統說明清除快取，再重新測試。
命令列工具也有其限制。例如 nslookup example.com 通常會查詢指定的解析器，但這不等同於瀏覽器的安全 DNS 請求，也未必受系統 HTTP 代理控制。命令執行成功，只能表示查詢收到回應，不能單獨證明瀏覽器的 DNS 路徑符合預期。
部分用戶端採用 Fake-IP 等機制，先將合成位址交給應用程式，再由代理核心進行後續處理。此時本機解析結果看起來不像網站的真實位址，不一定代表故障。請先確認模式說明，不要因為位址看起來陌生就任意更換 DNS 設定。
應用程式逐一驗證：瀏覽器能用，不代表全部都能用
依照實際使用情境分別測試，比只開啟查詢網站更可靠。瀏覽器瀏覽、登入開發工具、命令列下載及音視訊通話，可能採用不同的代理設定、傳輸方式與連線生命週期。每次測試都應觸發新的網路請求，並核對用戶端紀錄。
瀏覽器與擴充功能
先確認是否安裝了代理控制擴充功能，以及瀏覽器是否使用獨立代理設定。暫時只保留一種明確的控制方式，避免系統代理與擴充功能互相覆寫。載入快取頁面不算驗證成功；請載入新的頁面內容，並確認相關網域的出口。
命令列與開發工具
終端機、編輯器及其啟動的子程序，不一定會使用相同的代理環境。請檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY 是否適用於目前的工具；實際支援方式請以工具文件為準。命令列參數或工具本身的設定，也可能覆寫環境變數。
需要驗證明確指定的代理時，請從用戶端複製實際的監聽位址與連接埠，再依工具說明填入，不要照抄網路上的預設值。使用網域名稱透過 SOCKS 代理存取時，也要確認 DNS 解析是在本機還是代理端進行，這會影響 DNS 檢查結果。
行動裝置與即時通訊
Android 用戶端可能提供應用程式納入或排除清單；iOS 通常透過系統網路延伸功能建立連線，實際接管範圍仍取決於用戶端設定。Windows、macOS 和 Linux 的系統代理、隧道權限與應用程式支援也各不相同，不能直接套用其他平台的選項名稱。
音視訊或即時通訊也可能使用 UDP 與 WebRTC。網頁能開啟，不代表這些流量都可正常運作。WebRTC 檢測中出現本地候選位址，也不一定代表公網出口洩漏；還要判斷位址類型、實際選用的連線路徑及用戶端的支援範圍。
常見「假連線」情況與排查順序
「假連線」並非統一的技術狀態。有時只是用戶端介面仍保留連線圖示，有時是本地代理仍在監聽，但遠端線路已無法連通；也可能是線路正常，目標應用程式根本沒有使用它。先保留故障現象，再逐步縮小範圍。
- ✅ 確認設定已載入。訂閱更新成功只代表設定已取得，還要確認目前選用有效線路，並能發出實際請求。
- ✅ 確認系統接管狀態。檢查代理開關、隧道權限與排除清單，並留意其他網路工具是否改動了設定。
- ✅ 確認符合的規則。若目標網域被設為直連或拒絕，請先檢查相關規則，不要把規則結果誤認為線路故障。
- ✅ 確認遠端連線狀態。對同一個目標改用其他可選線路，觀察錯誤是否隨線路改變，避免同時修改多項設定。
- ✅ 確認目標服務狀態。帳戶地區、登入風險控管、服務故障和內容授權都可能造成存取失敗；出口正確不代表服務一定允許存取。
- ✅ 確認恢復後的新請求。切換網路或裝置喚醒後，重新建立應用程式連線，再檢查出口與紀錄。
訂閱連結是匯入設定的入口，不是連線成功的證明。用戶端能匯入訂閱，也不代表支援設定中的所有協定、傳輸選項與規則語法。若匯入後出現未知欄位或不支援協定的提示，請確認用戶端版本與設定格式，並參考使用教學，不要反覆重設系統網路。
速度慢也不能直接判定為連線未生效。即使出口與規則都正確，壅塞、目標網站回應速度及無線網路品質等因素仍會影響使用體驗。連線方式的名稱也不能取代驗證：無論是直連、中轉或專線，都應以目前請求的實際路徑為準。
也要另外檢查斷線後是否回復直連
線路正常運作，與斷線後仍能阻止直連，是兩個不同的問題。有些系統代理在遠端連線中斷後會讓應用程式回報錯誤，有些應用程式則會嘗試其他路徑；隧道結束後的行為也會受系統與用戶端設定影響。不要預設用戶端內建斷線保護，更不要在進行敏感操作時首次測試。
若用戶端明確提供相關功能，可先關閉敏感應用程式，再手動中斷連線，使用一般查詢網站觀察是否仍能存取，以及出口是否回到本地。接著重新連線，確認規則與 DNS 已恢復正常。手動中斷的結果不一定適用於程序異常結束或網路切換，因此只能說明已測試的情況。
出口 IP 符合目標規則、DNS 解析沒有偏離既定策略，且實際應用程式發出的新請求能在連線紀錄中找到相應說明，才算完成較完整的驗證。瀏覽器查詢成功只是其中一項；在分流模式下保留直連流量，也可能完全符合預期。
仍無法找出問題時，請整理作業系統、用戶端名稱、目前模式、故障時間、目標網域及已遮蔽敏感資訊的錯誤訊息，前往問題排查逐項檢查，或透過聯絡我們回報問題。具體說明哪一類請求失敗，比只說「顯示已連線但無法使用」更有助於找出原因。