network Troubleshooting
DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时
域名解析出现 NXDOMAIN、SERVFAIL、Temporary failure in name resolution 或解析慢时，用 dig、dig @1.1.1.1、dig +trace、resolvectl status 交叉对比本机解析器、公共 DNS 和权威 DNS，快速定位问题出在哪一层。
先区分是本机解析器、上游 DNS 还是权威 DNS 的问题。对同一个域名分别查本机 DNS、公共 DNS 和权威记录，结果很快会分叉。
Scenario
这篇文章解决什么问题
适用于“DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时”对应的线上或本地排障场景。不要只根据最终报错下结论，应先把问题拆成入口、链路、目标服务和资源限制几层，再用命令逐层证实。先区分是本机解析器、上游 DNS 还是权威 DNS 的问题。对同一个域名分别查本机 DNS、公共 DNS 和权威记录，结果很快会分叉。
Symptoms
典型现象
- 域名解析出现 NXDOMAIN、SERVFAIL、Temporary failure in name resolution 或解析慢时，用 dig、dig @1.1.1.1、dig +trace、resolvectl status 交叉对比本机解析器、公共 DNS 和权威 DNS，快速定位问题出在哪一层。
- 相关日志、命令或页面中反复出现 dns、dig、resolvectl 等关键词。
- 同一服务在不同机器、不同入口或不同时间段表现不一致，需要通过证据链缩小范围。
Before Debugging
排查前先确认
- 先判断失败发生在 DNS、TCP、TLS、HTTP、代理还是应用层。
- 从客户端、服务端和中间代理所在机器分别测试，避免只验证了其中一段。
- 记录域名、解析结果、目标 IP、端口、协议和代理配置。
Root Causes
常见根因分层
解析路径不一致
系统 DNS、浏览器 DoH、容器 DNS、代理端解析可能得到不同结果。NXDOMAIN、SERVFAIL 和 timeout 对应不同方向。
- dig 本机和公共 DNS 对比
- 必要时 dig +trace
- 检查 hosts 和容器 DNS
代理协议或解析位置错误
HTTP 代理和 SOCKS5 代理不能混用；socks5 与 socks5h 的 DNS 解析位置不同。
- curl -v 看连接阶段
- 确认代理端口本机监听
- 检查 NO_PROXY
TLS/HTTP 层误判为网络问题
证书、SNI、重定向、HSTS、HTTP/2 和网关错误可能被笼统描述为“连不上”。
- curl -vI 看 TLS 和状态码
- openssl 带 servername
- 记录响应头判断来源
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
dig example.com
dig @1.1.1.1 example.com A +short2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
dig @1.1.1.1 example.com A +short
dig +trace example.com
resolvectl status3. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 确认错误类型是 NXDOMAIN、SERVFAIL、timeout 还是被 hosts 覆盖。
- 用公共 DNS 对比，判断问题是否只发生在当前网络。
- 检查 /etc/resolv.conf、systemd-resolved 或容器 DNS 配置。
dig +trace example.com
resolvectl status
grep -n "example.com" /etc/hosts4. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 检查 /etc/resolv.conf、systemd-resolved 或容器 DNS 配置。
- 如果只有某个子域异常，用 dig +trace 追到权威 DNS。
- 修改 DNS 后刷新本机、浏览器、应用进程内缓存。
resolvectl status
grep -n "example.com" /etc/hostsCommands
排查命令与使用意图
命令 1
用于补充“DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时”的排查证据链。dig 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
dig example.com命令 2
用于补充“DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时”的排查证据链。dig 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
dig @1.1.1.1 example.com A +short命令 3
用于补充“DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时”的排查证据链。dig 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
dig +trace example.com命令 4
用于补充“DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时”的排查证据链。resolvectl 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
resolvectl status命令 5
用于补充“DNS 解析失败排查：NXDOMAIN、SERVFAIL 和超时”的排查证据链。grep 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
grep -n "example.com" /etc/hostsRisk Notes
容易踩坑的地方
- 不要只凭浏览器提示判断网络根因，浏览器错误页往往只是结果而非原因。
- 不要长期关闭证书校验或把代理写死到全局配置，这会在故障排查时引入额外变量。
- 不要忽略 curl -v 中间阶段的细节，DNS 解析时间、TCP 握手延迟和 TLS 版本都可能隐藏问题。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 DNS 解析失败 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 为关键域名保留 DNS、TCP、HTTPS 三层探测，确保网络链路各层都可用。
- 代理配置集中管理，明确 NO_PROXY 和 DNS 解析策略，避免内网域名被错误代理。
- 证书、域名和网关变更后做外网验证，从实际用户视角确认变更生效。
- 建立网络故障排查 SOP，按 DNS → TCP → TLS → HTTP → 代理逐层排查，减少盲猜。
常见问题
为什么浏览器能打开，curl 却解析失败？
浏览器可能使用 DoH、缓存或代理解析；curl 默认走系统解析器，二者路径不同。
SERVFAIL 一定是我的服务器问题吗？
不一定。SERVFAIL 常见于上游 DNSSEC、递归解析器故障或权威 DNS 配置异常，需要交叉查询确认。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- DNS 解析失败 NXDOMAIN
- DNS SERVFAIL 怎么排查
- dig trace 域名解析
- resolvectl DNS 不生效
- curl could not resolve host
- Temporary failure in name resolution
- systemd-resolved DNS 问题
- Docker 容器 DNS 解析失败
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。