VPN 並不是按下連線按鈕後，就能自動遮蔽所有網路資訊。它主要負責把符合規則的流量導向加密通道，但 DNS 查詢、瀏覽器即時通訊介面、系統代理設定、應用程式分流和作業系統網路服務，仍可能在通道之外運作。只要其中一個環節沒有被正確接管，網站或第三方服務就可能從 DNS 或 WebRTC 等資訊推測使用者的網路環境。

DNS 洩漏和 WebRTC 洩漏並不代表 VPN 一定不安全，也不等於所有公開的 IP 位址都能直接識別個人。它們代表的是：原本希望透過 VPN 處理的部分資訊，仍可能由本地網路、電信商、瀏覽器或其他網路服務取得。本文會分別說明兩種洩漏的原理、常見誤判、實際檢查順序，以及 Windows、macOS、Android、iOS 和 Linux 使用者可以採取的防護方式。

VPN 安全嗎：先理解它能保護什麼

VPN 的安全性不能只用「安全」或「不安全」二選一來判斷。建立連線後，裝置與 VPN 節點之間的資料通常會透過特定協定封裝和加密，讓本地網路較難直接看到通道內的內容。常見協定包括 WireGuard、OpenVPN、IKEv2、Shadowsocks、VMess、Trojan 和 Hysteria2，但實際支援項目取決於服務商與用戶端。不同協定在傳輸方式、平台相容性、分流能力和故障表現上都有差異。

不過，加密通道只涵蓋實際進入通道的流量。如果瀏覽器或作業系統把 DNS 請求送往本地路由器，這些查詢就可能沒有經過 VPN；如果瀏覽器的 WebRTC 功能取得了本地介面或候選連線位址，網頁也可能看到與一般 HTTP 請求不同的網路資訊。換句話說，VPN 的保護範圍受到「哪些流量被接管」影響，而不是隻由用戶端畫面上的連線狀態決定。

2

本文重點洩漏類型

7

常見連線協定

5

涵蓋主要平台

判斷安全性時，建議把問題拆成四層：第一層是 VPN 是否成功建立；第二層是系統代理或 TUN 模式是否接管了目標應用程式；第三層是 DNS 是否按照預期解析；第四層是瀏覽器是否透過 WebRTC 暴露額外位址。只有逐層檢查，才能知道問題是在 VPN 本身、用戶端設定，還是瀏覽器功能。

DNS 洩漏是什麼，為什麼會發生

DNS 的作用是把網域名稱轉換成 IP 位址。當使用者在瀏覽器輸入網域名稱時，裝置通常要先提出 DNS 查詢，才能知道應該連線到哪一個伺服器。若查詢由本地路由器、電信商 DNS 或作業系統預設 DNS 處理，即使後續網頁流量經過 VPN，查詢紀錄仍可能留在本地網路一側，這就是常說的 DNS 洩漏。

DNS 洩漏最常見於以下情況：用戶端只設定了系統代理，卻沒有接管系統 DNS；啟用規則分流後，DNS 模組仍使用原本的解析器；作業系統在 VPN 連線建立後保留了舊的 DNS 路由；IPv4 查詢走進 VPN，但 IPv6 查詢仍直接離開；或者瀏覽器、應用程式自行啟用加密 DNS，繞過用戶端的 DNS 設定。

DNS 洩漏檢查頁面通常會列出多個解析伺服器的網域、位址或註冊地區。看到本地電信商或家用路由器相關結果，並不一定代表每一筆資料都已暴露，也可能是分流規則刻意讓特定網域直連。重點是把檢查結果與自己的預期比較：如果目標是讓所有外部網域查詢交給 VPN 端處理，結果中就不應持續出現未預期的本地解析來源。

檢查 DNS 前先固定條件

檢查前先關閉瀏覽器其他分頁、暫停系統更新和大型同步工作，並記錄目前是否開啟 VPN、TUN 模式、瀏覽器加密 DNS 以及 IPv6。接著使用同一個瀏覽器，分別在未連線與已連線狀態下執行檢查。不要只看一次結果就下結論，因為解析器可能依照時間、網路環境和快取狀態回傳不同內容。

若要確認出口與 DNS，可使用本站的 IP 檢測頁面查看連線後的公開資訊。檢查時應同時注意公網 IP、DNS 伺服器、IPv4 與 IPv6 結果，以及瀏覽器是否有快取舊資料。不要把「IP 地區符合預期」直接當成「DNS 沒有洩漏」；這是兩個不同的檢查項目。

判斷結論：出口 IP 正常，只能證明部分流量可能已經換了出口；DNS 是否洩漏，仍要另外檢查解析伺服器來源。

WebRTC 洩漏如何暴露額外網路資訊

WebRTC 是瀏覽器支援的一組即時通訊技術，常用於語音、視訊、檔案傳輸和瀏覽器內的點對點連線。為了建立連線，瀏覽器會收集不同類型的候選位址，並嘗試判斷哪一條網路路徑適合通訊。這個過程可能涉及本地網路介面、路由器映射出的位址、VPN 虛擬介面和遠端反射伺服器。

過去部分瀏覽器和測試頁面可以透過 WebRTC 取得本地或候選網路位址，因此即使一般網頁請求已經使用代理，WebRTC 仍可能顯示額外資訊。現代瀏覽器已逐步加入限制、權限提示和位址遮蔽機制，但實際行為仍會受到瀏覽器版本、作業系統、隱私設定、擴充功能與網站程式碼影響，不能假設所有裝置都採用相同規則。

WebRTC 洩漏和 DNS 洩漏的差異在於，前者主要與瀏覽器的即時通訊 API 和網路介面候選有關，後者則是網域名稱解析路徑沒有按照預期通過 VPN。關閉瀏覽器的 WebRTC 功能，通常不能修復 DNS 洩漏；修改 DNS 伺服器，也不會自動阻止 WebRTC 收集候選位址。因此，兩者必須分別驗證。

檢查項目 主要涉及環節 常見異常表現 優先處理方向
DNS 洩漏 作業系統、路由器、用戶端 DNS 模組 結果出現未預期的本地解析器 檢查 DNS 路由、分流與 IPv6
WebRTC 洩漏 瀏覽器即時通訊 API、網路介面 測試頁面顯示額外本地或候選位址 調整瀏覽器權限與 WebRTC 設定
代理繞過 應用程式代理、TUN、規則模式 某個應用程式仍使用原本網路 確認應用程式是否被規則接管
IPv6 洩漏 系統 IPv6 路由與用戶端支援 IPv4 已切換，IPv6 仍顯示本地出口 確認 IPv6 是否被接管或暫時停用

動手檢查：從連線到 DNS 與 WebRTC

以下步驟適合在 Windows、macOS、Android、iOS 或 Linux 上作為通用排查框架。不同用戶端的按鈕名稱可能不同，Clash Verge、sing-box、Shadowrocket 和各平台官方用戶端也可能使用不同的模式。不要為了追求「全域」而一次更改所有選項，應該每完成一個步驟就重新測試，這樣比較容易找到真正造成差異的設定。

  1. 先關閉 VPN 和其他代理程式，使用同一個瀏覽器記錄未連線時的公開 IP、DNS 結果和 IPv4、IPv6 狀態。
  2. 只開啟一個 VPN 用戶端，匯入訂閱或設定檔，選擇一個線路並建立連線。不要同時啟動兩個代理用戶端，避免系統路由互相覆蓋。
  3. 確認用戶端顯示已連線，再查看系統代理、TUN 模式和分流模式。目前使用規則模式時，要確認檢查頁面的網域沒有被規則判定為直連。
  4. 重新開啟 IP 與 DNS 檢查頁面，清除瀏覽器快取後再次檢查。若結果仍顯示本地 DNS，先記錄結果，不要立即修改多項系統設定。
  5. 在瀏覽器的隱私或網站權限設定中，檢查 WebRTC、區域網路存取和即時通訊相關選項。若使用擴充功能，確認其是否真的適用於目前的瀏覽器版本。
  6. 切換一次全域模式或完整 TUN 接管，再重複 DNS 與 WebRTC 檢查。若全域模式正常、規則模式異常，問題多半在分流或 DNS 規則，而不是節點本身。
  7. 最後重新連線一次，檢查裝置從睡眠或更換網路後是否仍維持相同的防護狀態。

測試結果最好以「未連線正常」「連線後 DNS 仍為本地」「WebRTC 顯示額外候選位址」「只有某個瀏覽器異常」等可複核文字記錄。不要只截取 VPN 用戶端的連線畫面，因為那隻能證明通道建立，不能證明每一種流量都已經使用通道。

  • ✅ 檢查時固定同一台裝置、同一個瀏覽器和同一個網路環境
  • ✅ DNS 與 WebRTC 分開測試，不把一項結果當成另一項結論
  • ✅ 規則模式異常時，先查看 DNS 和分流規則，再考慮更換節點
  • ❌ 不要同時啟動兩個 VPN 或代理用戶端
  • ❌ 不要把單次檢查結果當成永久保證，換網路或更新瀏覽器後應重新確認

各平台的修復與防護方向

Windows、macOS 與 Linux

桌面系統通常提供較完整的系統代理、DNS 和 IPv6 選項，但也因此容易出現多個網路介面同時存在的情況。官方用戶端若支援完整流量接管，優先使用其明確標示的 TUN 或系統級模式；Clash Verge 和 sing-box 使用者則要分清系統代理與 TUN 的差異。系統代理主要讓支援代理的應用程式改用指定入口，TUN 則會建立虛擬網路介面，通常能接管更多不支援傳統代理的流量。

在 Windows 上，檢查乙太網路、Wi-Fi、虛擬介面和 IPv6 的 DNS 設定，特別留意 VPN 斷線後是否恢復原本設定。在 macOS 上，網路服務順序、私人轉送功能和瀏覽器自己的加密 DNS 可能同時影響結果。在 Linux 上，NetworkManager、systemd-resolved、resolv.conf、容器網路和桌面代理設定可能分別管理 DNS，單純修改其中一個檔案不一定有效。

如果使用 WireGuard、OpenVPN 或其他以路由為基礎的方案，應確認 DNS 位址與路由規則確實被套用。如果使用 Shadowsocks、VMess、Trojan 或 Hysteria2 等代理型協定，則要額外確認用戶端是否只設定了瀏覽器代理，還是已透過 TUN 或透明代理接管系統流量。協定名稱本身不能代表 DNS 或 WebRTC 一定不會洩漏。

Android 與 iOS

手機系統常會在切換 Wi-Fi、行動數據和省電狀態後重新建立網路路由。Android 使用者可查看 VPN 設定中的「一律使用 VPN」或類似選項，並留意「封鎖未使用 VPN 的連線」是否會影響斷線時的網路行為。不同品牌的省電管理也可能停止背景用戶端，導致裝置看似已安裝 VPN，實際上卻在背景中斷線。

iOS 對系統級 VPN 的管理較集中，但瀏覽器、私人轉送、應用程式專用網路功能仍可能影響檢查結果。Shadowrocket 等相容用戶端通常會提供全域、規則和代理模式，使用者應確認目前模式、DNS 解析方式以及是否允許某些網域直連。手機連線恢復後，建議重新打開檢查頁面，而不是隻依賴狀態列上的 VPN 圖示。

瀏覽器與應用程式設定

瀏覽器的加密 DNS 可提升解析傳輸的隱私，但它可能繞過用戶端預期使用的 DNS 模組。當你正在排查 DNS 洩漏時，可以暫時記錄並調整瀏覽器的安全 DNS 選項，再比較不同設定的結果。這不是要求所有人永久關閉加密 DNS，而是先確認到底由哪一層負責解析。

WebRTC 方面，應檢查瀏覽器的網站權限、區域網路存取和擴充功能。若工作、會議或教育平台需要 WebRTC，不宜直接全面停用而不測試功能；更合理的做法是限制不必要的網站權限，並確認視訊通話、麥克風和螢幕分享仍能正常工作。對於不需要即時通訊的瀏覽器配置，則可採取較嚴格的 WebRTC 位址保護策略。

修復原則：先找出是哪一層繞過了 VPN，再針對 DNS、IPv6、WebRTC 或分流規則處理；不要只是不斷更換節點。

公共網絡、付款與帳戶使用建議

在公共 Wi-Fi、旅館、機場或共享辦公室使用網路時，VPN 可以降低本地網路直接觀察部分連線內容的機會，但它不是釣魚網站、惡意程式和帳戶盜用的全面防護。連線前應確認網域名稱、使用 HTTPS、避免安裝不明憑證，也不要因為看到 VPN 已連線就忽略瀏覽器的安全警告。

付款和帳戶登入時，建議使用獨立且受信任的裝置，啟用多因素驗證，並避免在公共裝置儲存密碼、訂閱連結或付款資訊。若付款頁面因出口地區、風控或 DNS 位置出現異常，不要反覆重新整理或同時切換多條線路；先確認帳戶資料、網站網域與用戶端連線狀態，再依照服務商規則處理。VPN 能改變網路出口，但不能替使用者驗證網站是否真實。

共享裝置或家庭多裝置使用時，也要注意訂閱連結本身可能包含識別資訊。不要把訂閱連結放在公開文件、聊天羣組或截圖中。若懷疑連結外洩，應從服務面板重新產生或聯絡支援管道。用戶端不限裝置台數的條件，也不代表可以忽略帳戶密碼、瀏覽器工作階段和本機權限管理。

  • ✅ 公共網絡連線後重新檢查 IP、DNS 與 WebRTC 狀態
  • ✅ 付款和登入時確認網站網域與瀏覽器 HTTPS 狀態
  • ✅ 為帳戶啟用多因素驗證，並避免在共用裝置保存登入工作階段
  • ✅ 將訂閱連結視為敏感設定，避免公開分享
  • ❌ 不要把 VPN 當成防毒軟體、密碼管理器或釣魚網站攔截器

常見問題

IP 顯示正常，但 DNS 仍然洩漏，代表 VPN 失效嗎？

不一定。這通常表示一般網頁流量的出口已經改變，但 DNS 查詢仍由另一個解析器處理。先確認用戶端的 DNS 模式、分流規則、IPv6 狀態和瀏覽器加密 DNS，再重新檢查。若只有規則模式異常，可以比較全域模式或 TUN 模式的結果，以定位是否為分流問題。

WebRTC 顯示本地位址是否一定很危險？

不一定。WebRTC 顯示的候選位址可能是區域網路介面、虛擬介面或經過瀏覽器處理的遮蔽位址，實際意義要看測試頁面列出的類型和內容。若位址與預期的本地網路或 VPN 虛擬介面一致，風險判斷與直接顯示未經處理的外部出口不同。重點是確認瀏覽器是否暴露了不希望公開的網路資訊。

更換 WireGuard、VMess 或其他協定，就能修復洩漏嗎？

通常不能直接這樣推論。協定主要決定資料如何建立和傳輸通道，DNS 洩漏可能來自作業系統路由、用戶端 DNS 模組或分流規則，WebRTC 洩漏則主要與瀏覽器功能有關。更換協定有時會改變用戶端的接管方式，但真正的修復仍應回到 DNS、TUN、IPv6、代理和瀏覽器設定逐項確認。

多久需要重新檢查一次？

沒有適用所有人的固定週期。更新瀏覽器、作業系統或 VPN 用戶端，切換 Wi-Fi 與行動數據，修改分流規則，或在新的裝置上匯入訂閱後，都值得重新檢查。日常使用中若沒有變更設定，可以把檢查當成故障排查工具；一旦發現出口地區、DNS 結果或瀏覽器行為與過去不同，就應立即重新驗證。

總結來說，VPN 安全性取決於通道、路由、DNS、瀏覽器和帳戶習慣是否互相配合。先確認哪些流量被接管，再分別檢查 DNS 與 WebRTC，最後處理 IPv6、分流和瀏覽器權限，通常比盲目更換節點更有效。建立這套檢查順序後，即使換用不同平台或相容用戶端，也能較快判斷問題到底出在哪一層。