Chrome怎么关闭WebRTC？各浏览器防泄露设置教程
Chrome 没有原生的 WebRTC 总开关，只能靠 uBlock Origin 或 WebRTC Network Limiter 这类扩展来防止它泄露真实 IP；Firefox 是唯一能在浏览器内原生彻底关闭 WebRTC 的主流浏览器（about:config 里把 media.peerconnection.enabled 设为 false）。设置完成后，到 WebRTC 泄露检测 复测一次即可确认是否生效。
为什么要关闭或限制WebRTC？
一句话定义：WebRTC 泄露是指浏览器在收集点对点连接的候选地址（ICE candidate）时，把你的真实公网 IP 或内网 IP 暴露给了网页，即使你正在使用代理或 VPN。WebRTC 本身是浏览器内置的实时音视频通信能力，视频会议、网页语音都靠它。问题在于它为了打通连接，会主动枚举你设备上的网络地址——这些地址可以不经代理直接被页面脚本读到。对希望隐藏真实位置的用户来说，这相当于网页流量走了隧道、身份却从侧门溜了出去。ipkk.com 首页的封号风险系数（0-100，越高越危险）会把"是否存在 WebRTC 泄露"作为定性因子之一计入评估，泄露会推高整体风险系数。
Chrome和Edge怎么防止WebRTC泄露？
结论：Chrome 和 Edge 都不提供关闭 WebRTC 的原生设置，可靠做法是装扩展限制它，主流方案有两个：
- uBlock Origin（推荐，一举两得）：打开扩展的设置面板，在"隐私"分类下勾选"防止 WebRTC 泄漏本地 IP"。这不会关闭 WebRTC，而是阻止它上报代理之外的候选地址，视频会议基本不受影响。
- WebRTC Network Limiter（Google 官方扩展）：安装后在选项里选择"只使用默认公共网络接口（默认路由）"一档，强制 WebRTC 流量只从当前默认出口（即代理接管的出口）走，不再枚举其他网卡地址。
两个扩展选装一个即可，作用重叠。注意扩展界面的具体措辞可能随版本更新变化，以扩展官方说明为准。Edge 基于 Chromium，上述两个扩展同样适用。
Firefox怎么彻底关闭WebRTC？
结论：Firefox 是唯一能原生彻底关闭 WebRTC 的主流浏览器，改一个配置项即可。步骤：在地址栏输入 about:config 并回车，确认风险提示后，搜索 media.peerconnection.enabled，把它的值切换为 false。改完立即生效，无需重启浏览器。设为 false 后，Firefox 会完全禁用 PeerConnection，网页脚本拿不到任何 ICE 候选地址，泄露渠道被连根切断——代价是所有依赖 WebRTC 的功能（视频会议、网页语音、部分 P2P 传输）在这个浏览器里全部失效。如果你只想防泄露而保留通话能力，Firefox 也可以不动这个开关，改用 uBlock Origin 的同款"防止 WebRTC 泄漏本地 IP"选项。
各浏览器防泄露方法对比
先给结论：桌面端首选 Firefox 原生关闭或 Chrome 系扩展限制，Safari 较新版本一般无需处理，移动端浏览器基本无法单独关闭。对照下表选择你的方案：
| 浏览器 | 方法 | 效果 | 副作用 |
|---|---|---|---|
| Firefox | about:config 中 media.peerconnection.enabled 设为 false | 彻底关闭 | 视频会议、网页语音全部不可用 |
| Chrome / Edge | uBlock Origin 勾选"防止 WebRTC 泄漏本地 IP" | 仅防泄露 | 极少数依赖内网直连的应用可能连接变慢 |
| Chrome / Edge | WebRTC Network Limiter 选择只用默认路由 | 仅防泄露 | 多网卡场景下 P2P 连接质量可能下降 |
| Safari（较新版本） | 默认已限制 ICE 候选的暴露 | 仅防泄露（系统默认） | 一般无需处理，无额外副作用 |
| 移动端浏览器（iOS/Android） | 无法单独关闭，用代理客户端的 TUN 模式整体接管 UDP | 仅防泄露 | 依赖代理客户端能力，耗电略增 |
关闭WebRTC有什么副作用？
结论：彻底关闭 WebRTC 意味着 Google Meet、Microsoft Teams、网页版视频客服等所有依赖它的实时通信功能都会失效，因此"一刀切关掉"并不适合所有人。更实用的做法有两种：一是准备一个独立的浏览器配置（Profile）——日常开会用不动设置的配置，涉及隐私敏感操作时切换到已关闭或已限制 WebRTC 的配置；二是按需开关，Firefox 的 about:config 改动即时生效，扩展也可以随时启停，用完即恢复。相比之下，uBlock Origin 和 WebRTC Network Limiter 的"防泄露"模式副作用小得多：WebRTC 仍然可用，只是候选地址被限制在默认出口上，多数视频会议不受影响。
常见问答
Chrome的设置里真的找不到WebRTC开关吗？
找不到，Chrome 从未提供过面向普通用户的 WebRTC 总开关。桌面版 Chrome 只能通过扩展限制 WebRTC 的候选地址收集；如果你必须彻底禁用 WebRTC，换用 Firefox 并修改 media.peerconnection.enabled 是目前唯一的原生方案。
装了uBlock Origin勾选防泄露后还需要WebRTC Network Limiter吗？
不需要，二者作用重叠，装一个即可。uBlock Origin 的"防止 WebRTC 泄漏本地 IP"与 WebRTC Network Limiter 的"只用默认路由"实现思路一致，都是限制 WebRTC 只上报默认出口的地址。同时安装不会更安全，反而可能互相干扰排查。
无痕模式能防止WebRTC泄露吗？
不能。无痕模式只是不保存历史记录和 Cookie，WebRTC 的候选地址收集机制完全照常工作。而且部分浏览器在无痕模式下默认禁用扩展，防泄露扩展反而失效——记得在扩展管理里允许其在无痕模式下运行。
怎么确认设置真的生效了？
用 WebRTC 泄露检测 实测一次，这是唯一可靠的确认方式。合格标准有两条，满足其一即可：页面检测不到任何公网候选地址；或检测到的候选地址与你的代理出口 IP 一致。若仍能看到与代理出口不一致的公网地址，说明设置没生效，回头检查扩展是否启用、配置项是否保存。
手机上怎么防WebRTC泄露？
移动端浏览器基本无法单独关闭 WebRTC，思路要换成"整体接管"。iOS 和 Android 上的浏览器（包括 Chrome、Safari）都不开放这类设置，可行做法是让代理客户端开启 TUN 模式，把包括 UDP 在内的全部流量纳入隧道，WebRTC 枚举到的出口自然就是代理出口。配置后同样建议用手机浏览器打开检测页复测。
真实使用场景
一位做跨境电商的读者反馈：他在 ipkk.com 首页查自己的环境时，封号风险系数落在"风险一般"档，逐项对照因子发现 WebRTC 一项存在泄露。到 WebRTC 泄露检测 一测，页面确实枚举出了一个与代理出口不一致的公网候选地址——他的浏览器是 Chrome，代理只接管了 TCP 流量。他没有换浏览器，而是给 Chrome 装了 uBlock Origin 并勾选"防止 WebRTC 泄漏本地 IP"，同时新建了一个独立的浏览器配置专门用于店铺后台。重测后候选地址不再出现，风险系数回落，日常用另一个配置开视频会议也完全不受影响。需要提醒的是，多账号运营场景请以平台规则为前提合规操作，环境检测只是帮你确认配置是否达到了预期。