如何確認 VPN 是否真的生效？檢查出口 IP、DNS 與分應用程式驗證

如何確認 VPN 真的生效，不能只看用戶端裡的「已連線」。這個狀態通常只代表用戶端完成握手、代理連接埠已開始監聽，或系統中出現虛擬網路介面；不一定能證明瀏覽器、命令列工具和其他應用程式的請求都經過目標線路。可靠的判斷需要同時檢查出口 IP、DNS 請求去向，以及特定應用程式的實際路徑。

驗證時最重要的原則是進行前後對照。先記錄未連線時的網路狀態，再連線線路並重複完全相同的請求。只看連線後的單次結果，很容易把本地網路原有的出口、瀏覽器快取或安全 DNS 服務誤認為線路效果。以下流程不受用戶端品牌限制，也適用於系統代理、TUN 模式、原生 VPN 設定和瀏覽器擴充功能等常見連線方式。

判斷標準：圖示、握手與實際流量不是同一回事

一次連線可以分成載入設定、協定握手、系統接管和應用程式發出請求幾個環節。訂閱連結只是設定分發入口，成功匯入只能代表用戶端讀取了節點資訊。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 等協定完成握手後，用戶端仍需透過系統代理、虛擬網卡或應用程式內代理，將流量交給該連線。

因此，準確結論不是「用戶端亮燈」，而是「預期被接管的應用程式，其新建立的請求從目標出口發出，網域解析也符合目前設定」。如果啟用了分流，部分請求維持直連反而可能是正常行為，關鍵在於結果是否符合規則，而不是所有流量是否都呈現同一個出口。

基準記錄與出口 IP 對照

出口 IP 是最直接的第一層檢查。關閉連線後，透過可信的 IP 查詢頁面記錄公開位址、網路營運商和大致地區；接著連線目標線路，重新整理查詢結果。若位址與網路歸屬發生變化，表示目前的查詢請求確實經過另一個公開網路出口。

• ✅ 中斷線路，關閉可能自動接管流量的瀏覽器擴充功能，並記錄目前的出口資訊。
• ✅ 連線目標線路，等待用戶端顯示握手完成，再開啟新的瀏覽器分頁進行查詢。
• ✅ 比較公開位址、自治系統歸屬與地區，不要只看地圖上的城市名稱。
• ✅ 分別檢查 IPv4 與 IPv6；雙堆疊網路可能讓兩類請求選擇不同路徑。
• ✅ 使用另一個預期會被接管的應用程式複查，避免把瀏覽器專屬代理設定誤當成全域結果。

地區名稱只能作為輔助資訊。IP 資料庫可能將同一個位址區段標示為機房註冊地、網路營運商所在地或鄰近城市，因此城市不完全一致不代表線路失效。更有參考價值的是公開位址是否改變、網路歸屬是否符合節點類型，以及多次新建立的請求是否持續使用預期出口。

如果連線前後的位址完全相同，先不要反覆切換節點。應檢查目前模式是否只開啟本機代理連接埠，卻沒有啟用系統代理或 TUN；也要確認查詢頁面是否被分流規則判定為直連。瀏覽器擴充功能也可能覆寫系統設定，讓瀏覽器與其他應用程式呈現相反結果。

網域解析：DNS 歸屬與洩漏判斷

DNS 負責將網域轉換為可連線的位址。網頁流量經過線路，但 DNS 查詢仍交由本地網路解析器處理時，造訪的網域資訊可能沿著不同路徑傳送。這通常稱為 DNS 洩漏。判斷重點不是「DNS 所在國家必須與出口完全相同」，而是解析器是否符合用戶端、系統或瀏覽器中設定的方案。

現代瀏覽器可能啟用加密 DNS，直接使用瀏覽器指定的解析服務；Android 的私人 DNS、系統網路設定和用戶端內建 DNS 也可能互相覆寫。此時查詢結果顯示第三方解析網路，不會自動等於洩漏。需要先確認由誰負責解析，再判斷這條路徑是否符合預期。

各桌面平台都能查看目前的解析設定。以下命令用於觀察系統狀態，不會直接證明瀏覽器是否繞過系統 DNS，但能協助定位設定來源：

Windows
ipconfig /all

macOS
scutil --dns

Linux
resolvectl status

Windows 輸出中可以查看目前使用中的網路介面所使用的 DNS 伺服器；macOS 的結果會列出不同作用域的解析器；採用 systemd-resolved 的 Linux 環境則可查看各介面的 DNS 與預設路由狀態。若用戶端使用 TUN 並接管解析，通常能在相關虛擬介面或用戶端設定中找到對應線索。

瀏覽器端還要另外查看安全 DNS 設定。如果瀏覽器強制使用自訂解析器，系統命令顯示的伺服器可能根本沒有處理網頁查詢。相反地，某些用戶端會攔截系統 DNS，並在通道內轉送；此時本機看到的位址只是接收入口，最終遞迴解析器可能位於其他網路。

分應用程式請求：找出哪些程式直連

出口 IP 頁面只能證明發起查詢的那個應用程式經過線路。瀏覽器正常，不代表終端機、下載工具、遊戲平台或桌面通訊軟體也採用相同路徑。最穩妥的方法是逐一對應用程式發出相同請求，並將結果與連線模式對照。

系統代理通常只會影響主動讀取系統代理設定的軟體。有些命令列工具、遊戲和自帶網路堆疊的應用程式會忽略這項設定。TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，但仍可能受到路由排除項目、應用程式繞過規則和區域網路直連規則影響。瀏覽器擴充功能的範圍更小，通常只處理該瀏覽器內支援代理的請求。

1. 先在瀏覽器中檢查出口，並記錄結果。
2. 再使用命令列網路工具，向同類出口查詢介面發出請求，比較網路歸屬。
3. 開啟需要驗證的桌面或行動應用程式，觸發新的請求，而不是查看快取內容。
4. 查看用戶端連線記錄或活動連線清單，確認是否出現目標網域、目標位址或對應程序。
5. 切換為全域規則進行短暫對照；若全域模式正常而分流模式異常，問題通常出在規則比對。

用戶端記錄比「網頁能不能開啟」更適合定位分流問題。若記錄將請求標記為直連，應檢查網域規則、IP 規則、程序規則和規則優先順序。網域解析後可能連線至內容傳遞網路位址，只設定網域規則而實際比對發生在 IP 階段時，也可能得到與預期不同的路徑。

還要區分連線測試與服務可用性。線路握手成功、出口發生變化，代表傳輸路徑基本成立；目標服務仍然報錯，則可能與帳號地區、快取、瀏覽器儲存資料、時間設定或服務本身的策略有關。此時繼續修改代理連接埠通常無法解決應用程式層的問題。

常見誤判與對應修復方法

只啟動用戶端，沒有啟用系統接管

不少代理用戶端允許分開控制「啟動核心」與「設定系統代理」。前者只會在本機監聽代理連接埠，適合手動填寫代理的應用程式；後者才會修改系統代理設定。如果希望涵蓋更多不讀取系統代理的軟體，應在用戶端支援的情況下評估 TUN 模式，並檢查是否已授予虛擬網卡權限。

分流規則將測試目標設為直連

規則模式會根據網域、位址、程序或規則集決定路徑。出口查詢網站若命中直連規則，就會顯示本地出口，但其他目標可能已經透過線路。排查時可以暫時切換至全域模式進行對照，確認線路本身無誤後，再回到規則模式修正規則。

IPv4 經過線路，IPv6 維持直連

雙堆疊網路會根據網域回傳結果和系統路由選擇協定族。若用戶端只接管 IPv4，而應用程式優先建立 IPv6 連線，查詢結果可能暴露本地 IPv6 出口。修復方式不是盲目關閉系統功能，而是先確認用戶端是否支援相應流量，再調整 TUN、路由或 DNS 回傳策略。

瀏覽器和系統使用不同的 DNS

瀏覽器安全 DNS 可以繞過系統解析設定，系統的私人 DNS 也可能優先於用戶端設定。應明確選擇一種受控方案：由瀏覽器自行進行加密解析，或由用戶端在通道內統一處理。多層設定同時啟用時，結果雖然可能正常，但排錯會變得困難。

舊連線沒有隨線路切換

應用程式可能重複使用既有連線，連線池和背景程序也可能繼續維持舊路徑。切換節點後，應讓測試應用程式建立新的連線。退出應用程式、重新開啟頁面或清除相關連線狀態，比連續點擊重新整理更能排除舊工作階段的干擾。

• ✅ 瀏覽器有變化、其他應用程式不變：檢查系統代理的適用範圍，或改用合適的 TUN 接管。
• ✅ 全域模式有變化、規則模式不變：檢查直連規則、規則順序與程序比對。
• ✅ IP 發生變化、DNS 仍經由本地網路：檢查用戶端 DNS 接管與瀏覽器安全 DNS。
• ✅ IPv4 發生變化、IPv6 不變：檢查雙堆疊路由與用戶端對協定族的支援。
• ✅ 所有出口都正確但目標服務異常：改從帳號、快取、地區判定和應用程式層錯誤著手排查。

平台差異：為何相同設定會得到不同結果

在 Windows 上，系統代理與路由表是兩套不同機制。瀏覽器可能讀取系統代理，但命令列程式不一定會讀取；TUN 模式則取決於虛擬網卡與路由。可以使用 route print 查看預設路由及虛擬介面是否參與轉送，再結合用戶端記錄判斷具體請求。

macOS 會依網路服務儲存系統代理，而基於 Network Extension 的用戶端可以建立系統層級通道。若同一台裝置安裝了多個網路擴充功能，應避免同時啟用互相衝突的接管方式。查看 scutil --proxy 可以了解系統代理狀態，scutil --dns 則用於核對解析作用域。

在 iOS 上，系統狀態列的 VPN 標記只代表設定處於啟用狀態。瀏覽器、應用程式內請求和 DNS 是否符合預期，仍需透過出口與實際服務請求驗證。部分應用程式可能使用快取內容，因此切換線路後應觸發新的載入。由組織管理的分應用程式 VPN 與一般個人設定，也不是相同的接管範圍。

Android 同時存在 VPN 服務、永遠開啟連線、私人 DNS 和應用程式排除清單。若某個應用程式被排除，就會維持直連；若私人 DNS 獨立啟用，解析路徑也可能與用戶端不同。驗證時應檢查用戶端的分應用程式設定以及系統網路設定，而不是只看鑰匙或 VPN 圖示。

Linux 的桌面網路管理員、環境變數代理和 TUN 路由可以並存。終端機工具是否使用代理，取決於工具本身的設定和環境變數；系統層級路由則會影響更廣泛的流量。可用 ip route 查看路由，用 resolvectl status 查看解析器，再結合目標程序的連線記錄判斷。

完整複核：依固定順序縮小問題範圍

當結果互相矛盾時，不要同時修改協定、節點、DNS 和分流規則。一次只變更一個變數，才能知道哪項設定真正影響結果。建議先驗證線路基本連通，再驗證系統接管，最後處理應用程式規則與 DNS。

1. 中斷連線，記錄瀏覽器、命令列和系統 DNS 的基準狀態。
2. 連線線路，確認用戶端完成握手且沒有持續報錯。
3. 建立新的瀏覽器請求，對照出口 IP 與網路歸屬。
4. 檢查 IPv4、IPv6 和 DNS 是否符合目前的接管方案。
5. 分別向需要使用線路的應用程式發出新請求，並查看用戶端記錄。
6. 若應用程式結果不同，依序檢查系統代理、TUN、應用程式排除項目和分流規則。
7. 恢復日常規則後再次測試，確保排查時的臨時全域設定沒有掩蓋問題。