DNS 泄漏
访问网站前,设备要先把域名解析成 IP。这一步如果没走代理,你的运营商 DNS 服务器就会看到你访问过哪些域名——即便后续连接本身是加密且经过代理的。
常见原因是系统层面的 DNS 设置优先于代理规则,或者代理软件本身没有接管 DNS 请求。
使用说明
「泄漏」指的是你以为流量都走了代理或 VPN,但某些请求绕过了它,直接从本地网络发出,把真实 IP 暴露给了对方。代理软件显示「已连接」并不代表所有流量都受它管辖。
访问网站前,设备要先把域名解析成 IP。这一步如果没走代理,你的运营商 DNS 服务器就会看到你访问过哪些域名——即便后续连接本身是加密且经过代理的。
常见原因是系统层面的 DNS 设置优先于代理规则,或者代理软件本身没有接管 DNS 请求。
WebRTC 是浏览器内建的点对点通信能力,视频通话和屏幕共享都靠它。为了建立直连,它会主动向 STUN 服务器询问「我的公网地址是什么」,这个请求可能绕过代理。
结果是:网页看到的 IP 是代理的,但通过 WebRTC 拿到的是你的真实 IP。这是最经典也最容易被忽略的一类泄漏。
很多代理只处理 IPv4。如果你的网络同时有 IPv6,而目标网站也支持,浏览器可能优先走 IPv6 直连——代理形同虚设。
判断方法很直接:如果这个页面同时显示了一个 IPv4 和一个 IPv6,而它们归属不同,说明存在双栈分流。
严格说这不算泄漏,而是矛盾。系统时区、浏览器语言、IP 归属地三者应当自洽。IP 在美国而时区是 UTC+8,对风控系统是很强的信号——它不需要知道你的真实 IP,只需要知道你在伪装。
只能说明本次检测覆盖的这几条路径没有泄漏。浏览器插件、其它应用、系统更新都可能引入新的泄漏路径,换配置后建议重测。
优先在代理软件里开启「DNS 由代理接管」或类似选项;其次在系统网络设置里把 DNS 指向代理提供的地址。改浏览器的加密 DNS 只能解决浏览器这一个进程。
Chrome 系可以装限制 WebRTC 的扩展;Firefox 在 about:config 里把 media.peerconnection.enabled 设为 false。注意关掉后视频通话类网站会不可用。
两种做法:让代理同时接管 IPv6,或在系统网络设置里直接禁用 IPv6。后者更彻底,但会影响仅支持 IPv6 的服务。