用住宅代理时，很多人第一眼就盯着“IP变没变”。代理连上了，whatismyip也显示新地址，就觉得稳了。可浏览器里的WebRTC往往还在默默工作，把真实公网IP或者本地局域网地址露出去。结果主流量走了干净的住宅出口，WebRTC那边却把家底交了。多账号场景下，几个档案如果共享同一条真实IP泄漏，关联风险直接拉满；自动化脚本里也一样，登录流程看着正常，后台信号却对不上。

WebRTC本来是给实时音视频、P2P数据传输用的。浏览器通过ICE、STUN、TURN这些机制去找可用的网络路径，过程中会收集一堆候选地址。这些候选里经常包含你的真实公网IP、IPv6，甚至192.168开头的本地IP。代理或VPN只管HTTP/HTTPS那条路，WebRTC走的是另一条通道，默认情况下它不吃代理设置。站点只要跑一小段脚本，就能拿到这些信息。公共IP泄漏直接暴露真实地理位置和ISP；本地IP泄漏则给指纹多加一层网络拓扑特征。对隐私用户是麻烦，对多账号和账号养号的人来说，就是把隔离做废了。

测试并不复杂，但得按步骤来，别只看一眼就过。先断开所有代理和VPN，记清楚自己的真实IPv4和IPv6。然后连上目标住宅代理，确认主IP已经切换。打开WebRTC泄漏检测页面，看结果里只出现代理IP，还是混进了真实地址。公共IP泄漏最危险，本地IP泄漏也别忽略，尤其是多台机器或共享网络环境。每个反检测浏览器档案都要单独测一遍，系统级代理救不了单个Chromium实例。浏览器更新、扩展增减、代理更换后，最好重测。IPv6特别容易漏，很多工具默认只盯IPv4。

修复路径有几条，按场景选。Firefox最直接：about:config里把media.peerconnection.enabled设为false，彻底关掉。Chrome/Edge没有原生开关，得靠扩展，像WebRTC Control这类一键屏蔽。反检测浏览器通常自带WebRTC控制选项——替换、屏蔽、或者伪装成代理IP。选“替换”或“匹配代理”模式时，确保它跟着当前出口走，别固定成某个值。自动化环境更要注意：Puppeteer或Playwright启动时加相关flags禁用WebRTC，或者在页面加载前注入脚本清掉ICE候选。有些工具已经支持“活跃WebRTC伪装”，代理一旋转，WebRTC IP同步跟着变，避免旋转过程中出现不一致。

单靠修WebRTC还不够，得和住宅代理的会话策略绑在一起。高价值流程（登录、加购、多步表单）用粘性会话，让同一IP维持一段时间，比如10到30分钟，配合固定的浏览器指纹和时区。这样站点看到的是连贯身份。纯采集或大规模轮换就用动态旋转，但每轮都要确认WebRTC同步。指纹对齐很关键：代理选的是美国住宅，时区、语言、Canvas、WebGL也得匹配，否则IP再干净也显得假。Nexip提供的动态住宅IP支持粘性和轮换灵活切换，出口真实度高，方便和反检测配置搭配，减少信号冲突。配置时先用小流量测通，再上生产。

常见坑不少。只测系统浏览器，档案里照样漏；信任VPN图标或代理连接成功提示，不跑WebRTC专项检查；更新浏览器后忘记重测，默认设置又开回来了；把本地IP泄漏当小事，多账号时却成了关联线索；代理换了国家，WebRTC还停在旧地址。还有人只修HTTP层，忽略自动化里的无头浏览器默认行为。实操时建议建立检查清单：新档案上线前必须过WebRTC测试，生产任务加监控，失败时优先看IP一致性而不是单纯重试。

选型住宅代理时，除了池子大小和速度，还要看会话控制是否稳定、地理覆盖是否细到城市、是否方便对接自动化工具。Nexip这类服务在动态住宅场景下能给出干净的出口和可调的粘性时长，配合前面的浏览器加固，整体一致性会好很多。别指望代理 alone 解决一切，WebRTC是浏览器层的问题，代理解决的是路由层。两者一起做，多账号隔离和自动化成功率才会真正起来。日常就养成习惯：换代理必测，改配置必测，更新后必测。这样住宅IP的信任优势才不会被一个浏览器小功能给冲掉。