您已連線到 VPN。鎖定圖示亮起。你感覺很私密。

但是您的 VPN 很有可能正在洩漏——在您認為一切都受到保護的情況下，悄悄地將未加密的資料傳送到隧道外。 DNS 洩漏、WebRTC 洩漏和 IPv6 洩漏在免費和付費 VPN 中都很常見，而且大多數使用者從不檢查它們。

本指南將向您準確展示每種洩漏型別是什麼、技術上為什麼會發生、如何在五分鐘內測試它，以及如何在任何作業系統或瀏覽器上修復它。

---

為什麼會發生洩漏

VPN 的工作原理是透過加密隧道將所有網路流量路由到遠端伺服器。關鍵詞是 全部。如果您的流量的任何部分逃離該隧道並直接進入網際網路，您的真實 IP 和身份就會暴露——無論 VPN 對其他所有內容的加密程度如何。

洩漏的發生是因為現代作業系統和瀏覽器做出的架構決策將速度和相容性置於隱私之上。 VPN 經常與這些預設行為作鬥爭。

洩漏主要分為三種型別：

  • DNS 洩漏 — 您的 DNS 查詢（域查詢）離開 VPN 隧道併到達您的 ISP
  • WebRTC 洩露 — 您的瀏覽器透過點對點通訊 API 公開您的真實 IP
  • IPv6 洩漏 — 您的 IPv6 流量完全繞過 VPN，因為許多 VPN 只處理 IPv4

讓我們逐一逐一討論。

---

DNS 洩漏：最常見的問題

發生了什麼事

每次您訪問網站時，您的裝置都會傳送 DNS 查詢 - 本質上是詢問“該域名的 IP 地址是什麼？”在 VPN 的正常操作下，這些查詢應透過 VPN 隧道到達 VPN 提供商的 DNS 伺服器。當出現 DNS 洩漏時，它們會轉至 ISP 的 DNS 伺服器。

實際結果：即使您的實際瀏覽流量已加密，您的 ISP 也會看到您訪問的每個域。您的 VPN 正在加密您的連線內容，而您的 ISP 則維護您正在訪問的網站的完整列表。

為什麼會發生 DNS 洩漏

Windows 智慧多宿主名稱解析 (SMHNR) 是最常見的罪魁禍首。它在 Windows 8 中引入，並在 Windows 11 中仍然有效，旨在透過同時向所有可用的 DNS 伺服器傳送查詢並接受最先響應的伺服器來加速 DNS。在 VPN 上，這意味著查詢會同時傳送到 VPN 的 DNS 伺服器和 ISP 的伺服器，並且您的 ISP 幾乎總是響應速度更快。

特雷多 是另一個 Windows 問題 — 一種 IPv6 轉換協議，可以完全繞過 VPN 隧道路由流量。如果啟用，它可能優先於您的 VPN。

IPv6 不相容 會導致 DNS 洩漏。

VPN 客戶端配置錯誤 根本無法透過隧道重定向 DNS 流量。這在較舊或質量較低的 VPN 軟體中更為常見。

如何測試

  1. 連線到您的 VPN
  2. 參觀 dnsleaktest.com 點選“擴充套件測試”
  3. 檢視結果 — 您將看到收到您的查詢的 DNS 伺服器列表

你想看的： 屬於您的 VPN 提供商的 DNS 伺服器（或受信任的公共解析器，如 Cloudflare 1.1.1.1 或 Quad9 9.9.9.9）。

有什麼問題： 您的 ISP 名稱出現在 DNS 伺服器列表中。即使結果中只有一臺 ISP DNS 伺服器，也意味著您的查詢正在洩漏。

您還可以在以下位置進行全面檢查： ipleak.net，在單個頁面上測試 DNS、IP 和 WebRTC。

如何修復 DNS 洩漏

在您的 VPN 應用程式中： 查詢名為“DNS 洩漏保護”、“防止 DNS 洩漏”或“使用 VPN DNS”的設定。啟用它。這告訴 VPN 客戶端強制所有 DNS 查詢透過隧道。

手動設定您的 DNS 伺服器 到受信任的公共解析器：

  • Cloudflare： 1.1.1.1 / 1.0.0.1
  • Quad9： 9.9.9.9 / 149.112.112.112

這本身並不能防止洩漏，但可以確保如果查詢確實逃出了隧道，它至少不會到達您的 ISP 的伺服器。

在 Windows 上禁用 SMHNR（專業版/企業版）：

  1. 按 Win+R，輸入 gpedit.msc
  2. 導航至：計算機配置 → 管理模板 → 網路 → DNS 客戶端
  3. 找到“關閉智慧多宿主名稱解析”→設定為 已啟用
  4. 重新啟動Windows

在 Windows 上禁用 Teredo： 以管理員身份開啟命令提示符並執行：

命令 
netsh interface teredo set state disabled

進行更改後，在 dnsleaktest.com 重新測試以確認修復有效。

---

WebRTC 洩露：瀏覽器問題

發生了什麼事

WebRTC（網路實時通訊）是一種瀏覽器標準，可實現視訊通話、語音聊天和檔案共享等點對點功能。要在兩個瀏覽器之間建立直接連線，WebRTC 需要使用 STUN（NAT 會話遍歷實用程式）伺服器發現兩個裝置的真實 IP 地址。

問題在於：這些 STUN 請求在瀏覽器級別繞過您的 VPN 隧道。在任何網頁上執行的 JavaScript 都可以默默地觸發 WebRTC IP 發現請求，讀取結果，並將您的真實 IP 傳送到伺服器 - 同時您的 VPN 的鎖定圖示坐在那裡，看起來令人放心。

這會不同程度地影響 Chrome、Firefox、Edge、Opera 和 Brave。這是瀏覽器架構問題，而不是 VPN 故障。

如何測試

  1. 連線到您的 VPN
  2. 參觀 browserleaks.com 然後點選“WebRTC”
  3. 檢視“您的 IP 地址”下列出的 IP 地址

你想看的： 僅您的 VPN 伺服器的 IP 地址。

有什麼問題： 您的真實 ISP 分配的 IP 出現在結果中的任何位置，特別是在“公共 IP 地址”下。

您還可以檢視 ipleak.net — 它內建了 WebRTC 部分。

如何修復 WebRTC 洩漏（逐個瀏覽器）

火狐 — 最佳原生控制元件：

  1. 型別 about:config ，然後按 Enter
  2. 接受警告並尋找 media.peerconnection.enabled
  3. 雙擊切換至 false
  4. 對於額外硬化：也設定 media.peerconnection.ice.default_address_only 至 true

勇敢 — 具有內建 WebRTC 控制元件：

  1. 設定 → 隱私和安全 → WebRTC IP 處理策略
  2. 選擇 “禁用非代理 UDP”
  3. 重啟勇敢

鉻 — 無本機設定（主要限制）：

  • 安裝 《WebRTC 控制》 延長線
  • 該擴充套件新增了一個開關以禁用每個會話的 WebRTC

邊緣：

  1. 型別 about:flags 在位址列中輸入
  2. 搜尋“WebRTC”
  3. 啟用“匿名化 WebRTC 公開的本地 IP”
  4. 重新啟動 Edge

Tor 瀏覽器： WebRTC 預設情況下完全禁用。無需採取任何行動。

注意： 禁用 WebRTC 將中斷 Google Meet、Zoom（瀏覽器版）和瀏覽器中的 Discord 等視訊通話服務。如果您需要這些服務，請在使用時重新啟用 WebRTC，然後再將其禁用。

---

IPv6 洩露：協議不匹配

發生了什麼事

現代網際網路連線是雙棧的，這意味著它們同時支援 IPv4 和 IPv6。 IPv4 幾十年來一直是標準。 IPv6 是旨在取代它的較新協議，具有更大的地址空間。

大多數 VPN 都是在 IPv4 占主導地位時構建的。他們為 IPv4 流量建立加密隧道，但不對 IPv6 流量進行處理。如果您的連線分配了 IPv6 地址（大多數家庭和蜂窩連線上都可能這樣做），則該流量將完全在 VPN 隧道之外傳輸。任何具有 IPv6 地址的網站都會收到您的真實 IPv6 地址，而不是您的 VPN 地址。

IPv6 地址通常比 IPv4 地址更持久、更具體，使得這種洩漏可能比標準 IPv4 洩漏更容易識別。

如何測試

  1. 連線到您的 VPN
  2. 參觀 ipleak.net 並向下滾動到 IPv6 部分

你想看的： 未檢測到 IPv6 地址，或者 IPv6 地址屬於您的 VPN 提供商。

有什麼問題： 顯示您的真實 IPv6 地址 — 特別是當它與您的 ISP 分配的字首匹配時。

您可以透過斷開 VPN 並訪問 ipleak.net 進行比較來單獨驗證您的真實 IPv6 地址。

如何修復 IPv6 洩漏

選項 1：使用完全支援 IPv6 的 VPN。 Mulvad 透過 VPN 隧道路由 IPv6 流量。 NordVPN 預設阻止 IPv6 以防止洩露。如果您的 VPN 支援，這是最乾淨的解決方案。

選項 2：在作業系統級別禁用 IPv6 （最簡單的通用修復）：

窗戶：

  1. 設定 → 網路和 Internet → 高階網路設定
  2. 右鍵單擊您的活動網路介面卡 → 屬性
  3. 取消選中“Internet 協議版本 6 (TCP/IPv6)”
  4. 點選確定

或透過 PowerShell（適用於所有介面卡）：

命令 
Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6

macOS：

命令 
sudo networksetup -setv6off Wi-Fi
sudo networksetup -setv6off Ethernet

Linux： 將這些行新增到 /etc/sysctl.conf:

命令 
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

然後申請：

命令 
sudo sysctl -p

禁用 IPv6 後，在 ipleak.net 上重新測試。 IPv6 部分應顯示“未檢測到 IPv6 地址”。

---

死亡開關：你的最後一道防線

如果 VPN 連線意外斷開，終止開關會阻止所有網際網路流量。如果沒有，VPN 的短暫中斷（在重新連線、網路切換或睡眠/喚醒週期期間）會短暫暴露您的真實 IP 和 DNS 流量。

每個正規的VPN都有這個功能。根據提供商的不同，它可能被稱為“Kill Switch”、“網路鎖”、“永遠線上 VPN”或“Internet Kill Switch”。

啟用它。 如果您滿足以下條件，這一點尤其重要：

  • 頻繁切換網路（家庭→熱點→辦公室）
  • 讓您的 VPN 在睡眠/休眠狀態下保持執行
  • 使用 VPN 進行即使是短暫暴露也很重要的活動

測試一下： 連線到您的 VPN，啟用終止開關，然後斷開您的 VPN，而無需先禁用終止開關。嘗試載入網頁。在您重新連線 VPN 之前，它應該無法載入。如果頁面載入的是您的真實 IP，則終止開關不起作用。

---

完整測試清單

在初始 VPN 設定後、作業系統更新後以及 VPN 應用程式更新後執行此序列：

  1. 連線VPN，等待10秒連線穩定
  2. 參觀 ipleak.net — 確認 IP、DNS 伺服器和 WebRTC 均顯示 VPN 資料
  3. 參觀 dnsleaktest.com — 執行擴充套件測試，確認所有 DNS 伺服器屬於 VPN 提供商
  4. 參觀 browserleaks.com/webrtc — 確認 WebRTC 結果中沒有真實 IP
  5. 檢查 ipleak.net 上的 IPv6 部分 — 確認沒有真正的 IPv6 地址
  6. 斷開 VPN 連線（啟用終止開關）- 確認頁面不會載入
  7. 重新連線 VPN — 確認一切都返回 VPN 資料

如果任何測試顯示您的真實 IP 或 ISP 資料，請在考慮您的設定安全之前解決該洩漏問題。

---

哪些 VPN 能夠最好地處理洩漏

穆爾瓦德： 預設情況下啟用 DNS 洩漏保護、內建 WebRTC 阻止、透過隧道的完整 IPv6 路由。所有主流 VPN 中最注重隱私保護的預設設定。

NordVPN： 預設開啟 DNS 保護，自動阻止 WebRTC，預設阻止 IPv6 以防止洩露。 “網路鎖”終止開關可用。

質子 VPN： 保護紮實，但有些設定需要手動驗證。 DNS 洩漏保護和終止開關需要在某些平臺上顯式啟用。鑑於他們的隱私記錄，值得額外的設定時間。

ExpressVPN： 自動禁用 IPv6 以防止洩漏，透過 VPN 處理 DNS。非常使用者友好，需要更少的手動配置步驟。

如果作業系統級別設定干擾，所有這些仍然可能洩漏。無論您使用哪種 VPN，都請按照上述步驟測試您的設定。

---

洩露的內容實際上讓你接觸到了什麼

DNS 洩漏在特定情況下最為重要：如果您的 ISP 記錄並出售 DNS 資料，如果您位於有監控程式的司法管轄區，如果您位於受監控的網路（工作、學校、公共 WiFi）上，或者如果您正在訪問 ISP 根據目的地限制的內容。

對於在尊重隱私的司法管轄區進行日常瀏覽的大多數使用者來說，DNS 洩漏是一種隱私侵犯行為，但不會構成直接的安全風險。對於記者、活動人士或敵對網路上的任何人來說，DNS 洩漏可能會暴露真正危險的訪問模式。

無論您的威脅模型如何，修復漏洞都不需要任何成本，只需十分鐘。沒有理由不這樣做。

---

使用以下命令檢查您當前的 IP、DNS 和網路詳細資訊 IP 查詢工具 — 在測試 VPN 設定之前可用作基準。