隐形元凶：解析慢
『所有站点都变慢』这类模糊故障里，解析环节是常见元凶：每一次新连接都要先做名称解析，解析卡住会拖慢所有应用，包括接口调用、内容分发与第三方依赖。它的隐蔽之处在于浏览器有自己的缓存与预取，人工点几下网页感觉并不慢，而后端服务却在成批出现秒级超时。识别方法很直接：把请求分段计时，看解析阶段占了多少，再用逐台服务器查询把责任落到具体服务器上。
基本信息
| 典型症状 | 所有应用同时变慢、日志里出现规律性的秒级超时、连接建立前有明显停顿 |
|---|---|
| 量化方法 | 用请求分段计时看解析阶段耗时，再逐台查询服务器响应时间 |
| 常见根因 | 首台服务器不可达、单台等待时间乘重试次数被耗完、服务器过载 |
| 排查顺序 | 先量化解析耗时，再逐台测服务器，最后核对解析配置 |
症状与指向
| 症状 | 指向 | 验证方式 |
|---|---|---|
| 解析耗时远超预期 | 解析服务器响应慢或链路绕行 | 逐台查询并记录响应时间 |
| 超时金额规律，如五秒与十秒 | 等待时间乘重试次数被完整耗完 | 对照解析配置里的等待与重试参数 |
| 只有某些域名慢 | 上游或条件转发链路问题 | 对比同一服务器上不同域名 |
| 只有部分机器慢 | 该机器解析配置与网络路径差异 | 跨机器对照并检查各自配置 |
| 应用报错但本机查询正常 | 应用使用了自己的解析缓存或代理 | 检查应用侧配置与代理链路 |
典型使用场景
- 全线变慢定位：先排除解析这一层，避免在应用与数据库上白费力气
- 规律性超时排查：日志中周期性出现的秒级超时往往正对应解析等待
- 解析服务健康检查：定期逐台测量响应时间，作为容量与可用性基线
- 代理与容器环境排错：确认应用实际使用的解析路径是否与预期一致
- 变更后回归验证：调整解析配置后复测各阶段耗时是否回到基线
量化解析环节
量化解析环节
curl -sS -o /dev/null -w '解析=%{time_namelookup}s 连接=%{time_connect}s 总计=%{time_total}s\n' https://www.example.com/
time getent hosts www.example.com # 走系统解析路径，看整体耗时
# 逐台解析服务器测响应：
for s in $(awk '/^nameserver/{print $2}' /etc/resolv.conf); do
echo "== $s"; dig +time=3 +tries=1 @$s +noall +stats www.example.com | grep 'Query time'
done连接阶段耗时若明显超过往返时延的若干倍，说明握手之前就卡住了，解析与地址选择是第一嫌疑对象。
逐台测量的意义在于找出『哪一台慢』：首台长期不可达时，所有查询都要先等它超时，整体表现就是全体变慢。
修复后不清缓存或不让应用重连，验证结果会被旧状态干扰，容易得出『改了没用』的错误结论。