DNS 配置优化 - 洛璃 Blog

最近在优化 DNS 配置，想通过实测数据找到最优的 DNS 服务器组合。本文记录了完整的测试过程和最终配置。但是在此之前，先讲一下基础的知识：

代理场景下的 DNS 劫持#

DNS 劫持（本地对 53 端口的全局监听拦截）并不局限于虚拟网卡（TUN）模式，在纯代理模式下同样可以生效，只是生效的路径和作用对象有所不同。

关键在于区分「直连流量」和「代理流量」这两条路径对 DNS 结果的依赖程度是完全不同的：

直连流量：本地 DNS 解析出的 IP 会被实际用于建立连接，因此这条路径真正依赖本地 DNS 服务器返回结果的准确性。如果本地 DNS 被污染或被 ISP 劫持，直连流量会直接连到错误的地址。
代理流量：域名会被完整传递给本地代理，由代理软件自己完成解析并建立连接，本地 DNS 在这条路径上毫无意义。其中除 DIRECT 之外，需要被转发到远程节点的流量的 IP 是代理解析到的远程节点 IP，访问网站的 DNS 由远程节点解析。

这个分层恰好和实际的域名分布形成了一种天然的风险缓释：

需要直连 / DIRECT 的域名基本以国内域名为主，这部分即便使用国内 DNS 解析，被污染的概率本身就较低，风险可控；而真正需要抗污染诉求的境外域名，几乎全部被规则匹配为走远程节点，本地解析结果根本不会进入实际连接环节，污染也就无从影响，但依然会有 DNS 泄露风险。

fake-ip 机制说明#

fake-ip 在代理无效，正如上所说，没有需要篡改 DNS 结果的地方。在 TUN 模式下：

应用发起 DNS 查询，系统 DNS 回应
代理软件拦截并返回一个假 IP（fake-ip-range范围内的地址）
应用用这个假 IP 发起连接
代理软件在虚拟网卡流量层识别出目标是 fake-ip 段地址，拦截这条连接
代理软件从内部映射表中取出这个假 IP 对应的原始域名，按分流规则处理

因此，在 fake-ip 模式下，本地 DNS 服务器实际扮演的角色是触发拦截的信号，而非提供最终解析结果的权威源——它的核心作用是让代理软件能够识别出这是一次 DNS 查询、需要介入处理，至于解析出来的 IP 具体是什么、准不准，对于会被代理接管的域名而言并不重要，真正的、会被使用的解析工作发生在代理服务器一侧。

DNS Benchmark 测试#

xxnuo

dns-benchmark

dnspy 是一个批量 DNS 服务器基准测试工具，用于本地测量全世界的 DNS 服务器的可访问性和性能。生成可视化图表。dnspy is a bulk DNS server benchmarking tool used to measure the local accessibility and performance of DNS servers worldwide. It generates visual charts.

—

no-license

使用 DNS Benchmark 工具测试了尽可能全的 DNS 服务器列表，得到以下结果:

Warning

本测试结果具有高度的地域和网络环境特定性。测试基于河北省中国电信公网 IP 段 27.184.0.0/16(AS4134 ChinaNet 中国电信骨干网)进行，采用无 NAT 公网直连方式。不同地区、不同运营商、不同网络拓扑（家宽/移动数据/数据中心）、甚至不同时间下，DNS 服务器的性能表现都可能存在显著差异。建议读者在实际使用前，使用 DNS Benchmark 等工具在自身网络环境下进行实测，本文仅提供测试方法论和配置思路参考。

指标分析#

在这些指标中，QPS (每秒查询数) 是最重要的。为什么不选延迟最低的 156.154.71.2? 因为延迟指标波动极大，多次测试结果差异明显，参考价值有限。相比之下，QPS 是稳定的性能指标，直接反映 DNS 服务器的处理能力。

综合考虑:

QPS - 硬指标，决定实际性能
综合表现 - 平衡多个维度
成功率 - 保证可用性
延迟 - 参考意义最小

最终配置#

default-nameserver#

1
default-nameserver:
2
  - "114.114.115.115"
3
  - "8.8.8.8"
4
  - "1.1.1.1"

用于解析 DoH/DoT 服务器的域名(如 dns.alidns.com)，必须使用纯 IP 格式的 DNS。

DoH 检测中的「引导层查询」问题

这一步查询可能走明文 53 端口，因为在拿到 DoH 服务器 IP、建立起加密通道之前，没有别的办法去解析这个域名——这是协议层面天然存在的依赖关系，跟使用系统内置还是代理软件劫持无关，实测均会出现这一层引导查询，并不存在某种配置方式能够规避它。

这不构成真正的 DNS 泄露，验证方法：DNS 泄露检测结果中若出现两种不同归属的服务器混合出现——大部分域名解析落在预期的 DoH 服务商节点，唯独 DoH 服务商自己的域名解析落在本地 ISP——可作为判断依据。将 DoH 切换为纯明文 UDP DNS 后，该泄露记录消失，说明检测出的并非用户真实查询内容泄露，而是引导层的公开信息查询被检测工具错误计入了泄露范畴，检测工具本身未区分查询内容是否涉及用户隐私，只要是明文 53 端口经过本地 ISP 就一律标记，存在方法论局限。

结论：无需为消除这一条检测记录而调整 DoH 配置，因为该现象与模板来源无关，属于协议本身的固有行为，真正需要保护的用户浏览查询已全部走加密通道。

nameserver (主 DNS 列表)#

1
nameserver:
2
  - "https://dns.alidns.com/dns-query"

阿里 DoH - QPS(132.95) 和延迟 (74 ms) 在 DoH 中最优 (27.184.23.172, 2026/6/21)

排序依据:

mihomo 对 nameserver 是并发查询取最快返回，明文 UDP 几乎永远比 DoH 先到，混用会导致 DoH 形同虚设，且明文有被污染抢答的风险
Google dns64 DoH (https://dns64.dns.google/dns-query) 虽然成功率高 (97.19%)，但是不稳定，且需要设置遵循路由规则(respect-rules: true)

proxy-server-nameserver#

1
proxy-server-nameserver:
2
  - "https://dns.alidns.com/dns-query"
3
  - "https://dns.cloudflare.com/dns-query"
4
  - "https://cloudflare-dns.com/dns-query"

该字段用于解析代理节点服务器域名，请求是直连发出的(还没连上代理)。基于这个前提:

明文 UDP 必须删掉: 节点域名一旦被污染，明文会拿到错误 IP，代理直接连不上
直连境外的 DoH 不可靠: dns.google 等在国内直连本就不稳，留着只会拖慢并发结果
保留国内 DoH + Cloudflare DoH: 阿里 DoH 抗污染稳定，Cloudflare 两个 DoH 域名互为冗余

nameserver-policy (域名服务器策略)#

1
nameserver-policy:
2
  +.steampowered.com:
3
    - "8.8.8.8"

针对特定域名单独指定 DNS 服务器。

Note

此处使用 nameserver-policy 而非 fallback 机制，原因是 fallback 为全局策略，所有域名均需先经 nameserver 查询后再判断是否触发 fallback，开销较大；nameserver-policy 可直接对指定域名匹配特定 DNS，更精准高效。

注意：fallback-filter 仅在 fallback 不为空时生效，若 fallback: []，则 fallback-filter 中的所有规则均不会被执行。

音乐

音乐