DNS 解析防污染与防泄漏实战：DoH / DoT 与 Fake-IP 的最优参数组合

站点：AirPick · 机场推荐（airpick.co） · 分类：使用教程 / 配置调优 · 更新：2026

一、TL;DR：三句话结论

DNS 泄漏的本质不是"配置漏了"，而是"分流策略与解析路径没有对齐"。绝大多数人的 5% 泄漏率，来自 nameserver 与 fallback 的判定逻辑冲突，而不是加密方式选错了。
DoH 优先于 DoT。53/853 端口长期处于 QoS 与丢包劣化区间，443 端口的 DoH 流量与正常 HTTPS 混流，抗干扰能力高出 1 到 2 个数量级。国内用阿里 / 腾讯 DoH 做国内域名解析，海外走 Cloudflare / Google DoH 直达，是 2026 年性价比最高的组合。
Fake-IP 是"防泄漏"的放大器，也是"泄漏"的放大器。配好了，客户端拿到的是 198.18.0.0/16 段的占位地址，真实域名在代理端才被解析，污染与泄漏同时归零；配错了，Fake-IP 占位地址会被回传到上游 DNS，造成大面积解析失败与连接超时。

💡 👑 2026 全网综合第一主推 · 【光速云】读者专享特惠通道：
IEPL 企业级内网专线 + 全球IPLC，单节点最高 2.5Gbps，全节点 x1 无倍率，原生解锁 ChatGPT / Claude / Netflix 全区：

8折立减AMM复制 📋

直达光速云官网 ↗

👉 查看【光速云】实验室 2026 最新测速报告与深度评测 →

需要说清楚一点：本文所有 DNS 参数调优，都建立在底层传输链路本身可用的前提下。如果落地节点的国际出口本身拥塞，再完美的 DoH 配置也救不了 300ms 的首包延迟。关于链路层的选型，可以对照 /tech/ 里的 BGP 与 IEPL 专线原理篇一起看。

二、底层机理：DNS 污染到底发生在哪一层

要把配置调对，得先搞清楚三个物理事实。

事实一：无状态 UDP 53 天生可以被抢答。 一次标准 DNS 查询是"发一个 UDP 包、等一个 UDP 包"，没有握手、没有序列号校验、没有源端口强绑定（很多旧实现连随机化都不做）。这意味着链路上任何一台设备只要在真实应答到达前，抢先塞回一个构造好的应答包，客户端就会采信。抢答的伪造应答通常带一个极小的 TTL，客户端缓存几秒即失效，于是每次连接都重新查询、每次都拿到污染 IP——表现就是"能 ping 通但连不上"或"解析到奇怪 IP"。

事实二：加密不等于免疫，但能消灭"中间人抢答"。 DoH（RFC 8484）把 DNS 报文塞进 HTTPS 的请求体，走 443；DoT（RFC 7858）走 853，直接套一层 TLS；DoQ（RFC 9250）走 QUIC。三者的共同点是：应答具备密码学完整性，链路中间无法凭空伪造一个合法应答。攻击者能做的只剩下丢包、阻断握手、或对 TLS 握手进行 RST 注入。所以在 2026 年的实测环境里，DoH 的成功率显著高于 DoT——因为 443 端口的 TLS 流量和每天几十 GB 的正常 HTTPS 流量长得一模一样，阻断成本极高。

事实三：Fake-IP 把"解析"从客户端搬到了代理端。 开启 Fake-IP 后，本地 DNS 对所有非白名单域名立即返回一个 198.18.0.0/16 段的假地址，不发起任何真实查询。客户端拿着这个假地址去建连，代理内核根据连接记录反查回原始域名，再由代理节点在远端发起真实解析。这一步的工程价值极高：客户端全程没有发出任何真实域名的 DNS 请求，污染源头直接被掐断；同时因为远端解析发生在落地机房（多数是 IDC 直连 DNS 或 Cloudflare 就近解析），拿到的 CDN 节点也最接近真实用户位置。

但代价是：Fake-IP 与某些强依赖真实 IP 的应用天然冲突。VPN 类应用、部分游戏反作弊、局域网设备发现（mDNS）、以及使用 IP 直连而非域名的老式客户端，都可能因为拿到 198.18.x.x 而失效。这就是 fake-ip-filter 存在的意义。

三、核心参数对比矩阵

下表把 2026 年主流的六种解析方案，按十个量化维度做横向对照。延迟数据取自国内三网（电信 / 联通 / 移动）各 100 次采样的 P50 值，仅代表趋势。

维度	明文 UDP 53	DoT (853)	DoH (443)	DoQ (QUIC 853)	国内 DoH 直连	代理远端 Fake-IP
抗抢答污染	❌ 无效	✅ 有效	✅ 有效	✅ 有效	⚠️ 仅国内域名	✅ 完全免疫
抗端口 QoS 限速	❌ 高概率劣化	⚠️ 中等	✅ 极低	⚠️ 中等	✅ 低	—
握手开销（RTT）	0	1~2	1~2（可复用）	0~1	1~2	0（本地秒回）
国内 P50 延迟	8~15 ms	25~60 ms	15~40 ms	20~70 ms	15~40 ms	连接首次略增
缓存命中表现	好	好	优秀（HTTP 层可复用）	一般	优秀	优秀
隐私（上游可见性）	全明文	加密	加密	加密	服务商可记日志	代理侧可见
配置复杂度	极低	低	中	中高	低	中
泄漏风险	极高	低	低	低	中（境内域名外泄）	极低
IPv6 泄漏	常见	需显式关闭	需显式关闭	需显式关闭	需显式关闭	需显式关闭
推荐场景	仅内网	备用	主力	尝鲜	国内域名分流	海外域名主力

结论很直白：主力 = DoH + Fake-IP，国内域名用国内 DoH 分流，海外域名交给 Fake-IP + 代理远端解析。 DoT 留作备用（部分地区 853 端口反而未被限速），明文 53 只保留给 default-nameserver 这个引导层。

四、人群与场景选型

场景 A：纯轻量用户（只刷网页、看视频） 不需要 Fake-IP。国内 DoH 做 nameserver，海外 DoH 做 fallback，打开 fallback-filter 的 geoip 判定即可。配置量最小，误伤率最低。

场景 B：流媒体 + AI 重度用户（Netflix / ChatGPT / Claude） 必须开 Fake-IP。这类服务的风控会看"你的 DNS 解析地"和"你的实际出口地"是否一致，不一致极易触发人机验证或区域锁。Fake-IP + 远端解析能让两者天然一致。可参考 /scenario/chatgpt/ 的风控口径说明。

场景 C：跨境办公 / 开发（GitHub、npm、Docker Hub） 建议 nameserver-policy 精细化：把 geosite:geolocation-!cn 全量交给海外 DoH，把企业内网域名显式走本地 DNS，避免代理把内网请求带走。

场景 D：多设备家庭网络 在软路由上跑 mihomo / sing-box 做局域网 DNS，所有终端 DNS 服务器 指向网关。此时必须在路由器防火墙层做 DNS 劫持（DNAT 53 到网关），否则部分设备写死的 DNS 会成为泄漏通道。

五、分客户端实操配置

5.1 mihomo / Clash.Meta（推荐基线）

yaml

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false                  # 关键：不关 IPv6 是最常见的泄漏来源
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.msftconnecttest.com"
    - "+.stun.*.*"
  default-nameserver:          # 引导层，只用于解析下面 DoH 的域名
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:     # 节点域名解析，走国内明文最稳
    - 223.5.5.5
    - 119.29.29.29
  nameserver-policy:
    "geosite:cn": [https://dns.alidns.com/dns-query, https://doh.pub/dns-query]
    "geosite:geolocation-!cn": [https://1.1.1.1/dns-query, https://dns.google/dns-query]
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

三个容易踩的坑：

proxy-server-nameserver 千万别写成海外 DoH。节点域名一旦被代理自己解析，会造成"先有鸡还是先有蛋"的死循环，表现是启动后节点全部超时。
default-nameserver 必须是 IP 形式，不能是域名形式。它只负责解析 DoH 服务商自身的域名。
ipv6: false 要配合系统层一起关。只关配置不关系统，AAAA 记录仍可能从系统解析器泄漏出去。

5.2 sing-box

json

{
  "dns": {
    "servers": [
      { "tag": "cn", "address": "https://dns.alidns.com/dns-query", "detour": "direct" },
      { "tag": "remote", "address": "https://1.1.1.1/dns-query", "detour": "proxy" },
      { "tag": "local", "address": "223.5.5.5", "detour": "direct" }
    ],
    "rules": [
      { "rule_set": "geosite-cn", "server": "cn" },
      { "rule_set": "geosite-geolocation-!cn", "server": "remote" }
    ],
    "final": "remote",
    "strategy": "ipv4_only",
    "independent_cache": true
  }
}

注意 detour 字段：海外 DoH 的 detour 指向代理出站，这样 DNS 请求本身也走加密隧道，双重保险；国内 DoH 的 detour 指向 direct，避免国内解析绕一圈出国再回来。

5.3 移动端（Android / iOS）

Android 用户：系统设置里的"私人 DNS"填 dns.alidns.com（DoT）或直接用客户端内置 DNS。不要同时开系统私人 DNS 和客户端 Fake-IP，两者会打架。
iOS：Shadowrocket / Stash 类客户端建议把 DNS 设为客户端接管，关闭系统的"低数据模式"（会干扰长连接 DNS 缓存）。
无论哪个平台，关闭运营商 Wi-Fi 助手 / 智能网络切换，这类功能会在后台偷偷走明文 DNS。

六、抓包排障诊断手册

配置完不放心？用下面几条命令直接验证。

第一步：确认基础解析是否正常

bash

dig @223.5.5.5 www.taobao.com +short
dig @1.1.1.1 www.google.com +short

若第二条返回的是 31.13.x.x、59.24.x.x 之类的异常国内 IP，说明明文 53 已被污染——这正好反证了你必须走 DoH。

第二步：验证 DoH 端点连通性

bash

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
  "https://1.1.1.1/dns-query?name=example.com&type=A" \
  -H "accept: application/dns-json"

返回 200 且耗时在合理区间即为通。若返回 000 或超时，说明 443 到该 IP 的链路有问题，换 https://dns.google/dns-query 再试。

第三步：验证出口 IP 与 DNS 解析地是否一致

bash

dig @8.8.8.8 o-o.myaddr.l.google.com TXT +short
curl -s https://1.1.1.1/cdn-cgi/trace | grep -E "ip=|loc=|colo="

第一条返回的是 Google 看到的你的源 IP，第二条返回 Cloudflare 看到的位置码（colo）。如果 colo 显示的是香港/新加坡，而你的代理节点在日本，说明链路绕路了；如果返回的 IP 与你的代理节点 IP 不一致，说明存在真实 IP 泄漏。

第四步：路径质量诊断

bash

mtr -rwzc 100 1.1.1.1
tcping -x 5 8.8.8.8 53
tcping -x 5 1.1.1.1 443

对比 53 与 443 的丢包率。如果 53 丢包明显高于 443，直接坐实了端口 QoS 劣化，DoH 是唯一解。

第五步：系统层 DNS 泄漏检查

bash

# macOS
scutil --dns | grep "nameserver\[0\]"
# Linux
resolvectl status | grep -A2 "DNS Servers"
# Windows
ipconfig /all | findstr /i "DNS Servers"

若这里出现运营商 DNS（如 202.96.x.x），说明系统解析器没有被完全接管。

判定速查表

现象	高概率原因	处置
部分域名解析超时，其余正常	`fallback` 与 `nameserver` 判定冲突	补全 `fallback-filter.ipcidr`
全站解析到 `198.18.x.x` 但无法连接	Fake-IP 生效但代理未接管连接	检查 TUN / 系统代理是否开启
启动后所有节点超时	`proxy-server-nameserver` 配成了海外 DoH	改回国内明文 IP
视频站显示错误地区	DNS 解析地与出口地不一致	开 Fake-IP，走远端解析
内网 NAS / 打印机找不到	Fake-IP 劫持了 `.lan` / `.local`	加入 `fake-ip-filter`
移动网络下正常，Wi-Fi 下泄漏	路由器下发了运营商 DNS	路由器层做 53 端口 DNAT 劫持
DNS 正常但网页打不开	MTU 问题，非 DNS 问题	调 `tun.mtu` 至 1400 附近测试

七、行业避坑矩阵

宣传话术	真实含义	识别方法
"全程 DNS 加密，零泄漏"	只加密了查询，没做分流策略	查配置是否含 `nameserver-policy` 或 `detour`
"原生解锁 Netflix / ChatGPT"	多数只是 DNS 解锁，非原生 IP	用 `curl cdn-cgi/trace` 看 colo 与 ip 归属
"DoH 加速，解析快 10 倍"	营销话术，DoH 比明文慢是常态	实测握手 RTT，别信绝对倍数
"公共 DNS 免费无限用"	免费公共 DoH 普遍有 QPS 限流	高频查询下会返回 SERVFAIL
"不限速不限量"	通常指不额外限速，非不超售	晚高峰 20:00–23:00 单线程实测
"支持全协议"	可能只是支持协议名，不保证可用	逐协议实测握手成功率

关于"超售"这件事，最可靠的验证方式不是看商家页面，而是看晚高峰的 DNS 查询成功率。DNS 是链路上最轻的请求，如果连 DNS 查询都要重试三次才通，那这个节点的带宽水位已经接近饱和了。

八、常见问题 FAQ

Q1：DoH 和 DoT 到底选哪个？ 优先 DoH。853 端口在国内多地存在确定性限速，443 端口因与海量 HTTPS 共享，难以被针对性处理。DoT 建议只作为 DoH 全挂时的备用项。

Q2：为什么我开了 Fake-IP 之后速度反而变慢了？ 大概率是 fake-ip-filter 没配全，导致代理在做不必要的域名回查。另外首包会多一次"假 IP → 域名"的反查，冷启动略慢属于正常，热连接下来应当与直连持平。

Q3：国内 DNS 用阿里的还是腾讯的？ 两者在国内解析质量接近。阿里 DoH 端点 dns.alidns.com/dns-query，腾讯 doh.pub/dns-query。建议两个都配上做并发，任一故障另一个兜底。真正的差别在于 CDN 调度精度，南方电信偏阿里、北方联通腾讯表现更稳。

Q4：如何彻底解决 DNS 泄漏？ 三步：① 客户端开启 Fake-IP，让客户端不再发起真实查询；② 系统层关闭 IPv6 或强制 IPv6 走代理；③ 在网关层做 53 端口 DNAT 劫持，堵死写死 DNS 的设备。三步齐备后，理论上泄漏面为零。

Q5：Cloudflare 的 1.1.1.1 和 1.0.0.1 有什么区别？ 同一个 anycast 集群的两个入口地址，功能完全相同。1.1.1.1 在某些网络下更容易被识别，可尝试 1.0.0.1 或 DoH 域名形式 cloudflare-dns.com。

Q6：DNS 查询正常，为什么还是打不开某些网站？ 排查顺序应是"DNS → TCP → TLS → 应用"。先用 tcping 确认端口通，再用 curl -v 看 TLS 握手是否完整。TLS 阶段被重置属于链路层问题，不是 DNS 问题。相关链路选型见 /tech/。

Q7：节点订阅里的 DNS 配置要手动改吗？ 建议改。多数机场订阅为了兼容性会给出保守配置（明文 53 + redir-host），这在 2026 年的环境下已经不够用。可参考 /tutorial/ 里的配置覆盖方法，保留节点信息、替换 DNS 段落。

九、延伸阅读

链路层原理与专线选型：IEPL / IPLC 与 BGP 中转的技术差异
配置总入口与版本差异：使用教程总览
客户端配置合集：配置调优
流媒体解锁实测：Netflix 全区解锁判定方法
AI 服务连通性：ChatGPT / Claude 连通与风控说明
节点实测数据：光速云 2026 实验室测速报告
全部评测索引：机场评测库
常见故障自助：帮助中心

十、写在最后

DNS 这一层，说穿了就一句话：让查询走对路，让解析落在对的地方。

加密（DoH）解决的是"应答能不能被伪造"，Fake-IP 解决的是"查询该不该在客户端发生"，分流策略解决的是"国内域名别绕远路"。三件事各司其职，缺一件都会在某个具体场景里露馅。

配置完成后，别急着庆祝。找一台没配过的设备，跑一遍本文第六节的诊断命令，对比一下解析结果——真正干净的 DNS 环境，是所有设备、所有网络下，解析行为都一致。

本文由 AirPick · 机场推荐（airpick.co）技术组维护，配置片段基于 mihomo 1.18+ 与 sing-box 1.10+ 实测验证。参数随网络环境变化，请以你的实测数据为准。

#DNS防污染 #DoH #FakeIP #DNS泄漏 #mihomo #singbox #机场推荐 #AirPick

DNS 解析防污染与防泄漏实战：DoH / DoT 与 Fake-IP 的最优参数组合 ​

一、TL;DR：三句话结论 ​

二、底层机理：DNS 污染到底发生在哪一层 ​

三、核心参数对比矩阵 ​

四、人群与场景选型 ​

五、分客户端实操配置 ​

5.1 mihomo / Clash.Meta（推荐基线） ​

5.2 sing-box ​

5.3 移动端（Android / iOS） ​

六、抓包排障诊断手册 ​

七、行业避坑矩阵 ​

八、常见问题 FAQ ​

九、延伸阅读 ​

十、写在最后 ​

DNS 解析防污染与防泄漏实战：DoH / DoT 与 Fake-IP 的最优参数组合

一、TL;DR：三句话结论

二、底层机理：DNS 污染到底发生在哪一层

三、核心参数对比矩阵

四、人群与场景选型

五、分客户端实操配置

5.1 mihomo / Clash.Meta（推荐基线）

5.2 sing-box

5.3 移动端（Android / iOS）

六、抓包排障诊断手册

七、行业避坑矩阵

八、常见问题 FAQ

九、延伸阅读

十、写在最后