挂代理 WebRTC 还会漏 IP 吗？

本文属于 代理检测完全指南 系列，Cluster 5 安全与泄露验收——代理 IP 通过仍可能因 WebRTC 暴露真实地址。

系统代理或浏览器插件改好了出口 IP，链路检测 也显示 Pass——但页面里的 WebRTC 仍可能通过 ICE 候选把本机局域网或运营商公网 IP 送给对端。这类泄露不走 HTTP 隧道，DNS 修复也挡不住。本文按「机制区分 → 浏览器实测 → 自动化预检 → 修复验收」四步，给出可执行的诊断清单。

WebRTC 泄露与代理检测的区别

代理检测回答「对外显示的出口 IP 是不是代理」；WebRTC 泄露回答「浏览器是否额外暴露了本地网卡地址」。两者机制独立，须分开测。DNS 泄露改变的是域名解析路径，详见 DNS 泄露检测方法；WebRTC 通过 STUN 收集 host/srflx 候选，可能绕过应用层代理；浏览器 IP 处理策略见 RFC 8828。三者并列关系见 DNS 与 WebRTC 泄露区别。

典型失败场景：账号运营浏览器开了 SOCKS5，HTTP 请求走代理，但 WebRTC 仍上报 192.168.x.x 或真实公网 IP。平台比对「登录 IP vs WebRTC 候选」即可判定环境异常——比单看 HTTP 头更隐蔽也更要命。

浏览器环境下怎么测

方法一 · 内置诊断页：Chrome/Edge 地址栏输入 chrome://webrtc-internals（Firefox 为 about:webrtc），在代理已启用的同一浏览器会话中打开 WebRTC 检测页，观察 candidate 是否出现非代理网段的 host IP。

方法二 · 在线检测页：在代理环境下访问专用 WebRTC 测试页（如 browserleaks.com/webrtc），页面列出的「Public IP Address」应与代理出口一致。若出现第二行本地或真实公网地址 → Fail。

判读标准：仅允许出现代理出口 IP 或检测页不可达（部分企业网屏蔽 STUN）。出现任何与代理无关的公网/私网候选即 Fail。建议 Chrome、Firefox 各测一轮——扩展与策略不同，结果可能不一致。

自动化脚本预检思路

Playwright / Puppeteer 接代理后，可在 CI 中嵌入最小检测脚本：启动带 --proxy-server 的浏览器，导航至 WebRTC 检测页，解析 DOM 中的 IP 列表与预期出口比对。修复后须附加 Chromium 启动参数 --force-webrtc-ip-handling-policy=disable_non_proxied_udp（或企业策略 WebRtcIPHandlingPolicy=disable_non_proxied_udp），冷启动再跑一轮确认候选不再泄露。

注意：无头模式默认仍可能收集候选；不能因有头/无头差异跳过检测。STUN 被防火墙阻断时可能误报 Pass（页面无 IP）——须结合 webrtc-internals 确认是否真正禁用收集，而非网络不可达。

修复与验收清单

按优先级执行：

• 浏览器策略禁用非代理 UDP（Chrome enterprise policy）
• 安装 WebRTC 泄露防护扩展，或 Firefox media.peerconnection.enabled=false
• 确认代理为系统级或浏览器全局，而非仅 PAC 规则匹配部分域名
• DNS 与 WebRTC 并行复测，两项均 Pass 再交付运营

上线前清单（打印勾选）：□ 代理链路 Pass □ DNS 泄露 Pass □ WebRTC 检测页仅显示代理 IP □ 自动化脚本预检通过 □ 扩展/策略变更已写入 runbook。任一未勾选则阻断账号登录类业务。

分场景收紧：社媒账号、广告投放后台建议每台设备独立浏览器配置文件，禁止与同事共用 Chrome Profile——他人扩展可能重新开启 WebRTC。远程桌面运营须在远端会话内跑检测，本机浏览器结果不能代表云端环境。虚拟机/容器场景还要确认是否将 host 网卡透传进容器，Docker 默认 bridge 仍可能暴露宿主机段。

与 webrtc-test-guide 的分工：操作步骤与工具选型见站点已有 WebRTC 检测指南；本文聚焦代理已启用前提下的泄露判读与联合验收顺序。实操顺序建议：008ip 链路报告 → DNS 泄露三项 → 同一浏览器会话 WebRTC 页 → 自动化脚本复核。全程使用与生产相同的扩展白名单，测完再装广告拦截等插件，避免插件本身改写 WebRTC 策略造成假 Pass。

泄露修复后须冷启动浏览器再测一轮：部分策略仅对新进程生效。配置代理后，srflx 公网候选通常应等于代理出口 IP；若出现与代理不一致的公网地址，优先排查系统 VPN 与浏览器代理双路由。若 Fail 为明文 host 私网段（如 192.168.x.x），说明 mDNS 混淆未生效或被策略关闭，而非「mDNS 未禁用」。记录 Fail 截图与 candidate 类型，写入运维 runbook，比口头「已关 WebRTC」可审计得多。

定期复测频率：账号池每周、广告投手每日、爬虫浏览器环境在代理凭证轮换后立即测。平台风控升级新闻出现后 24 小时内加测一轮，不必等同版本发布。将 WebRTC 检测结果与 008ip 报告编号关联存档，事后追溯「哪批账号在何种泄露状态下登录」时才有据可依。

合规侧须知晓：WebRTC 泄露不等于代理供应商违约，而是本地浏览器配置问题；但交付给客户的「匿名环境」若包含 WebRTC Fail，仍属验收不合格。对外报告时分开陈述「代理出口达标」与「终端泄露未修复」，避免把两类问题混为一句「代理不行」导致错误换供应商。

macOS 与 Windows 的策略入口不同：前者多用 Chrome Profile + 扩展，后者可用组策略推送。跨平台团队应维护两份检测截图模板，避免运营按 Windows 文档在 Mac 上操作却以为已禁用 WebRTC。Firefox 容器标签（Multi-Account Containers）与代理插件并用时，须在对应容器内打开检测页，全局标签结果无效。

常见问题 FAQ