错误“Temporary failure in name resolution”表明DNS解析失败，而ping 8.8.8.8成功说明网络连通性正常，问题出在DNS解析链路中断，常见原因包括容器内resolv.conf配置无效（如仅含127.0.0.53）、宿主机systemd-resolved异常、bridge网络子网冲突、防火墙拦截UDP 53端口或DNS请求未发出/无响应。
容器内执行 nslookup baidu.com 报错 Temporary failure in name resolution 或 Could not resolve host，但 ping 8.8.8.8 成功，说明网络连通性正常，问题锁定在 DNS 解析链路中断——这通常不是容器应用本身的问题，而是从容器内部到外部 DNS 服务器之间的某一层被阻断或配置错误。
第一步：确认容器内 DNS 配置是否有效
进入目标容器执行：docker exec -it
检查输出中是否存在 【nameserver 行且 IP 地址可达】；若为空、仅有 127.0.0.53（systemd-resolved stub）、或指向一个明显不可达的地址（如 192.168.1.1 但宿主机已不走该网关），则解析必然失败。
注意：Docker 默认将宿主机 /etc/resolv.conf 的内容复制进容器，但若宿主机使用 systemd-resolved，其生成的 127.0.0.53 在容器内无法访问——这是最常见误配根源。
第二步：验证宿主机 DNS 是否真正可用
在宿主机上运行：nslookup baidu.com 8.8.8.8
这条命令绕过本地 resolver，直连公共 DNS 服务器。如果返回正确 IP，说明宿主机网络层可通 DNS；如果超时或报错，则问题出在宿主机层面：可能是 WiFi 断连、防火墙拦截 UDP 53 端口、systemd-resolved 进程崩溃，或路由器 DNS 设置异常。
若该命令失败，立即执行：systemctl status systemd-resolved → 若显示 inactive (dead)，运行 sudo systemctl restart systemd-resolved 并重新测试。
第三步：区分网络模式并检查转发路径
方法一：bridge 模式（默认）
容器通过 Docker 虚拟网桥通信，DNS 请求需经宿主机转发。执行：docker network inspect bridge | grep -A 5 "IPAM"，确认子网未与宿主机 WiFi 网段冲突（例如宿主机 WiFi 是 192.168.31.0/24，而 bridge 子网也是 192.168.31.0/24，会导致路由混乱）。
方法二：host 模式
容器直接复用宿主机网络栈，此时 /etc/resolv.conf 必须完全等同于宿主机。若宿主机 DNS 正常但容器仍失败，检查是否启用了 SELinux/AppArmor 限制：ausearch -m avc -ts recent | grep dns，命中记录即表明权限被拒。
方法三：自定义网络（含 Kubernetes）
若使用 docker network create --dns 114.114.114.114 或 K8s 中配置了 dnsConfig，需确认指定 DNS 地址真实可达：docker run --rm --dns 114.114.114.114 alpine nslookup baidu.com。若失败，说明该 DNS 服务本身异常或被中间设备拦截。
第四步：抓包定位 DNS 请求是否发出及响应是否返回
第一步：在容器内启用 tcpdump（若镜像不含，先装：apk add tcpdump 或 apt-get update && apt-get install -y tcpdump）
第二步：在容器内执行：tcpdump -i any port 53 -w /tmp/dns.pcap，另起终端触发解析：nslookup baidu.com
第三步：将抓包文件拷出：docker cp ，用 Wireshark 打开分析：
→ 若无任何 UDP 53 流量：说明容器内 resolver 根本没发请求，大概率是 /etc/nsswitch.conf 中 hosts: 行缺失 dns，或 libnss_dns.so.2 库损坏；
→ 若有请求但无响应：说明请求发出去了，但被丢弃或阻断，重点查宿主机 iptables/nftables 规则、CNI 插件 DNS 转发链（如 Calico 的 DNS_REDIRECT）、或物理网络 MTU 不匹配导致 UDP 分片丢失。
