DNS lookup failure 怎么排查：按报错和运行环境定位

更新于 2026-10-30 · sansui-r.com

简答：DNS lookup failure 表示应用没有完成域名解析，不一定是域名不存在。先确认实际使用的 DNS 服务器，再用 nslookup 或 dig 对比查询；

定义：DNS lookup failure 是客户端、容器或应用向解析器查询域名时未获得可用结果的统称，具体原因可能在本机配置、DNS 服务器、网络路径或应用自身缓存。

先用 3 分钟判断 DNS lookup failure 卡在哪一层

本文更新于 2026 年 10 月 30 日。排查时不要一开始就反复清缓存或直接修改 DNS。先记录失败域名、发生环境和完整报错，然后确认设备实际使用的 DNS 服务器。

确认网络配置：Windows 执行 ipconfig /all；Linux 执行 resolvectl status，如果系统没有 systemd-resolved，再查看 /etc/resolv.conf；macOS 可在“系统设置—网络—详细信息—DNS”查看配置。
直接查询失败域名：Windows 执行 nslookup example.com；Linux 或 macOS 执行 dig example.com。把 example.com 替换成实际域名。
绕过默认解析器做对照：Linux 或 macOS 可执行 dig @DNS服务器IP example.com；Windows 可执行 nslookup example.com DNS服务器IP。如果指定服务器能返回结果，而默认查询失败，重点检查本机、路由器或默认解析器配置。
分别查询 A 和 AAAA：dig example.com A 与 dig example.com AAAA。只有其中一种失败时，不要把问题直接判断为域名整体失效，应继续检查 IPv4/IPv6 地址选择。

Windows 官方排查顺序也是先检查 IP、网关和 DNS 服务器，再用 nslookup 查询失败记录；微软还说明，nslookup 不使用 Windows 客户端 DNS 缓存，因此适合用来区分缓存问题和解析器响应。参见微软 DNS 客户端排查文档。

现象或返回结果	通常说明什么	下一步
NXDOMAIN	权威结果表示查询名称不存在	核对域名拼写、子域名、委派和记录名称，不要只清本机缓存
NOERROR 但没有目标类型记录	域名存在，但当前查询类型没有记录，常称 NODATA	分别查询 A、AAAA、CNAME 或实际需要的记录类型
SERVFAIL	解析器无法处理查询，可能涉及上游失败、区域数据或验证问题	更换查询对象做对照，并检查权威服务器和 DNSSEC 状态
REFUSED	服务器基于策略拒绝查询	检查访问控制、递归权限、网络位置和查询服务器是否正确
Timeout、超时或没有响应	请求或响应未在预期时间内完成	检查 DNS 服务器地址、UDP/TCP 53 连通性、防火墙和网络路径
命令行成功，应用失败	应用可能使用独立缓存、hosts、容器解析器或其他 DNS 配置	进入应用、容器和浏览器分支继续验证

NXDOMAIN、SERVFAIL、REFUSED 的协议含义可对照RFC 1035；NODATA 的判断方式和负缓存规则可对照RFC 2308。NXDOMAIN 和 NODATA 是有意义的否定回答，不等同于“解析器完全故障”。

Windows、macOS 和 Linux 的 DNS lookup failure 排查步骤

Windows：先确认实际 DNS，再清理客户端缓存

在命令提示符执行 ipconfig /all，确认 IPv4 地址、默认网关和 DNS Servers 都属于当前网络。
执行 nslookup example.com，观察输出中的 Server 和 Address，确认查询发给了哪个 DNS 服务器。
直接测试 DNS 服务器是否可达，例如 ping DNS服务器IP。Ping 失败只能说明 ICMP 不通，不能单独证明 DNS 服务不可用；还应检查 UDP 或 TCP 53。
对比指定服务器：nslookup example.com DNS服务器IP。默认服务器失败、指定服务器成功时，优先检查网卡 DNS、路由器转发和本机防火墙。
如果域名记录刚修改，且 ipconfig /displaydns 显示了旧结果或“Name does not exist”，再执行 ipconfig /flushdns 后重试。

微软文档指出，hosts 文件会在查询 DNS 服务器前影响名称解析，因此还应检查 C:\Windows\System32\drivers\etc\hosts 是否存在旧地址或错误映射。不要为了排查而长期关闭系统防火墙；应只检查是否有规则阻断 UDP 或 TCP 53。相关说明见Windows DNS 客户端名称解析排查文档。

macOS：使用系统设置核对 DNS，并用 dig 复核

打开“系统设置—网络”，选择当前网络服务，进入“详细信息—DNS”，确认 DNS 服务器和搜索域符合当前网络。
在终端执行 scutil --dns，查看系统实际生效的解析配置。
执行 dig example.com，再执行 dig @DNS服务器IP example.com 做对照。
如果只是某个应用失败，检查该应用是否启用了独立的安全 DNS、代理或网络配置；不要只依据 Safari 或终端的单次结果判断所有应用都正常。

Apple 的官方说明显示，macOS 的 DNS 服务器和搜索域可在网络服务的 DNS 设置中修改；配置变更后应重新执行 scutil --dns 和 dig 验证，而不是只观察浏览器页面。参见Apple 更改 Mac DNS 设置文档。

Linux：先区分 systemd-resolved 和传统 resolv.conf

执行 resolvectl status，查看全局和网卡级 DNS 配置。
执行 resolvectl query example.com，观察使用的接口、服务器和返回结果。
如果系统使用 systemd-resolved，清理本地缓存可执行 sudo resolvectl flush-caches；该命令只清理本机服务维护的缓存，不会修复权威区域或上游服务器错误。
检查 /etc/resolv.conf 是否由其他网络管理组件维护。不要直接覆盖该文件后就结束排查，否则网络服务重启或 DHCP 更新时可能恢复原配置。
用 dig @DNS服务器IP example.com 绕过本地解析服务。如果直接查询成功而 resolvectl query 失败，重点检查本机解析服务、网卡配置或防火墙。

resolvectl 官方手册列出了 status、query 和 flush-caches 的用途；systemd-resolved 是否接管 /etc/resolv.conf，还需结合systemd-resolved 官方说明判断。

Docker 和 Kubernetes 中出现 DNS lookup failure 怎么定位

Docker：先在容器内确认 resolv.conf 和 127.0.0.11

查看容器实际配置：docker exec -it 容器名 cat /etc/resolv.conf。
进入容器执行 getent hosts example.com；如果镜像中有 dig，再执行 dig example.com。
查看容器网络：docker inspect 容器名，确认容器连接的网络和网关。
如果容器连接自定义网络，/etc/resolv.conf 中可能出现 Docker 内置 DNS 地址 127.0.0.11。这不是公网 DNS 地址，不能简单改成任意地址；应继续检查 Docker 宿主机 DNS、容器网络和上游解析器。
如果只有容器失败，分别在宿主机和容器内查询同一个域名。宿主机成功、容器失败时，重点检查容器网络、宿主机防火墙、DNS 转发和容器内应用的解析库。

Docker 官方文档说明，自定义网络中的容器使用 Docker 内置 DNS，地址为 127.0.0.11，该服务会把外部查询转发到宿主机配置的 DNS；默认 bridge 网络和自定义网络的行为并不完全相同。可对照Docker 网络与 DNS 官方文档。

Kubernetes：从 Pod、DNS Service 到 CoreDNS 日志逐层判断

先在故障 Pod 内执行 cat /etc/resolv.conf，记录 nameserver、search 和 options。
使用具备 DNS 查询工具的临时调试 Pod，分别测试集群内服务名和外部域名。例如先查询一个已知服务，再查询 example.com，不要只测试外部域名。
检查 DNS Service 和端点：kubectl get svc -n kube-system、kubectl get endpoints -n kube-system。具体资源名称以集群实际部署为准。
检查 CoreDNS Pod 状态和日志：kubectl get pods -n kube-system、kubectl logs -n kube-system -l k8s-app=kube-dns。如果标签选择器不同，以集群实际标签为准。
若 Pod 内的 nameserver 不正确、DNS Service 无端点或 CoreDNS 无法访问上游，再分别检查 kubelet、网络策略、线路网络和上游 DNS。

Kubernetes 官方的DNS 解析调试文档建议从 Pod 内的 /etc/resolv.conf、DNS Service、CoreDNS Pod 和日志逐层检查。命令返回成功并不代表应用一定成功，还要确认应用所在 Pod、命名空间和网络策略一致。

为什么 nslookup 或 dig 成功，但 Java、Nginx、Node.js 或浏览器仍失败

命令行工具和应用可能没有走同一条解析路径。常见差异包括：应用读取了 hosts 文件、使用独立 DNS 缓存、运行在容器内、固定缓存了旧地址、只查询 A 或 AAAA，或者浏览器启用了独立的安全 DNS。

先确认进程所在环境：在宿主机成功，不代表容器、虚拟机或 Kubernetes Pod 成功。
核对应用看到的配置：检查进程环境变量、容器内 /etc/resolv.conf、系统 hosts 文件和应用启动参数。
分别测试 A 与 AAAA：如果应用优先尝试 IPv6，而 IPv6 路径不可用，可能表现为解析后连接失败或整体请求超时；这时要把 DNS 阶段和 TCP 阶段分开记录。
检查应用缓存：Nginx 的上游域名解析受其 resolver 配置和缓存行为影响，不能用一次 dig 结果替代运行中进程的实际解析。Nginx 官方文档说明，动态解析可由 resolver 指令指定，并可通过 valid 控制缓存时间，详情见Nginx resolver 官方文档。
浏览器单站点失败：先用无痕窗口或另一浏览器做对照，再检查浏览器的安全 DNS、扩展、hosts 和系统代理设置；不要直接重置全部浏览器配置。

如果 dig 已经拿到 IP，但应用仍报 lookup failure，应记录应用进程的完整错误、查询域名、查询类型、发生时间和运行环境。此时问题可能已经从 DNS 内容层转移到应用解析库、连接建立或浏览器网络层，继续清理 DNS 缓存通常没有帮助。

排查完成后的判断边界

只有一个域名失败：优先核对域名拼写、记录类型、CNAME 链、委派和权威服务器，不要先修改所有客户端 DNS。
同一网络的多个设备都失败：检查路由器、企业 DNS、上游转发、UDP/TCP 53 和网络策略。
只有一个设备失败：检查本机 DNS、hosts、缓存、网卡配置、IPv6 和防火墙。
只有一个应用或容器失败：检查应用自己的解析路径、运行时环境和缓存，不要把宿主机的查询结果当作最终证据。
NXDOMAIN 与超时不能混为一谈：NXDOMAIN 是名称不存在的 DNS 回答；超时是请求未及时获得响应，处理方向分别是记录/委派核对与网络路径/服务器可达性核对。
清缓存不是通用修复：Windows 的 ipconfig /flushdns、Linux 的 resolvectl flush-caches 只影响本机缓存，不能修复错误的 DNS 记录、失效的委派、不可达的上游或容器网络故障。

建议每次只改一个变量，并保存修改前后的 ipconfig /all、resolvectl status、dig 或 nslookup 输出。这样才能判断问题究竟在哪一层恢复，而不是把偶然恢复误认为已解决。

常见问题

DNS lookup failure 是不是说明域名不存在？

不一定。NXDOMAIN 通常表示权威结果认为名称不存在，但 DNS lookup failure 也可能由 DNS 服务器超时、SERVFAIL、REFUSED、本机配置错误、容器解析失败或应用缓存导致。先执行 nslookup 或 dig 看具体返回结果。

Windows 上 DNS lookup failure 最先执行什么命令？

先执行 <code>ipconfig /all</code> 确认当前 DNS 服务器，再执行 <code>nslookup 失败域名</code>。如果怀疑记录刚修改或本机缓存了负结果，再执行 <code>ipconfig /displaydns</code> 和 <code>ipconfig /flushdns</code>，不要一开始就修改所有网络设置。

Linux 中看到 127.0.0.53，应该改成其他 DNS 吗？

不应直接修改。127.0.0.53 常见于 systemd-resolved 的本地 stub 解析器，先用 <code>resolvectl status</code> 查看它实际使用的上游 DNS，再用 <code>resolvectl query 域名</code> 验证。确认 systemd-resolved 是否管理 <code>/etc/resolv.conf</code> 后，再按网络管理组件修改配置。

Docker 容器里的 127.0.0.11 是不是错误地址？

不一定。Docker 官方文档说明，自定义网络中的容器可能使用内置 DNS 地址 127.0.0.11，由它转发外部查询。应在容器内查看 <code>/etc/resolv.conf</code>，并对比宿主机、容器和上游 DNS 的查询结果，不能只看到 127.0.0.11 就直接替换。

nslookup 能解析，为什么浏览器还是报 DNS lookup failure？

命令行和浏览器可能使用不同解析路径。检查浏览器安全 DNS、扩展、hosts、系统代理、IPv6 地址选择和浏览器缓存；同时用另一浏览器或无痕窗口对照。若只有一个应用失败，优先检查应用自己的 DNS 配置和缓存。