Appearance
解决科学上网 DNS 泄露全攻略 使用 ipleak.net 深度检测与消除定位暴露风险
⚡ Answer-First 核心速览
科学上网中的 DNS 泄露是指访问境外网站时，本地系统依然向境内运营商发送未加密的 DNS 查询，导致真实省份定位和访问历史直接暴露；通过 ipleak.net 检测，如果服务器列表中出现了中国电信、联通或移动的节点，即证实存在泄露；彻底杜绝泄露的工业级方案是开启客户端的 Fake-IP 模式，在本地直接为域名分配虚拟保留 IP，真实域名交由海外落地节点代理解析；配合境内外双栈 DoH 加密 DNS 分流，可以同时兼顾国内 CDN 极速直连与境外隐私防泄漏。
很多出海用户认为，只要在桌面客户端连接上了位于日本、香港或美国的代理节点，浏览器访问 IP 查询网站显示的是海外机房地址，自己的网络身份就处于完全匿名的状态。
现实网络交互中存在一个巨大的隐秘漏洞。当你访问网页时，数据内容本身确实通过加密隧道传输，但获取目标服务器 IP 的“寻址过程”（即域名解析 DNS 请求），却可能悄悄顺着本地运营商的未加密通道流出。哪怕你的出口 IP 显示在旧金山，你所访问的每一个海外域名、请求发生的具体时间戳，依然被本地宽带运营商的机房系统一览无余。
掌握 DNS 泄露的物理成因，学会使用权威工具进行深度排查，并利用现代代理内核的 Fake-IP 机制与 DoH 双栈架构，是每一位重视数据安全的工程师的必修功课。
DNS 泄露的物理成因与安全威胁
要理解泄露是如何发生的，必须把网络访问拆分为“域名寻址”和“数据传输”两个互相独立的通信阶段。
text
[正常访问下的 DNS 严重泄露链路]
用户在浏览器输入: https://twitter.com
│
├── 1. 发起 DNS 查询请求 (UDP 53 端口明文)
│ └──> [绕过代理客户端] ──> 本地路由器 ──> [境内省份运营商 DNS (电信/联通/移动)]
│ │ (留存查询日志: 发现该宽带正在访问推特)
│ ▼
│ 返回被污染的黑洞 IP 或真实海外 IP
│
└── 2. 发起 HTTPS 数据握手
└──> [进入客户端代理隧道] ──> 加密送往海外落地服务器 (由于第一步泄露，身份已暴露)
-----------------------------------------------------------------------------------------
[Fake-IP 模式下的端到端零泄露链路]
用户在浏览器输入: https://twitter.com
│
├── 1. 客户端本地虚拟 DNS 引擎拦截请求
│ ├── 从 198.18.0.0/15 保留网段分配虚拟 IP (如 198.18.0.45)
│ ├── 建立内存映射表: 198.18.0.45 <===> twitter.com (耗时 0ms)
│ └── 将 198.18.0.45 立即返回给浏览器 (完全不向外部公网发送任何 DNS 包)
│
└── 2. 浏览器向 198.18.0.45 发起 TCP 连接
├── 客户端截获该连接，查表还原出原始域名 twitter.com
├── 将纯净域名打包进 Trojan/Shadowsocks 加密隧道
└── 投递至海外落地服务器代理解析 (真实 DNS 查询完全发生在海外机房)1. 什么是 DNS 泄露
所谓 DNS 泄露（DNS Leak），指的是在启用了出海代理或 VPN 的情况下，操作系统发起的域名解析请求没有经过加密隧道保护，依然经由本地物理网络向当地互联网服务提供商（ISP）的默认 DNS 服务器发送。
这种失误会产生极其严重的隐私暴露。 本地运营商的递归 DNS 服务器会忠实记录下每一个请求源 IP（即你的真实宽带公网 IP）在什么时间查询了什么域名。 对于某些深度依赖地理位置风控的国际平台（如 PayPal、英国线上银行、Netflix 流媒体平台），服务端不仅会校验你的 TCP 出口 IP，还会通过浏览器脚本探查你的 DNS 递归解析服务器归属。 如果你展示的出口 IP 位于洛杉矶，但向网站发起权威 DNS 解析请求的服务器却位于中国广东电信，系统会瞬间识别出你使用了代理翻墙工具，并立即将账号列入风控黑名单。
2. EDNS Client Subnet (ECS) 导致的定位穿透
除了系统默认 DNS 走漏，现代 DNS 协议扩展中的 EDNS Client Subnet（ECS，RFC 7871）也是导致定位泄露的推手。
ECS 技术最初是为了让大型 CDN 网络实现就近接入。当用户向支持 ECS 的公共 DNS 服务器发起解析请求时，该服务器会把用户客户端的前缀 IP（例如截取你的本地真实宽带 IP 前 24 位）附加在查询报文中，一并转发给目标网站的权威 DNS 服务器。 这样一来，权威 DNS 就能获知发起请求的网民物理位置在哪个城市，从而返回距离你最近的 CDN 节点。 但在出海场景下，如果你的 DNS 请求混入了境内中继，ECS 机制会把你的真实省份前缀直接出卖给海外目标服务器，导致匿名防御瞬间瓦解。
3. Windows 多宿主智能名称解析（SMNR）缺陷
Windows 系统自带的“多宿主名称解析”（Smart Multi-Homed Name Resolution）机制，是桌面端 DNS 泄露的高发地带。
当电脑连接了有线局域网、Wi-Fi，同时又启用了虚拟网卡或 VPN 时，Windows 系统会认定当前环境拥有多个并行的网络适配器。 为了追求极致的网页打开速度，Windows 会向所有网卡配置的每一个 DNS 服务器，同时并发广播发送 DNS 查询请求。 哪一个 DNS 服务器返回速度最快，Windows 就采纳哪一个结果，并丢弃其他响应。 由于本地电信或联通的 DNS 服务器物理距离极近，通常在 5 到 15 毫秒内就能做出响应，而经过加密代理发往海外的 DNS 往往需要几十甚至上百毫秒，结果就是 Windows 永远优先采用境内运营商返回的解析结果。这不仅导致了 DNS 记录的严重走漏，更经常引发惨烈的域名劫持与 DNS 投毒污染。
使用 ipleak.net 深度检测泄露实战
要确认当前网络环境是否存在 DNS 泄露，不能单凭主观感觉，必须使用专业的无缓存探针工具进行动态压力测试。
1. 权威检测平台与探测原理解析
目前网络安全界公认最权威的检测平台是 ipleak.net 与 browserleaks.com。
这些专业平台的工作原理极其精妙： 当你打开测试页面时，网页前端的 JavaScript 脚本会在毫秒级时间内，动态随机生成几十个形如 a7x9q2-test.ipleak.net 的独一无二的子域名，并强制你的浏览器向本地系统发起解析请求。 由于这些随机子域名在全世界任何公共 DNS 缓存中都不可能存在，本地系统必须层层向上迭代查询，最终一定会打到 ipleak.net 官方架设的权威根服务器上。 权威服务器在收到请求的一瞬间，记录下究竟是公网上的哪一台递归 DNS 服务器向它发出了询问，并将这台 DNS 服务器的 IP、运营商名称和国家国旗实时反馈在你的网页屏幕上。
2. 泄露判定标准与图谱解读
在开启代理客户端后，打开 https://ipleak.net/，重点观察页面中部的 DNS Addresses 结果检测区。
判定为严重泄露的特征
如果检测出的 DNS 列表里面，赫然出现了中国国旗（CN），并且运营商名称标明为 China Telecom、China Unicom、China Mobile 或 114.114.114.114，这意味着你的浏览器发出的所有海外域名查询正在被境内运营商实时审计，存在 100% 的 DNS 泄露。
判定为合格零泄露的标准
在测试结果中，DNS 列表中展示的服务器 IP 数量通常只有 1 到 3 个，且地理位置全部与你当前选中的代理节点机房所在国家一致，或者显示为知名的中立海外隐私安全 DNS（如 Cloudflare 的 1.1.1.1、Google 的 8.8.8.8）。绝对看不到任何一个带有中国大陆地域标签的服务器，这才算达到了真正安全合规的零泄露标准。
3. 关联排查：WebRTC 与 IPv6 隐蔽泄露
在排查 DNS 的同时，还需要留意 ipleak 页面上的另外两个高危漏洞。
WebRTC 泄露
WebRTC 是现代浏览器用于网页端音视频实时通信的底层接口。为了建立 P2P 视频连线，WebRTC 会绕过常规的应用层代理，直接调用系统底层网络 Socket 向 STUN 服务器发起探测，从而获取并广播电脑的真实局域网 IP 与本地宽带公网 IP。 如果 ipleak 页面底部的 WebRTC 检测区展示出了你的真实公网 IP，需要在浏览器中安装扩展（如 WebRTC Control）或者在客户端中开启强制 TUN 模式予以阻断。
IPv6 双栈泄露
国内很多家庭宽带与手机热点已经全面普及了 IPv6。但绝大多数机场的代理节点仅支持 IPv4 转发，缺乏对 IPv6 的封装能力。 当访问一个同时具备 IPv4 和 IPv6 记录的海外网站时，操作系统可能会优先通过未受代理保护的本地原生 IPv6 通道发起连接，导致真实 IPv6 地址外泄。在客户端设置中直接关闭 IPv6 解析（ipv6: false），是杜绝此类泄露最稳妥的工程手段。
消除泄露方案一：Fake-IP 模式工作机制与原理深度解析
在消除 DNS 泄露的技术方案中，Fake-IP 是最具颠覆性、执行最彻底的一项创新。
1. 传统 Redir-Host 模式的死结
在 Fake-IP 普及之前，客户端普遍使用传统的 Redir-Host 模式。 在 Redir-Host 模式下，当应用程序请求 youtube.com 时，客户端本地的 DNS 模块必须先跨越公网，通过加密通道向海外的真实公共 DNS 发起一次网络请求，拿到真实的目标机房 IP（例如 172.217.160.78），再把真实 IP 返回给浏览器。
这种流程存在两个天然缺陷：
- 额外的网络往返延迟（RTT）。每次打开一个从没访问过的海外网页，浏览器都必须硬等这几十到几百毫秒的真实 DNS 解析往返，用户会明显感知到网页在初次加载时有长达数秒的“白屏卡顿”。
- 复杂的分流误判与泄露隐患。如果分流规则稍微配置不当，或者使用了某些老旧驱动，本地系统依然有可能跳过客户端直接向本地 DNS 查询，造成泄露。
2. Fake-IP 的零泄露实现
Fake-IP 模式完全跳出了“必须先拿到真实 IP 才能发起连接”的思维定势。
text
[浏览器应用态] [Mihomo 本地虚拟 DNS] [远程代理节点]
│ │ │
├── 1. 查询 google.com 的 A 记录 ───────────>│ │
│ │ (内部哈希表分配 198.18.0.2) │
│ │ (记录: 198.18.0.2=google.com)│
│<── 2. 立即返回 IP: 198.18.0.2 (0毫秒响应)──┤ │
│ │ │
├── 3. 发起对 198.18.0.2 的 TCP 握手 ────────>│ │
│ │ (截获三层数据包) │
│ │ (查表还原原始域名: google.com) │
│ ├── 4. 封装加密隧道，传输域名 ──>│
│ │ (不包含任何本地 IP 痕迹) │
│ │ ├── 5. 在海外机房发起真实解析并建立连接根据 RFC 2544 国际网络标准，198.18.0.0/15 被划定为基准网络互联测试的保留专用网段，在公网互联网中永远不会被分配给任何真实的物理服务器。Fake-IP 机制正是利用了这块纯净的虚拟地址空间。
当操作系统发来任何域名的 DNS 解析请求时，Fake-IP 模块根本不对外发送任何网络查询。 它在本地操作系统的内存中，以微秒级的速度从保留池中抽取一个虚拟 IP（例如 198.18.0.2），建立一条键值映射 198.18.0.2 <-> google.com，随后立即把虚拟 IP 交付给发起请求的软件。
对于浏览器来说，它拿到了一个完全合法的 IPv4 地址，于是心满意足地向 198.18.0.2 发起标准的 TCP 握手。 数据包一旦发出，代理客户端的内核（或 TUN 虚拟网卡）在网络驱动层立刻将这个包截获。 内核读取到目标 IP 为 198.18.0.2，在内存哈希表中反向一查，瞬间得知调用方的真实意图是要访问 google.com。 客户端直接把原始域名 google.com 连同 TCP 载荷，打包送进加密隧道直飞海外。真正的域名解析全部发生在几千公里外的海外机房中。
在整个生命周期中，你的电脑物理网卡上没有向公网发出过哪怕一个字节的明文 DNS 查询数据包。本地运营商既无法嗅探你的目标域名，更不可能实施任何污染。DNS 泄露的物理基础被直接抹除。
3. fake-ip-filter 过滤名单的必要性
Fake-IP 虽然优雅，但在面对某些特殊的本地软件时需要做出豁免。这就是 fake-ip-filter 白名单的作用。
某些特定应用（如 Windows 系统网络连通性探测 NCSI、NTP 网络授时协议、局域网设备组网以及严格校验服务器真实 IP 签名的极个别国产金融客户端），一旦发现解析出来的地址是 198.18.x.x，会误判定当前没有连接公网而报错。 因此，必须在配置文件中通过 fake-ip-filter，把局域网域名（*.lan、*.local）和微软状态探测域名排除在 Fake-IP 池之外，强制让它们走常规的真实解析。
消除泄露方案二：DoH (DNS-over-HTTPS) 加密双栈架构设计
许多新手走入另一个极端，开启出海工具后，直接把全系统的 DNS 服务器全部强行修改为 Cloudflare 的 1.1.1.1 或 Google 的 8.8.8.8。这虽然杜绝了境内运营商监听，但会引发灾难性的国内网络体验劣化。
1. 全盘海外 DNS 的严重副作用
中国大陆的互联网基础设施高度依赖智能 CDN 分流。 当你访问淘宝、京东、腾讯视频或网易云音乐时，这些国内服务在全国几十个省份部署了成千上万个边缘机房。 如果国内域名全被抛给海外的 8.8.8.8 进行解析，Google 的服务器位于海外，它根本无法得知你真实的本地网络归属，只能把你引导到跨国边缘节点，或者返回位于香港甚至美国的 CDN IP。 其后果就是国内网页加载缓慢、高清视频频繁卡顿缓冲，原本千兆的家庭宽带体验大幅缩水。
2. 双栈分流架构的黄金准则
解决矛盾的工程方案是构建基于分流规则的 DoH 加密双栈 DNS 系统。
text
[应用程序发出 DNS 查询]
│
▼
[Mihomo 智能 DNS 分流分发器]
│
┌────────────────────────┴────────────────────────┐
▼ ▼
【匹配国内域名】 【匹配海外域名】
(通过 Geosite:cn 规则) (通过 Geosite:geolocation-!cn)
│ │
▼ ▼
[国内清白安全 DNS 组] [海外纯净加密 DNS 组]
(阿里/腾讯 提供的加密 DoH 节点) (Cloudflare / Google 提供的海外 DoH 节点)
│ │
│ (直连物理网卡，超低延迟) │ (强制通过节点加密代理隧道转发)
▼ ▼
获取最优就近国内 CDN IP 彻底隔绝境内污染，实现零泄露双栈 DNS 体系把解析工作精准划分为两大阵营：
- 境内国内组（Default / Direct DNS）。使用阿里巴巴提供的
https://dns.alidns.com/dns-query或腾讯提供的https://doh.pub/dns-query。通过现代标准的 HTTPS 加密协议进行查询，运营商在中间链路上无法伪造篡改，同时这些服务器能够精准识别你的本地宽带线路，返回延迟最低的大陆 CDN 节点。 - 海外代理组（Proxy DNS）。使用 Cloudflare 的
https://cloudflare-dns.com/dns-query或 Google 的https://dns.google/dns-query。在客户端内部配置中，强制声明该 DNS 请求本身必须通过选中的出海代理节点进行转发（detour或走代理策略组）。解析动作完全在加密隧道保护下执行，境内防火墙根本无法拦截。
现代 DNS 工作机制横向技术对比
下表将出海网络演进过程中出现的四种主要 DNS 处理方式进行全方位对比。
| 技术维度 | 传统本地明文 DNS | 远程 Redir-Host 模式 | 现代 Fake-IP 模式 | 规则分流 DoH 双栈模式 |
|---|---|---|---|---|
| 传输层协议与端口 | 标准 UDP / TCP 53 端口 | 加密或普通 UDP 端口 | 纯本地内存分配，无网络端口 | 基于 TLS 的 HTTPS 443 端口 |
| 抗运营商监听能力 | 零（明文报文完全裸奔） | 较好（走加密隧道） | 完美（无任何外发解析包） | 极佳（标准 HTTPS 流量特征） |
| 首包解析延迟 | 极低（本地局域网 5-15ms） | 极高（需等待海外往返 150-300ms） | 绝对零延迟（本地查表 0ms） | 国内极低，海外完全免除等待 |
| 国内 CDN 加速友好度 | 良好（易受污染影响） | 较差（海外解析易定位错误） | 配合规则分流可达完美 | 完美（国内就近调度，海外精准覆盖） |
| 配置维护门槛 | 极低（无需任何干预） | 适中 | 适中（需维护避坑白名单） | 较高（需编写分流策略规则） |
| ipleak 检测安全性 | 必然爆出大量境内运营商 IP | 偶发由于驱动缺陷产生漏包 | 完美杜绝泄露，全绿通过 | 完美杜绝泄露，全绿通过 |
从工程演进角度来看，以 Fake-IP 作为核心基础，配合规则分流 DoH 双栈，是当前科学出海领域防御 DNS 泄露的最优解。
生产级实战配置：Clash Verge Rev / Mihomo 无泄露 DNS 模块
下面提供一份经过严格压力测试、直接用于 Clash Verge Rev / Mihomo 的无泄露生产级 DNS 配置代码片段：
yaml
# ==========================================
# 生产级防 DNS 泄露双栈配置模块
# ==========================================
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
# 开启现代 Fake-IP 模式，彻底杜绝本地解析外泄
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
# 基础 Fake-IP 过滤清单，避免特定服务异常
fake-ip-filter:
- "*.lan"
- "*.local"
- "*.localdomain"
- "time.*.com"
- "ntp.*.com"
- "+.market.xiaomi.com"
- "connectivitycheck.gstatic.com"
- "*.msftconnecttest.com"
- "*.msftncsi.com"
# 默认基础解析服务器 (用于解析 DoH 自身的域名)
default-nameserver:
- 223.5.5.5
- 119.29.29.29
# 国内常规直连解析组 (采用加密 DoH，防止本地污染)
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
# 备用容灾与海外兜底解析组
fallback:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
# 声明 fallback 组判定为海外 IP 的筛选条件
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
# 策略路由规则分流 (核心防泄露机制)
nameserver-policy:
# 匹配中国大陆地理域名，强制走国内加密 DoH
"geosite:cn":
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
# 匹配海外受限服务，强制走境外纯净 DoH
"geosite:geolocation-!cn":
- https://1.1.1.1/dns-query
- https://dns.google/dns-query关键配置项逻辑剖析
enhanced-mode: fake-ip是整套防御体系的开关。它启动了本地虚拟 IP 映射，截断了所有常规的操作系统主动查询通道。nameserver-policy实现了域名级的精准分流。当一个国内域名（如jd.com）进入时，它匹配到geosite:cn，被安全投递给阿里的 DoH 解析，既保证了国内 CDN 就近分配，又通过 HTTPS 加密防范了本地运营商的侧信道嗅探；当海外域名进入时，通过策略组分发给境外节点解析。default-nameserver配置了两台纯 IP 形式的国内公共 DNS。它们的作用十分纯粹，仅仅用于在客户端刚启动、网络尚未完全就绪时，解析dns.alidns.com等 DoH 域名自身的 IP 地址，避免产生解析死锁循环。
常见问题深度解答
Q1 为什么开启代理后在命令行执行 nslookup 查到的总是 198.18 开头的 IP
这是开启 Fake-IP 模式后的必然现象，完全属于正常运行状态。 当你在 CMD 或 PowerShell 中运行 nslookup google.com 时，Windows 系统向本地代理客户端的虚拟 DNS 模块发起了询问。客户端按照 Fake-IP 的规范，立即从保留地址池分配了一个 198.18.x.x 的虚拟地址并返回给命令行工具。 你看到的并不是 Google 在公网上的真实物理服务器 IP，而是客户端临时签发给你本地使用的“连接凭证代码”。你的软件只要向这个凭证 IP 发起连接，客户端内核就能精确还原出目标域名并正常转发。
Q2 为什么有时候使用 ipleak 检测会显示出很多个不同的 DNS 服务器
这取决于你的代理节点所接入的基础设施。 很多大型海外托管机房（如 Cloudflare、AWS、Linode、DigitalOcean）在内部搭建了具有分布式负载均衡特性的 Anycast 递归 DNS 集群。 当你发起检测请求时，机房可能会将你的并发查询随机分配到集群内部的三四台物理子节点上执行。只要这些服务器全部属于机房所在国家（或者全属于 Cloudflare/Google 等可信厂商），并且没有出现哪怕一个带有中国大陆地域标签的境内节点，就属于绝对健康的零泄露状态。
Q3 在路由器上配置透明代理为什么更容易发生 DNS 泄露
因为家庭路由器承担着整个局域网的网关与 DHCP 调度重任。 如果软路由固件（如 OpenWrt、OpenClash）的防火墙规则（iptables / nftables）配置不严密，局域网中某些安卓手机、电视盒子或者智能家居设备可能会硬编码使用公共 DNS（如直接写死 8.8.8.8 或当地运营商的真实 DNS）。 如果路由器的防火墙没有配置强行的 53 端口流量重定向（DNS Hijacking），这些设备发出的明文 DNS 数据包就会直接绕过代理内核，顺着 WAN 口物理网卡直出互联网，从而导致全屋设备的 DNS 大规模走漏。在软路由上必须开启“强制劫持所有 53 端口查询”开关。
Q4 开启 DoH 加密解析会不会导致看视频和下载速度变慢
不会。DNS 解析仅仅负责在 TCP 建立连接的最开始一瞬间，把域名翻译为 IP 地址。 一旦握手完成，后续几百兆甚至几十吉字节的高清视频流和下载数据，全部走的是建立好的 TCP 或 UDP 加密通道，跟 DNS 服务器不再发生任何交互。 DoH 引入的轻微 TLS 握手开销通常只有几毫秒，并且现代客户端内部都带有高效的本地 DNS 内存缓存机制，第二次访问同一域名时直接从内存秒读，对实际的数据吞吐量和下载峰值速率毫无影响。