nslookup 与 dig 响应时间差异大，说明系统未按 /etc/resolv.conf 直连 dns，而是经由本地解析服务（如 systemd-resolved、dnsmasq）或受 nss 配置、ipv6 协议栈、mdns 等干扰导致延迟。
nslookup 和 dig 返回时间差异大，说明什么
说明系统没走 /etc/resolv.conf 里配的 DNS，或者被本地缓存/代理劫持了。nslookup 默认用系统解析器（会走 libc 的 getaddrinfo，受 nsswitch.conf、systemd-resolved 或 dnsmasq 影响），而 dig 直连指定 DNS（默认 8.8.8.8 或 resolv.conf 第一行）。两者耗时差 2 秒以上，基本能锁定是本地解析链路出了问题。
实操建议：
- 先跑
dig @127.0.0.53 google.com（systemd-resolved 默认监听地址）和dig @127.0.0.1 google.com（dnsmasq 常见地址），看是否慢 - 对比
nslookup google.com 127.0.0.53和nslookup google.com 8.8.8.8，确认是不是本地服务拖慢 - 检查
systemctl is-active systemd-resolved，若为 active 且你没主动用它，反而可能是干扰源
systemd-resolved 占用 53 端口但没启用，导致超时
这是常见静默故障：systemd-resolved 进程在运行、占着 127.0.0.53:53，但 resolv.conf 指向的是它，而它实际没配置上游 DNS 或处于 failed 状态。结果所有请求卡在 connect timeout（默认 5 秒）。
实操建议：
- 查状态：
systemctl status systemd-resolved，注意看最后一行是否含 “failed” 或 “inactive” - 看真实配置：
resolvectl status，若显示 “No current DNS server” 或 upstream 为空，就是它的问题 - 临时绕过：
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf（改用 stub 模式）或直接停用：sudo systemctl disable --now systemd-resolved - 别手动改
/etc/resolv.conf为8.8.8.8后还留着 resolved 跑着——它会悄悄覆盖你的修改
glibc 的 getaddrinfo() 在 IPv6 不可用时卡顿
很多程序（curl、wget、ssh）底层调 getaddrinfo，默认查 A + AAAA 记录。如果本地 IPv6 网络不通、DNS 又返回了 AAAA，glibc 会等 IPv6 查询超时（通常 1–5 秒）才回退到 IPv4。这不是 DNS 慢，是协议栈行为。
实操建议：
- 验证：
getent ahosts google.com，看是否先出 IPv6 行、且延迟明显 - 临时禁 IPv6 解析：
echo 'options inet6' | sudo tee -a /etc/resolv.conf（不推荐长期用） - 更稳妥：在应用层控制，比如 curl 加
--ipv4，或设环境变量export GODEBUG=netdns=go（对 Go 程序） - 检查网卡是否误启 IPv6：
sysctl net.ipv6.conf.all.disable_ipv6应为 1；若为 0，且你没用 IPv6，建议关掉
/etc/nsswitch.conf 中 dns 条目顺序影响解析路径
hosts: files mdns4_minimal [NOTFOUND=return] dns 这种写法里，mdns4_minimal 查不到就 return，跳过 dns；但如果写成 hosts: files dns mdns4_minimal，就会先查公网 DNS，再查 mDNS——而 mDNS 在局域网外会卡住几秒。
实操建议：
- 运行
getent hosts google.com，再立刻strace -e trace=connect,getaddrinfo getent hosts google.com 2>&1 | grep -E "(connect|getaddrinfo)"，看它到底连了哪些地址 - 标准最小化配置应为：
hosts: files dns，删掉mdns4_minimal、resolve等非必要模块 - 某些发行版（如 Ubuntu）默认带
[!UNAVAIL=return]这类条件跳转，一旦某个模块响应慢（比如 avahi-daemon 挂了），整个链路就卡住
真正麻烦的不是某一个配置项，而是多个服务（resolved、avahi、dnsmasq、NetworkManager）同时监听 53 端口、互相覆盖 resolv.conf，又各自有 fallback 逻辑。定位时别只盯 DNS 响应时间，得顺着进程 → 端口 → 配置文件 → 解析函数调用链一层层切进去。
