Linux 容器内 DNS 偶发失败怎么定位：resolv.conf、路由与 NSS 顺序

容器里的接口有时能访问 IP，有时却报“域名解析失败”，最容易误判成上游服务不稳定。真正有效的排查顺序是把问题拆成三段：容器拿到的 /etc/resolv.conf 是否正确，请求是否能到达 DNS 服务器，以及当前进程到底使用哪套 NSS 解析顺序。三段证据对不上时，才需要改配置。

先把“偶发失败”变成可比较的两组证据

别只在故障出现的时候跑一次解析命令，挑一个出过失败情况的域名，再选一个始终稳定的域名，分别记录两种域名在解析成功和失败场景下的完整输出，尤其要记下对应容器名称、操作时间、解析返回的地址，还有应用打印出的具体错误文本。

cat /etc/resolv.conf
getent ahostsv4 api.example.internal
nslookup api.example.internal
ip route get 10.0.0.53

这四条命令各自覆盖的排查维度完全不同：第一条看静态配置规则，第二条走系统自带的解析入口，第三条直接抓包观测DNS原始查询，第四条只校验到DNS服务地址的三层连通性，别把所有情况都笼统归为一句“DNS不通”。

检查 resolv.conf 是否被容器运行时改写

容器里的 /etc/resolv.conf 不一定来自宿主机原文件，运行时可能根据网络命名空间和网络模式重新生成。先看 nameserver 是否指向当前网络中可达的地址，再看 search 域是否把短主机名拼成了意外的查询。

如果修改后的配置在容器重建后自动恢复成原始状态，说明临时修改没有写入网络运行时读取的正式配置源。这时候别急着把 nameserver 直接改成公共DNS地址，先确认业务网络的规则是否要求优先使用内网DNS做解析。

用 getent 和 nslookup 区分解析层

getent 更接近普通程序调用的系统解析链路，而 nslookup 更适合观察 DNS 服务器返回了什么。两者结果不同，通常不是“一个命令错了”，而是它们经过的层次不同。

• getent 失败、nslookup 成功：重点看 /etc/nsswitch.conf、本地缓存模块以及应用使用的运行库。
• 两类查询都失败：接着检查 nameserver 配置、到DNS地址的路由连通性、UDP/TCP 53端口访问规则和底层网络策略限制。
• 两类查询都成功但应用还是报错：留存好完整应用日志，检查应用是否缓存了旧的解析地址，是否内置了独立解析器或者走了代理链路。

可以把 /etc/nsswitch.conf 中的 hosts: 行单独记下来。例如它决定先查本地文件、再查 DNS，顺序和模块缺失都可能让“偶发”表现得像网络抖动。

把路由、超时与应用缓存分开验证

能查到到DNS服务器的合法路由，只能证明内核存在对应下一跳规则，不能证明发出去的查询一定能收到正常应答。可以在相同容器、同一个网络命名空间里连续跑几轮小规模验证，记录每一次的耗时和返回地址，别拿一次成功的结果掩盖偶发的网络丢包问题。

for i in 1 2 3 4 5; do
  date -u
  getent ahostsv4 api.example.internal | head -n 2
done

要是多次解析结果都稳定，但应用仍然报解析错误，接着查应用自身的连接超时配置和本地地址缓存逻辑；要是只有某一个DNS服务地址访问失败，优先核对路由规则和网络访问策略；要是多个不同解析入口同时出现失败，再回头检查nameserver配置和当前容器的网络命名空间状态。

常见问题：为什么改了 nameserver 还是偶发失败

容器里能解析宿主机，为什么业务域名不行？

宿主机名的解析可能走本地映射表或者专属搜索域，业务域名的解析则需要访问内网DNS集群，两类场景分开核对完整域名、指向的nameserver和到对应DNS地址的连通性。

nslookup 成功就能证明应用没问题吗？

不能。应用通常通过系统解析入口或自己的运行库工作，至少还要用 getent 和应用日志做一次对照。

search 和 ndots 为什么会放大延迟？

短名称查询时可能会先挨个拼接多个搜索域发起请求，全部失败后才会尝试查询输入的绝对名称。短名称解析状态不稳定的时候，优先用完整绝对域名做验证，再根据业务实际需求调整搜索域相关配置。

一份可复用的验收清单

1. 保存故障时的 /etc/resolv.conf、/etc/nsswitch.conf 和容器网络模式。
2. 用同一域名对照 getent、nslookup 与应用日志。
3. 对配置里的每一个nameserver地址都执行路由核对，确认报文出口属于预期的网络命名空间。
4. 容器重建后重复走一遍排查流程，确认修复逻辑已经写入运行时读取的正式配置源，而不是仅修改了当前运行的单个容器。

处理DNS偶发故障最忌讳看到一次成功结果就直接下结论。把配置层、路由层、解析库层和应用缓存层的状态分开记录，通常很快就能定位到需要修复的具体环节。