WebRTC 泄露和 DNS 泄露：如何防止 IP 暴露
WebRTC 泄露是指浏览器通过 STUN 请求暴露您的真实 IP，即使代理正在运行也是如此。DNS 泄露是指域名查询被发送到您的 ISP，而不是通过代理隧道。这两种泄露都会让通过 Nsocks 或任何服务商路由流量的做法失去意义。测试只需几分钟，下文的修复方法适用于 Chrome、Firefox 和脚本化会话。
本页使用的图例：✅ 检查已确认 · ❌ 泄露或缺少控制 · ⚠️ 部分保护 · 💡 实用提示。不使用其他标记。
什么是 WebRTC 泄露
WebRTC 泄露会通过对等连接期间收集的 ICE 候选暴露您的本地或公网 IP，无论代理设置如何。浏览器使用 WebRTC 进行视频通话，而 STUN 服务器请求通过 UDP 传输，大多数基于 HTTP 的代理根本不会处理。地址栏看起来已经过代理，但浏览器却悄悄报告了其他信息。
💡 在执行任何面向客户的任务之前先运行 WebRTC 泄露测试，而不是等到发现问题之后。
什么是 DNS 泄露
DNS 泄露是指主机名解析发生在您的本地网络，而不是通过代理进行。DNS 查询会暴露您访问了哪些网站，而所用的解析器通常会暴露原始网络。标准 SOCKS5 配置默认在本地解析 DNS，这正是这种暴露的起点。
泄露类型、原因与修复方法
大多数暴露问题都可以归结为少数几个原因。下表是本文使用的唯一参考，因此泄露类型不会在每个标题下重复出现。每行列出了原因、检测方法和修复方法。
| 泄露类型 | 原因 | 检测方法 | 修复方法 |
|---|---|---|---|
| WebRTC | STUN 请求通过 UDP 绕过代理 | 浏览器 ICE 候选检查 | 限制 IP 处理策略 |
| DNS | 解析器查询在隧道外发送 | 将解析器与代理位置进行对比 | 使用远程 DNS 解析 |
| IPv6 | 代理仅覆盖 IPv4 | 双栈测试显示第二个地址 | 禁用 IPv6 或为其配置路由 |
| mDNS 候选 | ICE 收集期间暴露本地主机名 | mdns 主机名可见 | 启用候选混淆 |
| 隧道中断 | 代理在会话中途断开 | 任务中途 IP 突然变化 | 添加快速失败逻辑 |
如何测试您的设置是否存在泄露
配置文件启动后需要验证的内容
将 WebRTC 泄露测试与 DNS 泄露测试结合使用，可以在大多数暴露问题进入生产环境之前将其捕获。以下步骤对浏览器标签页或脚本化会话同样适用。每次都应运行全部五个步骤，而不仅是在感觉不对劲时。
- 关闭代理，记下您的真实 IP。
- 打开代理，确认显示的 IP 已发生变化。
- 在信誉良好的网站上运行带解析器检查的 IP 泄露测试。
- 将每个结果与您的真实 IP 和 ISP 解析器进行对比，标记任何匹配项。
- 在真实工作环境中重复测试，因为干净的标签页结果对自动化而言意义不大。
如何使用 socks5h 防止 DNS 泄露
普通 SOCKS5 在客户端解析主机名，而 socks5h 将该查询通过代理本身发送。仅这一个字母就能彻底堵住最常见的 DNS 泄露路径。远程 DNS 解析将每个查询都保持在隧道内，这对调研、QA 和特定市场工作非常重要。
域名在何处被解析
curl --socks5-hostname USERNAME:PASSWORD@PROXY_IP:PORT https://example.com
大多数爬虫库默认使用普通 socks5，除非另有指定，因此花三十秒检查一下连接字符串是值得的。✅ 有文档记录的 socks5h 支持可以省去一个步骤。
如何在浏览器中控制 WebRTC
浏览器内置的 WebRTC IP 处理策略各不相同，单靠任何一种都无法保证完全匿名。Firefox 可以通过 about:config 完全禁用 WebRTC，而 Chromium 由于没有原生开关，只能依赖相同的策略或扩展程序。设置为禁用非代理 UDP 的策略会强制 ICE 候选通过当前活动的代理。
- ✅ Firefox：将 media.peerconnection.enabled 设为 false，或使用 ice.no_host 获得部分保护
- ✅ Chromium：将 IP 处理策略设置为禁用非代理 UDP
- ⚠️ 扩展程序有帮助，但更新可能会重置设置
- ❌ 假设代理会自动阻止 WebRTC，但大多数代理并不会
每次浏览器更新后都要重新测试，因为厂商对默认行为的更改往往比发行说明中透露的更多。糟糕的策略通常是这一层发生 WebRTC 泄露的最大原因。mDNS 混淆可以隐藏本地 IP，但公网方面需要单独的修复方法。
IPv6 流量与未隧道路由
IPv6 流量会绕过仅为 IPv4 构建的代理，这一缺口是目前较容易被忽视的暴露路径之一。双栈连接可能通过代理显示干净的 IPv4 地址，而 IPv6 则通过真实的 ISP 路由出去。大多数 IP 检测工具只显示 IPv4 结果。通过未隧道化的 IPv6 接口发生的 WebRTC IP 泄露看起来与干净的会话完全相同。
💡 如果代理设置未覆盖 IPv6，请在适配器层面禁用它，或在运行任何面向客户的任务之前确认双栈路由。
一致性：IP、DNS、时区和语言
即使通过了测试，如果其他信号不一致，仍会留下缺口。仅靠 DNS 泄露测试无法发现系统时钟与代理所在地区之间的时区不匹配。语言、键盘布局和区域设置都会影响平台从会话中构建的同一画面。这种风险在多个客户配置文件之间会成倍增加，更深入的细分分析请参阅我们的管理多个浏览器配置文件指南。
自动化任务的预检清单
自动化和无头浏览器任务在每次运行前都需要可重复的检查，而不是一次性设置。此清单与上文的手动步骤不同，因为脚本会以测试人员能立即注意到的方式静默失败。请将其视为投入生产前的最低标准。
- ✅ 记录每个请求的出口 IP，而不仅是在会话开始时记录
- ✅ 如果记录的 IP 超出预期范围，则快速失败
- ✅ 在任何浏览器或驱动程序更新后重新检查泄露
- ✅ 确认连接字符串中的远程解析已启用
- ✅ 将 IPv6 路由与 IPv4 分开检查
- ✅ 验证时区和区域设置与代理所在地区相匹配
- ⚠️ 将上周通过的结果视为已过期，而非仍然有效
- ❌ 不要因为"昨天还能用"而跳过检查
简短的清单只有有人对其负责时才能发挥价值，因此请将其固定在团队在任务上线前能看到的地方。
常见错误
大多数反复出现的暴露问题源于流程缺陷，而非某种未知的泄露类型。团队通常只在设置时检查一次，而在更新发布后跳过重新测试。在普通标签页中测试，而不是在真实环境中测试，会带来虚假的安全感。只依赖服务商的控制面板而非独立检测工具，会漏掉后者专门设计要捕获的问题。把一次 WebRTC 泄露当作偶发事件而不是流程失败来处理，注定会再次发生。
代理设置如何影响泄露风险
披露声明：Nsocks 是我们的服务，本节介绍我们的设置如何处理上述风险。我们销售住宅代理和静态 IP 代理，两者都在代理端提供远程 DNS 解析。大多数关于 WebRTC 泄露的支持工单都可以追溯到上表中的某一行。该表列出的是每项功能在日常中的实际意义，而非营销用语。
| 功能 | 实际意义 |
|---|---|
| socks5h 支持 | 解析在代理端进行，而非客户端 |
| 支持 IPv6 的路由 | 在支持的范围内，双栈流量保持在隧道内 |
| 有文档记录的 IP 处理 | 步骤与当前浏览器策略保持一致 |
| 会话日志 | 每个请求的出口 IP 对 QA 可见 |
这些都不能替代浏览器层面的配置或重新测试的习惯。代理负责路由；浏览器决定暴露什么。在每次客户会话前运行 WebRTC 泄露测试的团队遇到的意外更少。试用 Nsocks 演示以查看连接详情，或注册以访问控制面板。
要点总结
- 在每次客户会话前运行 WebRTC 和 DNS 泄露测试，而不是只运行一次。
- socks5h 将解析移至代理端，堵住了最常见的暴露路径。
- IPv6 需要单独检查，因为大多数 IP 工具默认只显示 IPv4。
- IP、DNS、时区和区域设置之间的一致性与单项测试同等重要。
- 更新后重新测试可以捕获大多数被团队描述为"突然"的泄露。
披露声明与数据来源
本文由 Nsocks 发布。我们销售代理服务，因此在介绍我们自己设置的章节中存在商业利益。文中引用的测试工具和浏览器设置归其各自所有者所有，包括浏览器厂商和独立检测服务。详细信息于 2026 年 8 月核对，不同版本之间的行为可能有所变化，因此请先重新核实相关设置。
常见问题解答
什么是 WebRTC 泄露？
浏览器会通过 STUN 或 ICE 候选暴露您的真实 IP，即使代理处于活动状态。
如何测试 DNS 泄露？
在泄露测试网站上运行解析器检查，并将其与您的代理所在位置进行对比。
SOCKS5 和 socks5h 有什么区别？
SOCKS5 在本地解析主机名；socks5h 将该查询通过代理服务器发送。
禁用 WebRTC 会导致视频通话无法使用吗？
会，完全禁用会彻底中断通话，因此部分 ICE 限制是更好的选择。
IPv6 会暴露我的真实 IP 吗？
会，如果代理仅处理 IPv4 流量，IPv6 也可能绕过它。
我应该多久重新测试一次自动化设置？
每次浏览器或驱动程序更新后，此外还应按固定周期进行测试。
