概念定义：WebRTC本地IP泄露与谷歌斗篷的关系
先说WebRTC本地IP泄露到底是什么。浏览器为了支持实时通信，会去收集本机的网络接口地址，这个过程走的是ICE候选机制，收集到的地址会被暴露给通信对端，或者被页面脚本直接读走。暴露出来的东西包括局域网地址、回环地址、虚拟网卡地址，有些网络环境下连NAT映射后的公网地址也会一并带出来。那这事儿跟谷歌斗篷有什么关系？关键点不在WebRTC这个技术本身，而在于它可能让页面的网络出口特征跟代理链路对不上。
谷歌斗篷干的核心工作，是让访问谷歌广告系统的流量按照规则呈现出不同的网络出口和环境特征。问题就出在这儿：浏览器明明是通过代理出口去访问页面的，可WebRTC偏偏走本地网卡直连STUN服务器，页面侧一观察，两套网络路径同时摆在那儿。风控系统看到这种路径不一致，会把它记成特征冲突信号，账号稳定性就受影响了。所以WebRTC本地IP泄露的检测与抑制，是环境一致性优化里的一个具体环节，别把它当成谷歌斗篷的全部。
泄露通道与检测方法
泄露产生的主要通道
地址收集这件事由ICE框架负责，一般会涉及三类候选地址。主机候选来自本机网卡，服务器自反候选是STUN服务器反射回来的，中继候选则来自TURN服务器。暴露风险主要集中在前两类身上。页面脚本只要创建了RTCPeerConnection并开始收集候选地址，哪怕根本没有真实通话发生，几秒钟之内就能把本机地址列表拿到手。
主机候选：内网地址段直接暴露，办公网络或家庭网络没做隔离的话，这种情况很常见。；服务器自反候选：STUN请求从本机网络发出，真实公网出口就露出来了，跟代理出口形成冲突。；mDNS混淆：有些浏览器会用随机主机名把内网地址替换掉，可识别性降低了，但没有彻底消除。。
检测方法
检测要确认的事情只有一件：页面环境里到底有没有能被读到的本地地址。做法上，可以在受控页面里调用RTCPeerConnection，监听icecandidate事件，把候选地址字符串一条条记下来。然后拿候选地址里的公网地址跟代理出口地址做比对，看是否一致。顺便检查一下浏览器有没有开启mDNS候选混淆。这里有个前提，检测必须在跟投放环境相同的浏览器版本和网络配置下做，因为不同版本对候选地址的暴露策略差别不小。
有一点得说清楚。检测只能确认浏览器层面是否暴露了地址，至于风控系统有没有已经采集到这个信号，检测是看不出来的。检测结果是环境自检的输入项，不能拿它当账号异常的直接证据。
抑制方案与技术手段
浏览器层抑制
最省事的抑制就在浏览器配置层做。主流浏览器都提供了关闭或限制WebRTC地址暴露的选项，不同内核、不同版本，配置项名称不一样。企业级部署的话，通过策略模板统一下发就行，没必要一台台手工调。代价是关闭之后依赖WebRTC的实时音视频功能会受影响，所以这手段适合以页面访问和广告投放为主的场景，需要真实RTC功能的业务页面就别这么干了。
网络层抑制
网络层的思路是让STUN请求也老老实实走代理。浏览器或系统代理如果没覆盖UDP流量，STUN请求就可能直连出去。解决办法有这么几种：代理规则里强制UDP转发、在网关侧把直连STUN端口拦掉、或者直接换成支持UDP转发的代理协议。这么配下来链路复杂度和延迟都会增加，得权衡着来。
页面层抑制
如果是自有落地页，可以靠内容安全策略（CSP）去限制或审计脚本对RTCPeerConnection的调用，把非必要脚本触发地址收集的概率压下去。这手段不改变浏览器底层行为，只是降低页面侧主动采集的可能性。第三方脚本多的页面，CSP配置得逐条验证，别误伤了正常功能。
适用条件与边界
这套方案适用的条件，我一般会先确认三条。业务以页面访问和广告投放为主，不依赖真实WebRTC通信，这是头一条。代理链路对UDP流量的覆盖情况得是已知的，并且能做针对性配置。投放环境里的浏览器版本要可控，能统一做策略下发。
它解决不了的问题同样得摆明。代理IP本身的信誉和纯净度，它管不了；DNS解析路径跟代理出口不一致的问题，它修不了；Cookie、设备指纹这些其它环境特征，它也不处理。账号层面的合规运营，更不是它能替代的。把WebRTC抑制当成账号稳定性的全部手段，这个误判挺常见。
举个匿名化的案例，边界在哪就很清楚了。有个跨境电商团队做谷歌投放，日均点击量千次上下，用的是自建代理加云端浏览器。上线一段时间后，账号侧开始出现特征冲突提示。团队一开始认定是代理IP的问题，换了好几批出口，情况没见好转。后来做环境自检才发现，浏览器根本没做WebRTC抑制，STUN请求走的是本地网络，页面侧能同时看到内网地址段和代理出口。调整方式分几步：浏览器策略层关闭地址暴露，网关侧拦截直连STUN端口，同时核对DNS解析是不是也走了代理。调整完，特征冲突提示少了，但没有完全消失。剩下的那部分来自设备指纹和Cookie历史，属于另一类活儿。这个案例的结论就是：WebRTC抑制是必要项，不是充分项。
相邻概念对比
DNS泄露是域名解析请求没走代理路径，暴露的是解析出口；WebRTC泄露暴露的是网络接口地址。两者都属于网络路径一致性这个范畴，但检测位置和抑制手段是两回事。DNS泄露通常在系统或浏览器DNS配置层处理，WebRTC泄露得在浏览器策略和UDP转发层处理。
与设备指纹的对比
设备指纹描述的是浏览器与硬件环境的稳定特征组合，WebRTC地址只是其中一项，远不是全部。指纹治理关注的是跨会话的一致性，WebRTC抑制关注的是单次访问里的路径冲突。目标不同，互相替代不了。
与代理IP信誉的对比
代理IP信誉说的是出口地址在风控库里的历史评价，属于资源质量层面的事；WebRTC抑制属于配置层面的事。资源质量差的时候，配置再干净也难稳定；配置有漏洞的时候，资源再好也会冒出特征冲突。
常见问题
关闭WebRTC后是否完全消除本地IP暴露
不完全。关闭或限制之后，浏览器通常不再返回主机候选，或者返回一个混淆过的地址，但具体行为取决于浏览器版本和策略实现。部分环境下，通过其它接口仍然可能拿到网络信息。所以WebRTC抑制应该被当成降低异常特征触发概率的一环，别指望它做到绝对隔离。
是否需要为每个投放环境单独检测
需要。浏览器版本、操作系统、代理协议、网络拓扑，这些都会影响候选地址的收集结果。我的建议是，环境模板变更后、浏览器升级后、代理链路调整后，各做一次自检，把检测结果作为环境配置的一部分记录下来。
该方案是否影响页面正常功能
会影响依赖WebRTC的功能，网页版实时音视频、部分在线协作工具都算。落地页如果包含这类功能，就得在抑制范围上做取舍，或者干脆把它们放到独立环境里跑，别跟投放环境混用。
