DNS解析延迟不直接降低吞吐量，但会拖慢连接建立、导致吞吐统计失真；排查需分离解析与传输耗时，通过dig、curl -w、ss、tcpdump等工具定位瓶颈，并验证缓存、配置及上游响应。
DNS解析延迟本身不直接降低网络吞吐量，但它会显著拖慢连接建立速度，进而让吞吐统计失真——比如你看到“平均下载速率只有2MB/s”，实际可能是前3秒全卡在解析上，后面10秒才真正传数据。排查关键在于分离“解析耗时”和“传输耗时”，不能把两者混在一起看。
确认DNS延迟是否真实存在
先排除误判：很多所谓“DNS慢”其实是应用层重试或超时策略导致的假象。
- 用time dig google.com +short测单次解析耗时，重复5次看波动。超过300ms且不稳定，才算可疑
- 对比dig @8.8.8.8 google.com和dig @127.0.0.53 google.com（systemd-resolved本地地址），若后者明显更慢，说明本地解析器是瓶颈
- 运行curl -w "@curl-format.txt" -o /dev/null -s http://example.com，其中curl-format.txt含
%{time_namelookup}字段，直接提取DNS阶段耗时
检查DNS延迟是否干扰吞吐测量工具
像iftop、nethogs这类工具只统计已建立连接的流量，但ss、tcpdump能捕获连接建立全过程。如果DNS延迟高，大量连接会堆积在SYN_SENT或未完成三次握手，造成“有连接请求却没流量”的假象。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 执行ss -tan state syn-sent | wc -l，数值持续大于10，说明大量连接卡在DNS或TCP握手阶段
- 用tcpdump -i any port 53 -w dns.pcap抓DNS流量，Wireshark里看是否有重传、超时或响应间隔突增
- 观察netstat -s | grep -A5 "DNS"（部分内核支持）或resolvectl statistics，查缓存命中率和平均响应时间
验证DNS对应用吞吐的实际影响
很多服务（如curl、wget、Python requests）默认启用DNS缓存，但缓存时间短或被禁用时，每次HTTP请求都触发新解析，放大延迟效应。
- 写一个简单测试脚本：for i in {1..10}; do time curl -s -o /dev/null http://example.com; done，再对比用IP直连：time curl -s -o /dev/null http://93.184.216.34，差值主要就是DNS开销
- 检查应用是否启用SO_REUSEADDR和连接池。未复用连接的应用，DNS延迟会被反复放大
- 用strace -e trace=connect,sendto,recvfrom -p $(pgrep your_app)跟踪系统调用，确认是否频繁阻塞在getaddrinfo()上
隔离并修复DNS环节
一旦确认DNS是瓶颈，不要直接换DNS服务器了事——要定位具体断点。
- 查/etc/nsswitch.conf中
hosts: files dns顺序，避免/etc/hosts里错误条目引发等待超时 - 运行dig +trace example.com，看是否某一级（如根或.com服务器）响应慢或超时，判断是上游问题还是本地转发异常
- 临时停用systemd-resolved：sudo systemctl stop systemd-resolved，改用nameserver 8.8.8.8直连测试，快速验证是否本地服务拖累
