必须用nslookup -debug或dig @DNS +stats测单次解析延迟，并结合ping/mtr验证链路质量，再通过systemd-resolve --statistics确认缓存命中率与DNS生效状态，才能准确判断DNS是否拖慢网页打开速度。
在统信UOS中准确判断DNS解析是否拖慢网页打开速度，必须分离DNS解析延迟与网络链路丢包——因为域名解析失败、网页白屏或HTTPS握手超时，常被误认为是“网速慢”，实则是DNS响应卡顿或中间节点丢包导致解析请求根本未抵达上游服务器。
用nslookup测DNS单次解析延迟
第一步：打开终端（Ctrl+Alt+T），执行nslookup -debug www.baidu.com 223.5.5.5。加-debug参数会输出完整查询过程，包括发起时间、收到响应时间及各阶段耗时；目标DNS填你当前配置的地址，比如阿里DNS（223.5.5.5）或114DNS（114.114.114.114）。
第二步：观察输出中Query time:字段后的毫秒数，例如Query time: 42 msec——这就是本次解析从发包到收包的总延迟。若连续多次超过300ms，说明该DNS服务器响应迟缓或本地到它的路径存在拥塞。
注意：不要用域名代替IP测试，否则nslookup自身会先查该域名的DNS服务器地址，形成嵌套查询，测出的不是目标DNS延迟，而是你当前默认DNS的递归能力。
用dig对比多个DNS的解析性能
方法一：测指定DNS的A记录响应时间
执行dig @223.5.5.5 www.taobao.com A +stats，查看末尾QUERY TIME:行。重复替换@后地址为114.114.114.114、8.8.8.8，横向比对三者延迟值。
方法二：批量测常用域名并排序
运行for dns in "223.5.5.5" "114.114.114.114" "1.1.1.1"; do echo -n "$dns: "; dig @$dns baidu.com A +short +stats 2>&1 | grep "Query time" | awk '{print $4}'; done | sort -k2n。这条命令自动遍历三个DNS，对baidu.com做A记录查询，并按延迟升序排列结果——最靠前的就是当前环境下响应最快的DNS。
dig比nslookup更精准，它不依赖系统/etc/resolv.conf，且+stats强制显示计时，避免因缓存命中导致误判。
用ping和mtr交叉验证DNS链路质量
① 先确认DNS服务器本身可达且低丢包：
执行ping -c 10 -n 223.5.5.5，重点看末尾packet loss是否为0%、time=平均值是否稳定低于100ms。若丢包率＞0%，说明从本机到该DNS服务器之间已有链路异常，解析再快也无意义。
② 定位哪一跳造成DNS请求失败：
运行sudo mtr -n -c 50 223.5.5.5，等待完成。检查Loss%列——如果首跳（你的网关）丢包为0%，但第二跳开始出现持续＞5%丢包，说明运营商出口或骨干网节点存在问题；此时换DNS无效，必须联系网络管理员。
③ 验证DNS解析是否真被干扰：
执行nslookup www.qq.com 114.114.114.114成功，但nslookup www.qq.com 8.8.8.8超时，同时ping -c 5 -n 8.8.8.8又完全通，就基本锁定是8.8.8.8主动屏蔽了来自中国境内某些IP段的DNS查询，而非网络故障。
关键提醒：所有mtr命令必须带-n参数，否则DNS反向解析会卡在第一跳，让Loss%显示虚高，误导你误判本地网关有问题。
用systemd-resolve查看实时DNS缓存与统计
如果你启用了systemd-resolved服务（UOS默认启用），可直接读取内核级DNS缓存状态和解析计数：
执行systemd-resolve --statistics，关注Cache hits:和Cache misses:两行比例——若miss占比长期＞30%，说明本地缓存命中率过低，应考虑部署dnsmasq或更换更高缓存效率的DNS。
再运行systemd-resolve --status，检查Current DNS Server:是否为你手动设置的地址，以及Global DNS Servers:列表是否包含预期IP。若此处仍是127.0.0.53，说明NetworkManager未将DNS正确推送至resolved服务，图形界面或nmcli配置可能未生效。
这一步不需要安装额外工具，数据来自系统服务自身维护的实时状态，比反复nslookup更反映真实使用负载。
