VPN 主要保護的是裝置與 VPN 伺服器之間的連線通道，但「已連線」不代表所有網路請求都一定按照預期路徑傳輸。當作業系統、瀏覽器、應用程式或用戶端設定不完整時，DNS 查詢可能仍交給本地網路處理；瀏覽器的 WebRTC 功能也可能暴露部分網路介面資訊。因此，判斷 VPN 是否安全，不能只看用戶端圖示，而要分別檢查出口位址、DNS 解析路徑與瀏覽器功能。
本文會先說明 DNS 洩漏與 WebRTC 暴露的差異，再提供 Windows、macOS、Android、iOS 與 Linux 通用的檢查思路。你不需要只依賴某一個測試網站；透過用戶端狀態、系統設定、瀏覽器測試與命令列結果交叉比對，才能分辨是真正的 DNS 洩漏、分流規則造成的正常例外，還是測試頁面快取導致的誤判。
DNS 洩漏到底是什麼
DNS 可以理解為把網域名稱轉換成 IP 位址的查詢服務。例如瀏覽器要開啟某個網站時，通常先查詢該網站的網域，取得可連線的位址後才建立後續連線。若 VPN 已經接管主要流量，卻仍由本地寬頻業者、公共 Wi-Fi 或路由器提供 DNS 查詢，查詢的網域名稱就可能暴露在 VPN 通道之外，這種情況通常被稱為 DNS 洩漏。
DNS 洩漏不一定表示網站內容已被直接讀取，也不等於帳號密碼立即外流；它首先暴露的是「裝置曾查詢哪些網域」。不過，網域名稱本身可能反映使用者正在存取的服務、工作平台或網站類型，因此在公共 Wi-Fi、共享網路或重視隱私的日常使用情境中，仍值得處理。
常見原因包括：VPN 用戶端只設定了系統代理，沒有接管系統 DNS；分流模式刻意讓部分網域直連；作業系統在切換 Wi-Fi 與行動網路時重新套用原有 DNS；瀏覽器啟用了自己的安全 DNS；或者同時執行兩個代理、加密 DNS 與 VPN 工具，導致實際查詢路徑與預期不同。
90+
可選國家
200+
可選線路
不限
同時在線裝置
上述節點數量與裝置支援範圍，不能取代本機驗證。無論使用官方 Windows、macOS、Android、iOS 或 Linux 用戶端，還是將訂閱匯入 Clash Verge、sing-box、Shadowrocket 等相容客戶端，都要確認目前採用的是哪一種模式，以及 DNS 是否由該客戶端接管。
DNS 洩漏與 WebRTC 暴露有何不同
DNS 洩漏關注的是網域解析請求經由哪一個 DNS 伺服器送出；WebRTC 則是瀏覽器為了語音、視訊與點對點連線而使用的一組網路能力。部分 WebRTC 測試會嘗試取得本地網路介面、區域網路位址或連線候選資訊。它與 DNS 是不同的問題，因此只看到 DNS 測試正常，不能推斷 WebRTC 一定沒有暴露資訊。
現代瀏覽器通常會透過權限機制、位址遮蔽與瀏覽器策略降低暴露程度，但不同瀏覽器版本、擴充功能、企業管理設定與作業系統行為可能造成差異。某些測試頁面顯示的本地位址，可能只是瀏覽器為連線協商產生的候選資訊，不一定等於遠端服務已經能直接連入你的裝置；判讀時應看測試頁面標示的位址類型與說明，不要把每個內部位址都當成嚴重漏洞。
| 檢查項目 | 主要觀察內容 | 常見處理方向 |
|---|---|---|
| DNS | 測試頁面顯示的 DNS 服務商與所在網路 | 啟用用戶端 DNS 接管，檢查分流與加密 DNS 設定 |
| WebRTC | 瀏覽器是否顯示不希望暴露的網路介面資訊 | 檢查瀏覽器權限、擴充功能與 WebRTC 相關政策 |
| 出口 IP | 外部網站看到的公共 IP 是否符合目前節點 | 確認 VPN 模式、節點狀態與應用程式是否走代理 |
| IPv6 | IPv6 請求是否繞過只處理 IPv4 的代理通道 | 確認用戶端支援 IPv6，或暫時停用未受保護的 IPv6 路徑 |
修復前先做一次完整檢查
檢查前先關閉其他 VPN、代理、加密 DNS 工具與瀏覽器擴充功能，避免多個元件同時修改路徑。接著記下目前使用的網路類型，例如家用 Wi-Fi、公司網路、公共 Wi-Fi 或行動數據；再確認 VPN 用戶端使用的是全域模式、規則分流、系統代理，還是虛擬網卡模式。不同模式對 DNS 與未支援代理的應用程式，接管程度可能完全不同。
- 連線到 VPN 節點後，先檢查外部 IP。若仍顯示本地網路的出口，不要急著判定 DNS 問題，應先處理 VPN 沒有正確接管流量的問題。
- 在無痕視窗開啟 DNS 洩漏測試頁面，執行標準或完整測試，記錄顯示的 DNS 服務商、國家或網路提供者。無痕模式可減少快取與登入狀態幹擾，但不會改變 VPN 的底層路徑。
- 清除 DNS 快取後再次測試。Windows 可在命令提示字元執行
ipconfig /flushdns；macOS 與 Linux 的清除方式會依系統版本及所使用的解析服務不同，不宜直接套用其他版本的單一指令。 - 在同一瀏覽器中檢查 WebRTC，再使用另一個瀏覽器交叉比對。若只有某個瀏覽器出現額外資訊，應優先檢查該瀏覽器的權限、擴充功能與安全 DNS 選項。
- 更換一次 VPN 節點，或在 Wi-Fi 與行動網路之間切換後重測。若只有某個節點或某種接入方式出現異常，問題可能與節點設定、協定實作或本地網路相容性有關。
在 Windows 上，還可以執行 nslookup example.com 觀察系統回報的 DNS 伺服器；macOS 可在「系統設定」的網路詳細資訊中查看 DNS；Linux 則可使用系統網路管理工具或 resolvectl status 查看目前解析器。這些命令反映的是作業系統看到的設定，不一定能完整描述所有應用程式的實際行為，所以仍要和瀏覽器測試結果一起判斷。
Android 與 iOS 的系統權限較受限制，部分命令列方法不適用。使用者應先查看 VPN 設定是否顯示已連線、是否啟用「封鎖沒有 VPN 的連線」或類似的永遠開啟選項，再檢查瀏覽器中的安全 DNS 與 WebRTC 行為。若使用第三方相容客戶端，則要查看其 DNS 模式、TUN 或虛擬網卡狀態，以及是否允許 IPv6 流量直連。
DNS 洩漏的修復方法
最直接的做法，是在 VPN 用戶端中啟用 DNS 接管或隨 VPN 連線套用 DNS。官方用戶端通常會在連線設定、進階設定或隱私選項中提供相關開關；不同版本的名稱可能不同。開啟後重新連線，再清除本機 DNS 快取並重測。若用戶端提供「僅代理指定網域」的規則，必須確認測試使用的網域沒有被列為直連。
如果使用 Clash Verge、sing-box 或 Shadowrocket，應檢查 DNS 模式與路由規則是否互相矛盾。DNS 設定可能包含直連解析、代理解析、假 IP、分流 DNS 或遠端解析等選項。不要只複製網路上的設定片段；先確認目前客戶端支援的語法與版本，再逐項修改。設定完成後，應觀察解析請求是否依規則送往代理路徑，並確認本地服務、區域網路印表機或公司內部網域是否仍需要直連解析。
瀏覽器自己的安全 DNS 也可能讓測試結果與系統 DNS 不同。這並非必然是漏洞：瀏覽器可能透過 HTTPS 向指定服務商發出加密查詢，但它仍可能繞過 VPN 用戶端預期的分流策略。若你的目標是讓 DNS 路徑由 VPN 統一管理，應在瀏覽器中關閉獨立的安全 DNS，或選擇與目前代理規則相容的設定，之後重新啟動瀏覽器測試。
IPv6 是常被忽略的因素。有些舊版代理只處理 IPv4，而作業系統仍可透過 IPv6 直接連線。此時即使 IPv4 測試看起來正常，特定網站或應用程式仍可能使用未受保護的 IPv6 路徑。優先使用支援 IPv6 接管的用戶端；若目前環境無法正確處理 IPv6，再按照作業系統與網路管理政策暫時停用 IPv6，並在更新用戶端後重新評估，而不是長期忽略這個差異。
- ✅ 一次只保留一個主要 VPN 或代理客戶端，避免路由與 DNS 設定互相覆寫
- ✅ 修改 DNS、分流或 TUN 設定後，先斷線再重新連線
- ✅ Wi-Fi、行動網路與公共網路切換後，重新檢查 DNS 與出口 IP
- ✅ 確認 IPv4 與 IPv6 都有符合預期的代理路徑
- ❌ 不要只依賴用戶端的「已連線」字樣判定隱私設定完整
- ❌ 不要把瀏覽器 WebRTC 測試結果直接當成 DNS 洩漏證據
瀏覽器與應用程式的額外設定
瀏覽器是最容易檢查、也最容易出現例外的應用程式。檢查時建議先停用不必要的代理擴充功能，因為擴充功能可能只改變瀏覽器請求，卻不會影響其他應用程式。若同時啟用瀏覽器代理、系統代理與 VPN 虛擬網卡，實際路徑可能難以判斷。保留一種主要接管方式，再用無痕視窗測試，通常更容易定位問題。
部分桌面應用程式不使用系統代理，可能直接建立自己的 TCP、UDP 或 QUIC 連線。這類程式即使瀏覽器沒有 DNS 洩漏，也不代表它一定遵循同一條通道。需要保護的應用程式應查看自身是否支援代理設定，或使用能接管整個系統流量的虛擬網卡模式。對遊戲、視訊會議、命令列工具與開發環境，還要留意它們是否自行管理 DNS、憑證與連線重試。
如果你使用 WireGuard、Shadowsocks、VMess、Trojan 或 Hysteria2 等協定，不能僅根據協定名稱推斷 DNS 一定安全。協定負責建立或承載連線，DNS 是否進入代理通道，仍取決於客戶端的 DNS、路由、分流與系統整合方式。即使同一份訂閱在不同客戶端匯入，DNS 行為也可能不同，因此換客戶端後必須重新檢查。
公共 Wi-Fi、網銀與日常上網怎麼設定
在公共 Wi-Fi 使用 VPN 時，首先要確認網路本身已完成登入或驗證。有些場所會先要求開啟入口頁面，VPN 連線可能因此無法建立；此時可先按照場所要求完成連線，再啟用 VPN。不要在尚未確認通道有效時登入重要帳號，也不要因為瀏覽器顯示鎖頭圖示，就忽略 DNS、出口與裝置安全更新。
網銀與支付服務應優先使用官方應用程式或自行輸入的正確網址，避免從不明訊息開啟重新導向連結。VPN 可以協助保護裝置到代理節點之間的傳輸，但不能辨識所有釣魚網站，也不能取代多因素驗證、裝置更新與帳號通知。若銀行對異常地區、出口或裝置變化觸發額外驗證，應依官方流程處理，不要反覆切換節點試圖避開安全檢查。
日常上網可使用規則分流，讓本地服務、公司內部資源與區域網路裝置維持直連，同時讓需要代理的網站經由 VPN。分流雖然方便，但它也增加了 DNS 判讀難度：某些直連網域的解析本來就可能使用本地 DNS。設定分流前應先決定優先目標，是完整隱私、區域網路相容性，還是特定應用程式可用性；不要把所有模式都宣稱為同一種安全等級。
完成設定後，至少保留一份自己的檢查記錄：使用的作業系統、VPN 客戶端、協定、分流模式、DNS 模式與測試時間。當問題再次出現時，可以先比較設定是否改變，而不是重複安裝多個工具。若公共網路管理者、瀏覽器或作業系統更新了網路行為，也能更快找出異常來源。
常見問題
VPN 顯示已連線，就代表沒有 DNS 洩漏嗎？
不代表。已連線通常只說明用戶端完成了連線狀態，DNS 可能仍由系統原有解析器處理。你需要在連線狀態下執行 DNS 測試，並在切換節點、網路或客戶端後重新驗證。
改用公共 DNS 就能修復洩漏嗎？
不一定。更換 DNS 服務商只能改變查詢的目的地，不能保證查詢一定經過 VPN 通道。如果系統或瀏覽器仍繞過 VPN，公共 DNS 也可能暴露查詢來源或與分流策略不一致。正確順序是先確認路由與 DNS 接管，再選擇符合需求的解析服務。
WebRTC 顯示本地位址，是否代表 VPN 已失效？
不一定。WebRTC 顯示的是瀏覽器連線協商可能使用的候選資訊，與 DNS 測試不同。應查看測試頁面所標示的位址類型，並使用另一個瀏覽器交叉比對；若不希望瀏覽器提供相關資訊，再調整權限或 WebRTC 政策。
修復後仍看到原本的 DNS，應該怎麼辦？
先清除 DNS 快取、完全關閉並重新開啟瀏覽器，再確認 VPN 是否重新連線。接著檢查瀏覽器安全 DNS、IPv6、分流規則與其他代理工具。如果只有特定網域出現原本的解析器，可能是規則刻意直連；如果所有網域都如此，則應回到客戶端的 DNS 接管與虛擬網卡設定逐項排查。