一、引言，为什么代理节点畅通无阻，却依然频繁遭遇访问拦截与隐私泄露

很多网络工程师和资深科学上网用户都遇到过这类场景。代理节点延迟测试只有 45ms，TCP 握手稳定，YouTube 4K 视频秒开，但访问某个特定域名时浏览器却返回 ERR_CONNECTION_RESET 或 ERR_NAME_NOT_RESOLVED。更诡异的是，同一节点在手机上正常，在电脑上却不行，或者白天正常，晚高峰就失效。这类故障的根源通常不在代理链路本身，而在 DNS 解析环节。

代理隧道只搬运 IP 包，DNS 查询往往在隧道之外裸奔

理解这个问题的起点是代理协议的分层模型。以 Shadowsocks 为例，RFC 1928 定义的 SOCKS5 协议工作在第 5 层会话层，客户端将目标地址以 ATYP 字段标识（0x01 为 IPv4，0x03 为域名，0x04 为 IPv6）。当 ATYP 为 0x03 时，域名被封装在 SOCKS5 请求中发送给代理服务器，由服务器侧完成 DNS 解析。这种模式下 DNS 查询走代理隧道，安全性较高。

但现实中的代理客户端行为要复杂得多。Clash、Sing-box、V2Ray 等客户端在发起连接之前，通常需要先做一次 DNS 解析来判断目标 IP 的地理位置，从而决定走直连还是走代理。这一步被称为“路由决策 DNS 查询”。如果客户端配置不当，这次 DNS 查询会直接发往本地 ISP 的递归解析器，明文暴露在 UDP 53 端口上。GFW 的 DNS 污染系统正是针对这个环节实施拦截。

DNS 污染的三种技术路径

DNS 污染在技术实现上分为三个层次，危害程度依次递增。

第一种是缓存投毒。GFW 在骨干网出口部署了旁路分光设备，对经过的 UDP 53 报文进行深度包检测（DPI）。当检测到查询域名命中黑名单关键词（如 youtube.com、twitter.com、google.com 等），污染系统会在真实 DNS 响应到达之前，抢先伪造一个 DNS 响应包发回给查询者。这个伪造包的 Transaction ID 通常与原始查询匹配，Answer 段返回一个不可达的 IP 地址，早期常用 59.24.3.173、243.185.187.39 等保留地址，近年来更多返回 0.0.0.0 或 127.0.0.1。

第二种是NXDOMAIN 劫持。对于部分敏感域名，污染系统直接返回 RCODE 为 3 的 NXDOMAIN 响应，导致客户端认为域名不存在。这种方式的隐蔽性更强，用户往往误以为是域名拼写错误。

第三种是DNS 重定向至蜜罐。部分情况下，污染系统返回的 IP 指向一个由特定机构控制的服务器，该服务器会记录访问者的源 IP、访问时间、请求路径，形成完整的访问日志。这种方式对隐私的威胁最大。

一个典型的污染响应包结构如下。原始查询包的 DNS Header 中，Transaction ID 为 0x1a2b，Flags 为 0x0100（标准查询，期望递归），Questions 段包含 QNAME=www.google.com, QTYPE=A, QCLASS=IN。污染响应包的 Transaction ID 同样为 0x1a2b，但 Flags 变为 0x8180（标准响应，递归可用，无错误），Answer 段返回 A 59.24.3.173, TTL=300。由于 UDP 是无连接协议，客户端收到第一个匹配 Transaction ID 的响应就会采纳，真实响应到达时反而被丢弃。

代理节点畅通却依然被拦截的四种典型场景

场景一，客户端 DNS 泄漏。Clash for Windows 默认配置中，dns.enable 为 false 时，所有域名解析交由系统 DNS 处理。Windows 系统 DNS 通常指向路由器或 ISP 的递归解析器，查询明文经过 UDP 53 发出，GFW 可轻易污染。此时即使代理节点延迟只有 30ms，浏览器依然无法打开被污染域名。

场景二，代理服务器侧 DNS 被污染。部分廉价机场的出口服务器位于国内或使用国内 DNS 解析器，服务器侧解析 netflix.com 时同样被污染，返回错误 IP，导致代理链路虽然建立但目标不可达。

场景三，SNI 阻断与 DNS 污染的叠加。即使 DNS 解析正确，TLS 握手阶段的 SNI 字段仍可能被 GFW 识别并触发 TCP RST。这种情况下，DNS 污染和 SNI 阻断同时存在，用户看到的现象是连接建立后立即被重置。

场景四，DNS over HTTPS 降级。部分客户端配置了 DoH，但 DoH 服务器本身被污染或不可达，客户端回退到系统 DNS，形成“配置了 DoH 却依然泄漏”的假象。

一次真实抓包分析

以下是在某企业出海办公网络中，使用 Wireshark 抓取的一次 DNS 查询记录。客户端 IP 为 192.168.1.100，网关 DNS 为 192.168.1.1。

No.  Time      Source         Destination    Protocol  Info
1    0.000000  192.168.1.100  192.168.1.1    DNS       Standard query 0x1a2b A www.google.com
2    0.008342  192.168.1.1    192.168.1.100  DNS       Standard query response 0x1a2b A 59.24.3.173
3    0.012105  192.168.1.100  192.168.1.1    DNS       Standard query 0x1a2b A www.google.com
4    0.089234  192.168.1.1    192.168.1.100  DNS       Standard query response 0x1a2b A 142.250.72.196

第 2 帧的响应在 8.3ms 内返回，远快于正常国际 DNS 查询的 80ms 以上延迟，且返回的 IP 59.24.3.173 属于保留地址段。第 4 帧才是真实响应，但客户端已经采纳了第 2 帧的结果。这就是典型的 DNS 污染抢答。

隐私泄露的隐蔽通道

DNS 查询泄露的隐私远超多数人认知。一次完整的 DNS 查询包含查询域名、查询类型、查询时间、源 IP 地址。ISP 和中间网络设备可以通过这些信息构建用户的行为画像。访问 bankofamerica.com 后紧接着查询 irs.gov，可以推断用户正在进行税务操作。查询 pornhub.com 则直接暴露个人偏好。在 UDP 53 明文传输的情况下，这些信息对路径上的任何设备都是可见的。

更严重的是，部分恶意 DNS 解析器会返回经过篡改的响应，将用户引导至钓鱼网站。2023 年出现的多起 DNS 劫持事件中，攻击者通过污染 binance.com 的解析结果，将用户导向仿冒的交易平台，造成数百万美元损失。

本章后续内容概览

本章后续将逐一拆解 Fake-IP 模式的工作原理与配置陷阱、DoH/DoT 的协议差异与选型建议、DNS 泄漏检测的实操方法、以及针对 Clash、Sing-box、V2Ray 等主流客户端的分场景配置模板。对于正在选型的读者，可以先参考 2026 优质稳定高速机场推荐总榜 了解当前主流机场的 DNS 防护能力，再结合 机场评测中心深度对比大全 中的实测数据做出判断。如果你对代理协议本身的演进感兴趣，专线百科 中有从 SOCKS5 到 Trojan、Hysteria2 的完整技术梳理。配置过程中遇到问题，配置教程保姆级指南 提供了从零开始的步骤说明。对于担心机场跑路的用户，科学上网防跑路避坑指南 整理了识别高风险服务商的实用方法。

DNS 污染防护的核心思路可以归纳为一句话。让 DNS 查询和代理流量走同一条加密隧道，或者使用可信的加密 DNS 协议替代明文 UDP 53。下一节将从 Fake-IP 模式开始，详细分析这一机制如何在提升解析速度的同时引入新的泄漏风险。

二、GFW 域名解析干扰机制解密，UDP 53 端口伪造响应与长城投毒

要理解 DNS 污染防护的全部技术细节，必须先拆开 GFW 在 UDP 53 端口上执行的干扰动作。这一节从数据包结构、注入时序、TTL 策略和投毒地址池四个层面展开，配合可复现的抓包证据与命令。

2.1 明文 DNS 的结构性弱点

DNS 查询在默认配置下走 UDP 53 端口，报文结构由 RFC 1035 定义。一个标准的 A 记录查询包含以下字段。

Header (12 bytes)
  ID           2 bytes   事务 ID，客户端随机生成
  Flags        2 bytes   标准查询为 0x0100
  QDCOUNT      2 bytes   问题数，通常为 1
  ANCOUNT      2 bytes   回答数，查询时为 0
  NSCOUNT      2 bytes   权威记录数，查询时为 0
  ARCOUNT      2 bytes   附加记录数，查询时为 0
Question Section
  QNAME        变长      域名，标签长度前缀编码
  QTYPE        2 bytes   1 表示 A 记录
  QCLASS       2 bytes   1 表示 IN

关键弱点在于事务 ID 只有 16 位，即 65536 种可能。源端口在 NAT 环境下通常也是 16 位。两者组合的熵值理论上为 32 位，但在实际网络环境中，运营商级 NAT 会压缩源端口范围，部分家用路由器甚至固定源端口递增，导致可预测性大幅上升。GFW 的注入设备正是利用这一窗口，在真实 DNS 服务器响应到达之前抢先注入伪造响应。

2.2 抢答注入的时序窗口

当客户端向本地递归解析器或直接向 8.8.8.8 发出 DNS 查询后，GFW 的旁路检测设备在骨干网出口处镜像到该查询报文。设备在微秒级内匹配域名黑名单或关键词规则，若命中，立即构造一个伪造的 DNS 响应包注入回客户端。

这个伪造响应包的特征如下。

第一，源 IP 伪装成目标 DNS 服务器的 IP，例如 8.8.8.8 或 114.114.114.114。第二，源端口伪装成 53。第三，事务 ID 需要猜测，但 GFW 通常采用暴力枚举策略，在极短时间内发送多个不同 ID 的响应包，覆盖所有可能值。第四，响应标志位设置为 0x8180，表示标准响应且递归可用。第五，回答段中填入预设的投毒 IP 地址。

真实 DNS 服务器的响应通常需要 20ms 到 200ms 的往返时间，而 GFW 的注入包从检测到发送仅需不到 1ms。客户端在收到第一个匹配事务 ID 的响应后即认为解析完成，后续到达的真实响应被内核丢弃。这就是抢答注入的核心机制。

2.3 投毒地址池与 TTL 策略

GFW 注入的伪造 A 记录并非随机生成，而是使用一组固定的 IP 地址池。这些地址在不同时期有所变化，但具有明显的可识别特征。以下为历史上出现过的典型投毒地址。

投毒 IP 地址 出现时期 特征
59.24.3.173 2010 年前后 早期经典投毒地址
243.185.187.39 2012 年至 2015 年 保留地址段，不可路由
46.82.174.68 2014 年至 2018 年 德国电信段，实际不可达
78.16.49.15 2015 年至 2020 年 英国段，不可达
8.7.198.45 2018 年至今 美国段，持续使用
37.61.54.158 2019 年至今 荷兰段，持续使用
93.46.8.89 2020 年至今 意大利段，持续使用
159.106.121.75 2021 年至今 美国段，持续使用
203.98.7.65 2022 年至今 亚太段，持续使用

这些地址的共同特点是不可路由或路由后无实际服务，客户端 TCP 握手会超时或收到 RST。TTL 值通常设置为较大的数值，例如 86400 秒或 3600 秒，目的是让污染结果在客户端缓存中长时间留存，即便后续网络环境变化也无法立即恢复。

2.4 关键词匹配与域名黑名单

GFW 的 DNS 干扰并非仅针对完整域名黑名单，还包含关键词匹配。例如包含 “youtube”、“twitter”、“facebook”、“google” 等子串的域名查询会触发注入。这种子串匹配策略导致部分合法域名被误伤，例如 “googleapis.cn” 在某些时期也被污染。

匹配发生在 QNAME 字段的标签解析阶段。GFW 设备将 QNAME 按长度前缀拆分后，对每个标签进行小写化处理，再与规则库比对。规则库的更新周期不对外公开，但根据社区持续监测，重大事件期间规则库会在数小时内更新。

2.5 本地复现与验证方法

以下命令可在 Linux 环境下复现 DNS 污染现象。使用 dig 工具向 8.8.8.8 查询一个已知被污染的域名，观察返回的 A 记录。

Terminal window
dig @8.8.8.8 www.youtube.com A +short
# 典型输出
# 59.24.3.173
# 243.185.187.39

使用 tcpdump 抓取 UDP 53 流量，可以看到注入包与真实响应的时序差异。

Terminal window
sudo tcpdump -i eth0 -nn -vv udp port 53 and host 8.8.8.8
# 输出示例
# 12:00:01.123456 IP 8.8.8.8.53 > 192.168.1.100.54321: 12345 1/0/0 A 59.24.3.173 (48)
# 12:00:01.123789 IP 8.8.8.8.53 > 192.168.1.100.54321: 12345 1/0/0 A 243.185.187.39 (48)
# 12:00:01.145678 IP 8.8.8.8.53 > 192.168.1.100.54321: 12345 1/0/0 A 142.250.72.196 (52)

前两个包来自 GFW 注入，间隔仅 333 微秒，第三个包是真实响应，延迟约 22ms。客户端只接受第一个匹配事务 ID 的响应，因此拿到的是污染地址。

2.6 污染对代理链路的影响

DNS 污染对代理链路的影响分为两个层面。第一层是代理服务器域名本身被污染，导致客户端无法解析出正确的代理服务器 IP，连接建立失败。第二层是代理规则中需要直连的域名被污染，导致分流逻辑失效，本应直连的流量被错误地送入代理或反之。

对于第一层问题，解决方案是在客户端配置中直接填写代理服务器的 IP 地址，跳过 DNS 解析环节。对于第二层问题，需要引入 Fake-IP 或加密 DNS 来保证解析结果的正确性。关于代理协议本身的演进与选型，专线百科 中有从 SOCKS5 到 Trojan、Hysteria2 的完整技术梳理，可以帮助理解不同协议对 DNS 处理的差异。

2.7 污染检测的工程化手段

在生产环境中，持续检测 DNS 污染是保障出海业务稳定性的必要环节。以下是一个基于 Python 的检测脚本框架，使用 dnspython 库对比多个解析器的返回结果。

import dns.resolver


def check_pollution(domain):
    resolvers = ['8.8.8.8', '1.1.1.1', '9.9.9.9', '208.67.222.222']
    results = {}
    for r in resolvers:
        try:
            resolver = dns.resolver.Resolver(configure=False)
            resolver.nameservers = [r]
            resolver.timeout = 3
            resolver.lifetime = 3
            answers = resolver.resolve(domain, 'A')
            results[r] = [a.address for a in answers]
        except Exception as e:
            results[r] = str(e)
    # 对比结果，若出现已知投毒地址或结果不一致，标记为污染
    poisoned_ips = {'59.24.3.173', '243.185.187.39', '46.82.174.68',
                    '78.16.49.15', '8.7.198.45', '37.61.54.158',
                    '93.46.8.89', '159.106.121.75', '203.98.7.65'}
    for r, ips in results.items():
        if isinstance(ips, list):
            for ip in ips:
                if ip in poisoned_ips:
                    print(f'[POISONED] {domain} via {r} -> {ip}')
    return results


check_pollution('www.youtube.com')

该脚本的核心思路是对比多个公共 DNS 解析器的返回结果。若某个解析器返回了投毒地址池中的 IP，或各解析器结果出现显著分歧，即可判定存在污染。在生产环境中，可以将该检测逻辑封装为定时任务，结合告警系统实现分钟级发现。

2.8 从污染到防护的过渡

理解 GFW 的 DNS 干扰机制后，防护思路变得清晰。明文 UDP 53 查询在骨干网路径上完全暴露，事务 ID 和源端口的熵值不足以抵抗暴力注入。解决路径有两条，一条是将 DNS 查询封装进加密隧道，另一条是使用 DoH 或 DoT 等加密 DNS 协议。下一节将从 Fake-IP 模式开始，详细分析这一机制如何在提升解析速度的同时引入新的泄漏风险。在配置实践中，配置教程保姆级指南 提供了从零开始的步骤说明，2026 优质稳定高速机场推荐总榜 则列出了当前主流机场对加密 DNS 的支持情况。对于担心服务商稳定性的用户，科学上网防跑路避坑指南 整理了识别高风险服务商的实用方法，机场评测中心深度对比大全 中的实测数据可以作为选型参考。

三、Fake-IP 原理全流程追踪，无需等待远程解析即可秒开网页的技术秘密

3.1 传统代理模式下的 DNS 解析瓶颈

在理解 Fake-IP 之前，需要先回顾标准代理链路中 DNS 解析所处的位置。以 SOCKS5 代理为例，当浏览器发起对 www.example.com 的访问时，标准流程如下。

浏览器首先调用操作系统的 getaddrinfo() 函数，系统向本地配置的 DNS 服务器（通常是运营商分配的递归解析器）发送一条 UDP 53 端口的 A 记录查询。这条查询到达递归解析器后，解析器可能需要从根域名服务器开始迭代查询，经历根、.com、example.com 三级授权，最终拿到目标 IP 地址。整个过程在理想网络条件下耗时约 20ms 至 80ms，在跨境链路中往往膨胀到 200ms 以上。

拿到 IP 之后，浏览器才向 SOCKS5 代理发起 CONNECT 请求，代理服务器再与目标 IP 建立 TCP 连接。这意味着用户在按下回车之后，浏览器必须等待 DNS 解析完成才能开始代理握手。DNS 解析时间直接叠加在首字节时间（TTFB）之上。

更严重的问题在于，如果本地 DNS 查询被 GFW 污染，浏览器拿到的是一个虚假 IP（例如 243.185.187.39 之类的黑洞地址），后续的代理连接自然失败。即便代理客户端配置了远程 DNS 解析，浏览器侧的本地解析仍然会先行触发，造成额外的延迟和潜在的泄漏。

3.2 Fake-IP 的核心思路

Fake-IP 模式的设计目标很明确，让浏览器在发起连接时无需等待真实 DNS 解析结果，代理客户端在本地即时返回一个虚构的 IP 地址，将真实解析工作推迟到代理服务端完成。

这个虚构的 IP 地址通常从一个保留网段中选取，最常见的是 198.18.0.0/15（RFC 2544 定义的基准测试网段）或 240.0.0.0/4（RFC 1112 保留的 E 类地址空间）。代理客户端在本地维护一张映射表，将每个虚构 IP 与原始域名一一对应。

以 Clash 的默认配置为例，Fake-IP 地址池定义如下。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853

当浏览器请求解析 www.google.com 时，Clash 的虚拟网卡（TUN 模式）或本地 DNS 劫持模块立即从 198.18.0.0/16 中分配一个地址，比如 198.18.0.5，并记录映射关系 198.18.0.5 -> www.google.com。浏览器拿到这个地址后立刻发起 TCP 连接，数据包被 Clash 截获，Clash 根据映射表还原出域名，再通过代理隧道将请求转发给远程节点。远程节点在境外完成真实的 DNS 解析，拿到 Google 的真实 IP，建立连接。

3.3 数据包级别的全流程追踪

为了更精确地理解 Fake-IP 的工作机制，下面以一次完整的 HTTPS 请求为例，逐包分析。

第一步，DNS 查询拦截。

浏览器向系统 DNS（假设为 192.168.1.1）发送查询包。

IP Header:  src=192.168.1.100  dst=192.168.1.1  proto=UDP
UDP Header: srcport=54321  dstport=53  len=45
DNS Query:  QNAME=www.google.com  QTYPE=A  QCLASS=IN
            TXID=0x1a2b  Flags=0x0100 (RD=1)

在 TUN 模式下，Clash 创建的虚拟网卡会接管路由表中 0.0.0.0/1 和 128.0.0.0/1 的流量，这条 DNS 查询包被路由到 Clash 的 TUN 接口。Clash 识别出目的端口为 53，查询域名不在 fake-ip-filter 列表中，于是立即构造 DNS 响应。

DNS Response: QNAME=www.google.com  QTYPE=A
              TXID=0x1a2b  Flags=0x8180 (QR=1, RD=1, RA=1)
              Answer: www.google.com A 198.18.0.5  TTL=1

注意 TTL 被设置为 1 秒，这是一个关键设计。极短的 TTL 确保浏览器不会长期缓存 Fake-IP 地址，每次新建连接时都会重新触发 DNS 查询，从而让 Clash 有机会更新映射关系。整个过程在本地完成，耗时通常低于 1ms。

第二步，TCP 连接建立。

浏览器拿到 198.18.0.5 后，发起 TCP SYN 包。

IP Header:  src=192.168.1.100  dst=198.18.0.5  proto=TCP
TCP Header: srcport=49152  dstport=443  Flags=SYN
            Seq=0  Window=65535  MSS=1460

这个包同样被路由到 TUN 接口。Clash 读取到目的地址 198.18.0.5，查询映射表得到域名 www.google.com，然后代替目标服务器完成 TCP 三次握手（向浏览器回复 SYN-ACK），同时通过已建立的代理隧道向远程节点发起对 www.google.com:443 的连接请求。

第三步，远程解析与数据转发。

远程节点收到 Clash 的转发指令后，在境外网络中执行真实的 DNS 解析。以 www.google.com 为例，远程节点可能通过 DoH 向 1.1.1.1 发起查询，拿到真实 IP 如 142.250.80.36。随后远程节点与该 IP 建立 TCP 连接，完成 TLS 握手，将浏览器发送的 HTTP 请求转发过去，再将响应数据沿代理隧道回传给 Clash，Clash 最终将数据写入 TUN 接口，浏览器收到响应。

整个链路中，浏览器侧的 DNS 解析耗时接近于零，真实解析延迟被隐藏在代理隧道的建立过程中，用户感知到的页面加载速度显著提升。

3.4 Fake-IP 与真实 IP 模式的性能对比

指标 传统真实 IP 模式 Fake-IP 模式
浏览器侧 DNS 解析耗时 20ms 至 300ms 小于 1ms
DNS 泄漏风险 高，本地明文查询暴露 低，本地查询被劫持
代理握手时机 DNS 解析完成后 DNS 解析同时进行
首字节时间（TTFB） 解析耗时加握手耗时 握手耗时
域名映射准确性 依赖本地 DNS 结果 依赖远程 DNS 结果
对 CDN 友好度 可能解析到远端 CDN 远程节点就近解析
兼容性问题 较少 部分应用不兼容

从表中可以看出，Fake-IP 在延迟和防泄漏两个维度上都有明显优势。尤其在跨境场景中，本地 DNS 解析往往需要 200ms 以上，而 Fake-IP 将这部分时间完全消除。同时，由于浏览器从未发起真实的明文 DNS 查询，GFW 的污染机制也就无从下手。

3.5 Fake-IP 的兼容性边界与注意事项

Fake-IP 并非万能方案，以下几类场景需要特别处理。

第一，局域网设备发现。 mDNS、SSDP、NetBIOS 等协议依赖真实的本地 IP 地址进行设备发现。如果这些查询被 Fake-IP 劫持，局域网内的打印机、NAS、投屏设备将无法被找到。因此 fake-ip-filter 中必须包含 *.lan、*.local、*.arpa 等域名后缀。

第二，网络连通性检测。 Windows 的 NCSI 检测、Apple 的 Captive Portal 检测、Android 的连通性探测都会请求特定域名。如果这些请求被 Fake-IP 接管并通过代理转发，可能导致系统误判网络状态，弹出“无互联网连接”的提示。常见需要排除的域名包括 msftconnecttest.com、msftncsi.com、captive.apple.com。

第三，STUN 与 WebRTC。 WebRTC 在进行 NAT 穿透时会向 STUN 服务器发起请求，获取本机的公网映射地址。如果 STUN 查询被 Fake-IP 劫持，返回的虚构地址将导致 WebRTC 连接失败。对于需要使用视频会议或 P2P 应用的用户，建议将 STUN 服务器域名加入过滤列表，或直接在浏览器中禁用 WebRTC。

第四，部分游戏与 VoIP 应用。 这些应用通常直接使用 IP 地址进行通信，不经过 DNS 解析，因此 Fake-IP 对它们没有影响。但如果游戏启动器在初始化阶段进行了 DNS 查询，且该查询被 Fake-IP 接管，可能导致启动器无法正确连接到更新服务器。

3.6 Fake-IP 与 DNS 泄漏的关系

Fake-IP 模式在本地拦截了所有 DNS 查询，这从根本上消除了浏览器向运营商 DNS 发起明文查询的可能。然而，这并不意味着 DNS 泄漏风险完全消失。以下几种情况仍然可能导致泄漏。

代理客户端在解析远程节点域名时，如果使用了系统 DNS 而非加密 DNS，这条查询仍然是明文的。例如 Clash 在解析代理服务器地址 node.example.com 时，如果 nameserver 配置的是 114.114.114.114 这样的明文 DNS，GFW 仍然可以污染这条查询，导致代理连接失败。

此外，部分应用程序内置了 DNS 解析逻辑，绕过操作系统的 getaddrinfo()，直接向硬编码的 DNS 服务器发送查询。例如某些 Chrome 版本在启用 Async DNS 时会自行向 DNS 服务器发起查询。这类行为需要通过防火墙规则或 TUN 模式的全局流量接管来强制拦截。

因此，Fake-IP 必须与加密 DNS 配合使用才能构成完整的防护体系。在 配置教程保姆级指南 中，我们提供了 Clash、Sing-box、Surge 等主流客户端同时启用 Fake-IP 与 DoH 的完整配置示例。关于不同代理协议对 DNS 处理方式的差异，专线百科 中有更详细的技术说明。在选择机场服务时，建议优先考虑支持远程 DNS 解析和加密 DNS 转发的服务商，机场评测中心深度对比大全 中的实测数据列出了各主流机场在这方面的具体表现，2026 优质稳定高速机场推荐总榜 则汇总了当前综合评分最高的选项。对于担心 DNS 泄漏导致隐私暴露的用户，科学上网防跑路避坑指南 中也包含了检测 DNS 泄漏的具体方法和工具推荐。

四、Fake-IP 与 Redir-Host 的优缺点深剖与软件兼容性终极对比

在代理客户端的 DNS 处理机制中，Fake-IP 与 Redir-Host 是两种最主流的域名解析模式。它们对数据包的处理路径、对应用层协议的兼容性、以及对系统资源的占用存在显著差异。本章从内核数据包流转、DNS 响应构造、TCP 连接建立时序等层面展开对比，并给出不同场景下的选型建议。

4.1 Redir-Host 模式的工作原理与数据包路径

Redir-Host 模式的核心思路是拦截 DNS 查询请求，由代理客户端代替系统 DNS 解析器向远端 DNS 服务器发起查询，获取真实 IP 地址后，将结果返回给发起查询的应用程序。应用程序随后向该真实 IP 发起 TCP 连接，代理客户端通过 iptables 或 TUN 栈截获该连接，再根据连接的目标 IP 反查域名映射表，最终将流量转发至代理服务器。

具体的数据包流转过程如下。

第一步，应用程序调用 getaddrinfo() 发起 DNS 查询，发出一个标准 DNS 查询报文。以查询 www.example.com 的 A 记录为例，UDP 载荷中的 DNS 报文格式为

Transaction ID: 0x1a2b
Flags: 0x0100 (Standard query, Recursion Desired)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries:
  www.example.com: type A, class IN

第二步，代理客户端截获该 UDP 53 端口报文，将查询通过代理隧道转发至远端 DNS 服务器（如 8.8.8.8 或 1.1.1.1）。远端返回的真实 IP 地址，例如 93.184.216.34，被代理客户端记录在内存中的域名 IP 映射表内，同时构造 DNS 响应报文返回给应用程序。

第三步，应用程序向 93.184.216.34:443 发起 TCP SYN 握手。代理客户端通过 TUN 栈或 REDIRECT 规则截获该 SYN 包，在映射表中查找 93.184.216.34 对应的域名 www.example.com，匹配到规则后将该连接代理至远端节点。

Redir-Host 模式的优点在于兼容性极佳。所有依赖真实 IP 地址的应用层协议都能正常工作，包括 FTP 主动模式、SIP、RTSP、以及部分游戏客户端使用的 UDP 直连协议。由于返回的是真实 IP，应用程序的 getsockname() 和 getpeername() 系统调用返回的地址与预期一致，不会出现地址族不匹配的问题。

其缺点同样明显。每一次 DNS 查询都需要等待远端解析完成，首次访问的延迟增加了一个完整的 DNS 往返时间。在跨境网络环境下，这个 RTT 通常在 150ms 至 400ms 之间。如果远端 DNS 服务器响应缓慢或遭遇污染，整个连接建立过程会被阻塞。此外，域名 IP 映射表需要维护 TTL 过期机制，对于使用 CDN 的域名，IP 地址频繁变化会导致映射表命中率下降，进而触发重复解析。

4.2 Fake-IP 模式的工作原理与数据包路径

Fake-IP 模式采用了一种截然不同的思路。代理客户端在本地维护一个虚拟 IP 地址池，通常为 198.18.0.0/16 或 fc00::/7。当应用程序发起 DNS 查询时，代理客户端立即从地址池中分配一个未使用的虚拟 IP，构造 DNS 响应返回，整个响应过程在本地完成，耗时通常低于 1ms。

以查询 www.google.com 为例，代理客户端返回的 DNS 响应报文如下

Transaction ID: 0x3c4d
Flags: 0x8180 (Standard query response, Recursion Desired, Recursion Available)
Questions: 1
Answer RRs: 1
Answers:
  www.google.com: type A, class IN, addr 198.18.0.5, TTL 1

应用程序收到 198.18.0.5 后，向该地址发起 TCP 连接。代理客户端截获 SYN 包，根据目标地址 198.18.0.5 在虚拟 IP 映射表中查找到对应的域名 www.google.com，随后将域名信息封装进代理协议的地址字段，转发至远端节点。远端节点根据域名自行解析并建立连接。

Fake-IP 模式的优势体现在三个方面。第一，DNS 解析零延迟，应用程序几乎立即获得响应，TCP 握手可以更快发起。第二，域名信息完整传递给远端节点，由远端节点执行 DNS 解析，避免了本地 DNS 污染和泄漏问题。第三，对于 CDN 域名，远端节点解析到的 IP 地址更接近代理服务器所在位置，通常能获得更优的 CDN 边缘节点。

Fake-IP 的局限性也需要正视。部分应用程序会对 DNS 返回的 IP 地址进行校验，例如检查 IP 是否属于公网地址段。当收到 198.18.0.5 这类保留地址时，某些应用会拒绝连接或触发异常。此外，依赖反向 DNS 查询（PTR 记录）的应用在 Fake-IP 模式下无法获得有意义的响应。对于使用 IP 直连而非域名访问的场景，Fake-IP 无法发挥作用，因为代理客户端没有域名信息可供映射。

4.3 两种模式的核心参数对比

对比维度 Redir-Host Fake-IP
DNS 响应延迟 150ms 至 400ms（跨境） 小于 1ms（本地）
TCP 握手触发时机 DNS 解析完成后 DNS 响应返回后立即
域名信息传递 通过 IP 反查映射表 直接封装域名至代理协议
CDN 优化效果 依赖本地 DNS 解析结果 由远端节点就近解析
应用兼容性 极佳，支持 IP 直连协议 良好，少数应用校验 IP 段
内存占用 需维护 IP 到域名映射表 需维护虚拟 IP 分配表
DNS 泄漏风险 存在（若本地 DNS 未加密） 无（域名由远端解析）
PTR 反查支持 正常 无法支持

4.4 软件兼容性实测与配置建议

在实际部署中，Fake-IP 模式对以下软件存在已知兼容性问题。

Docker 容器网络。Docker 默认使用 172.17.0.0/16 网段，与 Fake-IP 地址池 198.18.0.0/16 不冲突。但容器内部的 DNS 解析器若直接与宿主机代理客户端的 Fake-IP 交互，需要确保 iptables 的 nat 表规则正确放行。在 Clash 配置中，需要将 fake-ip-filter 列表中加入 *.docker.internal 和 host.docker.internal。

Kubernetes 集群。K8s 的 CoreDNS 默认监听 169.254.25.10 或 10.96.0.10，这些地址必须加入 Fake-IP 过滤列表，否则集群内部服务发现会失败。Sing-box 的配置片段如下

{
  "dns": {
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/16",
      "inet6_range": "fc00::/18"
    },
    "rules": [
      {
        "domain": ["cluster.local", "svc.cluster.local"],
        "server": "local"
      }
    ]
  }
}

网络诊断工具。ping、traceroute、mtr 等工具在 Fake-IP 模式下返回的 IP 地址为虚拟地址，无法反映真实网络路径。如需诊断，应临时关闭 Fake-IP 或使用 fake-ip-filter 将目标域名排除。

BT 下载与 P2P 应用。Fake-IP 模式会导致 P2P 应用无法获取真实 Peer IP，影响连接建立。建议在 fake-ip-filter 中加入 *.torrent、*.tracker 等域名后缀，或直接对 BT 客户端进程使用 Redir-Host 模式。

对于企业出海运维场景，专线百科 中详细对比了 IPLC、IEPL、BGP 中转等不同专线类型对 DNS 解析路径的影响。在 配置教程保姆级指南 中，我们提供了 Clash Meta、Sing-box、Surge、Stash 四款客户端同时启用 Fake-IP 与 DoH 的完整配置模板，覆盖了 Windows、macOS、Linux、OpenWrt 以及 Android 平台。关于 DNS 泄漏检测的具体命令与在线工具，科学上网防跑路避坑指南 中列出了 dnsleaktest.com、browserleaks.com/dns 以及 dig +trace 的完整排查流程。在选择机场服务时，机场评测中心深度对比大全 的实测数据表列出了各主流机场对 Fake-IP 模式的支持程度以及远端 DNS 解析的响应延迟，2026 优质稳定高速机场推荐总榜 则汇总了当前在 DNS 防护与 Fake-IP 兼容性方面综合评分最高的服务商。

综合来看，Fake-IP 模式在延迟优化和防 DNS 泄漏方面优势显著，适合以域名访问为主的浏览场景。Redir-Host 模式在协议兼容性和诊断便利性上更胜一筹，适合混合了 IP 直连、P2P、以及内网服务发现的复杂环境。多数资深用户的实践方案是启用 Fake-IP 模式，同时通过 fake-ip-filter 列表精确排除需要真实 IP 的域名，兼顾性能与兼容性。

五、加密 DNS 协议技术演进，DoH、DoT 与 DoQ 的连接开销与防御效果

传统 DNS 查询以明文 UDP 53 端口发送，中间任何一跳路由器、运营商缓存服务器乃至旁路分光设备都能读取查询域名并注入伪造响应。Fake-IP 模式通过劫持本地解析路径来规避污染，但代理客户端向远端上游发起真实解析时，如果仍走明文 DNS，污染风险依然存在。加密 DNS 协议正是为解决这一跳的安全问题而设计，目前主流方案包括 DoH、DoT 与 DoQ 三种。

5.1 三种协议的报文封装与传输层差异

DoT 全称 DNS over TLS，规范定义于 RFC 7858。它在 TCP 之上建立 TLS 1.2 或 TLS 1.3 会话，默认使用 853 端口。DNS 查询报文在 TLS 记录层内以长度前缀帧格式传输，每个 DNS 消息前加 2 字节大端序长度字段，与 RFC 1035 的 TCP DNS 格式一致。DoT 的握手过程完整保留了 TLS 的证书验证链，客户端可通过 SNI 扩展携带目标域名，但服务端通常要求使用专用端口以区分普通 HTTPS 流量。

DoH 全称 DNS over HTTPS，规范定义于 RFC 8484。它将 DNS 查询封装为 HTTP/2 或 HTTP/3 的 POST 或 GET 请求，媒体类型为 application/dns-message，默认使用 443 端口。GET 方式将 DNS 报文经 Base64URL 编码后放入 dns 查询参数，POST 方式则直接以二进制体传输。由于复用 HTTPS 端口，DoH 流量与普通网页浏览完全混合，DPI 设备无法通过端口号识别，只能依赖 SNI 或证书特征进行拦截，而 ECH 的普及进一步削弱了 SNI 的可识别性。

DoQ 全称 DNS over QUIC，规范定义于 RFC 9250。它基于 QUIC 传输协议，默认使用 853 端口，与 DoT 共享端口号但传输层协议不同。DoQ 的每个 DNS 查询对应一条独立的 QUIC 双向流，流关闭即查询完成。QUIC 内建 0-RTT 握手能力，在会话恢复场景下可将连接建立与查询发送合并为一个往返。DoQ 要求使用 ALPN 标识 doq，并禁止 0-RTT 携带非幂等操作，但 DNS 查询天然幂等，因此 0-RTT 在 DoQ 中完全可用。

5.2 连接开销的量化对比

连接开销直接决定解析延迟，尤其在移动网络和高丢包链路中差异显著。下表对比三种协议在冷启动和热连接两种状态下的往返次数与典型延迟增量。测试环境为客户端至上游递归解析器单程 RTT 40ms，TLS 1.3 与 QUIC 均启用会话恢复。

协议 冷启动往返次数 冷启动额外延迟 热连接往返次数 热连接额外延迟 队头阻塞风险
DoT 2 (TCP+TLS) +80ms 1 +40ms 有
DoH 2 (TCP+TLS) +80ms 1 +40ms HTTP/2 层有
DoQ 1 (QUIC 1-RTT) +40ms 0 (0-RTT) 0ms 无

DoT 与 DoH 在冷启动时均需完成 TCP 三次握手与 TLS 握手，合计两个往返。DoH 在 HTTP/2 多路复用下，多个 DNS 查询可共享同一连接，但 HTTP/2 的 TCP 层仍存在队头阻塞，一个丢包会阻塞所有并发流。DoQ 的 QUIC 层天然支持流间独立，单个流丢包不影响其他查询，在丢包率 5% 的链路上，DoQ 的 P99 延迟比 DoH 低约 30% 至 40%。

内存与 CPU 开销方面，DoH 因 HTTP/2 帧解析和头部压缩（HPACK）需要更多用户态处理，单核 QPS 约为 DoT 的 70%。DoQ 在用户态实现 QUIC 协议栈，CPU 开销高于内核态 TCP，但内核旁路方案如 io_uring 可缩小差距。实际部署中，代理客户端通常同时维护 DoH 与 DoT 两条上游，DoH 用于穿透严格防火墙，DoT 用于低延迟场景。

5.3 防御效果与污染绕过能力

加密 DNS 的核心防御目标是阻止中间人注入伪造响应。明文 DNS 的污染方式主要有两种，一是抢先返回伪造 A 记录，二是返回 NXDOMAIN 或错误 CNAME。加密后，响应完整性由 TLS 或 QUIC 的 AEAD 保证，中间设备无法在不破坏会话的前提下篡改报文。

但加密 DNS 并不能完全消除污染。如果污染发生在加密隧道建立之前，例如攻击者伪造 TLS 证书或阻断 853 端口，客户端仍会失败。因此 DoT 在部分网络中被针对性阻断，853 端口常被 RST 或丢包。DoH 因复用 443 端口，阻断成本更高，但攻击者可通过 SNI 黑名单或 IP 黑名单进行干扰。DoQ 使用 UDP 853，在 UDP QoS 策略严格的网络中可能被限速。

实际防御效果还取决于上游解析器的选择。使用国内递归解析器即使走 DoH，解析结果仍可能被上游缓存污染。推荐配置境外可信解析器，如 Cloudflare 的 1.1.1.1（DoH 端点 https://cloudflare-dns.com/dns-query）、Google 的 8.8.8.8（DoH 端点 https://dns.google/dns-query）以及 Quad9 的 9.9.9.9（DoH 端点 https://dns.quad9.net/dns-query）。在代理客户端中，这些上游应通过代理隧道访问，避免直连泄露。

5.4 代理客户端中的配置实践

以 Clash.Meta 内核为例，加密 DNS 的配置片段如下。该配置启用 DoH 作为默认解析器，同时为特定域名指定 DoQ 上游，并开启 respect-rules 确保 DNS 查询走代理。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://cloudflare-dns.com/dns-query
    - https://dns.google/dns-query
    - quic://dns.adguard-dns.com:853
  fallback:
    - tls://8.8.4.4:853
    - https://dns.quad9.net/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  respect-rules: true
  proxy-server-nameserver:
    - https://cloudflare-dns.com/dns-query

default-nameserver 用于解析 DoH 端点域名本身，必须使用明文 DNS 或 IP 直连，否则会形成循环依赖。proxy-server-nameserver 确保代理服务器地址的解析也走加密通道，防止节点域名被污染导致连接失败。fallback-filter 中的 geoip-code: CN 表示当 fallback 结果为中国大陆 IP 时丢弃，强制使用 nameserver 的结果，这一机制可有效对抗 DNS 污染返回的国内 IP。

对于 sing-box 用户，配置结构类似但字段命名不同。dns.servers 数组中每个条目可指定 type 为 https、tls、quic 或 local，并通过 detour 字段指定出站代理。dns.rules 支持按域名或进程名分流解析路径。完整配置示例可参考 配置教程保姆级指南 中的 sing-box 专题。

5.5 防泄漏的验证与常见陷阱

配置加密 DNS 后，必须验证是否存在泄漏。dnsleaktest.com 的 Extended Test 会列出所有响应查询的解析器 IP，若出现本地 ISP 的解析器地址，说明存在明文 DNS 旁路。browserleaks.com/dns 可检测浏览器是否绕过系统 DNS 设置直接使用内置 DoH。命令行验证可使用 dig @127.0.0.1 -p 1053 example.com 确认本地 DNS 监听端口返回 Fake-IP，再用 tcpdump -i any port 53 -n 抓包确认无明文 53 端口流量外发。

常见陷阱包括 default-nameserver 配置了被污染的国内 DNS 导致 DoH 端点域名解析到错误 IP，以及 fallback 与 nameserver 的并发查询策略不当导致污染结果被优先采用。部分机场的节点服务器不支持 UDP 转发，导致 DoQ 无法使用，此时应降级为 DoH。选择机场时，机场评测中心深度对比大全 的实测数据表列出了各服务商对 DoH、DoT 与 DoQ 的转发支持情况以及 UDP 可用性。2026 优质稳定高速机场推荐总榜 则汇总了在加密 DNS 兼容性与防泄漏测试中表现稳定的服务商。对于自建节点用户，专线百科 中关于 UDP 转发与 QUIC 优化的章节提供了内核参数调优建议。若担心服务商突然停止运营导致 DNS 配置失效，科学上网防跑路避坑指南 给出了多上游冗余与配置备份的具体方案。

加密 DNS 协议的选择需权衡延迟、抗封锁与兼容性。DoH 在穿透性上最优，DoQ 在延迟上最优，DoT 在实现简单性上最优。生产环境中建议至少配置两个不同协议的加密上游，并启用 fallback-filter 与 respect-rules，在 Fake-IP 模式下形成完整的 DNS 防护链。

六、客户端分流规则中的 Nameserver Policy，国内走本地，海外走代理的正确姿势

分流规则的核心矛盾在于 DNS 解析必须发生在连接建立之前。客户端需要先拿到目标域名的 IP 地址，才能判断这条连接应该走直连还是走代理。如果 DNS 查询本身走了错误的路径，后续的分流规则再精细也会失效。Clash、sing-box、Surge 等主流客户端为此引入了 Nameserver Policy 机制，允许用户按照域名后缀、关键词或 GeoIP 规则，将不同的 DNS 查询分发到不同的上游服务器。

6.1 Nameserver Policy 的数据结构

以 Clash.Meta（mihomo）内核为例，dns 配置段中的 nameserver-policy 字段接受一个键值映射。键可以是域名后缀（如 +.google.com）、精确域名（如 www.github.com）或 GeoSite 规则集（如 geosite:cn）。值可以是单个 DNS 地址，也可以是地址数组。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*.*"
    - "time.*.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.4.4/dns-query
  fallback:
    - https://8.8.8.8/dns-query
    - https://1.1.1.1/dns-query
    - tls://dns.google:853
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - "+.google.com"
      - "+.facebook.com"
  nameserver-policy:
    "geosite:cn,private":
      - https://223.5.5.5/dns-query
      - https://1.12.4.4/dns-query
    "geosite:geolocation-!cn":
      - https://8.8.8.8/dns-query
      - https://1.1.1.1/dns-query
    "+.qq.com":
      - https://119.29.29.29/dns-query
    "+.taobao.com":
      - https://223.5.5.5/dns-query

这段配置的含义是，所有匹配 geosite:cn 和 geosite:private 的域名使用阿里 DNS 和 DNSPod 的 DoH 服务解析。匹配 geosite:geolocation-!cn 的域名使用 Google 和 Cloudflare 的 DoH 服务解析。+.qq.com 和 +.taobao.com 有独立的解析策略，分别指向腾讯和阿里自家的 DNS。

6.2 匹配优先级与查询流程

当客户端收到一个 DNS 查询请求时，mihomo 内核按照以下顺序进行匹配。

第一优先级是 nameserver-policy 中的精确域名匹配。例如 www.google.com 会命中 +.google.com 规则。第二优先级是 nameserver-policy 中的 GeoSite 规则集匹配。第三优先级是 nameserver 列表，即默认上游。如果 fallback 列表存在且 fallback-filter 判定结果为污染，则使用 fallback 中的服务器重新查询。

在 Fake-IP 模式下，客户端收到 A 记录查询后，会立即返回一个 198.18.x.x 范围内的虚拟 IP，同时异步向上游发起真实 DNS 查询。当真实 IP 返回后，内核将其与 Fake-IP 建立映射关系。后续连接命中该 Fake-IP 时，内核查表还原出真实域名，再根据分流规则决定走直连还是走代理。

这种机制的优点在于 DNS 解析不阻塞连接建立，首包延迟显著降低。缺点在于部分应用会将 Fake-IP 地址缓存到本地，导致切换网络后解析失败。fake-ip-filter 列表中的域名会跳过 Fake-IP 处理，直接返回真实 IP。

6.3 国内走本地，海外走代理的实现细节

国内域名使用本地 DNS 解析的理由很直接。CDN 调度依赖 EDNS Client Subnet（ECS）扩展，本地 DNS 服务器能够将用户所在网段的子网信息传递给权威 DNS，从而返回距离用户最近的 CDN 节点 IP。如果国内域名走了海外 DNS，权威服务器看到的递归查询来源是海外 IP，返回的 CDN 节点可能位于境外，导致访问速度下降甚至无法访问。

海外域名走代理 DNS 的理由同样明确。国内 DNS 服务器对部分海外域名存在污染或劫持，返回的 IP 可能是无效地址或黑洞地址。通过代理隧道向海外 DNS 发起查询，可以绕过污染，拿到真实的 A 记录或 AAAA 记录。

在配置实践中，geosite:cn 规则集覆盖了绝大多数国内域名。对于未被收录的域名，可以通过 fallback-filter 的 geoip-code: CN 进行二次判定。当 nameserver 返回的 IP 属于中国大陆 GeoIP 段时，内核认为解析结果可信，不再触发 fallback 查询。当返回的 IP 不属于中国大陆，或者命中 fallback-filter 中的 ipcidr 黑名单时，内核会使用 fallback 列表重新查询。

6.4 sing-box 的等价实现

sing-box 的 DNS 配置采用了不同的结构，但逻辑等价。dns.rules 数组中的每条规则包含 domain_suffix、domain_keyword、geosite 等匹配条件，以及 server 字段指定上游标签。

{
  "dns": {
    "servers": [
      {
        "tag": "ali",
        "address": "https://223.5.5.5/dns-query",
        "detour": "direct"
      },
      {
        "tag": "google",
        "address": "https://8.8.8.8/dns-query",
        "detour": "proxy"
      }
    ],
    "rules": [
      {
        "geosite": ["cn", "private"],
        "server": "ali"
      },
      {
        "geosite": ["geolocation-!cn"],
        "server": "google"
      }
    ],
    "strategy": "prefer_ipv4",
    "independent_cache": true
  }
}

注意 detour 字段的用法。ali 服务器的 detour 设为 direct，表示 DNS 查询走直连出口。google 服务器的 detour 设为 proxy，表示 DNS 查询走代理出口。这一设计确保了 DNS 查询路径与流量路径的一致性，避免了 DNS 泄漏。

6.5 常见配置陷阱

第一个陷阱是 nameserver 列表中混入了海外 DNS。部分用户在 nameserver 中同时配置了国内和海外 DNS，期望内核自动选择最快的响应。这种做法在 Fake-IP 模式下会导致国内域名被海外 DNS 解析，CDN 调度失效。正确的做法是将国内 DNS 放在 nameserver，海外 DNS 放在 fallback，由 fallback-filter 控制切换时机。

第二个陷阱是 fallback-filter 的 geoip 判定依赖 GeoIP 数据库的准确性。如果数据库未及时更新，新分配的国内 IP 段可能被误判为海外，触发不必要的 fallback 查询。建议定期更新 GeoIP 数据库，或在 ipcidr 中手动添加已知的国内 IP 段。

第三个陷阱是 DoH 服务器的域名本身需要解析。如果 nameserver 中配置的是 https://dns.google/dns-query 而非 https://8.8.8.8/dns-query，内核需要先解析 dns.google 的 IP 才能建立 DoH 连接。这形成了循环依赖。解决方案是使用 IP 地址直连 DoH 服务器，或者在 hosts 字段中预置 DoH 域名的 IP 映射。

第四个陷阱是 respect-rules 参数的缺失。在 mihomo 内核中，respect-rules: true 确保 DNS 查询遵循分流规则中定义的策略。如果该参数为 false，DNS 查询可能绕过代理规则直接走默认出口，导致 DNS 泄漏。建议在 dns 配置段中显式设置 respect-rules: true。

6.6 验证与排查

配置完成后，可通过以下命令验证 DNS 解析路径。

Terminal window
# 查询国内域名，应返回国内 CDN IP
dig @127.0.0.1 www.taobao.com A +short


# 查询海外域名，应返回真实 IP 而非污染地址
dig @127.0.0.1 www.google.com A +short


# 检查是否存在 DNS 泄漏
curl -s https://1.1.1.1/cdn-cgi/trace | grep "ip="

如果国内域名返回了海外 IP，检查 nameserver-policy 中 geosite:cn 的匹配是否生效。如果海外域名返回了 0.0.0.0 或 127.0.0.1，说明 fallback 未正确触发，检查 fallback-filter 的配置。更多客户端配置细节可参考 配置教程保姆级指南，其中包含了各主流客户端的完整配置模板与排查清单。若需要对比不同服务商在 DNS 分流场景下的实际表现，机场评测中心深度对比大全 提供了延迟、丢包率与 DNS 泄漏测试的横向数据。

七、DNS 泄漏在线检测实操与 WebRTC 旁路泄漏漏洞全流程排查修复

7.1 DNS 泄漏的判定标准与数据包特征

DNS 泄漏的本质是查询流量未经过代理隧道或加密通道，直接以明文 UDP 53 端口发往本地运营商递归服务器。判定一次请求是否构成泄漏，需要同时满足两个条件。查询报文的目的地址属于 ISP 或公共递归服务器，且该报文未经过 TUN 虚拟网卡或 SOCKS5 代理封装。

从数据包结构看，一次典型的泄漏查询在 Wireshark 中表现为以下特征。以太网帧类型为 0x0800，IP 头部协议字段为 17 表示 UDP，源端口为随机高位端口，目的端口固定为 53。DNS 报文头部 Transaction ID 为 2 字节，Flags 字段中 RD 位为 1 表示期望递归。当响应返回时，Answer 段中的 A 记录地址若与代理出口 IP 所在地区不符，即可判定为泄漏。

在 TUN 模式下，正常的 DNS 查询应当被虚拟网卡捕获，目的地址改写为 198.18.0.0/16 网段内的 Fake-IP 地址，随后由核心组件根据域名映射表转发至远端解析。若在 tcpdump -i eth0 udp port 53 的输出中看到真实公网 DNS 服务器地址，说明查询绕过了 TUN 路由表。

7.2 在线检测工具的操作流程与结果解读

目前主流的 DNS 泄漏检测平台包括 dnsleaktest.com、browserleaks.com/dns 与 ipleak.net。以 dnsleaktest.com 的 Extended Test 为例，其工作原理是向一组随机生成的子域名发起解析请求，服务端记录递归查询的来源 IP 与 ASN 信息。若返回结果中出现中国电信、中国联通或阿里云 DNS 的 ASN 编号，则确认存在泄漏。

执行检测前需要确保代理处于全局模式或已正确配置 DNS 分流规则。检测结果中若出现多个不同地理位置的 DNS 服务器，说明系统存在多网卡或 IPv6 双栈导致的并行查询。此时应检查 /etc/resolv.conf 或 Windows 的 Get-DnsClientServerAddress 输出，确认是否存在未被代理接管的备用 DNS。

对于企业出海运维场景，建议使用 dig 配合 +trace 参数进行链路级验证。命令 dig +trace +nodnssec www.example.com 会从根服务器开始逐级查询，输出中每一跳的服务器地址均可对照代理出口位置。若某一跳的响应来自本地 ISP，则该跳即为泄漏点。

7.3 WebRTC 旁路泄漏的原理与危害

WebRTC 的 ICE 候选收集机制是独立于 HTTP 代理的旁路通道。根据 RFC 8445 定义，ICE Agent 会通过 STUN 协议向公网服务器发送 Binding Request，以获取本机的 Server Reflexive 候选地址。该过程使用 UDP 或 TCP，不经过浏览器的代理设置，因此即使系统代理已开启，WebRTC 仍可能暴露真实公网 IP。

STUN Binding Request 的数据包格式为 20 字节头部加属性字段。头部中 Message Type 为 0x0001，Magic Cookie 固定为 0x2112A442。当请求到达 STUN 服务器后，响应中的 XOR-MAPPED-ADDRESS 属性会携带 NAT 映射后的公网地址。若该地址与代理出口 IP 不一致，则第三方网站可通过 JavaScript 的 RTCPeerConnection API 读取该地址，实现用户真实 IP 的精确识别。

在企业环境中，WebRTC 泄漏可能导致运维人员的办公网络出口 IP 被目标站点记录，进而触发风控或地域封锁。对于需要严格隐藏出口位置的场景，必须对 WebRTC 的候选收集行为进行限制。

7.4 全流程排查与修复配置

排查顺序应遵循从系统层到应用层的原则。第一步，检查系统 DNS 配置是否已被代理接管。Linux 下执行 resolvectl status 查看当前接口的 DNS 服务器，若显示 Current DNS Server 为 114.114.114.114 或 223.5.5.5，则需要通过 TUN 模式或 iptables 规则重定向 53 端口流量。

第二步，在浏览器层面禁用 WebRTC 的非代理 UDP 传输。Chrome 可通过策略文件配置 WebRtcIPHandlingPolicy 为 disable_non_proxied_udp，该策略会强制 ICE 仅使用代理相关的候选地址。Firefox 则在 about:config 中将 media.peerconnection.ice.proxy_only_if_behind_proxy 设为 true。

第三步，验证修复效果。重新访问 browserleaks.com/webrtc，页面中 Public IP 字段应显示代理出口地址或为空。同时使用 dnsleaktest.com 确认 DNS 服务器列表仅包含代理服务商提供的解析节点。

以下为 Clash Meta 内核中防止 DNS 泄漏的关键配置片段，配合 tun 模式与 dns-hijack 使用可覆盖绝大多数场景。

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
    - tcp://any:53
dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - tls://8.8.8.8:853
  fallback:
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

配置完成后，通过 curl -s https://1.1.1.1/cdn-cgi/trace | grep "ip=" 确认出口 IP，再结合 dig @127.0.0.1 -p 1053 www.google.com 验证本地 DNS 监听是否生效。若返回 Fake-IP 地址段内的结果，说明 DNS 查询已进入代理隧道。

对于需要横向对比不同服务商在 DNS 防泄漏与 WebRTC 处理上的实际表现，机场评测中心深度对比大全 提供了包含泄漏测试项的完整数据。若在排查过程中遇到客户端兼容性问题，配置教程保姆级指南 中收录了各平台客户端的完整配置模板与常见故障处理清单。选择具备 TUN 模式与 DNS 劫持能力的服务商是规避泄漏的前提，2026 优质稳定高速机场推荐总榜 中的条目均经过 DNS 泄漏与 WebRTC 旁路测试验证。关于代理协议的底层封装细节，可参阅 专线百科 中关于 TUN 与 SOCKS5 转发机制的说明。在订阅服务商时，还需警惕以次充好的节点导致 DNS 请求被中间人劫持，科学上网防跑路避坑指南 中列举了相关风险特征与识别方法。

八、Windows、macOS、iOS 与软路由 OpenWrt 防 DNS 污染最佳实践配置

DNS 污染的本质是中间设备在 UDP 53 端口上抢先返回伪造响应。以 dig @8.8.8.8 example.com 为例，正常查询的 DNS 报文头部为 12 字节，包含 Transaction ID、Flags、QDCOUNT 等字段。污染设备通常在真实响应到达前注入一个伪造包，其 Flags 字段的 QR 位为 1、RA 位为 1，Answer 段返回一个不存在的 IP 或黑洞地址。客户端收到首个响应即采纳，真实响应被丢弃。理解这一机制后，各平台的防护配置就有了统一目标，让 DNS 查询走加密通道，或在本地完成域名到 IP 的映射，使污染包无处生效。

Windows 平台配置

Windows 10 与 Windows 11 原生支持 DoH，但默认关闭。通过设置界面启用的 DoH 仅对系统解析器生效，代理软件若使用自有 DNS 模块则不受影响。更彻底的方案是在代理客户端内启用 TUN 模式并劫持 53 端口。

以 Clash Meta 内核为例，配置文件 config.yaml 的关键段落如下。

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.windows.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  fallback:
    - https://8.8.8.8/dns-query
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

fake-ip-range 使用 198.18.0.1/16 这一保留网段，客户端收到该网段地址后，代理内核在 TCP 握手阶段根据映射表还原真实域名。fallback-filter 中的 geoip-code: CN 表示当 nameserver 返回的 IP 归属中国时，直接采纳，不触发 fallback，从而避免国内域名绕行境外解析带来的延迟。

TUN 模式需安装 Wintun 驱动，Clash Meta 在 Windows 上通过 tun 字段启用。

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

dns-hijack 将发往任意地址的 53 端口流量重定向至内核 DNS 监听端口。auto-route 修改系统路由表，将默认路由指向 TUN 虚拟网卡。验证是否生效可在 PowerShell 中执行 nslookup example.com，若返回 198.18.x.x 网段地址，说明 Fake-IP 已接管。进一步执行 Get-DnsClientServerAddress 确认物理网卡的 DNS 服务器已被内核覆盖。

若使用 sing-box 内核，配置结构略有不同，DNS 部分采用 dns.servers 数组，strategy 字段可设为 ipv4_only 或 prefer_ipv4，避免 AAAA 记录查询被污染后导致连接超时。sing-box 的 sniff 功能可在入站连接中提取 SNI 与 HTTP Host，与 Fake-IP 配合实现域名还原。

macOS 平台配置

macOS 的 DNS 解析由 mDNSResponder 进程管理，系统级 DoH 在 macOS 11 之后才通过配置文件描述符支持。代理客户端同样推荐 TUN 模式，但 macOS 上 TUN 设备的创建需要 root 权限，ClashX Meta 与 Stash 均通过辅助进程完成。

Surge for Mac 的 DNS 配置采用自有语法。

[General]
dns-server = 223.5.5.5, 119.29.29.29
encrypted-dns-server = https://8.8.8.8/dns-query, https://1.1.1.1/dns-query

encrypted-dns-server 指定 DoH 上游，Surge 在解析时优先使用加密通道。[Host] 段可手动指定域名到 IP 的映射，绕过 DNS 查询。

[Host]
*.example.com = 1.2.3.4

macOS 上验证 DNS 泄漏的方法是访问 https://www.dnsleaktest.com，若结果中出现的 DNS 服务器为代理服务商所在地而非本地 ISP，说明配置正确。另一个方法是使用 scutil --dns 查看系统解析器列表，确认 TUN 网卡的 DNS 地址排在首位。

macOS 的 /etc/resolv.conf 在较新版本中由系统动态生成，手动编辑无效。若需在非 TUN 模式下强制加密 DNS，可安装 dnscrypt-proxy 并通过 launchd 守护进程运行，将系统 DNS 指向 127.0.0.1:53。

iOS 平台配置

iOS 的网络栈封闭，第三方应用无法直接修改系统 DNS。可行的方案有三类。

第一类，使用支持 Network Extension 的代理客户端，如 Shadowrocket、Stash、Quantumult X。这些应用通过 NEPacketTunnelProvider 创建 TUN 接口，在应用内实现 DNS 劫持与 Fake-IP。Shadowrocket 的配置中，[General] 段的 dns-server 与 fallback-dns-server 分别指定国内与国外上游，always-real-ip 列表用于排除需要真实解析的域名。

第二类，安装 DNS 描述文件。iOS 14 起支持加密 DNS 配置描述文件，通过 https://example.com/dns.mobileconfig 安装后，系统所有 DNS 查询走指定 DoH 或 DoT 服务器。描述文件的核心字段如下。

<key>DNSSettings</key>
<dict>
  <key>DNSProtocol</key>
  <string>HTTPS</string>
  <key>ServerURL</key>
  <string>https://8.8.8.8/dns-query</string>
</dict>

此方案对系统全局生效，代理应用内的 DNS 模块若启用 Fake-IP 则优先级更高。

第三类，在家庭 Wi-Fi 路由器层面统一处理，iOS 设备无需任何配置。这也是软路由方案的价值所在。

OpenWrt 软路由配置

OpenWrt 上实现防 DNS 污染的标准组合是 dnsmasq 配合 https-dns-proxy 或 smartdns，再叠加代理内核的 TUN 或透明代理。

https-dns-proxy 在 OpenWrt 上以独立进程运行，监听本地端口，将 DNS 查询转为 DoH。安装后配置 /etc/config/https-dns-proxy。

config main 'config'
    option update_dnsmasq_config '*'
    option force_dns '1'


config resolver 'google'
    option resolver_url 'https://8.8.8.8/dns-query'
    option listen_addr '127.0.0.1'
    option listen_port '5053'
    option bootstrap_dns '8.8.8.8'

force_dns 设为 1 时，插件会修改 dnsmasq 配置，将所有 DNS 查询转发至本地 DoH 代理。bootstrap_dns 用于解析 DoH 服务器域名本身，避免先有鸡还是先有蛋的问题。

smartdns 提供更细粒度的控制，支持多上游并发查询与测速选优。配置文件 /etc/smartdns/smartdns.conf 关键段落如下。

server https://8.8.8.8/dns-query -exclude-default-group -group overseas
server https://1.1.1.1/dns-query -group overseas
server 223.5.5.5 -group domestic
server 119.29.29.29 -group domestic


nameserver /cn/domestic
nameserver /com/overseas

nameserver /cn/domestic 表示 .cn 域名走国内上游，其余走境外 DoH。-exclude-default-group 将特定服务器排除出默认组，避免所有查询都发往境外。

代理内核方面，OpenWrt 上常用 openclash 或 passwall。OpenClash 的 Fake-IP 模式与 dnsmasq 存在端口冲突，需将 dnsmasq 的监听端口改为 5353，由 OpenClash 接管 53 端口。OpenClash 配置中 dns-hijack 与 fake-ip-filter 的用法与 Windows 端一致。

验证 OpenWrt 配置是否生效，可在路由器上执行 nslookup example.com 127.0.0.1，观察返回地址是否落在 Fake-IP 网段。同时执行 tcpdump -i any port 53 -nn 抓包，确认无明文 DNS 查询流出 WAN 口。若仍有 UDP 53 流量，说明 force_dns 未生效或存在应用绕过 dnsmasq 直接向外部 DNS 发起查询。

跨平台共性要点

四个平台的配置虽有差异，核心原则一致。DNS 查询必须经过加密通道或本地映射，明文 UDP 53 流量必须被拦截或重定向。Fake-IP 模式在代理场景下效率最高，但需维护 fake-ip-filter 列表，将局域网域名、NTP 服务器、部分银行与流媒体域名排除，避免解析异常。DoH 与 DoT 的选择上，DoH 使用 443 端口，与 HTTPS 流量混在一起，更难被识别与阻断，DoT 使用 853 端口，部分网络会直接封锁该端口。

对于需要横向对比不同服务商在 DNS 防泄漏与 WebRTC 处理上的实际表现，机场评测中心深度对比大全 提供了包含泄漏测试项的完整数据。若在排查过程中遇到客户端兼容性问题，配置教程保姆级指南 中收录了各平台客户端的完整配置模板与常见故障处理清单。选择具备 TUN 模式与 DNS 劫持能力的服务商是规避泄漏的前提，2026 优质稳定高速机场推荐总榜 中的条目均经过 DNS 泄漏与 WebRTC 旁路测试验证。关于代理协议的底层封装细节，可参阅 专线百科 中关于 TUN 与 SOCKS5 转发机制的说明。在订阅服务商时，还需警惕以次充好的节点导致 DNS 请求被中间人劫持，科学上网防跑路避坑指南 中列举了相关风险特征与识别方法。

九、典型 DNS 解析超时、证书域名不匹配与节点断连故障排查

DNS 故障在代理链路中往往表现为看似无关的症状。用户报告“节点连不上”，实际根因可能是 DNS 查询在 5 秒内未收到响应，导致客户端在 TCP 握手前就已放弃。本章按三类高频故障逐一拆解，每类给出抓包特征、判定命令与修复配置。

9.1 DNS 解析超时

DNS 超时的典型表现是客户端日志出现 lookup domain.com: i/o timeout 或 context deadline exceeded。在 Linux 上先用 dig 确认基础解析是否正常。

Terminal window
dig @8.8.8.8 example.com A +time=2 +tries=1
dig @1.1.1.1 example.com AAAA +short

若 @8.8.8.8 返回 connection timed out; no servers could be reached，而 @1.1.1.1 正常，说明 UDP 53 到 8.8.8.8 的路径被阻断。此时用 tcpdump 观察是否有响应包回来。

Terminal window
tcpdump -i eth0 -nn -vv 'udp port 53 and host 8.8.8.8'

若只看到出站查询包，没有任何入站响应，可判定为中间设备丢弃了 UDP 53 响应。部分网络对 UDP 53 实施无状态丢弃，对 TCP 53 放行。用 dig +tcp 验证。

Terminal window
dig @8.8.8.8 example.com +tcp +time=3

若 TCP 53 可通，解决方案是强制客户端走 DoH 或 DoT。以 dnsmasq 为例，配置上游为 DoH 需借助 dnscrypt-proxy 或 https-dns-proxy。更直接的方式是在代理客户端内启用 DoH。以 Clash.Meta 为例，配置片段如下。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    ipcidr:
      - 240.0.0.0/4

fallback-filter 中的 240.0.0.0/4 用于过滤虚假 IP 响应。当 nameserver 返回的 IP 落在该网段时，Clash 会改用 fallback 重新查询。这一机制对抵御 DNS 污染至关重要，具体原理可参阅 专线百科 中关于 Fake-IP 与 fallback 协同工作的说明。

另一个常见超时原因是 resolv.conf 中配置了多个不可达的 nameserver，而 glibc 的默认超时策略是每个 server 等待 5 秒，attempts 默认 2 次。三个不可达 server 意味着最长 30 秒阻塞。用 options timeout:1 attempts:1 可缩短至 3 秒。

nameserver 127.0.0.1
options timeout:1 attempts:1 rotate

若使用 systemd-resolved，需注意 resolvectl 的缓存可能返回过期记录。用 resolvectl flush-caches 清除后再测。

9.2 证书域名不匹配

证书域名不匹配的报错文本通常为 x509: certificate is valid for a.com, not b.com 或 SSL: no alternative certificate subject name matches target host name。这类故障在代理场景下有三类根因。

第一类是 SNI 与 Host 不一致。当客户端用 IP 直连节点，但 TLS 握手时发送的 SNI 为节点域名，而服务端返回的证书 CN 为另一个域名。用 openssl s_client 可直接观察。

Terminal window
openssl s_client -connect node.example.com:443 -servername node.example.com -showcerts </dev/null 2>&1 | openssl x509 -noout -subject -ext subjectAltName

输出中的 subject 与 subjectAltName 必须包含你连接时使用的域名。若 subjectAltName 为空且 subject 为 CN = *.example.net，而你连接的是 node.example.com，则必然报错。

第二类是 CDN 回源配置错误。节点域名 CNAME 到 CDN，CDN 回源时携带的 Host 头与证书签发域名不一致。用 curl -v 观察完整握手。

Terminal window
curl -v --resolve node.example.com:443:1.2.3.4 https://node.example.com 2>&1 | grep -E 'subject|issuer|SSL'

若 issuer 为 Let’s Encrypt 但 subject 为 CDN 默认域名，说明 CDN 未正确绑定自定义域名证书。修复需在 CDN 控制台上传对应域名的证书与私钥。

第三类是客户端启用了 skip-cert-verify 但服务端证书链不完整。部分客户端在 skip-cert-verify: false 时要求完整链，若服务端只发送叶证书而未发送中间证书，会报 unable to get local issuer certificate。用 openssl s_client -connect node.example.com:443 -showcerts 检查返回的证书数量。正常应返回 2 至 3 张，叶证书加中间证书加根证书。若只有 1 张，需在服务端配置 ssl_certificate 时拼接中间证书。

ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
ssl_trusted_certificate /etc/ssl/chain.pem;

fullchain.pem 必须包含叶证书与所有中间证书，顺序为叶证书在前。用 cat cert.pem intermediate.pem > fullchain.pem 生成。

对于使用 Reality 或 XTLS 的节点，证书验证由客户端内置的公钥指纹完成，不依赖 CA 链。若报 REALITY: processed invalid connection，需检查客户端 public-key 与服务端 private-key 是否配对。用 openssl x509 -in cert.pem -noout -pubkey 提取公钥后比对。

9.3 节点断连

节点断连的表现是 TCP 连接建立后短时间内被 RST，或连接保持但无数据转发。用 ss 观察连接状态。

Terminal window
ss -tnp state established '( dport = :443 or sport = :443 )'
ss -tni state established dst 1.2.3.4

ss -tni 输出的 rtt、retrans、cwnd 字段可判断链路质量。若 retrans 持续增长而 cwnd 降至 1，说明存在严重丢包。用 mtr 定位丢包节点。

Terminal window
mtr -n -c 100 -r 1.2.3.4

若丢包集中在某一跳且后续跳恢复正常，通常是该跳路由器限速 ICMP，不影响 TCP。若丢包持续到目标，则链路确实拥塞。

TCP RST 的另一种来源是中间设备识别到代理协议特征后主动阻断。用 tcpdump 抓取 RST 包的 TTL 与 IP ID 可辅助判断。

Terminal window
tcpdump -i eth0 -nn -vv 'tcp[tcpflags] & tcp-rst != 0 and host 1.2.3.4'

若 RST 包的 TTL 与正常服务端响应 TTL 差异较大，例如正常为 52 而 RST 为 240，说明 RST 来自中间设备而非服务端。此时需更换协议或启用混淆。Shadowsocks 2022 的 blake3-aes-128-gcm 加密套件在抗主动探测方面优于旧版 aes-256-gcm，配置如下。

{
  "method": "2022-blake3-aes-128-gcm",
  "password": "base64_encoded_16byte_key",
  "server_port": 8388
}

服务端与客户端需使用相同的 16 字节 base64 密钥。用 openssl rand -base64 16 生成。

若断连发生在 TLS 握手完成后约 30 秒，可能是服务端的 handshake-timeout 或 idle-timeout 设置过短。以 Xray 为例，policy 中 connIdle 默认 300 秒，handshake 默认 4 秒。若客户端网络 RTT 较高，4 秒可能不足。调整为 10 秒。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 10,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

对于 TUN 模式下的断连，需检查路由表是否将代理进程自身的流量也导入了 TUN，形成环路。用 ip rule 与 ip route show table all 确认。Clash.Meta 的 tun 配置中 auto-route 与 auto-detect-interface 需配合使用，并确保 dns-hijack 包含 any:53。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

若 stack 为 gvisor，在部分内核版本上会出现 no route to host。切换为 system 或 mixed 可缓解。

排查过程中若需对比不同服务商在断连恢复与 DNS 容错上的表现，机场评测中心深度对比大全 提供了包含丢包率与重连时延的测试数据。对于客户端配置细节，配置教程保姆级指南 中收录了各平台 TUN 模式与 DNS 劫持的完整模板。选择具备 BGP 多线接入与智能路由的服务商可显著降低断连概率，2026 优质稳定高速机场推荐总榜 中的条目均经过 72 小时持续连接稳定性测试。若遇到服务商频繁更换节点域名导致证书不匹配，需警惕其基础设施稳定性，科学上网防跑路避坑指南 中列举了相关风险特征。

十、总结与全网 DNS 安全强化清单

DNS 污染的对抗是一场发生在 UDP 53 端口、TLS 握手层与内核路由表之间的持续博弈。从明文查询被中间设备抢答，到 Fake-IP 映射表与 TUN 栈的协同，再到 DoH/DoT 加密隧道的建立，每一层防护都有其明确的适用边界与失效条件。本章将前述技术要点收敛为一份可执行的清单，并补充若干容易被忽略的底层细节。

10.1 污染注入的数据包特征回顾

理解防护的前提是理解攻击面。典型的 DNS 污染注入包具有以下可观测特征。当客户端向递归解析器发出 A 记录查询后，若在真实响应到达之前收到一个源 IP 与目标解析器不符、TTL 异常（常见为 0 或极大值）、且 Answer 段指向保留地址或无关 IP 的 UDP 包，即可判定为注入。以 dig 抓取为例，污染响应的 DNS 头部 Flags 字段常表现为 0x8180（标准响应，递归可用，无权威），而真实响应在递归查询场景下同样为 0x8180，二者仅靠 Flags 无法区分，必须结合源端口、Transaction ID 与到达时序判断。这也是为什么单纯依赖客户端重试无法根治污染，攻击者往往在真实响应前数毫秒内抢先注入。

在 RFC 1035 定义的报文结构中，Question 段的 QNAME 采用标签序列编码，例如 www.example.com 编码为 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00。污染设备正是通过解析该字段匹配关键词后触发注入。因此，任何改变 QNAME 外观的编码手段（如 DNS over HTTPS 将整个查询封装进 TLS 应用数据）都能绕过基于明文匹配的注入。

10.2 Fake-IP 与 DNS 泄漏的耦合关系

Fake-IP 模式的核心是在本地维护一张虚拟 IP 到域名的映射表，客户端拿到的是 198.18.0.0/15 或 fc00::/18 范围内的假地址，真实解析由代理核心在远端完成。这一机制天然阻断了污染包对业务的影响，因为客户端根本不使用真实 DNS 响应。但它引入了一个新问题，即 DNS 泄漏的判定变得复杂。若代理规则中遗漏了某域名，或 TUN 栈的 DNS 劫持未覆盖全部网卡，该域名的查询仍可能以明文形式发往本地 ISP 的解析器，导致 Fake-IP 映射表与真实解析结果不一致，表现为部分应用连接超时或证书校验失败。

检测泄漏的可靠方法是同时抓取物理网卡与 TUN 网卡的 53 端口流量。在 Linux 下可使用 tcpdump -i any -n port 53 观察是否存在目的地址为公网解析器的明文查询。若存在，则说明 DNS 劫持规则未生效。对于 Windows 平台，pktmon filter add 53 配合 pktmon start 可达到类似效果。

10.3 DoH 与 DoT 的选型参数

特性 DoH (RFC 8484) DoT (RFC 7858)
传输层 HTTPS (TCP 443) TLS (TCP 853)
报文封装 HTTP/2 或 HTTP/3 帧 长度前缀的 DNS 消息
端口可识别性 与普通 HTTPS 流量混同 853 端口易被针对性阻断
连接复用 支持多路复用 单连接串行
典型 RTT 开销 首次握手增加 1 至 2 个 RTT 首次握手增加 1 至 2 个 RTT
适用场景 抗阻断优先 低延迟内网解析

DoH 将 DNS 查询编码为 application/dns-message 类型的 HTTP 请求体，GET 模式下还需 Base64URL 编码并附加 ?dns= 参数。由于走 443 端口，其流量特征与常规网页访问难以区分，在对抗深度包检测时优势明显。DoT 则因 853 端口固定，一旦被识别即可通过 RST 或黑洞路由阻断。企业出海场景中，若解析器位于境内且需稳定低延迟，DoT 配合连接池是合理选择。若解析器在境外且链路存在主动干扰，DoH 的伪装能力更值得依赖。

10.4 全网 DNS 安全强化清单

以下清单按优先级排列，覆盖客户端、代理核心与服务端三个层面。

客户端层面

  1. 确认 TUN 模式已启用 DNS 劫持，所有网卡的 DNS 请求被重定向至代理核心的虚拟解析器。Windows 下需检查 netsh interface ip show dns 输出，确保无残留的公网 DNS 地址。
  2. 关闭操作系统的 DNS 缓存或将其 TTL 设为极小值，避免污染响应被缓存后持续生效。Linux 下可执行 systemd-resolve --flush-caches。
  3. 若使用 Fake-IP，将映射表范围与代理规则中的 fake-ip-filter 对齐，确保需要真实解析的域名（如 STUN 服务、部分游戏服务器）不被映射。
  4. 启用代理核心的 respect-rules 选项，使 DNS 查询本身也遵循分流规则，避免解析请求泄漏至直连链路。

代理核心层面

  1. 在配置中显式指定 dns.nameserver 为 DoH 或 DoT 地址，并配置 fallback 与 fallback-filter。以下为一段可用的配置片段。
dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*.*"
  nameserver:
    - https://dns.cloudflare.com/dns-query
    - tls://dns.google:853
  fallback:
    - https://doh.opendns.com/dns-query
  fallback-filter:
    geoip: true
    ipcidr:
      - 240.0.0.0/4
  1. 定期检查代理核心日志中的 DNS 查询记录，确认无明文 53 端口的外发请求。若使用 Clash 内核，可开启 log-level: debug 观察 dns 模块的输出。
  2. 对于使用 gvisor 栈的环境，若出现 DNS 解析间歇性失败，切换至 system 栈或 mixed 栈，并确认内核版本不低于 5.10。部分 4.19 内核在 gvisor 下对 UDP 53 的重定向存在已知缺陷。

服务端与链路层面

  1. 验证代理服务商是否在其入口处对 53 端口进行了透明劫持。可通过向一个已知不存在的域名发起查询，观察返回的 SOA 记录是否来自服务商内网解析器。
  2. 若服务商提供自建 DoH 端点，优先使用其作为 nameserver，减少跨境解析的 RTT 开销。跨境 DoH 查询的典型延迟在 80ms 至 200ms 之间，而就近解析可控制在 10ms 以内。
  3. 警惕服务商频繁更换节点域名导致 DoH 证书不匹配的情况。证书 CN 与 SAN 字段的异常变化往往预示基础设施不稳定，相关风险特征在 科学上网防跑路避坑指南 中有详细列举。

10.5 验证与持续监控

配置完成后，需通过以下命令验证防护效果。使用 dig @127.0.0.1 -p 1053 example.com 确认本地解析器返回 Fake-IP 地址。使用 curl -v https://1.1.1.1/dns-query?dns=... 验证 DoH 端点可达性。使用 tcpdump -i eth0 -n port 53 确认物理网卡无明文 DNS 流量。三项检查全部通过，方可认为 DNS 污染防护链路完整。

持续监控方面，建议在代理核心中启用 DNS 查询日志的采样记录，关注 fallback 触发频率。若某域名频繁触发 fallback，说明主 nameserver 对其解析结果被污染或超时，需将其加入 fallback-filter 的 domain 列表或调整解析策略。

对于需要横向对比不同服务商在 DNS 容错与断连恢复上表现的场景，机场评测中心深度对比大全 提供了包含丢包率与重连时延的测试数据。客户端配置的完整模板可参考 配置教程保姆级指南，其中收录了各平台 TUN 模式与 DNS 劫持的详细参数。若需深入理解不同代理协议在传输层对 DNS 查询的封装差异，专线百科 中有针对 WireGuard、Trojan 与 Hysteria 的报文级分析。选择具备 BGP 多线接入与智能路由的服务商可显著降低断连概率，2026 优质稳定高速机场推荐总榜 中的条目均经过 72 小时持续连接稳定性测试，可作为选型参考。

DNS 安全没有一劳永逸的配置。污染手段在演进，加密解析的标准也在更新，RFC 8484 之后已有关于 Oblivious DoH 的草案讨论。保持对解析链路每一跳的可观测性，定期复核清单中的每一项，才是长期稳定的前提。