如果即使在打开 VPN 后仍看到以下任何症状，请怀疑 DNS 泄漏或 WebRTC 泄漏。泄漏是指应通过 VPN 路径的信息离开该路径（也称为渗漏）。
- IP验证页面显示VPN服务器IP，但DNS测试显示电信公司或路由器的DNS服务器。
- IPv4 地址已更改，但 IPv6 地址与关闭 VPN 之前相同。
- 在WebRTC测试页面上，公共IP显示为关闭VPN之前的状态。
- 原始IP只有在从Wi-Fi切换到移动数据或从睡眠模式唤醒后立即可见。
- 我为 Chrome 打开了 StageVPN，但其他浏览器和 PC 程序使用原始 IP 连接。
- 即使打开了 VPN，该网站也会根据原始区域显示语言和内容（这可能是由于帐户/cookie 设置所致）。
DNS 泄漏是指在 VPN 开启时，Web 通信经过隧道，但只有 DNS 查询走出隧道，域名对电信公司或 Wi-Fi 的 DNS 服务器可见的现象。 WebRTC 泄漏是指浏览器的 WebRTC 直接从 VPN/代理发送 STUN 请求，从而使网页发现实际的公共 IP 的现象。这两种现象都意味着页面内容正在泄漏。然而，它揭示了“谁正在访问哪里”。本文从症状入手，经过诊断、查明原因、复查六个阶段。
诊断：如何通过 6 个步骤检查泄漏
泄漏检查的原理是比较VPN关闭和打开时的值。比较站点上显示的 IP、接收 DNS 查询的服务器以及 WebRTC 候选地址。如果即使打开VPN后仍可以看到原始值，则表明存在泄漏。测试仅在您实际使用的设备和浏览器上才有意义。即使您没有特定的测试站点，您也可以仅使用浏览器检查大多数内容。 IP验证页面是在屏幕上显示连接者的公共IP地址的网页。您可以在搜索引擎中通过“检查 IP”找到它。用同样的方法找到DNS泄漏测试页面和WebRTC测试页面。无论您使用哪个页面，原理都是相同的，因此您不必依赖特定站点。
- 关闭VPN并记录您的IP。 打开 IP 验证页面并记下公共 IPv4 地址和 IPv6 地址（如果有）。该值是后续所有比较的基础。
- 打开您的 VPN 并比较 IP。 检查 StageVPN 应用程序上的连接完成指示灯或 StageVPN for Chrome 图标上的绿色 ON 指示灯后，再次打开同一页面。 IPv4 应替换为您的 VPN 服务器地址。
- 检查您的 DNS 服务器。 打开 DNS 泄漏测试页面。这些页面查询随机子域，然后显示发送查询的 DNS 服务器。如果您可以看到运营商或路由器的服务器，则表明存在 DNS 泄漏。
- 打开 chrome://webrtc-internals。 在 Chrome 地址栏中输入此地址将显示正在进行的 WebRTC 连接和候选地址。如果您在另一个选项卡中打开 WebRTC 测试页面或视频通话页面，则会出现该项目。
- 检查候选IP。 如果 srflx（服务器反射）候选者的地址与步骤 1 中的原始公共 IP 相同，则这是 WebRTC 泄漏。如果是 VPN 服务器 IP 或仅可见 .local 名称和私有 IP，则不会公开公共 IP。
- 检查 IPv6。 如果您在步骤 1 中拥有 IPv6 地址，请打开 VPN 并查看该地址是否已消失或更改。如果是这种情况，则 IPv6 将离开隧道。切换Wi-Fi和移动数据，重启浏览器后重复查看结果是否相同。
| 观察结果 | 意义 | 下一个原因 |
|---|---|---|
| VPN 服务器 IP 现场可见 | Web 通信通过 VPN 路径 | 正常，下一步 |
| IPv4变了，但IPv6还是原来的地址 | IPv6离开隧道 | 原因2 |
| DNS服务器来自电信公司或路由器。 | DNS 泄漏 | 原因 1、3、4、5 |
| DNS 服务器是公共 DNS 提供商 | VPN 配置中的 DNS 或您自己指定的安全 DNS。 | 不要仅根据公司名称就认为是泄漏，检查原因 4 |
| 原始公网IP在WebRTC中可见 | WebRTC 泄露 | 原因 6 和 7 |
| WebRTC 中仅可见 .local 名称或私有 IP | 公网IP不暴露 | 一般正常 |
| 仅在网络切换后立即使用原始IP | 过渡时刻的间隙 | 原因8 |
结果可能因测试地点而异。有的地方只查看IPv4，有的地方查看IPv6，查找DNS服务器的方法也不同。在多个地方进行比较并切换到多个网络。
DNS 查询揭示什么？
DNS 查询包含域名。不包括页面内容或输入的值。 DNS 是互联网的地址簿系统，它将人类读取的域名转换为计算机使用的 IP 地址。每次您在浏览器中输入地址或应用程序联系服务器时，您的设备都会首先询问 DNS 服务器“该名称的地址是什么？”因此，只需查看查询历史记录，您就可以了解有关您尝试访问的时间和服务的大量信息。
- 我的设备应用程序/浏览器
- 纯文本 DNS 查询
- 公共无线网络咖啡厅路由器
- 纯文本 DNS 查询
- 运营商 DNS现有服务器
- 可能暴露的区域
- 我的设备应用程序/浏览器
- 隧道中的 DNS
- 公共无线网络咖啡厅路由器
- 隧道中的 DNS
- VPN服务器StageVPN
- 通过VPN服务器IP查询
- DNS服务器在 VPN 配置中指定
- VPN加密
传统的 DNS 查询会发送至未加密的 UDP 端口 53。为了弥补这一点，创建了将查询包装在 HTTPS 中的 DoH (RFC 8484) 和将查询包装在 TLS 中的 DoT (RFC 7858)。但是，即使您使用加密的 DNS，如果站点和浏览器不支持 ECH（加密客户端 Hello），通过 HTTPS 连接到站点时发送的服务器名称 (SNI) 也可能在网络上可见。
| 交货方式 | 同一 Wi-Fi 下的观察者 | Wi-Fi 运营商/通信公司 | DNS服务器接收查询 |
|---|---|---|---|
| 纯 DNS（明文） | 可以看到 | 可以看到 | 可见，用我的公网IP |
| DoH/DoT（加密 DNS） | 看不到 | 不可见，DNS服务器地址可见 | 可见，用我的公网IP |
| VPN 隧道内的 DNS | 看不到 | 不可见，只看到它正在与VPN服务器通信 | 可见，有VPN服务器IP |
| DNS 泄漏状态 | 如果是纯文本，就可以看到。 | 可以看到 | 可见，用我的公网IP |
安全 DNS (DoH) 和 VPN 具有不同的目的。 DoH 仅加密 DNS 查询；站点访问本身和站点看到的 IP 保持不变。 VPN 会对您的设备或浏览器与 VPN 服务器之间的整个通信进行加密，并更改站点看到的 IP。隐身模式也无法阻止泄密。隐身模式是一种不会在设备上留下历史记录或 cookie、也不会更改 DNS 查询或 WebRTC 路由的功能。
WebRTC 如何确定 IP 地址？
WebRTC通过多种方式找到自己的地址，通过最短路径连接两个设备，并将结果传递给网页上的脚本。 WebRTC 是一种网络标准技术，允许您无需在浏览器中安装插件即可进行视频通话、语音通话和文件传输。收集地址的过程称为 ICE (RFC 8445)。即使不进行视频通话的页面也可以使用脚本启动此过程。
- 创建连接对象网页脚本创建 RTCPeerConnection
- 聚集当地候选人您的浏览器收集您设备的网络设备的地址
- STUN查询使用 UDP 询问 STUN 服务器“我的地址是什么样的”
- 候选人交付包含 STUN 服务器提供的公共地址的候选列表被传送到该页面。
| 候选人类型 | 某物 | 可能泄露的信息 | 保护最新浏览器 |
|---|---|---|---|
| 主持人 | 机器的网络设备地址 | 私有IP（192.168.x等） | 使用随机 .local 名称 (mDNS) 进行屏蔽，但可以在授予摄像头和麦克风权限的网站上看到。 |
| srflx（服务器反射） | STUN 服务器看到的我的公共地址 | 公网IP，如果绕过代理则为真实IP | 可以受WebRTC IP处理策略的限制 |
| 中继 | TURN 中继服务器地址 | 中继服务器IP | 如果你使用中继，对方看到的将是服务器地址而不是你的IP。 |
问题出在步骤 3 中的 STUN 查询。浏览器代理转发 Web 请求，但在浏览器默认设置中，WebRTC 的 UDP 通信不经过代理。所以STUN服务器提供的地址并不是代理服务器，而是我原来的公网IP。设备级 VPN 的情况有所不同。由于所有 UDP 通信（包括 STUN 请求）都会进入隧道，因此 STUN 服务器看到的地址也是 VPN 服务器的 IP。
浏览器代理和默认策略
- Web 请求通过代理
- STUN 请求直接发送至 UDP
- 页面可以看到真实的公网IP
浏览器代理和disable_non_proxied_udp
- 阻止 UDP 通过代理
- WebRTC仅使用代理路径
- 某些通话具有不同的连接方法或质量
设备范围内的 VPN
- STUN 请求也通过隧道。
- 公共地址候选者是 VPN 服务器 IP
- 断开连接和 IPv6 处理需要确认
Chrome 有一个“WebRTC IP 处理策略”，用于确定 WebRTC 将使用哪个地址，并且扩展程序可以更改此值。每个值对应于 IETF 的 WebRTC IP 地址处理建议 (RFC 8828) 中概述的四种方法。
| 政策价值 | 移动 | 曝光范围 |
|---|---|---|
| 默认 | 从所有网络设备收集候选者 | 最宽（被 mDNS 屏蔽的本地地址） |
| 默认公共和私有接口 | 仅使用默认路由上的设备，同时使用公共和私有地址 | 不暴露其他设备的地址 |
| 仅默认公共接口 | 只使用默认路由的公网地址 | 私有地址不暴露 |
| 禁用非代理UDP | 没有通过代理的 UDP，如果代理不支持 UDP，则通过代理使用 TCP | 不要暴露代理外部的路由地址 |
解决方法：如何根据原因进行检查和修复
大多数泄漏都有八个原因之一： 这通常是由重叠设置引起的。首先检查诊断表中指出的原因编号，每修复一个，就重复上图中的步骤6，看看结果是否有变化。如果您一次更改多个设置，您将不知道哪些设置有效。
原因1 · VPN 配置中没有DNS 服务器或设备使用不同的DNS。
查看 打开 VPN 后，DNS 测试会显示 Wi-Fi 路由器或运营商的 DNS 服务器。您设备的 Wi-Fi 设置中通常有手动 DNS。
解决 StageVPN 应用程序在 VPN 配置中包含一个 DNS 服务器，并将查询发送到隧道中。在设备的网络设置中将手动 DNS 恢复为自动，然后断开 VPN 连接并重新连接。如果问题仍然存在，请检查原因 3 和 5。
原因2 IPv6出隧道
查看 IPv4 已更改为 VPN 服务器地址，但 IPv6 仍与步骤 1 中记录的值相同。如果 VPN 仅隧道 IPv4，则 IPv6 查询和通信将走原始路由。
解决 StageVPN 应用程序也配置为向隧道发送 IPv6 通信 (AllowedIPs 0.0.0.0/0, ::/0)，因此通常无需将其关闭。如果 IPv6 仍然按其应有的方式显示，请首先检查其他 VPN 应用程序或设备设置是否正在更改路由。有些测试站点不支持 IPv6，因此请在多个站点进行比较。
原因3 · 操作系统同时查询多个网络设备的DNS。
查看 尤其是在 Windows PC 上进行 VPN 连接期间，DNS 测试会显示 VPN 的 DNS 和运营商的 DNS。这是由同时询问所有网络设备的功能引起的，例如 Windows 的智能多宿主名称解析。
解决 使您的操作系统和 VPN 软件保持最新并重复测试。这种现象主要出现在 PC 上的设备范围 VPN 中，由于结构不同，智能手机上的 StageVPN 应用程序和 Chrome 上的 StageVPN for Chrome 不会以相同的方式出现。
原因 4 · 在浏览器或设备中单独指定安全 DNS (DoH)
查看 DNS 测试显示来自公共 DNS 提供商的服务器。在这种情况下，可能不是泄漏，而是您自己指定的设置。如果您有设备范围的 VPN，则此查询也将通过隧道，但将由指定的提供商而不是 VPN 配置中的 DNS 接收。
解决 如果这是预期的设置，您可以保持原样。如果您想使用 DNS 进行 VPN 配置，它将自动更改您的浏览器和设备上的安全 DNS 设置。重要的是，不要仅通过查看公司名称就认为这是泄漏。
原因5·其他VPN、代理和安全应用程序也打开
查看 其他 VPN 应用程序、代理扩展、广告过滤器或安全程序的网络功能会同时打开。路由设置会相互覆盖，导致某些查询转到原始路由。
解决 一次仅打开一个。关闭其他应用程序和扩展程序，断开并重新连接 StageVPN，然后重复步骤 6。Chrome 的代理设置一次只能控制一个扩展程序，因此如果另一个扩展程序正在使用代理，StageVPN for Chrome 将无法连接，并会告诉您原因。
原因6·仅使用浏览器代理，但期望在浏览器外部进行通信
查看 我为 Chrome 打开了 StageVPN，但其他浏览器、PC Messenger 和邮件程序使用原始 IP 和原始 DNS 进行连接。这不是泄漏，这是设计范围。该扩展仅涵盖 Chrome 中的通信。
解决 如果您需要保护 Chrome 之外的程序，请使用适用于整个设备的 VPN。在智能手机上，StageVPN 应用程序就是这样做的。两种方法之间的范围差异是 浏览器 VPN 与应用程序 VPN我把它组织在 .
原因 7 WebRTC 策略未应用
查看 我打开了 Chrome 的 StageVPN，可以在 WebRTC 测试中或 chrome://webrtc-internals 中的 srflx 候选中看到原始公共 IP。如果另一个扩展程序或公司/组织的管理策略首先控制 WebRTC 设置，StageVPN for Chrome 将不会更改策略并保持原样。
解决 关闭控制 WebRTC 设置的任何其他扩展程序并重新连接 StageVPN for Chrome。如果管理策略是原因，请联系您的管理员。要在隐身窗口中书写，您必须在扩展管理屏幕中打开“允许在隐身模式下”。关闭后，隐身窗口中的通信不会通过代理。
原因8·VPN连接丢失的那一刻
查看 原来的IP只有在切换网络或从睡眠模式唤醒后立即可见，过一会儿就正常了。在断开连接期间，所有查询和通信都通过正常路由进行。
解决 在进行任何敏感工作之前，请检查应用程序的连接完成指示灯或扩展程序图标是否打开。 StageVPN 应用程序使用的 WireGuard 即使从 Wi-Fi 更改为 LTE 也不会重新建立隧道，但该协议无法补偿网络本身的临时断开连接。 VPN 断开连接时自动阻止通信的功能不是 StageVPN 提供的功能。原理是 解释 WireGuard 原理它是在
StageVPN 应用和适用于 Chrome 的 StageVPN 如何阻止泄密？
StageVPN 应用程序通过隧道传输所有通信来减少泄漏，而适用于 Chrome 的 StageVPN 则代理名称查找并调整 WebRTC 策略。由于保护范围不同，处理方式也不同。
| 物品 | StageVPN 应用程序（iPhone·iPad·Android） | 适用于 Chrome 的 StageVPN |
|---|---|---|
| 保护范围 | 所有设备 | Chrome浏览器 |
| 通过 VPN 路由发送的通信 | IPv4·IPv6 全部（允许的 IP 0.0.0.0/0，::/0） | Web 请求通过代理（不包括私有 IP 频段和本地主机） |
| DNS 查询 | 在隧道内转发到 VPN 配置中指定的 DNS 服务器。 | 通过代理的请求不会由 Chrome 查找，而是由代理服务器查找。 |
| 网络RTC | 所有 UDP 通信都通过隧道。 | 在连接期间应用disable_non_proxied_udp，并在断开连接时返回到原始设置。 |
| 您当前在网络上看到的内容 | 与 VPN 服务器的加密通信和数据量的事实 | 代理服务器地址的名称查找、与代理的加密连接以及来自 Chrome 外部应用程序的通信 |
| 可能不适用的情况 | 当 VPN 连接丢失时，当另一个 VPN 应用程序重新路由时 | 当另一个扩展或管理策略控制代理/WebRTC 设置时，隐身窗口中允许隐身模式关闭 |
| 访问历史记录（93天） | 查看的域名不会被记录 | 记录连接的目标主机名，但不记录路径或搜索词。 |
StageVPN 不会引导您完成单独的 DNS 泄漏保护设置菜单作为其产品的一项功能。上述行为取决于应用程序的默认 VPN 配置和扩展程序的连接方法。提供范围为 产品特点和范围您可以在这里查看。
无泄漏意味着查询和通信通过 VPN 路径而不是运营商。这并不意味着不会保留任何记录。 StageVPN 根据通信秘密保护法保留访问记录 93 天，不记录通信内容。该项目是 访问记录存储通知好吧，我透露它的原因是 我们为什么要披露我们的访问记录保留政策？解释道。
重新检查清单：更改后您会重新检查哪些内容？
每次修复一个原因时，请从头开始再次检查以下项目。如果全部通过，则不存在泄漏。如果任何项目失败，则返回到相应的原因卡。
- 断开并重新连接VPN后，我检查应用程序是否显示连接完成或扩展图标是否显示ON。
- 在 IP 验证页面上，您将看到 IPv4 和 IPv6 的 VPN 服务器地址，或者不会看到 IPv6。
- DNS测试不会显示电信公司或路由器的DNS服务器。
- chrome://webrtc-internals 中的 srflx 候选者没有原始公共 IP。
- 其他 VPN 应用程序、代理/VPN 扩展和安全程序的网络功能已关闭。
- 如果您为设备和浏览器设置了手动 DNS 或安全 DNS，则您已验证这是否是预期的设置。
- 您的操作系统、浏览器以及 StageVPN 应用程序和扩展程序都是最新的。
- 即使在 Wi-Fi 和移动数据之间切换并重新启动浏览器后，结果也是相同的。
- 如果您需要保护 Chrome 之外的程序，可以使用设备范围的 VPN 而不是扩展程序。
确定何时需要重新检查也是一个好主意。这是在对操作系统或浏览器进行重大更新之后、安装新的扩展程序或安全应用程序之后、或者在您首次连接的网络上执行任何敏感工作之前。如果设置相同但结果发生了变化，则通常是这三件事之一造成的。一旦掌握了窍门，只需几分钟即可完成 6 个阶段的诊断。
如果问题仍然存在，请整理设备型号、操作系统和应用版本、发生时间和测试结果。 客户支持请联系我们。请不要发送您的密码或验证码。与泄漏检查一起检查的设备设置包括： 10 项智能手机隐私设置嗯，有些风险是仅靠 VPN 无法解决的。 VPN 能阻止什么和不能阻止什么那么，您在公共网络上的习惯是 公共Wi-Fi安全规则我把它组织在 .
参考资料
- RFC 1034：域名 — 概念和设施 — DNS 结构和解析器的作用 (IETF)
- RFC 8484：通过 HTTPS 的 DNS 查询 (DoH) — 如何通过 HTTPS 加密 DNS 查询 (IETF)
- RFC 7858：基于 TLS 的 DNS — 如何使用 TLS 加密 DNS 查询 (IETF)
- RFC 8445：交互式连接建立 (ICE) — WebRTC连接候选类型和收集程序（IETF）
- RFC 8828：WebRTC IP 地址处理要求 — 浏览器向 WebRTC (IETF) 公开的地址范围
- chrome.隐私 API — Chrome WebRTC IP 处理策略值（Chrome for Developers）
- chrome.proxy API — 扩展代理设置、绕过列表和控制优先级（Chrome for Developers）
- WebRTC API — RTCPeerConnection 和 ICE 候选者的概念（MDN Web 文档）
