WebRTC 地址泄漏
未检测通过 STUN 获取 WebRTC 实际使用的公网地址，按候选类型与同协议族的网页出口比较（IPv6 按 /64 比较）
LEAK CHECK
VPN 泄漏检测
检测 DNS 泄漏（DNS 泄露）、WebRTC 泄露、IPv6 泄漏与时区一致性，确认使用 VPN 或代理时，真实 IP 有没有暴露。
DNS 解析路径
未检测通过一次性域名观察浏览器触发的解析出口、ECS 子网及检测完整度。
IPv6 出口
未检测比较 IPv4 与 IPv6 出口的国家、运营商与网络类型，判断 IPv6 是否绕过了代理
多端点出口一致性
未检测同时从本站、IPv4 / IPv6 回显和 Cloudflare 读取出口 IP，比较各端点看到的是否一致
TLS 连接指纹
JA4 / JA3 — 你的客户端 TLS 握手特征
正在采集 TLS 握手指纹…
使用说明
什么是 IP 泄漏，为什么代理开着也会漏
「泄漏」指的是你以为流量都走了代理或 VPN，但某些请求绕过了它，直接从本地网络发出，把真实 IP 暴露给了对方。代理软件显示「已连接」并不代表所有流量都受它管辖。
DNS 泄漏
访问网站前，设备要先把域名解析成 IP。这一步如果没走代理，你的运营商 DNS 服务器就会看到你访问过哪些域名——即便后续连接本身是加密且经过代理的。
常见原因是系统层面的 DNS 设置优先于代理规则，或者代理软件本身没有接管 DNS 请求。
WebRTC 泄漏
WebRTC 是浏览器内建的点对点通信能力，视频通话和屏幕共享都靠它。为了建立直连，它会主动向 STUN 服务器询问「我的公网地址是什么」，这个请求可能绕过代理。
结果是：网页看到的 IP 是代理的，但通过 WebRTC 拿到的是你的真实 IP。这是最经典也最容易被忽略的一类泄漏。
IPv6 泄漏
很多代理只处理 IPv4。如果你的网络同时有 IPv6，而目标网站也支持，浏览器可能优先走 IPv6 直连——代理形同虚设。
判断方法很直接：如果这个页面同时显示了一个 IPv4 和一个 IPv6，而它们归属不同，说明存在双栈分流。
时区与一致性
严格说这不算泄漏，而是矛盾。系统时区、浏览器语言、IP 归属地三者应当自洽。IP 在美国而时区是 UTC+8，对风控系统是很强的信号——它不需要知道你的真实 IP，只需要知道你在伪装。
常见问题
检测显示没有泄漏，是不是就绝对安全了？
只能说明本次检测覆盖的这几条路径没有泄漏。浏览器插件、其它应用、系统更新都可能引入新的泄漏路径，换配置后建议重测。
怎么修 DNS 泄漏？
优先在代理软件里开启「DNS 由代理接管」或类似选项；其次在系统网络设置里把 DNS 指向代理提供的地址。改浏览器的加密 DNS 只能解决浏览器这一个进程。
WebRTC 要不要关掉？
不建议直接关掉：缺少 WebRTC 的 Chromium 本身就能被识别。用策略限制它走哪条路即可：Chrome / Edge 把企业策略 WebRtcIPHandling 设为 disable_non_proxied_udp，Brave 选「禁用非代理 UDP」，Firefox 在 about:config 打开 media.peerconnection.ice.proxy_only_if_behind_proxy；最稳妥的是代理客户端用 TUN 模式。
有 IPv6 泄漏怎么办？
两种做法：让代理同时接管 IPv6，或在系统网络设置里直接禁用 IPv6。后者更彻底，但会影响仅支持 IPv6 的服务。