nslookup 默认不显示延迟，需加 -debug 查看“;; query time:”行（毫秒级，仅协议层）；真实耗时应使用 time 命令测 real 时间，并指定公共 dns（如 8.8.8.8）排除本地干扰。
怎么看 nslookup 返回的延迟数值
MacOS 自带的 nslookup 默认不直接显示毫秒级耗时，很多人盯着输出反复看“有没有 time 字样”，其实它藏得挺深——只有加 -debug 才会吐出 ;; Query time: 这一行。但要注意：macOS 的 nslookup -debug 输出里，这个时间是 DNS 协议层的响应间隔，不含进程启动、解析命令行等开销，和真实用户感知有偏差。
- 执行
nslookup -debug example.com，滚动到末尾找;; Query time: 42这类行（单位是毫秒） - 如果没看到，说明当前 DNS 服务器返回包里没带标准 time 字段，或 macOS 版本较老（如 macOS 12 以前），这时必须换方法
- 别信“Non-authoritative answer”下面的空行——那里没有隐藏时间，纯属误导
用 time 命令测真实墙钟时间
想测用户实际等待多久？time 是唯一靠谱的方式，它捕获的是从敲回车到光标回来的全部耗时（real 时间），包括网络往返、本地解析、甚至 DNS 服务器卡顿。这对判断“为什么打开网页总卡 2 秒”特别关键。
- 运行
time nslookup example.com 8.8.8.8（指定 DNS 避免受本地缓存干扰） - 重点看
real行，比如real 0m1.245s就是 1245 毫秒 - 单次结果不准，至少跑三次：
time nslookup example.com 1.1.1.1、time nslookup example.com 223.5.5.5，对比波动——如果只在某个 DNS 上持续 >1000ms，问题大概率出在那个服务器或通往它的路径上
为什么指定 DNS 服务器比默认设置更可靠
MacOS 默认用路由器或 ISP 提供的 DNS，但这些服务器常被限速、缓存污染，甚至静默丢包。直接绕过它们，才能分清是“你家 DNS 不行”还是“目标域名本身有问题”。
- 常见组合：用
nslookup example.com 114.114.114.114测国内解析，nslookup example.com 8.8.8.8测国际链路 - 如果所有公共 DNS 都慢，但
ping 93.184.216.34（example.com 的 IP）很快，说明不是网络通路问题，而是 DNS 层故障 - 注意：部分企业网络会拦截非 53 端口 DNS 查询，若
nslookup example.com 1.1.1.1超时但nslookup example.com 8.8.8.8正常，可能是防火墙策略导致
debug 模式下最该盯住的三处信息
nslookup -debug 输出很长，但真正影响延迟判断的只有三行，其余全是噪音。很多人花十分钟翻日志，却漏掉关键线索。
- 找
server:开头的行——确认实际发请求的是哪台服务器，不是你“以为”的那台（比如你设了 1.1.1.1，但它可能被路由器重定向到 192.168.1.1） - 找
auth:后面的值——auth = 1表示来自权威服务器，响应可信；auth = 0是缓存结果，延迟低但可能过期 - 找
;; Query time:和紧随其后的;; SERVER:——如果 time 很小（如 12ms）但 SERVER 显示的是你本地路由器（192.168.1.1），说明延迟不在公网，而在你路由器转发到上游 DNS 这一跳
真正在意延迟的人，不会只跑一次 nslookup 就下结论。DNS 解析是分层的，本地缓存、路由器转发、ISP 递归、根域查询……每一层都可能拖后腿。你看到的 real 0m0.892s 是终点，但 -debug 里那一行 ;; SERVER: 192.168.1.1#53 才是起点。
