VPS DNS 解析慢怎么排查：6 个公共 DNS 实测，114DNS 丢包 100% 照样解析

VPS DNS 解析慢怎么排查，别一上来就动 /etc/resolv.conf。在你自己这台机器上敲一条 curl -sS -o /dev/null -w '%{time_namelookup} %{time_connect} %{time_total}\n' https://你的域名，把一次请求拆成解析、建连、总耗时三段。namelookup 那一栏小得可以忽略，慢就不在 DNS；它要是占了总耗时一大截，再去查现在到底是谁在替你解析。全程只读，不装包、不改配置，跑完还能原样复现一遍。

黑五那几天刚到手一台机器，装环境第一步 apt update 就卡住，光标停在 [Connecting to ...] 那行不动，等了好一会儿才往下爬两格。多数人的第一反应是换镜像，apt 换源怎么换 那篇照着做一遍，源换到国内，还是卡。这时候才有人想起来：连的是域名，域名得先变成 IP。把 curl -w 那行补上去，namelookup 一栏跳上去，锅才落到 DNS 头上。下载源和解析源是两件事，换镜像解决的是前一件。

这次用的是两台自有生产探测源，不是哪家拿来卖的样机，得分开记。cn-probe-1 是 103.39.226.31，中国广东电信 AS4816 单线；cn-probe-2 是 8.140.30.240，中国北京阿里云 AS37963 BGP 多线。采集从 2026-11-09 10:11:17 起，同一时段串行跑完，只用了 ping、curl、dig 和读文件的只读命令，触发解析的公开域名是 www.baidu.com，换成你自己的域名照做就行。两台机器上没改过任何一行系统配置。

先确认慢是不是 DNS 造成的

很多人一觉得卡就怪 DNS，其实一次 HTTPS 请求里，解析只占开头那一小段。想知道该不该怪它，得先把这段时间量出来。

用 curl -w 把一次请求拆开

curl 的 -w 能把一次请求的各段时间打出来，两台源这次实际敲的是这条：

curl -sS -o /dev/null \
  -w 'namelookup=%{time_namelookup} connect=%{time_connect} appconnect=%{time_appconnect} total=%{time_total} ip=%{remote_ip}' \
  --max-time 15 https://www.baidu.com/

四个变量各管一段：%{time_namelookup} 是域名解析完花的时间，%{time_connect} 是 TCP 建连，%{time_appconnect} 是 TLS 握手做完，%{time_total} 是整趟业务总耗时。curl time_namelookup 这一栏就是很多人嘴里的 DNS 慢，它跟后面几段是分开的，别拿 total 当解析时间用。变量含义在 curl 官方手册里逐条列着，%{time_namelookup} 的完整说明也在 同一个手册的 -w 段落里。

双源：两台源对同一域名的分段耗时对照

采集标注：命令为上面那条 curl -sS -o /dev/null -w ... --max-time 15 https://www.baidu.com/，cn-probe-1（中国广东电信 AS4816 单线）与 cn-probe-2（中国北京阿里云 AS37963 BGP 多线）各跑 5 轮，2026-11-09 采集，单位秒。这里用的是每台源系统默认解析器，不是按公共 DNS 拆开的，所以下面这几张表不能拿去给某个公共 DNS 排名。

cn-probe-1 中国广东 电信 AS4816（单线） 103.39.226.31：

cn-probe-2 中国北京 阿里云 AS37963（BGP 多线） 8.140.30.240：

把 5 轮收成均值，两台源摆一起：

双源 namelookup 均值差 0.004772 − 0.004000 = +0.000772 秒，也就是 +0.772 ms。占比那两栏，一台 4.278%，一台 3.584%，算式分别是 0.004772 / 0.111537 和 0.004000 / 0.111600。

我第一次把广东那 5 行贴进表的时候，盯着轮 1 的 0.016547 看了半天，以为是解析器抽了一下，往下翻到轮 2 变成 0.001091 才明白：第一轮多半没吃上缓存。后面四轮 0.001091、0.001964、0.002257、0.002000 都贴得很近，min 0.001091、avg 0.004772、max 0.016547 就是这么来的。所以测解析别只跑一次，多跑几轮取 min 和 avg，单轮高值很容易把人带偏。北京那台更整齐，5 轮 namelookup 全是 0.004000，connect 全是 0.007000。

哪些慢不是 DNS

把两张表横着看，真正的大头不在 namelookup。广东源 appconnect 均值 0.101720 秒、total 均值 0.111537 秒；北京源 appconnect 均值 0.107200 秒、total 均值 0.111600 秒。TLS 那一段比解析大了二十倍不止，解析只占 4.278% 和 3.584% 两栏。这次这个域名在两台源上，DNS 都不是慢的主因。

剩下的时间去别处找：回程那半边拖了没有，去程走的哪条路，TCP 建连和首包是不是被 MTU 卡住，机器本身负载高不高。按线路和方向翻，去程路由怎么查 和 回程线路怎么验证 是两套逐跳读法；要量延迟先看 延迟怎么测才准，那份讲的是 ping 采样口径，跟这里的协议分段不是一回事。包大了卡住可以顺手核一下 路径 MTU 怎么查怎么设，机器自己喘不喘得看 VPS 负载高怎么排查。

半夜被电话叫起来那次，对方第一句就问是不是 DNS。我没接话，先把 curl -w 贴过去，namelookup 那栏小得几乎看不见，appconnect 和 total 才是大头，两栏摆着，是不是 DNS 一眼就有答案。怪 DNS 之前先量一次，比争半小时快。

别急着改配置：先看现在真正生效的解析器是谁

VPS DNS 解析慢怎么排查，最容易跳过的一步是搞清楚「现在到底谁在解析」。不少人照着教程改 /etc/resolv.conf，改完没反应，就是没先弄明白这一层。

只读 cat /etc/resolv.conf 与 resolvectl status

两台源这次把文件原样读了出来，没动一个字。

cn-probe-1（Ubuntu，curl 8.5.0）：

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
nameserver 127.0.0.53
options edns0 trust-ad
search .

cn-probe-2（CentOS 7，curl 7.29.0）：

options timeout:2 attempts:3 rotate single-request-reopen
; generated by /usr/sbin/dhclient-script
nameserver 100.100.2.136
nameserver 100.100.2.138

广东那台的 nameserver 127.0.0.53 是个本地桩，真正往外问的是 systemd-resolved 服务，文件头那行 # Do not edit. 已经写得很直白。常有人搜 /etc/resolv.conf 改了不生效，十次里有九次是这个 stub 在中间挡着：你改了软链指过去的那个文件，或者改完被服务覆写回去，解析照旧走 resolvectl status 里列的上游。想看当前生效的上游，读 resolvectl status 比盯这个文件靠谱。北京那台是 dhclient 生成的两个 100.100 段地址，带 rotate 和 single-request-reopen，属于另一套写法，两台别混着配。

为什么这次不改系统配置

两台都是生产探测源，改一处配置就得跟着改回来，还可能把后面几轮读数搅乱。所以这次全用显式指定解析器的办法：dig @<DNS_IP> 把查询直接递给某个公共 DNS，curl 那 5 轮则只读各源系统默认解析器的表现，谁都没去碰 /etc/resolv.conf。好处是结果能复跑，你在自己机器上敲同样的命令，得到的也是同一套口径。

也因为没有改前改后两批数据，像改了 /etc/resolv.conf 之后提升几倍这类对比，这里一句都不会给。海外VPS 默认DNS慢是不是通病，这次也不下结论，手上只有两台国内源的系统默认解析器读数。

6 个公共 DNS：ping 与 curl 双源、dig 单源（命令与口径）

目标清单与只读命令

搜索框里 223.5.5.5 和 8.8.8.8 哪个快 问得最多，这次两个都在列里。6 个公共 DNS 是 223.5.5.5、223.6.6.6（阿里公共 DNS 主备）、119.29.29.29（腾讯 DNSPod）、114.114.114.114（114DNS）、8.8.8.8（Google Public DNS）、1.1.1.1（Cloudflare）。VPS 公共DNS怎么选、VPS DNS怎么设置，落到命令上就下面几条，都是只读、免安装：

ping -c 20 -W 3 <DNS_IP>
curl -sS -o /dev/null -w 'namelookup=%{time_namelookup} connect=%{time_connect} appconnect=%{time_appconnect} total=%{time_total} ip=%{remote_ip}' --max-time 15 https://www.baidu.com/
dig @<DNS_IP> www.baidu.com A +stats +time=2 +tries=1

ping 两台源都跑，curl 两台源都跑 5 轮，dig 只在有工具的那一台跑，参数含义可以去 BIND 9 的 dig 手册页里查。

一个不能含糊的降级：--dns-servers 两台都用不了

这里得说死，不然后面的表会被读错。原本想用 curl --dns-servers <DNS_IP> 在两台源上按解析器拆开，能力检查直接否掉了：cn-probe-1 回显 the installed libcurl version doesn't support this，cn-probe-2 回显 option --dns-servers: is unknown。再看工具，广东那台 Ubuntu 有 /usr/bin/dig、nslookup、host；北京那台 CentOS 7 是 curl 7.29.0 (NSS)，dig、nslookup、host 一个都没有。

于是按降级纪律收窄：按公共 DNS 拆分的 dig Query time 只来自 cn-probe-1（中国广东电信 AS4816 单线），下面那张 dig 表是单源数据，这张表不能写成「双源实测」，也不能写成两台源都是。北京源按解析器拆分的查询耗时没取得，也不补、不估。北京那台只出现在两处：双源 ICMP 对照，和双源系统默认解析器的 curl 分段拆解。

三个口径别混

表多了最容易看串，先把三个口径钉住：

ping 出来的是包往返延迟，它跟 DNS 解析速度是两码事，正文里不会把 ping 值说成解析快慢。三张表各归各，排名也各排各的。

核心对照：双源 ICMP × 6 公共 DNS，广东源单源 dig

VPS DNS 解析慢怎么排查，值钱的就是下面这几张并排表。每张都标了命令、源和采集时间，数字能一条条对回原始回显。表1 与表1b 是双源数据，表3、表3b、表4 只有广东源单源；编号跳过表2，是因为原计划的双源解析耗时对照在北京源缺少 dig 与 --dns-servers 能力后未能产出，没有补一张凑数。

表1　ICMP 延迟两源对照

采集标注：命令 ping -c 20 -W 3 <DNS_IP>，cn-probe-1（中国广东电信 AS4816 单线）与 cn-probe-2（中国北京阿里云 AS37963 BGP 多线）各对每个 DNS 跑一次，2026-11-09 采集，单位 ms。

表1 里 8.8.8.8 那两行的原始回显也放上来，cn-probe-1 avg 166.160 ms、cn-probe-2 avg 205.174 ms，对着看更清楚：

114.114.114.114 两源都是 20 发 0 收、100% 丢包，未取得延迟，未做任何估算，表里那两格就空着，不替它补一个更快的数。广东源 1.1.1.1 是 18/20、丢包 10%，这栏得连着 avg 198.402 一起看，别只抄一个平均数。

表1b　两源差值与各自极差

采集标注：用表1 的 avg 直接相减，cn-probe-1 减 cn-probe-2，2026-11-09 采集，单位 ms。

三个国内地址广东都比北京慢一点点，+1.696、+4.240、+3.210 ms，量级很小。翻到境外两个就掉头了：8.8.8.8 广东比北京快 39.014 ms，1.1.1.1 快 55.856 ms。广东电信 AS4816 单线对国内目标不吃亏，北京阿里云 AS37963 BGP 多线这两个境外地址反倒绕得更远。各自极差也拉开：cn-probe-1 最低 223.5.5.5 的 4.171、最高 1.1.1.1 的 198.402，差 194.231 ms；cn-probe-2 最低 223.6.6.6 的 0.976、最高 1.1.1.1 的 254.258，差 253.282 ms。

表3　广东源 dig 3 轮 Query time（单源）

采集标注：命令 dig @<DNS_IP> www.baidu.com A +stats +time=2 +tries=1，仅 cn-probe-1（中国广东电信 AS4816 单线），每个 DNS 3 轮，2026-11-09 采集，单位 msec。北京源没有这张表。

广东源这一栏，最低 223.5.5.5 的 3.667 msec，最高 8.8.8.8 的 170.333 msec，差 166.667 msec（170.333 − 3.667）。六个都是 NOERROR，没有一轮超时。

表3b　ICMP 排序 vs dig 查询耗时排序

采集标注：ICMP avg 来自表1 的 cn-probe-1 行，dig 3 轮均值来自表3，同为 2026-11-09 采集、同为广东源，两列各自升序。

有个结论得如实说：两个口径的第一名相同，都是 223.5.5.5，ICMP 4.171 ms、dig 3.667 msec，实测不支持换个口径头名就换人这种话。前三名也一一对得上，阿里主、阿里备、腾讯 DNSPod 在两个口径里都是这个次序。

真正翻掉的是后面两个。ICMP 上 8.8.8.8 166.160 ms 快于 1.1.1.1 198.402 ms，到了 dig 查询耗时，1.1.1.1 52.000 msec 反而比 8.8.8.8 170.333 msec 快一大截，前后次序整个倒过来。所以能下的结论是这一句：ICMP 排序不能预测 DNS 查询耗时排序。ping 值低的那个，解析未必快。

ping 不通，不等于 DNS 不可用

同一台 cn-probe-1（广东电信 AS4816 单线）、同一个 114.114.114.114，ICMP 那张 20 发 0 收、未取得延迟，未做任何估算，dig 那张 status NOERROR、Query time 28 msec、A 记录照给。

见过太多次这个动作：ping 114.114.114.114 一片超时，就把 114DNS 从候选里划掉，顺手在群里丢一句这个已经不能用了。这次广东源 ping 114 确实是 20 发 0 收、100% 丢包、未取得延迟，未做任何估算；可转头跑 dig @114.114.114.114，三轮全 NOERROR，Query time 28、25、25，均值 26.000 msec，A 记录照给 180.101.51.73、180.101.49.44。ICMP 被挡掉，跟 53 端口的解析服务是不是能用，是两件事。「ping 不通 ≠ DNS 不可用」，别拿一次 ping 给解析器判死刑。北京源那个 114 也是 100% 丢包、0/20、未取得延迟，未做任何估算，但北京没跑 dig，它能不能解析这次没有数据，不推断。

能收敛下来的证伪就两条：ICMP 排序预测不了 DNS 查询耗时排序，ICMP 可达性也代表不了 DNS 服务可用性。至于存在一个对所有人都最快的 DNS、换运营商第一名就变这种说法，按解析器拆分的数据只有广东源一份，北京源没测，这次验证不了，不写。

表4　同一域名经不同解析器解析到的 A 记录差异

采集标注：命令 dig @<DNS_IP> www.baidu.com A +stats +time=2 +tries=1，仅 cn-probe-1，取轮 1 的 ANSWER SECTION，2026-11-09 采集。只抄客观结果。

同一个 www.baidu.com，前三个解析器给的是 183.2.172.177，114 给的是两个 180.101 段地址，8.8.8.8 和 1.1.1.1 多了一跳 www.wshifen.com. 的 CNAME、落到另外两组 IP。系统默认解析器那边也对得上：广东源 5 轮 remote_ip 全是 183.2.172.177，北京源在 220.181.111.1 和 220.181.111.232 之间来回。这里只记现象，解析到不同 IP、CNAME 链长短不同，不往别的原因上猜。对 VPS 拉包来说，落到哪个节点是实打实会影响后面那串 connect 和 total 的，所以换解析器之前值得先 dig 一眼。

表5　派生差值汇总

采集标注：下表结果全部由 2026-11-09 采集的原始读数直接相减得到，口径按表1、表3 分列。

哪些结论这次不能下

该下的结论前面都下了，不能下的集中在这儿说一次。按解析器拆分的查询耗时只有广东源一份，凡是要两台源对比解析快慢的说法，都没数据撑着。两台探测源也不代表全国别的运营商和地域。全程没改配置，就没有改前改后，更没有提升几倍那种对比。手上没有商家真机，CPU、磁盘 IO、UnixBench、带宽跑分、流媒体解锁、IP 质量这些一项没测，也不写。解析结果只写返回了什么 IP、CNAME 链长什么样，旁的归因不下。想复跑的，把命令里的 www.baidu.com 换成自己的域名就行。

怎么选：按场景而不是按 ping 排名

VPS 公共DNS怎么选、VPS DNS怎么设置，看完表反倒不该去找一张最快排行榜。两台源的 ICMP 差值和那次排序翻转已经说明，ping 排名换个口径就不作数。

国内域名为主、跨境域名为主、DoH 的取舍

只给决策口径，不给某个地址发奖状。国内域名为主，先拿 dig @<DNS_IP> 你的域名 看解析到的 IP 是不是离你机器近，再看 Query time 稳不稳，表4 那种落到不同节点的情况得自己核一遍。跨境域名为主，重点看解析结果给的是哪组地址，ICMP 上境外 DNS 明显更高（8.8.8.8 广东 166.160 ms、北京 205.174 ms），但别据此断言解析一定慢，表3b 里 1.1.1.1 就是反例。DoH 走的是另一条链路，这次的 ping、curl、dig 三条命令都覆盖不到，不评。至于各家厂商标称的节点数、Anycast 覆盖、SLA、隐私政策，这次没核过官方来源，一个数字都不引。

换 DNS 清单（在你自己机器上照做）

一份能照着走的动作，全在你自己的机器：

1. cat /etc/resolv.conf 加 resolvectl status，先弄清当前谁在解析，别对着 systemd-resolved 的 stub 文件硬改。
2. curl --version 看支不支持 --dns-servers，command -v dig 看有没有 dig，能力不同走不同路子。
3. 有 dig 就用 dig @<DNS_IP> 你的域名 A +stats +time=2 +tries=1，每个候选跑三轮，把 Query time 和返回的 A 记录一起抄下来，显式指定解析器，不碰系统配置。
4. 真要改，改之前备份原文件，改完用 resolvectl status 和 dig 复核生效没有。
5. 拉包链路一起看：解析慢会拖住换源之后每一次域名解析，把下载源换成国内镜像 和选对解析器是一前一后两件事，别只做半边。

这份清单是给你在自己机器上照做的，这次两台探测源全程只读，没有代谁改过任何配置。

常见问题

curl --dns-servers 报错、机器上又没有 dig，怎么办？

这次两台源都撞上了：广东那台回显 the installed libcurl version doesn't support this，北京那台回显 option --dns-servers: is unknown，北京连 dig、nslookup、host 都没有。能做的是把结论收窄：只留双源 ICMP 对照和双源系统默认解析器的 time_namelookup 拆解，按解析器拆分的查询耗时只在有 dig 的那台给，也就是这次的广东源。别为了凑一张双源表去补数。真要临时量，可以先确认机器上有没有 nslookup，命令能不能跑，跑不了就把结论降级，别硬写。

为什么第二次查询明显比第一次快？

看广东源那 5 轮就清楚：轮 1 的 namelookup 是 0.016547，轮 2 掉到 0.001091，后面 0.001964、0.002257、0.002000 都贴在这个量级。第一次多半没吃上缓存，后面命中了。所以量解析别只跑一次，多跑几轮取 min 和 avg，广东源 5 轮 min 0.001091、avg 0.004772、max 0.016547，单看第一轮会以为慢了十倍。北京源 5 轮全是 0.004000，是另一种整齐。

同一个域名，不同 DNS 解析到不同 IP，是不是出问题了？

不一定。表4 里同一个 www.baidu.com，223.5.5.5 给 183.2.172.177，114.114.114.114 给 180.101.51.73 和 180.101.49.44，8.8.8.8 和 1.1.1.1 还多一跳 www.wshifen.com. 的 CNAME，落到 103.235 和 45.113 两组地址。系统默认解析器也一样，北京源 5 轮在 220.181.111.1 和 220.181.111.232 之间换。这里只写客观现象：解析到不同 IP、CNAME 链不同。至于为什么这么调度，只读探测证实不了，不归因，也不写那些没法验证的说法。

改了 /etc/resolv.conf 不生效，是哪里没对？

多半是 systemd-resolved 的桩在中间。广东那台读出来是 nameserver 127.0.0.53，文件头还写着 # Do not edit.，真正往外问的是 resolvectl status 里列的上游；你改的那个文件可能是软链，或者改完被服务覆写回去。北京那台是 dhclient 生成的 100.100.2.136、100.100.2.138，带 rotate，是另一套。先读 resolvectl status 确认当前生效的上游，再决定动哪一处，别对着桩文件反复改。这也正是这次干脆不改、只用 dig @ 显式指定的原因。

ping 值最低的那个 DNS，是不是就该选它？

不该只按这个选。表3b 摆着：ICMP 上 8.8.8.8 166.160 ms 比 1.1.1.1 198.402 ms 快，dig 查询耗时却反过来，1.1.1.1 52.000 msec 对 8.8.8.8 170.333 msec。更极端的是 114.114.114.114，广东源 ping 100% 丢包、0/20、未取得延迟，未做任何估算，dig @114.114.114.114 三轮全 NOERROR、均值 26.000 msec 还正常给 A 记录。ping 量的是包往返，解析量的是 53 端口那一次问答，两码事。真要选，用 dig 对着自己的域名跑三轮，看 Query time 和返回的 IP，比抄一张 ping 榜单稳。

把答案跑在自己机器上

VPS DNS 解析慢怎么排查，动作其实就一条：先 curl -w 把一次请求拆开，确认 namelookup 占了多少；再 cat /etc/resolv.conf、resolvectl status 看清谁在解析；最后用 dig @<DNS_IP> 你的域名 显式指定解析器，多跑几轮，把 Query time 和 A 记录一起抄下来。这次两台不同运营商的源，6 个公共 DNS 的 ICMP 延迟并排摆着，广东源 114DNS 丢包 100% 照样给出 NOERROR 和 26.000 msec，8.8.8.8 与 1.1.1.1 在两个口径里次序翻了个个儿。看一眼原始输出，就不太会再拿 ping 值当解析速度使了。

下一步很具体：挑一台你常用来连 VPS 的机器，把 www.baidu.com 换成你自己的域名，照前面那份清单跑一遍。机器到手之后要接着盯线路和历史读数，VPS 线路评测与历史读数汇总 是按线路和时段归过的一套，主机商与线路资料汇总 收的是另一层维度；挑机器那阵子，把 在售套餐与优惠汇总 和这份清单摆一起看，能自己核的几格核完，剩下的等机器到手再验。