如何避免 WebRTC 绕过代理连接？

普通网页显示代理出口，并不自动证明 WebRTC 也使用了同一条路线。WebRTC 会为实时音视频和点对点连接寻找可用网络路径，因此使用代理的账号还需要单独核对 WebRTC 网络策略。

MaskPilot 推荐使用「禁用非代理 UDP」：允许 WebRTC 在代理支持时使用代理 UDP，否则回退到代理 TCP，而不是直接使用未经过代理的 UDP。这个选项限制网络路径，并不等于关闭 WebRTC。

检查当前账号设置

1. 完全关闭目标账号，等待状态恢复为可启动。
2. 编辑该账号，打开指纹设置中的「WebRTC 网络策略」。
3. 确认选择「禁用非代理 UDP（推荐）」。
4. 保存后重新启动账号。正在运行的浏览器不会读取刚保存的新策略，必须完整重启。
5. 在这个重新启动的账号中核对普通网页出口与 WebRTC 检测结果，不要使用另一个浏览器或另一个账号代替。

新建账号默认采用推荐策略，但已有账号可能保存了不同选择，因此排查时仍应逐个确认。

检测结果仍出现设备网络怎么办

如果 WebRTC 检测显示当前设备的公网 IP，或者与普通网页出口明显不同，按顺序检查：

1. 确认测试的是刚刚修改并重启的同一个账号。
2. 返回代理页面，对绑定的入口代理执行「检测连接」；设置了上游代理时，再执行「检测完整连接」。
3. 确认账号仍绑定预期代理，没有临时切换为直接连接。
4. 再次完全关闭账号，确认没有残留浏览器进程，然后重新启动并复测。
5. 暂停可能改写网络路径的其他 VPN、系统代理或网络过滤软件，一次只改变一个变量。
6. 使用第二个可信的 WebRTC 检查页面交叉验证，避免把单个检测页面的展示差异当作确定结论。

如果普通网页出口本身也不正确，应先处理代理路线，而不是继续调整 WebRTC。参见为什么绑定代理后账号无法启动？和为什么代理测试失败？。

不要直接关闭全部实时通信能力

「禁用非代理 UDP」的目标是限制未经过代理的 UDP，而不是移除 WebRTC。完全禁用实时通信可能让会议、语音、视频或点对点功能无法使用，也会让排查失去对真实代理路径的验证。

推荐策略可能增加实时通信延迟；如果目标服务无法通过代理 UDP 或 TCP 建立所需连接，相关功能也可能失败。需要使用实时通信时，先在测试账号验证业务功能，不要为了让单个检测页面显示“通过”而随意改成更宽松的网络策略。

修改策略后仍没有生效

WebRTC 策略和其他指纹设置一样，只在浏览器启动时载入。保存后仍显示旧结果时：

• 确认编辑的是正确账号。
• 确认原浏览器进程已经完全退出。
• 不要同时修改代理、浏览器版本和多个指纹项。
• 先恢复推荐策略并完整重启，再逐项定位差异。

关于指纹设置的生效方式，参见配置稳定的浏览器指纹和修改账号设置后没有生效怎么办？。

联系支持前准备

记录浏览器版本、WebRTC 策略、代理类型、是否存在上游链、普通网页出口与 WebRTC 结果是否一致，以及复测时间。截图时遮盖账号信息和代理凭据，不要提交完整代理地址、用户名、密码或密钥。

Chrome Enterprise 的 WebRTC IP handling 官方说明解释了推荐策略如何限制非代理 UDP；Chrome for Developers 也记录了 WebRTC 通过代理连接时的兼容性取舍。