如何在不猜测的情况下修复慢 DNS 查询

确认 DNS 是变慢的阶段

页面变慢可能由名称解析、连接建立、TLS、服务器处理或内容传输造成。修复慢 DNS 查询要先区分这些阶段。更换解析器无法修复一个花费数秒生成响应的应用。

选择一个公共主机名和一个已知正常的对比主机名。保持设备、网络、VPN 状态和测试方法一致。记录问题何时发生，不要只依赖忙碌浏览器标签页的一次直觉。

收集少量计时样本

curl --output NUL --silent --show-error --max-time 20 --write-out "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} firstbyte=%{time_starttransfer} total=%{time_total}\n" https://example.com/

此命令适用于 Windows 命令提示符；如果 shell 使用了其他 curl 别名，请使用 curl.exe。在 macOS 或 Linux 上，用 /dev/null 替代 NUL。在 Windows 批处理文件中，百分号需要按 shell 规则转义。报告值单位是秒，通常是从开始时间起的累计里程碑，而不是五个相互独立的耗时。

对于直接 HTTPS 请求，在把问题归咎于 DNS 之前，比较名称查询与连接和 TLS 里程碑。代理、重定向、缓存、连接复用和重试都会影响解读。记录这些条件。不要把一条命令的输出变成通用的提供商速度排名。

比较重复观察结果

这些数值是虚构示例，不是 Arcvenza 测量结果。第二次请求更快可能涉及多个已预热组件。保留多个样本并检查不一致的结果。目标是找出能够经受正常波动、可重复出现的模式。

缩小受影响范围

如果只有一台设备变慢，请在同一个获准网络上，将它的解析器配置、VPN 状态和应用行为与正常设备比较。如果许多设备对许多名称都很慢，请与负责人员一起调查共享解析器或网络路径。

如果只有一个域名在独立观察中变慢，请检查它的委派、权威响应和别名链。过长的链或无法访问的权威服务器值得调查，但仅仅存在 CNAME 不能证明有故障。

在不替换网络的情况下测试一个替代项

nslookup -type=A example.com
nslookup -type=A example.com 1.1.1.1

在获准情况下，通过正常解析器和一个明确选定的解析器比较相同问题。第二条命令只改变该查询的目标。不要把仅限内部使用的名称发送到组织 DNS 系统之外。

将 Arcvenza NSLookup 作为独立的公共观测点。其显示的时长表示从所述测试节点执行服务器端操作的时间。它不是浏览器经历的延迟，不应替代本地计时表中的数据。

选择并验证针对性的修复

本地旧结果可能支持进行本地缓存重置。递归解析器故障需要获运营方批准的解析器修复或更换。特定域名的权威问题应交给 DNS 所有者。完成一次变更后，使用原始设备、名称和应用重新测试。

不要为追求一次快速结果而禁用安全验证、全局弱化防火墙或轮换许多解析器。保留原始设置和回滚路径。当修复在不破坏私有名称或必需策略的情况下改善可重复的任务完成，才说明修复有效。

常见问题和下一步

较低的 DNS TTL 是否总能让网站更快？不能。TTL 控制缓存寿命；更短的缓存时间可能增加需要执行解析工作的频率。

我应该向支持团队发送什么？分享公共主机名、受影响范围、查询类型、解析器、时间、错误状态以及脱敏后的前后结果。如果查询超时，请使用 DNS 服务器排查指南，而不是只运行缓慢。

技术参考

Microsoft: nslookup · RFC 7766: DNS over TCP · curl command manual

Microsoft：nslookup · RFC 7766：DNS over TCP · curl 命令手册