linux dns解析慢需逐层排查：先查/etc/resolv.conf配置及systemd-resolved状态，再对比直连公网DNS（如dig @8.8.8.8）与本地解析耗时；接着测试上游DNS响应延迟与可靠性；然后检查本地代理服务干扰及缓存；最后用tcpdump或dig +trace抓包分析请求路径。
Linux 下 DNS 解析慢，通常不是单一原因导致的，得从本地配置、网络链路、DNS 服务器响应多个层面逐步验证。核心思路是：先确认是不是 DNS 本身慢，再定位慢在哪个环节。
检查本机 DNS 配置是否合理
系统默认用 /etc/resolv.conf 里的 nameserver，但这个文件可能被 NetworkManager、systemd-resolved 或 DHCP 动态覆盖，内容未必可靠。
- 运行 cat /etc/resolv.conf 查看当前生效的 DNS 地址，注意有没有 127.0.0.53（systemd-resolved 的 stub 地址）或 127.0.0.1（可能指向本地 dnsmasq）
- 如果是 127.0.0.53，用 resolvectl status 查看 systemd-resolved 实际上游 DNS 是什么，它可能加了缓存或转发策略
- 临时绕过本地服务直连公网 DNS 测试：比如 dig @8.8.8.8 google.com，对比 dig google.com 耗时，能快速判断是不是本地解析器拖慢了
测 DNS 服务器响应延迟和可靠性
不同 DNS 服务器性能差异很大，尤其跨地域或运营商时。别只信“公共 DNS 好”，要实测。
- 用 dig +stats @DNS_IP domain.com 看 query time（毫秒），多试几次，关注平均值和抖动
- 重点测你 /etc/resolv.conf 里排第一的 nameserver，它优先被用到；如果超时或返回 SERVFaiL，系统会等几秒才切下一个
- 常见组合参考：国内推荐 223.5.5.5（阿里）、114.114.114.114（老牌）；海外可试 8.8.8.8 或 1.1.1.1，但注意有些会被 QoS 限速
排查本地服务干扰或缓存失效
systemd-resolved、dnsmasq、甚至某些安全软件都可能拦截 DNS 请求，引入额外开销或错误逻辑。
- 查是否有本地 DNS 代理在运行：systemctl is-active systemd-resolved、ps aux | grep -E “(dnsmasq|unbound)”
- 如果启用了 systemd-resolved，它默认开启缓存，但有时缓存策略或 fallback 行为反而导致首次解析变慢；可临时停用测试：sudo systemctl stop systemd-resolved && sudo systemctl disable systemd-resolved，再改 /etc/resolv.conf 指向真实 DNS
- 清空本地缓存（如启用的话）：sudo resolvectl flush-caches 或 sudo systemctl restart dnsmasq
抓包确认实际请求路径和耗时
当以上都看不出问题，就用 tcpdump 或 dig +trace 看真实交互过程。
- 在终端执行：sudo tcpdump -i any port 53 -w dns.pcap，然后另起窗口跑 dig example.com，结束后用 wireshark 打开 pcap 分析每段请求/响应时间
- 或者用 dig +trace example.com 观察是否卡在根域、TLD 或权威服务器环节（说明是上游 DNS 问题，不是你本地）
- 注意 udp 截断（TC=1）后降级 TCP 的情况——TCP 握手会增加延迟，可尝试 dig +tcp 强制走 TCP 对比
基本上就这些。DNS 慢不复杂但容易忽略细节，比如 resolv.conf 被覆盖、systemd-resolved 的 fallback 超时、或某段网络对 DNS UDP 包做了限速。逐层排除，多数情况能快速定位。