DNS、WebRTC 和 TLS 泄露：最常见的错误
当您连接到 VPN 或使用代理时，通常认为您的真实 IP 地址和在线活动会保持隐藏。但在实践中，情况并非总是如此。存在所谓的泄漏——导致部分数据在安全通道之外传输的技术机制。
DNS、WebRTC 和 TLS 泄漏是指由于网络或浏览器设置导致技术数据暴露的情况：例如，DNS 服务器、真实 IP 或连接参数。此类泄漏不会泄露您的浏览历史记录，但它们可能会暴露 IP 地址、DNS 服务器和其他连接参数之间的不匹配，这可能会触发反欺诈系统。
在本文中，我们将探讨 DNS、WebRTC 和 TLS 泄漏是如何发生的，如何检测它们，以及哪些措施可以帮助降低风险。
DNS、WebRTC 和 TLS 泄漏到底是什么？
DNS、WebRTC 和 TLS 在网络交互的不同层面上运行。因此，每种情况下的数据暴露机制各不相同。在一种情况下，请求绕过了安全通道；在另一种情况下，浏览器直接传输网络信息；在第三种情况下，加密连接的参数被分析。
让我们分别剖析每种类型，以了解其中的风险以及保护自己的方法。
DNS 泄漏
DNS（域名系统）是一个将熟悉的网站名称转换为 IP 地址的系统。当您在浏览器中输入地址时，您的设备首先会发送一个 DNS 请求以找出要连接的 IP，然后才会建立与该网站的连接。
使用 VPN 时，通常认为所有请求都会通过加密隧道，并由 VPN 提供商自己的 DNS 服务器处理。然而，在某些情况下，系统会继续将 DNS 请求直接发送到 ISP（互联网服务提供商）的服务器。这就是所谓的 DNS 泄漏。
在这种情况下，即使主要流量通过 VPN，ISP 也能看到设备正在请求哪些域名。同时，页面内容和传输的数据仍然是加密的。网站本身和反机器人系统无法访问用户的 DNS 请求。它们只能间接检测到问题——例如，如果 DNS 服务器属于一个国家或提供商，而公共 IP 地址属于另一个网络。
原因可能多种多样：网络配置不正确、VPN 缺乏内置的 DNS 泄漏保护、协议冲突或操作系统的特定功能。
WebRTC 泄漏
WebRTC（Web 实时通信）是现代浏览器内置的一项技术，允许在用户之间建立直接连接。它用于视频通话、语音通信、在线会议以及直接在浏览器窗口中进行数据传输，而无需安装额外的软件。
为了使连接正常工作，WebRTC 会请求设备的网络信息，包括其本地和外部 IP 地址。在某些情况下，WebRTC 可以直接传输网络信息，绕过 VPN 隧道。即使网站流量通过 VPN 或代理，浏览器也可以通过特殊的数据交换机制（例如，ICE 候选者——设备为直接连接提供的可能网络地址和路由列表）传输真实 IP 地址。
结果，启用了 WebRTC 的网页能够确定用户的真实 IP。同时，VPN 本身继续工作，但一些网络信息被直接暴露。这正是为什么 WebRTC 泄漏被认为是使用 VPN 或代理时降低匿名级别的最常见问题之一。
TLS 指纹：它是什么以及为什么会暴露您
TLS（传输层安全性）是一种加密浏览器和网站之间数据的协议。多亏了它，连接显示为 HTTPS，并且页面内容受到保护，免遭拦截。但 TLS 有一个很少有人考虑到的副作用——TLS 指纹。
当浏览器通过 HTTPS 连接到网站时，它做的第一件事就是向服务器发送一条 ClientHello 消息——一种“名片”。它指定了客户端支持哪些加密方法、使用哪些 TLS 扩展，以及以何种顺序列出它们。此消息 未加密——甚至在建立安全连接之前，服务器就能看到它。
每个浏览器和每个程序在 ClientHello 中发送自己独特的一组参数。Chrome 以一种顺序列出密码套件和扩展，Firefox 以另一种顺序，而基于标准库的 Python 脚本或机器人则以第三种顺序。这种组合就是 TLS 指纹。它可以比作笔迹：您写着相同的字母，但您特有的风格可以将您与他人区分开来。
有计算此类指纹的标准方法——JA3 和更现代的 JA4。它们从 ClientHello 中提取参数（密码套件列表、扩展、支持的算法）并将它们转换为一个简短的哈希值——一串可用于将客户端与已知浏览器或程序匹配的字符。
为什么 TLS 指纹很重要
许多反机器人和欺诈保护系统 被动地 分析 TLS 指纹——它们不需要在页面上执行脚本或检查 Cookie。只需查看 ClientHello 就足够了。如果请求带有 Chrome 的 User-Agent 标头，但 TLS 指纹与 Python 库匹配，服务器会立即明白它面对的不是真实用户。这样的连接可能会被标记为可疑、收到验证码（CAPTCHA）或最终被封锁。
这是第一道防线，甚至在分析页面上的行为之前就会触发。这正是为什么如果 TLS 指纹暴露了自动化操作，即使是配置完美的 HTTP 标头也无济于事的原因。
如何检查 DNS、WebRTC 和 TLS 泄漏
如果您使用 VPN 或其他匿名工具，检查泄漏是必不可少的步骤。让我们剖析一下在实践中如何检查。
检查 DNS 泄漏
DNS 泄漏最容易通过在线服务检测。检查只需几分钟，不需要特殊技能。
您可以使用以下工具进行检查：
要进行检查，首先连接到您的 VPN 或代理，然后打开其中一个 DNS 测试服务。有时结果会立即加载，但在某些情况下，您需要运行测试。
报告将显示您的请求所经过的 DNS 服务器。如果列出了 VPN 提供商的服务器或公共 DNS（例如，Cloudflare 或 Google），则保护工作正常。如果显示了您的 ISP 的名称或 IP，这就是 DNS 泄漏的迹象。
您也可以在不使用在线服务的情况下检查正在使用的 DNS。
如果您使用的是 Windows：
- 打开命令提示符（Win + R → cmd）。
- 输入命令：
nslookup example.com - Server（服务器）行将指示处理该请求的 DNS 服务器。
如果您使用的是 macOS / Linux：
在终端中，运行：nslookup example.com 或 dig example.com
如果在开启 VPN 时显示了您 ISP 的 DNS，这意味着请求绕过了隧道，并且保护配置不正确。
检查 WebRTC 泄漏
您可以使用特殊的在线服务来检查 WebRTC 泄漏。该过程类似于 DNS 测试。
您可以使用以下工具进行检查：
要进行检查，首先连接到您的 VPN 或代理，然后打开其中一个服务。通常，结果会自动显示，但有时您需要手动启动测试。
报告将指示浏览器通过 WebRTC 传输的公共 IP 地址和网络参数。如果显示的是您真实的 ISP IP 地址而不是 VPN IP，则说明 WebRTC 正在直接暴露数据。如果仅列出了 VPN 服务器的 IP，则没有泄漏。有些服务只会简单地通知您是否存在泄漏。
除了在线测试之外，检查浏览器本身是否启用了 WebRTC 也很重要。
如果您使用的是 Firefox，请在地址栏中输入 about:config。在搜索栏中，找到 media.peerconnection.enabled 参数。如果值为 true，则 WebRTC 处于活动状态。如果为 false，则 WebRTC 被禁用。
在 Chrome 和 Edge 中，没有内置的 WebRTC 状态指示器。您可以通过内部诊断页面检查其运行情况：在地址栏中打开 chrome://webrtc-internals（或 edge://webrtc-internals）。如果在访问网站或运行测试时那里显示了连接活动，则说明 WebRTC 正在工作。如果未创建连接，则传输受到限制。
在 Brave 浏览器中，打开“设置 → 隐私和安全”。在那里您可以找到 WebRTC 处理参数，并确定是否允许传输本地 IP 地址。
检查 TLS 指纹
您可以使用 tls.peet.ws 服务检查您的 TLS 指纹。它会显示您浏览器的 ClientHello 参数、计算出的 JA3/JA4 哈希值，并允许您将其与流行浏览器的指纹进行比较。这样，您就可以查看您的连接看起来像不像普通的 Chrome，或者是否与众不同。
如何保护自己免受泄漏
防止泄漏需要采取综合的方法。仅仅打开 VPN 是不够的——正确配置系统和浏览器，以及定期检查连接同样重要。让我们从防止 DNS 泄漏开始。
防止 DNS 泄漏
第一步 是选择具有内置 DNS 泄漏保护功能的 VPN 服务。这种功能通常被称为 DNS 泄漏保护（DNS Leak Protection），意味着所有 DNS 请求都会自动通过 VPN 本身的安全服务器进行路由。
许多主要提供商都实现了这种保护，例如 NordVPN、ExpressVPN 和 Proton VPN。使用此类服务时，即使系统采用默认配置，DNS 请求也不会直接发送到 ISP。
第二层保护 是手动配置 DNS 服务器。您可以指定与您的 ISP 无关的公共 DNS。最常见的选项是 Cloudflare (1.1.1.1) 和 Google (8.8.8.8)。
您可以在操作系统的网络连接设置中配置 DNS。在 Windows 中，这在适配器属性中完成；在 macOS 中，在“网络”部分中完成。此外，一些现代浏览器允许您直接在设置中启用安全 DNS（Secure DNS）。
结合使用激活了 DNS 泄漏保护的 VPN 和手动设置的 DNS 服务器，可显著降低将请求直接传输给 ISP 的风险。
防止 WebRTC 泄漏
WebRTC 在浏览器级别运行，因此保护措施也正是在那里配置。如果您使用 VPN 但没有限制 WebRTC，浏览器仍然可能暴露您的真实 IP。
第一种方法 是在浏览器设置中禁用 WebRTC。在 Firefox 中，这是通过 about:config 页面完成的：您需要找到 media.peerconnection.enabled 参数并将其值设置为 false。在此之后，浏览器将停止使用 WebRTC 建立直接连接。
在 Chrome 和 Edge 中，无法使用标准工具完全禁用 WebRTC。在这种情况下，可以使用阻止通过 WebRTC 传输网络数据的扩展程序。流行的选项有 uBlock Origin（需要额外配置）和 WebRTC Control。它们通过浏览器机制限制真实 IP 的传输。
第三种选项是使用具有增强隐私保护的浏览器。例如，Brave 默认不阻止 WebRTC，但是，可以在浏览器的隐私设置中更改此参数。
进行更改后，建议通过在线测试重新检查连接，以确保不再显示真实 IP。
防止 TLS 泄漏
禁用发送 ClientHello 是不可能的——没有它，就无法建立加密连接。目标不是隐藏指纹，而是确保它在数百万普通用户中 不显得突兀。
最可靠的方法是使用最新版本的基于 Chromium 的浏览器。在这种情况下，您的 TLS 指纹将与大量 Chrome 用户的指纹相匹配，反机器人系统将不会看到任何可疑之处。
当链条中出现非标准的东西时，问题就会出现：过时的浏览器、非典型的 TLS 库或自动化工具。指纹会立即变得罕见，因此引人注目。
在 Linken Sphere 中，这个问题不存在。该浏览器在最新的 Chromium 引擎上运行，因此每个配置文件在连接时，都会发送与相应版本的常规 Chrome 相同的密码套件和扩展集。TLS 指纹不会是唯一的——它只会与成千上万的真实用户相匹配。这正是适当伪装所需要的。
结论
您可以通过遵循以下几个简单的规则来降低泄漏风险：
- 使用具有 DNS 泄漏保护（DNS Leak Protection）和终止开关（Kill Switch）的可靠 VPN。
- 如有必要，手动指定公共 DNS 服务器。
- 检查浏览器中的 WebRTC 状态，并在需要时将其禁用。
- 定期检查您的连接是否存在 DNS 和 WebRTC 泄漏。
这些措施不能保证完全的匿名性，但它们会显著提高保护水平。
常见问题
DNS将网址转换为服务器IP地址。WebRTC是一种用于直接连接（通话、视频聊天）的浏览器技术。TLS是一种加密协议，用于保护浏览器和网站之间的数据（HTTPS）。
不能。它只是不在您的设备上保存历史记录，但并不能隐藏您的IP地址，也不能防止DNS或WebRTC泄露。
不能。VPN可以隐藏您的IP并加密流量，但如果配置不当，仍有可能发生DNS或WebRTC泄露。
终止开关（Kill Switch）是一项在VPN断开时阻止互联网连接的功能。这可以防止流量直接通过您的互联网服务提供商（ISP）传输。
这是一种将所有DNS请求路由通过VPN服务器的机制，可防止系统访问您的ISP的DNS。
