省级DNS地址别照抄：验证运营商递归解析与CDN调度

上周有人在群里甩了张截图，标题写着某运营商32个省的DNS地址大全区，底下跟着一长串以 202.96 开头的服务器IP，说照着填完，家里宽带打开网页要转三圈才出来。这种事我见过太多次了，问题多半不在地址本身，而在于这个地址和你当前的接入位置、线路类型、拨号方式三者压根不匹配。DNS地址和所谓"最快的服务器IP"这两件事，被太多帖子混在一起讲，抄的人也就跟着一起糊涂。

这篇东西想解决的就是这个糊涂账：一份省级DNS列表从哪来才可信、怎么确认它现在还有没有用、所谓"4G最快服务器IP"在技术上到底指什么、以及怎么用几条命令自己测出结论而不是照抄别人。适合手上有一堆抄来的地址不知道填哪个的人，也适合想搞清楚运营商递归解析和CDN调度关系的人。基础的部分我会讲得慢一点，涉及命令和脚本的地方会给出可复现的写法，你照着跑一遍基本就有感觉了。

1. 那张流传很广的省级DNS对照表，抄完为什么反而更慢

1.1 省级分配这件事，和行政区划不是一回事

很多人默认"一个省一个DNS"，所以看到32个省列了32组地址觉得很合理。实际网络里的组织方式要粗粝得多。运营商的递归解析服务器通常按大区或者按城域网来部署，一个省里往往同时存在多组、甚至十几组合格的递归地址，分布在不同的机房，通过路由策略把用户导向最近的那一组。你在省内A市拨号拿到的地址，和在B市拨号拿到的地址，很可能根本不是一个段。

这就解释了一个现象：网上流传的"某省DNS"，通常只是某个时间点、某个城市、某条特定线路上下发到的一对主备地址，被截图保存下来，然后被反复转载。它在采集的那一刻是对的,但你所在的城域网如果不往那个机房走，填进去之后每次查询都要多绕一跳甚至跨城，解析时延自然就上去了。所以那张表的问题不在于"假"，而在于"窄"——它只代表一个点，却被当成一个面来用。

还有一个更隐蔽的点：递归服务器地址是有生命周期的。地址池调整、机房搬迁、集群扩容，都会导致某些老地址降级成低优先级甚至直接下线。你在帖子里看到的地址可能确实还在响应，但它响应得慢，因为背后那台机器已经不再是主力了。

1.2 三类最常见的失效场景

实际排查下来，抄来的地址不好用，基本落在下面这三种情况里。

第三种最容易被忽略。现在的系统大多是IPv6优先，如果你手动把DNS改成一个只监听IPv4的地址，解析请求走v4出去，但访问目标站点时又走v6回来，中间多了一次协议栈切换和可能的路径重选。表现出来就是"有的站秒开，有的站一直转圈"，你换浏览器、清缓存都治不好。

1.3 判断一个地址现在还值不值得用，两个动作就够

不用一上来就大动干戈。先做最朴素的两件事：看它回答得快不快，看它答得准不准。

第一件事，直接问它。把下面这条命令里的地址换成你要验证的那个：

# Linux / macOS，连续问 10 次，看平均耗时和是否有超时 for i in $(seq 1 10); do dig +short +time=2 +tries=1 www.example.com @202.96.xx.xx | head -1 done

如果十次里有两三次直接超时，这个地址基本可以放弃了，不用再纠结。如果都能答，但耗时忽高忽低（比如在 8ms 和 120ms 之间反复横跳），说明它虽然活着，但路由不稳定，同样不建议长期用。

第二件事，看它返回的IP是不是"就近的"。这一步是区分好坏的关键：同一个域名，用运营商本地递归去问，和用一个异地递归去问，返回的CDN边缘节点IP往往不一样。你把两个结果分别 ping 一下，延迟差距一目了然。

# 分别用两个不同的解析器查同一个域名 dig +short cdn.example.com @202.96.xx.xx # 候选地址A dig +short cdn.example.com @202.96.yy.yy # 候选地址B

把这两条命令返回的IP各 ping 二十次，取平均。如果A返回的节点比B近了三四十毫秒，那基本不用犹豫，选A。这个判断方法比看任何"大全"都直接，因为它测的是端到端的真实路径，而不是纸面上的地址归属。

2. 拿到本省真实DNS的四个入口，比网上抄靠谱得多

2.1 拨号状态里就写着，只是没人去看

最靠谱的来源永远是你自己这条线路当下被下发了什么。PPPoE拨号成功后，BRAS会把主备两个递归地址推给客户端，Windows上一条命令就能看到：

ipconfig /all

输出里找"DNS 服务器"那几行，通常会有两个地址，第一个是主用，第二个是备用。这两个地址是运营商针对你这个接入点动态分配的，比你从任何帖子里抄的都准。

如果是路由器拨号、终端接在路由器后面，那就登录路由器后台，找WAN口状态或者外网设置页面，里面一般会显示"获得的DNS服务器"。这里有个细节值得注意：很多家用路由器默认开启了自己的DNS转发（dnsmasq），终端上ipconfig /all看到的其实是路由器的内网地址（比如 192.168.1.1），而不是运营商下发的真实地址。想看真实值，必须进路由器后台。

2.2 移动网络下的获取方式要绕一下

手机在Wi-Fi下看DNS很简单，进Wi-Fi详情就能看到。但在蜂窝数据下，系统一般不会把运营商下发的解析器地址暴露给用户界面。安卓部分机型还能通过调试桥读到：

adb shell getprop | grep -i "net.dns"

新一些的系统版本可能读不到，返回空或者只有net.dns1一个值，这属于正常现象，不用怀疑手机坏了。iOS 就更封闭，界面上完全看不到。这种情况下我的建议是别折腾，直接用系统默认——移动网络下的解析器是跟着基站和核心网走的，你手动指定的那个地址大概率还不如系统自动选的近。

2.3 命令行反查当前真正生效的解析器

终端上"配置了哪些"和"实际在用哪个"经常是两回事。Linux 和 macOS 上最直接：

# macOS scutil --dns | grep nameserver | head -5 # Linux（systemd-resolved 环境） resolvectl status | grep -A2 "DNS Servers" # 通用 cat /etc/resolv.conf

/etc/resolv.conf在有些发行版上只是个软链接或者被其他服务托管，改了不一定生效，这一点踩过坑的人应该都有印象。所以优先看resolvectl或者scutil的输出，那才是解析栈真正在用的配置。

2.4 为什么"运营商下发"通常优于"手动填写"

这里要把原理说透，不然容易被"公共DNS更快"的说法带偏。

运营商递归解析器在物理位置上离你近，这只是一半原因。更关键的是源IP归属。当你用运营商本地递归去查一个接了CDN的域名时，递归服务器把你的查询转发给CDN的全局负载均衡系统，GSLB 看到的源IP是这台递归服务器的地址，它能判断出"这个查询来自某省某运营商的网内"，于是返回同网、同省、甚至同城的边缘节点。

换成第三方公共解析器就不一样了。那台服务器可能在别的省份甚至别的运营商网内，GSLB 看到的是一个异地源IP，它只能按那个位置返回节点。结果就是你的请求被调度到一个物理上更远的边缘节点，解析这一步看着挺快（公共DNS的响应时间确实漂亮），但真正下载资源的时候跨了网、跨了省,整体体验反而更差。

这就是典型的"解析快、访问慢"，很多人只测了解析那一步就下结论，正好掉进这个坑里。

3. "4G最快服务器IP"这个说法，混淆了两个完全不同的东西

3.1 测速节点IP和DNS解析IP不是一回事

搜索词里经常把这两件事捆在一起，实际上它们服务于完全不同的目的。

DNS服务器IP的作用是"把域名翻译成IP"，它本身不传输你的业务流量（除非你用了加密DNS，那是另一回事）。而所谓"最快的服务器IP"，在绝大多数语境下指的是测速时用来打流量的那个目标节点，或者游戏、下载场景下的接入节点。你 ping 它得到的是这条路径的往返时延和丢包情况，跟域名解析没有直接关系。

把这两者混为一谈，最典型的后果就是：有人找了一堆"最快IP"填进DNS设置里，然后发现上不了网。因为那些地址根本不监听53端口，压根不是解析服务器。

3.2 移动网络下的"就近"是怎么发生的

4G/5G 场景下，"哪个服务器IP快"这个问题比固网更动态。原因在于移动网络的接入点是跟着你走的：你在城东连的基站和城西连的不是同一个，背后走的核心网网关也可能不同。同一个IP，早上在公司测出来 15ms，晚上回家测出来 60ms，这不是IP变了，是路径变了。

所以移动网络下追求一个"固定最快IP"意义有限。真正有用的做法是维护一个候选池，让工具在每次连接时自己挑。候选池里放什么？放你常用业务的实际接入地址——比如你常用的测速站点、常用服务的接入域名解析出来的IP，而不是网上抄来的一串陌生地址。

3.3 用延迟加丢包两个维度筛，别只看延迟

只测延迟容易被误导。有些节点延迟很低但丢包严重，实际吞吐惨不忍睹。我一般的筛法是两个指标一起看：

# 连续 50 次，看平均延迟、最大延迟、丢包率 ping -c 50 <候选IP>

判读的时候有个经验值可以参考：平均延迟低于 30ms、最大延迟不超过平均值的 3 倍、丢包为 0，这三条同时满足才算"稳"。如果平均延迟 20ms 但最大延迟飙到 300ms，说明路径上有拥塞或者队列抖动，这种节点在打游戏或者视频会议时体验会很差，哪怕它"平均"看起来很美。

想要看得更细，用 mtr 沿着路径逐跳看：

mtr -r -c 50 <候选IP>

输出里如果某一跳开始丢包，且后面每一跳都继承了这个丢包率，说明问题出在那一跳；如果只有中间某一跳丢包而最后一跳不丢，那通常是那台路由器对 ICMP 做了限速，不代表链路真有问题。这个区别很关键，不少人看到中间跳红了一片就以为线路坏了，其实业务流量根本没受影响。

4. DNS解析质量怎么测：三个指标，缺一个都会误判

4.1 解析时延只是入场券

很多人测DNS就测一个"查一个域名要多久"，这个指标有用但非常片面。它只反映第一次查询（缓存未命中）的开销，而且受测试域名影响极大。你拿一个本地根本没有缓存的冷门域名去测，和拿一个热门域名去测，结果能差十倍。

真正有参考价值的做法是准备一组域名，覆盖不同类型：一个热门站点、一个冷门站点、一个走CDN的静态资源域名，然后对每个候选DNS分别跑一轮，记录每一次的耗时，看的是分布而不是单次值。

#!/usr/bin/env bash # 对多个候选 DNS 逐域名测解析耗时 DOMAINS=("www.example.com" "static.example.com" "api.example.com") DNS_LIST=("202.96.xx.xx" "202.96.yy.yy" "202.96.zz.zz") for d in "${DNS_LIST[@]}"; do echo "=== $d ===" for dom in "${DOMAINS[@]}"; do total=0 for i in $(seq 1 5); do t=$(dig +short +time=3 +tries=1 "$dom" @"$d" > /dev/null 2>&1; echo $?) # 用 query time 更准，从 dig 的统计行里取 qt=$(dig "$dom" @"$d" 2>/dev/null | grep -o 'Query time: [0-9]*' | grep -o '[0-9]*') total=$((total + ${qt:-3000})) done echo " $dom 平均 ${((total/5))} ms" done done

注意脚本里+tries=1这个参数，不设的话 dig 默认会重试，超时也会被掩盖成"慢"而不是"失败"，测出来的数就没意义了。

4.2 命中率与TTL的关系，决定了你日常的体感

解析时延影响的是"第一次"，命中率影响的才是"每一天"。

递归服务器对常见域名是有缓存的，缓存有效期由域名自身的 TTL 决定。TTL 长的域名，你第二次、第三次查询基本都是缓存直接返回，几毫秒就完事；TTL 短的域名，缓存频繁失效，每次都要回源，时延就上去了。

这解释了一个常见困惑：为什么有人测 DNS 觉得"都差不多快"，实际用起来却感觉某个明显更顺。差别往往不在单次查询，而在于这个递归服务器对常用域名的缓存覆盖率高不高。大运营商的主力递归节点服务用户多、缓存热,命中率天然占优；一些小节点或者新上线的地址，缓存是冷的，什么都要回源问一遍。

判断方法也很土：把同一个域名连续查十次，看后九次的时间是不是稳定在个位数毫秒。如果十次都差不多，说明它压根没缓存（或者每次都给你返回不同结果），这种地址拿来日常用意义不大。

4.3 CDN调度准确性：最容易踩的"假快"陷阱

前面提过一次，这里展开说，因为这是整个话题里最容易误判的地方。

假设你测出某个公共 DNS 的解析时延只有 3ms，本地运营商递归是 8ms。数字上看公共 DNS 赢了，你换了。结果换完之后发现视频加载变慢、软件下载速度掉了一半。原因在于那 3ms 只代表"它回答你快"，不代表"它给你的答案对"。

验证方法很直接：用两个解析器查同一个 CDN 域名，把各自返回的IP拿出来，分别 ping。

# 拿到两边的解析结果 A=$(dig +short cdn.example.com @202.96.xx.xx | head -1) B=$(dig +short cdn.example.com @<公共DNS地址> | head -1) # 分别测往返时延 ping -c 20 "$A" ping -c 20 "$B"

如果 A 的延迟明显低于 B，说明本地递归给出的节点更近，那 3ms 的解析优势完全不值一提。解析省下的 5ms，抵不过传输多绕的 30ms。这个账很多人算不过来，是因为只盯着解析工具上那个数字看。

4.4 一套可以照着跑的对比流程

把上面这些串起来，我日常用的验证流程大概是这个顺序，大概十分钟能跑完一轮：

1. 从路由器 WAN 口读出当前下发的两个地址，记为基准组。
2. 从网上找来的列表里挑两三个同省地址，记为对照组。
3. 用 4.1 的脚本对两组分别测解析耗时，各跑五轮。
4. 用 4.3 的方法对同一个 CDN 域名比对返回IP的实际延迟。
5. 用 4.2 的方法看重复查询是否有缓存命中。
6. 三项综合，只要对照组没有在任何一项上明显胜出，就别换。

这个流程跑下来你会发现，绝大多数情况下基准组（运营商下发的那两个）综合表现最好。这不是巧合，是设计使然。

5. 想自己维护一份省级对照表，该怎么做

5.1 表结构这么设计，后面才不用返工

如果你确实有跨省的需求（比如做多地部署测试、给不同地区的同事做支持），与其收藏别人的表，不如自己建一张。字段不用多，但这几个必须有：

"采集方式"这一列看着多余，实际上最有用。凡是标着"他人提供"的，用之前一律按待验证处理；标着"拨号下发"的，可信度最高。有了这一列，你半年后回头看这张表，才知道哪些数据能直接用。

5.2 批量验证的写法

地址多了以后手工一个个 ping 不现实，写个小循环批量跑：

#!/usr/bin/env bash # 批量检查 DNS 地址可用性，输出格式便于粘贴回表格 while IFS=, read -r province ip; do [ -z "$ip" ] && continue result=$(dig +short +time=2 +tries=1 www.example.com @"$ip" 2>/dev/null | head -1) if [ -n "$result" ]; then qt=$(dig www.example.com @"$ip" 2>/dev/null | grep -o 'Query time: [0-9]*' | grep -o '[0-9]*') echo "$province,$ip,OK,${qt}ms" else echo "$province,$ip,FAIL,-" fi done < dns_list.csv

dns_list.csv里每行一个"省份,地址"，跑完直接出结果。这个脚本没什么技巧，但比手工靠谱得多，尤其是地址数量上了二三十个之后。

5.3 复核节奏：别等出问题才想起来

我的习惯是每季度过一遍。触发复核的信号有三个，任何一个出现就手动跑一次：换了宽带套餐或者换了光猫、所在小区做了线路改造、常用站点开始出现莫名卡顿。前两个是外部变化，第三个是结果反馈。

复核不用全量跑，先跑你常用的那几个省，其他的标个"待复核"放着。真到用的时候再验证，比维护一张"永远最新"的表现实得多——那张表根本不存在，谁声称有都是在卖快照。

6. 折腾这些年，几条反直觉的结论

6.1 全局替换DNS，绝大多数时候是负收益

我早期也干过这事，看到一个新地址就想全局换上，觉得"优化了"。后来发现大部分所谓优化都是自嗨。原因前面说过：手动填的地址丢失了源IP归属信息，CDN调度会偏。除非你能确认新地址在你这条线路上、在解析时延、缓存命中、调度准确性三项上都不输，否则别动。

真要改，我的做法是只改特定设备的特定场景。比如某台常做下载的机器，手动指定一个缓存命中率高的地址；其他设备一律保持自动。这样即使改错了，影响面也可控。

6.2 移动网络下，手动指定 DNS 的意义比固网小得多

固网拨号下发的地址相对稳定，你能测出一个固定结论。移动网络不是这样，你的接入网关跟着位置变，测试结果的时效性很短。今天测出来 A 比 B 快 10ms，明天换个地方可能就是反过来的。

所以在手机上手填 DNS，我一般只在两种情况下做：一是明确知道当前网络环境有解析异常（比如某些域名解析不出来而其他网络正常），二是需要临时绕过某个有问题的解析结果。日常使用就让系统自动选，省心且不容易出错。

6.3 什么时候手动指定反而是对的

也不是完全没用。有两种场景手动指定确实有优势。

第一种是设备本身不支持自动获取，比如某些老旧的嵌入式设备、部分网络摄像头、打印机，它们的网络配置界面只能填静态地址，那就只能手填，这时候用拨号下发的那两个值最稳。

第二种是需要固定解析行为的调试场景。比如你在排查"为什么这台机器访问某个服务总是走到错误的节点"，这时候把 DNS 固定住，排除解析层面的变量，才能定位到真正的问题。这种用法是"为了控制变量"，不是"为了提速"，目的完全不同。

最后分享一个我自己一直在用的小习惯：每次换网络环境（换城市、换宽带、换手机卡）之后，花两分钟跑一遍ipconfig /all或者resolvectl status，把当下下发的地址记到表里，顺手 ping 一下看延迟。时间长了你会发现，这张自己攒出来的表比任何一份网上流传的"大全"都好用，因为每一条后面都有你自己的验证记录，而不是一串来路不明的数字。