VPN 安⁠全嗎？DNS 洩漏檢查與隱⁠私防護指⁠南

VPN 安全嗎？答案不是單純的「安全」或「不安全」，而是取決於連線是否真的接管了 DNS 請求、瀏覽器是否暴露 WebRTC 位址、裝置是否仍把部分流量送出隧道，以及服務商如何處理連線資料。VPN 建立加密通道後，可以降低公共 Wi-Fi、陌生網路或中間節點直接查看傳輸內容的機會，但它不會自動消除所有隱私風險。

很多使用者看到客戶端顯示「已連線」，就認為所有流量都受到保護。實際上，VPN 可能只接管部分應用程式，DNS 仍由本地電信業者處理；瀏覽器也可能透過 WebRTC 顯示本機或真實網路位址。本文會依序檢查 DNS 洩漏、真實 IP、IPv6、WebRTC 與分流設定，並說明 Windows、macOS、Android、iOS 及 Linux 上的排查方向。

VPN 能保護什麼，不能保護什麼

VPN 的主要作用，是在裝置與 VPN 伺服器之間建立加密通道。當瀏覽器或應用程式透過這條通道連線時，本地網路通常較難直接讀取通道內的傳輸內容；網站看到的來源位址，也可能變成 VPN 線路的出口位址。這對公共 Wi-Fi、旅館網路、校園網路或不熟悉的路由環境尤其有幫助。

但 VPN 並不等於匿名工具。VPN 服務商可能看見連線時間、流量特徵或帳戶使用狀態；網站仍能透過登入帳號、Cookie、瀏覽器指紋及其他識別方式辨認使用者。若裝置感染惡意程式，或使用者主動把資料輸入釣魚網站，加密通道也無法阻止資料被交給錯誤的對象。

還要分清楚「加密通道」和「DNS 隱私」。DNS 是把網域名稱轉換成 IP 位址的查詢服務。即使網頁內容透過 VPN 傳送，如果 DNS 查詢仍交給本地網路或電信業者，對方可能從查詢紀錄推測使用者正在存取哪些網域。因此，DNS 由誰解析、查詢是否經過加密通道，是安全檢查的核心。

DNS 洩漏是怎麼發生的

VPN 連線後，理想狀態是 DNS 請求也透過加密通道送往預期的 DNS 伺服器。然而，作業系統可能保留原本的 DNS 設定，瀏覽器可能啟用自己的安全 DNS，第三方客戶端也可能因路由模式不同而使用獨立解析器。這些設定彼此衝突時，網頁可以正常開啟，使用者卻沒有察覺 DNS 已經繞過 VPN。

常見原因包括客戶端只代理瀏覽器以外的流量、啟用「允許本地網路」後仍保留本地解析、IPv6 沒有納入隧道路由，以及通用客戶端的 DNS 模式與系統服務互相覆蓋。Clash Verge、sing-box、Shadowrocket 等客戶端的設定項目名稱可能不同，不能只照搬其他平台的教學。

DNS 洩漏測試結果也需要正確解讀。測試頁面顯示某個 DNS 服務商名稱，不一定代表發生洩漏；重點是確認結果是否出現本地電信業者、家庭寬頻供應商或未預期的網路來源。如果每次切換線路後結果不同，應檢查客戶端的 DNS 策略、代理模式和訂閱設定，而不是隻更換瀏覽器。

先檢查真實 IP、DNS 與 WebRTC

檢查時不要只開啟一個測試頁面就下結論。建議先在未連線 VPN 的狀態記錄目前看到的 IPv4、IPv6、DNS 服務商與 WebRTC 資訊，再關閉頁面、連線 VPN，重新建立一次測試。兩組結果可以協助你分辨哪些項目被改變，哪些項目仍沿用原本的網路。

測試期間應暫停其他代理工具、瀏覽器擴充功能與自訂 DNS 應用程式。若同時開啟官方客戶端與 Clash Verge，兩者可能競爭系統代理或路由權限；若又在瀏覽器內啟用 Secure DNS，測試結果就可能反映瀏覽器自己的設定，而不是 VPN 客戶端的 DNS 策略。

• ✅ 先記錄未連線狀態的 IPv4、IPv6 與 DNS 結果，再進行對照。
• ✅ 連線後重新整理測試頁，確認 DNS 來源與出口位址是否一致。
• ✅ 在不同瀏覽器檢查 WebRTC，避免單一瀏覽器快取造成誤判。
• ✅ 暫時停用其他代理、Smart DNS 或自訂網路工具。
• ❌ 不要因為網站能正常開啟，就認定 DNS 一定經過 VPN。
• ❌ 不要把測試頁顯示的每一個 DNS 名稱都直接判定為洩漏。

WebRTC 是瀏覽器用於即時通訊、語音、視訊與點對點連線的技術。它可能取得網路介面資訊，並在特定條件下讓頁面看到與一般 HTTP 連線不同的位址。WebRTC 顯示本地私有位址不一定等於真實出口洩漏，但若顯示了未預期的公共 IPv4 或 IPv6，就應檢查瀏覽器權限、WebRTC 防護擴充功能與客戶端的路由狀態。

不同裝置的隱私防護設定

Windows、macOS 與 Linux

桌面系統最常見的問題，是系統代理與完整 VPN 隧道被混為一談。瀏覽器看到系統代理已設定，不代表所有應用程式都會遵守；反過來，某些 TUN 模式能接管較多流量，卻可能與本地虛擬網卡、企業安全軟體或其他 VPN 發生衝突。使用官方客戶端時，應先確認是否提供 DNS 防洩漏、斷線保護與 IPv6 處理選項。

Windows 可檢查目前網路介面、DNS 伺服器與虛擬網卡是否在 VPN 連線後出現；macOS 可留意 Wi-Fi 服務與 VPN 服務的 DNS 優先順序；Linux 則要特別注意 NetworkManager、systemd-resolved、容器網路與手動設定檔是否同時管理 DNS。使用 sing-box 或其他核心客戶端時，JSON 中的 DNS、route、tun 與 auto_route 選項必須互相配合，不能只複製單一區段。

Android 與 iOS

行動裝置通常會要求使用者授權建立 VPN 設定。Android 的「私人 DNS」與 VPN 客戶端的 DNS 設定可能同時存在；啟用分應用代理時，未列入代理清單的應用程式仍可能直接使用本地網路。iOS 則需要檢查按需連線、分流方式與應用程式是否真的取得系統 VPN 權限。當 Wi-Fi 切換到行動網路後，最好手動確認客戶端是否重新連線。

如果服務商提供官方 Windows、macOS、iOS、Android 或 Linux 客戶端，首次設定可優先使用官方應用程式，再依需要匯入訂閱連結至相容客戶端。通用客戶端的優點是可自行管理規則與策略組，但錯誤的 DNS 模式或分流規則，可能讓部分應用程式避開隧道。

動手排查與修正流程

以下流程適合在完成首次設定後使用，也適合每次更換客戶端或訂閱設定時重新執行。排查時請保留原有設定的備份，尤其是手動輸入的 DNS、路由規則與自訂節點，避免修改後無法回復。

1. 關閉其他網路工具：只保留一個 VPN 或代理客戶端，暫停瀏覽器內的代理擴充功能與自訂 DNS 應用程式。
2. 確認隧道已建立：查看系統 VPN 權限、虛擬網卡、客戶端的連線狀態及目前使用的線路。
3. 檢查 DNS 策略：確認客戶端是否啟用遠端 DNS、加密 DNS 或 DNS 代理，並查看分流規則是否把 DNS 送往本地介面。
4. 重新測試 IP：分別檢查 IPv4、IPv6 與 WebRTC，不要只看其中一項。若 IPv6 未納入隧道，可暫時停用 IPv6 作為排錯步驟，再依裝置與網路環境決定長期設定。
5. 啟用斷線保護：在客戶端支援的情況下啟用 Kill Switch 或阻止 VPN 斷線後流量外送的功能。確認它不會誤擋本地印表機、區域網路或必要的系統服務。
6. 逐項恢復功能：先恢復瀏覽器安全 DNS，再恢復分應用代理、規則組與其他網路工具；每次恢復一項後重新測試。

若修正後 DNS 結果仍顯示本地服務，先不要急著更換節點。檢查訂閱是否包含完整 DNS 設定、客戶端是否支援目前協定，以及系統是否存在多個網路介面。Shadowsocks、VMess、Trojan、Hysteria2、WireGuard 等協定負責傳輸方式不同，但「DNS 是否正確進入隧道」仍然是路由與客戶端配置問題，不能單靠協定名稱判定安全程度。

公共 Wi-Fi 與分流使用情境

在機場、咖啡店、旅館或共享辦公室使用公共 Wi-Fi 時，先確認網路登入頁已完成，再啟用 VPN，通常比較不容易遇到認證頁無法載入的問題。連線完成後，檢查 VPN 是否仍保持啟用；部分網路在切換存取點、進入休眠或訊號短暫中斷後，可能讓客戶端失去隧道。

分流模式不一定是不安全，但必須知道哪些流量被排除。瀏覽器、郵件、同步工具與工作應用程式可能被放在不同策略組；若 DNS 走全域設定、應用程式卻走直連，就會出現「網頁看似正常、隱私結果不一致」的情況。對不熟悉規則的使用者，全域模式通常較容易驗證；需要本地服務時，再逐項建立例外。

• ✅ 公共 Wi-Fi 重新連線或切換網路後，再確認 VPN 與 DNS 狀態。
• ✅ 為工作應用程式、本地服務與瀏覽器分別確認代理策略。
• ✅ 需要本地網路存取時，只放行必要的區域網路流量。
• ❌ 不在同一裝置同時啟用兩個會接管路由的客戶端。
• ❌ 不把「允許區域網路」理解成「所有流量都仍受 VPN 保護」。

常見問題