VPN 安全嗎？DNS 洩漏檢查與修復完整指南

開啟 VPN 並不代表所有網絡請求都會自動經過同一條受保護的通道。瀏覽器、作業系統與應用程式可能各自選擇 DNS 解析器、IPv4 或 IPv6 路徑，也可能因分流規則而直接連線。結果是網頁看似已經連上 VPN，但 DNS 查詢仍由本地網絡供應商處理，或瀏覽器透過 WebRTC 暴露了另一個可識別的網絡位址。

DNS 洩漏不一定代表 VPN 完全失效，但它會削弱私隱保護與網絡判斷的一致性。若你需要確認 VPN 是否按預期工作，應分開檢查出口 IP、DNS 解析位置、IPv6 路徑與 WebRTC 行為，再根據檢查結果修復，而不是隻看客戶端畫面上的「已連線」狀態。本文會依照實際排查順序，說明不同平台與常見客戶端的處理方法。

DNS 洩漏到底是甚麼

DNS 的作用是把網域名稱轉換成伺服器位址。當你在瀏覽器輸入一個網址時，裝置通常要先向 DNS 解析器發出查詢，才能知道應該連線到哪個伺服器。若 VPN 已建立通道，但這些查詢仍直接送往本地路由器、電信商 DNS 或系統預設解析器，就形成了 DNS 洩漏。

這種情況與「出口 IP 是否已改變」是兩個不同問題。出口 IP 可能已經顯示為 VPN 節點的位置，但 DNS 查詢仍在 VPN 通道外完成；也可能 DNS 已經改由遠端解析，而 IPv6 流量卻沒有進入相同通道。換句話說，單一測試頁面顯示位置改變，不能證明所有網絡請求都已經正確分流。

檢查項目	主要確認內容	出現問題時的常見原因
出口 IP	對外連線使用哪個公網位址與地區	VPN 未真正連線、應用程式被排除在分流規則之外
DNS 解析器	網域查詢由哪個服務或網絡處理	系統 DNS 優先級、瀏覽器安全 DNS、客戶端接管不完整
IPv6	IPv6 請求是否與 IPv4 使用相同保護通道	VPN 只接管 IPv4，或本地網絡仍提供可用 IPv6 路徑
WebRTC	瀏覽器即時通訊介面是否顯示額外網絡位址	瀏覽器允許候選位址暴露、擴充功能或權限設定未限制

還要區分 DNS 洩漏與惡意軟件篡改。前者通常是路由、系統或客戶端設定不一致，後者則可能涉及代理設定被修改、根憑證遭安裝或裝置受到感染。若每次關閉 VPN 後 DNS 都被改成陌生服務，或瀏覽器持續跳轉到不熟悉的頁面，就不應只調整 VPN，還要檢查系統安全狀態。

檢查前先固定測試條件

DNS 測試很容易受到瀏覽器快取、私人 DNS、企業網絡政策及分流規則影響。為了避免把偶然結果誤判為修復成功，建議先記錄沒有連線 VPN 時的狀態，再在同一裝置、同一網絡及相近時間重新測試。不要只測試一個網站，也不要在同一時間開啟兩個代理客戶端，否則系統路由可能互相覆蓋。

關閉 VPN，記錄目前的出口 IP、DNS 服務名稱及 IPv6 是否可用。
清除瀏覽器的 DNS 快取，或使用私人瀏覽視窗重新開啟測試頁。
只開啟一個 VPN 客戶端，等待連線狀態穩定後再進行檢查。
分別測試一般網站、IPv6 測試頁、DNS 洩漏測試與 WebRTC 檢查頁。
切換一次節點或網絡環境，確認結果不是某個特定節點的暫時異常。

測試頁面顯示多個 DNS 位址並不一定代表洩漏。有些 VPN 服務會使用多個遠端解析器，或讓同一服務由不同入口回應。真正需要關注的是：是否出現本地電信商、家用路由器、公司網絡或不應出現的解析器；以及 VPN 連線前後，解析器是否仍完全沒有變化。

如何分辨 DNS、IPv6 與 WebRTC 問題

三者經常一起被稱為「洩漏」，但修復方式並不相同。DNS 洩漏是網域查詢路徑不符合預期；IPv6 問題是某類流量走了 VPN 沒有接管的位址族；WebRTC 則是瀏覽器在建立即時連線時取得並展示網絡候選位址。先分清楚問題類型，才不會盲目更換 DNS 或重裝客戶端。

DNS 洩漏的特徵

最常見的特徵是 VPN 已連線、出口 IP 已改變，但測試頁仍顯示本地網絡供應商的 DNS。另一種情況是作業系統的命令列查詢走遠端解析器，瀏覽器卻因啟用內建安全 DNS 而採取另一條路徑。此時不能只修改系統 DNS，還要檢查瀏覽器的安全 DNS 設定及客戶端是否能接管加密 DNS。

IPv6 路徑沒有被接管

不少裝置同時具備 IPv4 與 IPv6 連線能力。若 VPN 只處理 IPv4，瀏覽器可能優先使用 IPv6 連線到目標網站，造成實際出口位置與測試結果不一致。這不一定會顯示為 DNS 洩漏，但會讓使用者誤以為 VPN 已保護全部流量。檢查時應分別查看 IPv4 與 IPv6 的出口結果，不要以其中一項正常就推論另一項也正常。

WebRTC 暴露額外位址

WebRTC 用於瀏覽器內的語音、視訊與點對點連線。它會收集候選網絡位址，以便建立連線；在某些瀏覽器或權限組合下，測試頁可能看到本地網絡位址、區域網絡介面或其他候選資訊。WebRTC 位址暴露與 DNS 查詢不是同一件事，因此關閉瀏覽器的 WebRTC 相關權限，不能取代 DNS 路由修復。

✅ 出口 IP、DNS 解析器與 IPv6 結果要分開記錄
✅ 測試時只保留一個 VPN 或代理客戶端運作
✅ 瀏覽器內建安全 DNS 要與 VPN 的分流策略一致
❌ 不要把 WebRTC 顯示的位址直接當成 DNS 洩漏證據
❌ 不要為了測試而把訂閱連結或完整設定檔貼到陌生網站

Windows、macOS 與 Linux 的修復方法

桌面系統的修復順序應從客戶端開始，再檢查系統 DNS、IPv6 與瀏覽器。大部分現代 VPN 客戶端會提供「DNS 洩漏防護」「阻止 VPN 外流量」或「網絡鎖」等選項。這些名稱可能不同，但核心目標是：連線建立前後，限制不符合規則的 DNS 查詢與普通流量離開裝置。

Windows

在 Windows 上，先確認 VPN 客戶端使用的是完整隧道還是規則分流。若採用分流，瀏覽器或 DNS 程序可能被排除在通道之外。檢查網絡介面清單，確認 VPN 連線後是否新增虛擬介面；再查看目前使用的 DNS 伺服器。修改系統 DNS 後，應先斷開並重新連線 VPN，再清除 DNS 快取，因為已存在的解析結果可能會令測試頁短時間內仍顯示舊資料。

如果問題只在某個瀏覽器出現，應檢查該瀏覽器的安全 DNS、代理設定與 WebRTC 權限。不要只在 Windows 網絡設定中反覆填寫公共 DNS；若客戶端本身要求接管 DNS，手動設定可能被覆蓋，也可能造成兩套解析策略互相衝突。

macOS 與 Linux

macOS 可能同時存在 Wi-Fi、乙太網路、VPN 及其他虛擬介面。DNS 服務順序會影響實際查詢路徑，因此應在 VPN 連線後檢查目前生效的解析器，而不是隻查看某一個網絡服務的預設值。若使用第三方客戶端，還要確認它是否支援系統 DNS 接管、IPv6 阻擋及斷線保護。

Linux 的網絡管理方式取決於 NetworkManager、systemd-resolved、桌面環境及客戶端核心。使用 sing-box、Clash Verge 或其他相容工具時，透明代理、TUN 介面與 DNS 分流需要同時配置；只開啟 HTTP 或 SOCKS 代理，並不代表系統所有應用程式都會自動使用它。若命令列工具與瀏覽器結果不同，應先比較兩者的代理環境變數、DNS 模式及路由表。

修復結論：桌面裝置上，優先使用客戶端提供的 DNS 洩漏防護與斷線阻擋，再處理瀏覽器安全 DNS和 IPv6；單獨修改系統 DNS 通常不足以涵蓋所有應用程式。

Android 與 iPhone 的處理方式

手機的 DNS 路徑比桌面系統更容易受到「私人 DNS」、系統級加密解析、應用程式分流及省電策略影響。Android 使用者應檢查系統的私人 DNS 設定，並確認 VPN 客戶端是否要求使用自己的 DNS 模式。如果私人 DNS 強制指定某個主機名稱，VPN 客戶端未必能按照預期接管查詢；反過來，完全關閉系統功能也不一定是最佳答案，重點是兩者必須採用一致的路由策略。

Android 的 VPN 設定通常可以查看是否啟用「封鎖沒有 VPN 的連線」或類似選項。這類功能能在 VPN 斷線時阻止部分流量外流，但不代表一定能修復瀏覽器 WebRTC、IPv6 或應用程式自建 DNS 的問題。完成設定後，應分別測試瀏覽器與需要連線的應用程式。

iPhone 與 iPad 的 VPN 行為受系統網絡權限與客戶端實作限制。若使用官方客戶端，先在應用程式內啟用 DNS 保護、連線時封鎖未受保護流量等功能，再檢查 iCloud Private Relay、企業描述檔或其他網絡過濾工具是否同時運作。多個網絡隱私功能並行時，測試結果可能難以判斷，排查期間應逐一停用非必要的網絡代理或內容過濾設定。

在行動裝置上，切換 Wi-Fi 與流動數據後必須重新測試。某些客戶端在網絡切換時會重新建立隧道，但也可能短暫保留舊的 DNS 狀態。若只在 Wi-Fi 正常、流動數據異常，問題可能來自該網絡的 IPv6、私人 DNS 或系統權限，而不一定是節點本身。

第三方客戶端與協定設定要點

Clash Verge、sing-box、Shadowrocket 等相容客戶端通常提供比官方客戶端更多的 DNS、TUN、分流與路由選項，但彈性越高，越需要理解設定的實際作用。使用訂閱匯入節點後，先確認客戶端核心是否支援訂閱中的協定，例如 Shadowsocks、VMess、Trojan、Hysteria2 或 WireGuard；訂閱成功匯入，不等於 DNS 模式、TUN 介面與分流規則已正確啟用。

如果使用規則分流，應先決定 DNS 查詢要由哪一個解析器處理，再決定哪些網域走代理、哪些網域直連。若規則只處理瀏覽器流量，系統更新、命令列工具或其他應用程式可能仍使用本地解析。若使用 fake-IP、Redir-Host 或 TUN 模式，也要確認 DNS 回應與路由模式相互匹配，避免出現網域能解析但實際連線走錯介面的情況。

Shadowrocket 等行動客戶端常見「代理 DNS」「遠端 DNS」「按規則解析」等選項。這些選項的名稱並不完全一致，不能單靠字面判斷。完成修改後，應重新連線，清除瀏覽器快取，再使用相同測試條件檢查。若某一協定正常、另一協定出現洩漏，問題可能是核心實作或該設定檔的 DNS 路由，而不是裝置本身。

修復後如何確認沒有再次洩漏

修復不是把某個選項打開後立刻結束，而是要驗證不同情境下的結果。先在 VPN 連線狀態下測試，再手動切換節點、切換 Wi-Fi 與流動數據、暫時關閉 VPN，最後重新開啟。每個情境都記錄出口 IP、DNS 解析器、IPv4、IPv6 及 WebRTC 結果，才能知道問題是固定設定、特定節點，還是網絡切換時才出現。

驗證時也應測試實際使用的應用程式。瀏覽器測試正常，不代表電子郵件客戶端、命令列工具、遊戲或影音應用程式一定遵守同一套代理設定。有些應用程式會使用自己的 DNS、QUIC 或 UDP 通道；如果客戶端只代理 TCP，這些流量可能需要額外規則，或應改用支援相應流量的模式。

若你使用的是公司、學校或公共 Wi-Fi，網絡管理員可能會強制指定 DNS 或封鎖某些協定。此時測試結果要與個人流動數據或另一個可信網絡比較。不要為了繞過管理政策而隨意安裝陌生根憑證、修改系統安全設定或下載來源不明的客戶端，因為這些做法可能造成比 DNS 洩漏更嚴重的安全風險。

✅ VPN 連線前後，出口 IP 與 DNS 解析器變化符合預期
✅ IPv4 與 IPv6 都沒有繞過既定的保護通道
✅ 瀏覽器 WebRTC 沒有展示不應公開的本地或額外位址
✅ 切換節點與網絡後，設定仍能自動重新套用
❌ 不要只用一次測試結果宣稱所有應用程式都已受保護

常見問題

VPN 顯示已連線，為甚麼仍然會 DNS 洩漏？

「已連線」通常只代表 VPN 客戶端已成功建立某條隧道，不代表所有應用程式與 DNS 查詢都使用該隧道。常見原因包括規則分流、瀏覽器安全 DNS、IPv6 未被接管、系統私人 DNS 或另一個代理工具仍在運作。應先確認是哪一類請求外流，再針對相應設定修復。

改用另一個公共 DNS 就能解決問題嗎？

不一定。改用公共 DNS 可能改變解析服務，但如果查詢仍直接經過本地網絡，依然不符合 VPN 通道的保護預期。更換 DNS 之前，應確認客戶端是否支援遠端解析、DNS 接管與斷線阻擋，並檢查瀏覽器是否另行啟用了安全 DNS。

關閉 WebRTC 後是否代表 DNS 已經安全？

不是。關閉或限制 WebRTC 只處理瀏覽器即時連線可能暴露額外位址的問題，不能改變作業系統 DNS 路由。DNS、IPv6 與 WebRTC 應分開測試，並按照不同問題使用不同修復方法。

甚麼情況下應重裝客戶端？

如果設定已恢復預設、系統代理沒有陌生項目、DNS 與路由規則也已確認，仍只在某個客戶端出現異常，才考慮更新或重裝。重裝前先備份必要設定，但不要把包含帳戶權杖的訂閱連結公開保存。若多個客戶端與多個網絡都出現異常，則應優先檢查系統安全、根憑證及網絡環境，而不是不斷重裝。

完整結論：確認 VPN 安全性不能只看連線圖示。依序檢查出口 IP、DNS、IPv6 與 WebRTC，統一客戶端和系統的解析策略，再於不同網絡與應用程式中重複驗證，才能較可靠地判斷是否仍有流量走錯通道。