代理开了，位置还是被看穿

这是最让人困惑的一类问题：IP 检测页显示出口在美国，但目标网站依然判断你在别处，或者账号行为分明显偏低。原因通常是代理只改了 TCP 出口，没管住其他通道。

浏览器至少有四条路径能把真实位置送出去：DNS 解析、WebRTC、IPv6、以及时区语言这类软信号。先看总览，再逐条处理。

一、DNS 泄漏：最常见，也最好修

原理：浏览器访问域名要先解析。如果解析请求走的是本地运营商 DNS（而不是通过代理远端解析），那么目标网站的 CDN、第三方统计、甚至你自己的服务器日志，都能看到"一个来自你真实地区 IP 的解析请求"。

怎么发现：打开 DNS 泄漏检测页，看它列出的解析服务器归属地。如果出口 IP 在洛杉矶，解析器却在国内，就是泄漏。

怎么修：

• 代理客户端里开启远端 DNS 解析（Remote DNS / 代理解析域名），不要用本地解析。
• 浏览器层面关闭"使用安全 DNS"的本地解析，或者反过来统一走加密 DNS，避免两套解析并存。
• 验证时清空 DNS 缓存再测，否则看到的是旧结果。

二、WebRTC 泄漏：IP 改干净了，本地地址还在喊

原理：WebRTC 为了建立点对点连接，会用 STUN 服务器探测本机的网络候选地址，包括内网地址和公网出口。如果这一步没走代理，真实公网 IP 会直接暴露给对端，甚至在页面脚本里就能读到。

怎么发现：WebRTC 检测页会列出"公网 IP"和"本地 IP"。出现与代理出口不同的公网地址，就是泄漏；出现 192.168.x.x 这类内网段，说明候选地址未被屏蔽，也是一条信息。

怎么修：在浏览器或指纹环境里关闭 WebRTC（或设为"仅代理"模式），并在代理客户端禁用 UDP 直连。做多账号运营的环境，这一项应该默认为关闭。

三、IPv6：最隐蔽的一条旁路

很多人只处理了 IPv4 的代理，但系统同时具备 IPv6 地址。当目标站点支持 IPv6 时，浏览器可能优先走 IPv6 直连——完全绕过你的代理，把真实地址交出去。

处置：要么在系统层禁用 IPv6，要么确保代理同时接管 IPv6 流量。检测方法很简单：在 IPv6 测试页看是否显示你的真实运营商地址段。

四、软信号：时区、语言、字体

这几项不叫"泄漏"，但起到同样效果。IP 在洛杉矶、时区 UTC+8、语言 zh-CN、字体是中文 Windows 默认组合——这套组合比固定用一个差 IP 更可疑，因为它明确指向"伪装"。

细节可以看指纹浏览器配错 IP，防关联等于白做，那边把五层指纹和三条一致性铁律讲全了。

五、一次完整的泄漏自检（六步）

1. 出口 IP：确认 IP 检测页显示的国家、城市与预期一致。
2. DNS：解析器归属地必须与出口国家一致。
3. WebRTC：不出现真实公网 IP，也不暴露内网段。
4. IPv6：不出现与出口无关的地址。
5. 时区与语言：与 IP 所在城市匹配，不是只匹配国家。
6. 页面级验证：打开一个会显示访客信息的第三方统计站，交叉确认。

六步全过再登录账号。顺序反了——先登录再检测——等于已经把可疑信号发出去了。

六、都修好了还是不对？三个常见残留问题

• 分流规则漏网：客户端按域名/地区分流，目标站点恰好走了直连。检查规则列表，必要时改为全局。
• 系统代理 vs 应用代理：某些客户端只设了系统 HTTP 代理，不接管 UDP 和独立进程。用支持 TUN 模式的客户端更彻底。
• QUIC / HTTP3：走 UDP 443，部分代理默认不转发，导致回退或直连。可在浏览器禁用 QUIC 排除干扰。

结语

代理只解决"出口是谁"的问题，不解决"还有哪些通道在说话"。DNS、WebRTC、IPv6 三条旁路任何一条没关，前面的努力都会打折。

把这三条都处理干净，再配上一个归属真实、可长期固定的出口，整套环境才算立得住。需要住宅属性的固定出口，可以看双 ISP 家宽；上线前建议用IP 纯净度自测把归属与一致性一起验一遍。