代理只覆盖 HTTP 流量，WebRTC 通过 STUN/ICE 走 UDP 交换候选地址。讲清它什么时候把本机与内网地址交出去，以及让网络出口和环境对齐的处理方向。
代理买好了，IP 查询页面显示的地区、运营商都对得上，看起来网络身份已经处理干净。可打开泄漏检测页面，WebRTC 那一栏是红的，显示的地址是你真实的运营商出口。
先别急着换代理。问题大多不在代理的质量上，而在它管不到的地方。
代理只管 HTTP，WebRTC 走的是另一条路
代理的工作位置在网络层。不管它做成浏览器插件还是系统级隧道，处理的对象都是 HTTP/HTTPS 请求，把这一路流量从代理出口送出去。
WebRTC 是另一回事。它是浏览器自带的实时通信能力，为了让音视频通话和 P2P 传输找到合适的路径，会主动向外部服务器发起 STUN 查询——问一句从你那边看我的地址是什么，再把结果整理成 ICE 候选交给网页。这些查询走 UDP，跟 HTTP 隧道是两条互不相干的通道。
于是就出现了这样的结果：网页请求从代理出口走了，浏览器同时又把你本机的地址报了出去。以为配好代理就等于网络身份处理干净，是这类问题最常见的起点。
交出去的不只是公网 IP
ICE 候选里通常有两类地址。一类是公网地址，也就是你真实的运营商出口；另一类是本地地址，比如 192.168 开头的内网地址，有时还会带上虚拟网卡的地址。
内网地址单独看说明不了什么，随便哪台电脑都有一个。但它足够稳定，多个账号的候选地址反复重叠，平台就能顺着这条线把它们归到同一台设备上。公网地址更直接，它指向真实的运营商和大致地理位置，粒度能细到哪一步取决于对方做到哪一步，方向是清楚的：地址越真，关联起来越省事。
什么情况下真的会被读到
不是每个网站都会去读。地址交换需要页面主动创建 RTCPeerConnection 对象，普通内容页不会做这件事。
会做的一般是这几类：需要实时通信的站点，比如视频会议、在线客服和部分直播页面；以广告和反欺诈为主要收入来源的站点；以及风控体系比较完整的平台。这些读取发生在前端看不见的地方，收集起来之后怎么用，你也不会收到通知。
还有一种情况跟网站无关。代理重连或者切换节点的间隙，浏览器发出的 STUN 请求可能落在本地网络上。窗口很短，但足够被记录一次。
三种常见的失效情形
浏览器插件类的代理通常只接管 HTTP/HTTPS 请求，UDP 不在管辖范围内，界面上勾了全局也不会改变这一点。
系统级的全局代理看起来彻底，覆盖整机流量。但候选地址的收集可以直接绑定本地网络接口，绕开系统路由表，隧道在这个环节是漏的。
第三种不是技术问题，而是节奏问题。风控侧陆续把 WebRTC 地址列入账号关联的参考信号，过去测不出来或者懒得看的数据，现在会被算进判定里。
方向是让出口自洽，而不是关掉一个开关
具体做法大致几种。业务上完全不需要实时通信的，直接禁用 WebRTC 最省事，代价是视频通话、在线客服这类功能一起用不了。
需要保留功能的，让 WebRTC 层面返回的地址与代理出口保持一致，这是日常使用最多的一种。更稳妥的是把 STUN 请求也送进代理通道转发，接口上不暴露本机地址。有 P2P 或视频通话需求的，则要让 UDP 整体走代理，而不是只处理 HTTP 这一层。
这里容易走偏的地方在于：单独把 WebRTC 关掉，不等于环境就干净了。要保证的是网络出口、DNS 解析、IP 归属与 ASN、时区语言、设备特征这一整套互相自洽。任何一项对不上，都会留下异常信号，WebRTC 只是其中最先被忽略的那一项。
验证方式很简单，切换节点之后和正式投入使用之前各测一次：打开泄漏检测页面，看 WebRTC 一栏返回的是代理出口地址、本地地址还是真实公网地址。普通的 IP 查询看不出这一项。
浏览器内核层的环境隔离方案可以在每个环境里单独设定 WebRTC 的地址策略，并让它跟这个环境绑定的网络出口配套，PurpleMark 提供的就是这一类能力。如果多个环境共用一个出口，或者各环境的地址策略互不一致，隔离的意义会大打折扣。
以上为技术原理说明，请在遵守平台规则与当地法律的前提下使用相关工具。
