先执行ping -c 3 8.8.8.8和ping -c 3 baidu.com对比响应：前者快后者慢则确认DNS解析延迟过高；再用curl提取time_namelookup值，持续＞1000ms即坐实；dig +trace或横向对比不同DNS的Query time可定位瓶颈，resolvectl status查真实生效DNS，停systemd-resolved直连测试可验证本地服务是否拖后腿。
确认是否真是DNS解析延迟过高
先别急着查配置，执行 ping -c 3 8.8.8.8 和 ping -c 3 baidu.com 对比：前者毫秒级响应，后者卡顿或超时，说明问题出在域名解析环节；如果两者都慢，那根本不是DNS的事，是网络链路或本机路由出了问题。
再用 curl -o /dev/null -s -w '%{time_namelookup}\n' https://baidu.com 提取纯DNS解析耗时——这个值若持续 >1000ms，就坐实了DNS延迟过高。
快速定位卡在哪一级递归服务器
方法一：用 dig +trace baidu.com 看完整解析路径。重点盯住每一跳的 Query time 字段：如果卡在“问根服务器”或“问 .com 顶级域”这步（比如耗时 800ms），说明你当前配置的递归DNS服务器上游质量差，不是你本地网络的问题。
方法二：横向对比不同递归服务器表现：dig @1.1.1.1 baidu.com +short、dig @223.5.5.5 baidu.com +short、dig @8.8.8.8 baidu.com +short 各跑三次，记录每次 Query time。若某台 consistently 超过 300ms 且波动大，基本可淘汰。
注意：dig @127.0.0.53 baidu.com 这种查的是 systemd-resolved 的 stub resolver，结果受其转发逻辑影响，不能代表真实递归服务器性能。
检查本地DNS服务是否拖后腿
第一步：运行 ls -l /etc/resolv.conf。如果它指向 /run/systemd/resolve/stub-resolv.conf 或 /run/NetworkManager/resolv.conf，说明 DNS 请求实际由 systemd-resolved 或 NetworkManager 中转，不是直连你写的 nameserver。
第二步：查真实生效的递归服务器：resolvectl status，看 Global 下的 “DNS Servers” 行——这才是你系统真正发请求的目标地址。
第三步：临时绕过中间层，强制直连测试：sudo systemctl stop systemd-resolved → echo "nameserver 223.5.5.5" | sudo tee /etc/resolv.conf → 再跑 dig baidu.com +short。如果延迟骤降，说明 systemd-resolved 的转发或缓存机制本身成了瓶颈。
验证DNS服务器可达性与稳定性
对 resolvectl status 显示的主DNS地址（如 192.168.1.1 或 114.114.114.114），执行：ping -c 5 【目标IP】。丢包率 >0% 或平均延迟 >100ms，该服务器就不适合当主力。
再用 dig @【目标IP】 google.com +short 连续执行 10 次，用 awk '{print $NF}' 提取 Query time 并观察分布：若出现多次 >500ms 或数值忽高忽低（如 23ms/412ms/18ms/893ms），说明该DNS服务不稳定，会放大应用层超时风险。
公司内网有自建DNS的，优先测内网地址（如 192.168.1.11）——它通常比任何公网DNS快一个数量级，且不受出口带宽和运营商策略限制。
更换并固化优质递归DNS
① 编辑 /etc/systemd/resolved.conf，取消注释并修改 DNS= 行：DNS=1.1.1.1 223.5.5.5 9.9.9.9；
② 添加关键优化参数：Options timeout:1 rotate（首查超时缩至1秒，多个DNS轮询防单点卡死）；
③ 执行 sudo systemctl restart systemd-resolved；
④ 验证生效：resolvectl query baidu.com，确认 SERVER 字段显示的是你刚配的 IP 地址之一，且 Query time 稳定在 50ms 以内。
