明明配了代理，检测网站却仍显示真实IP？多半是WebRTC在泄露。本文讲清指纹浏览器里WebRTC的替换、转发、真实、禁用、代理UDP五种配置模式的原理与取舍，以及怎么按场景选择并验证是否生效。
你有没有遇到过这种情况：明明已经给浏览器配好了代理，打开 IP 检测网站却仍显示你的真实地址？问题很可能是 WebRTC 泄露。
WebRTC（网页实时通信）让浏览器无需插件就能做音视频通话，但它在建立连接时，可能绕过代理直接暴露你设备的真实 IP——视频会议、语音聊天、在线客服，甚至一些你注意不到的网页脚本都可能悄悄调用它。这篇文章讲清在指纹浏览器（如 PurpleMark）里，WebRTC 有哪些配置模式、各自取舍，以及怎么选、怎么验证。
一、WebRTC 配置的 5 种模式
多账号指纹浏览器通常在"环境指纹配置"里提供几种 WebRTC 处理方式，常见有这五种：
1. 替换模式（Replace）—— 多数场景的默认选择 网页发起 WebRTC 请求时，浏览器返回你为该环境配置的代理 IP，并屏蔽本地真实 IP，让"代理 IP"与"WebRTC 看到的 IP"保持一致。适合 Amazon、TikTok、Shopify、Facebook 等常规账号的日常运营——这也是最推荐先试的模式。
2. 转发模式（Forward）—— 替换的进阶版 通过公开 STUN 服务器中转 WebRTC 请求，让请求路径看起来像由正常网络节点发出，而非简单篡改。相比替换模式更难被察觉，适合对连接来源校验更严格的平台（如部分交易类、支付类网站）。
3. 真实模式（Real）—— 不干预 直接用设备的物理真实 IP，不做任何处理。它通常只在做网络测试、本地开发调试等明确需要真实环境的场景下才用；在需要环境隔离的批量运营里基本不该开启。
4. 禁用模式（Disabled）—— 从源头切断 直接关闭浏览器的 WebRTC 能力，网站无法发起任何 WebRTC 请求，从根源上消除这种泄露。代价是依赖摄像头、语音的网站（如网页版语音、在线客服）会无法使用。适合对隐私要求很高、又不依赖网页音视频通信的场景。
5. 代理 UDP（禁用 UDP）—— 更底层的协议控制 WebRTC 主要靠 UDP 传输。开启这项会把通信限制在 TCP 下，屏蔽通过 UDP 端口探测真实路径的可能。适合需要应对较严格网络检测的环境。
二、按场景怎么选？
| 你的需求 | 推荐模式 | 说明 |
|---|---|---|
| 最大化隐私、不需要网页音视频 | 禁用模式 | 从源头杜绝 WebRTC 泄露 |
| 需要 WebRTC 功能 + 保护 IP | 代理 UDP（禁用 UDP） | 保留必要功能同时屏蔽 UDP 探测 |
| 日常多账号运营、避免地址不一致 | 替换模式 | 代理 IP 与 WebRTC IP 一致，兼顾真实与稳定 |
| 对来源校验很严的平台 | 转发模式 | 经 STUN 中转，更自然 |
一般来说，先选替换模式就能满足大多数场景；遇到对连接审计更严格、或个别依赖语音的站点，再按需切到转发或禁用 UDP。
三、在哪里配置？怎么验证生效？
配置位置：在指纹浏览器里新建或编辑浏览器环境，进入"指纹配置"（指纹参数）一栏，找到 WebRTC 选项选择对应模式；同时确保该环境已正确配置代理，让流量经由预设的代理服务器，而不是直连公网。
验证方法：配置并打开环境后，访问一个 WebRTC 泄漏检测工具，看它显示的 IP 是否与你为该环境配置的代理 IP 一致、有没有露出本地真实 IP。若显示一致且没有真实地址，说明配置已生效。
四、常见问题
为什么用了代理，账号还是可能被关联？ 很可能是 WebRTC 泄露——它绕过代理把真实物理 IP 暴露给了网站。在指纹浏览器里选对 WebRTC 模式即可拦截这类泄露。
禁用模式会影响正常上网吗？ 会影响依赖网页音视频/语音的功能。如果确定用不到这些，禁用模式是隐私最稳妥的选择；需要的话就改用替换或转发模式。
总结
WebRTC 是"配了代理仍可能泄露真实 IP"的常见原因。指纹浏览器提供的替换、转发、真实、禁用、代理 UDP 五种模式，本质是在"隐私保护"和"功能可用"之间做取舍：默认先用替换，审严格用转发，不依赖音视频就禁用，必要时再关 UDP。选好后用泄漏检测工具验证一下，确认显示的 IP 与代理 IP 一致，才算真正配到位。
