有一批账号被平台连着关联处理，我第一反应是 IP 不干净，换成高匿的、加了白名单直连，结果照旧被认出来。最后没办法，把浏览器环境一项一项扒开对，才发现问题不在 IP，而在几个我从来没注意过的地方。

IP 在地图上，浏览器却在别处

最常见的一处是时区。IP 归属成都，浏览器时区还是 UTC+0，语言是 en-US，这组合在风控眼里基本等于自报家门。语言头、Accept-Language、地理位置权限给出去的坐标，都是同一类信号。

我的处理办法很简单：按 IP 的归属城市去配时区与语言。用短效 IP 轮换的时候，要么让环境跟着 IP 走，要么在提取的时候用 Area 把城市固定住，别让同一套环境今天在成都明天在广州。星月代理的池子覆盖全国 300 多个城市，指定城市提是支持的，这一点在账号类业务里挺关键。

WebRTC 那一漏

WebRTC 默认可能把本地地址甚至真实公网出口暴露出去，而你页面上显示的出口还是代理。检测方法不复杂：拿那个环境去开一个 WebRTC 检测页，看它列出来的 IP 里有没有你本机的运营商出口。有的话，在指纹浏览器里把 WebRTC 关掉，或者干脆走不支持它的那套方案。

还有两处容易漏的

一是 DNS 归属：本地 DNS 会把你的运营商和地区露出去，跟代理出口对不上。二是 UA 与内核版本的组合——用了很新的 UA 配很老的内核，或者反过来，这种矛盾比 UA 本身更容易被识别。

我现在每次都过一遍的清单

短效 IP 轮换时，环境要不要跟着换

我的做法是分业务：账号类的，一个环境固定一条 IP，IP 尽量固定在同一个城市和运营商，别追求"越换越安全"；纯采集的，环境随便，只要保证并发别全压在同一条 IP 上就行。这条分界线想清楚，能省掉一堆无效折腾。

环境一致性要点：时区、语言、地理位置要跟着 IP 归属地走；WebRTC 和 DNS 是两条常见的真实出口泄露路径；UA 与内核版本别自相矛盾；账号类业务坚持一个环境一条 IP，且 IP 城市固定。