记录一下那天晚上的排查过程。同一台 CentOS 7.9 上，ping www.example.com 能通，curl https://www.example.com 直接报 curl: (6) Could not resolve host，换成 IP 访问又正常，nsswitch.conf 看起来没人动过。
刚开始盯着「容器的 resolv.conf 里只有 127.0.0.11，宿主机上并没有这个 DNS」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。curl 走的是 c-ares 或 NSS，和 ping 用的解析路径不同。少数情况下是/etc/hosts 里有一条错误的静态映射，curl 优先命中。
还有一种情况，IPv6 的 AAAA 查询超时，curl 等不到结果就报失败。
上来先确认 curl 实际用的解析结果
curl -v https://www.example.com 2>&1 | grep -iE 'trying|resolve'再往下对比不同解析工具的返回
getent hosts www.example.com && nslookup www.example.com接着检查 hosts 和 resolv.conf
cat /etc/hosts /etc/resolv.conf强制用 IPv4 验证一次
curl -4 -sI https://www.example.com | head -1这类问题以前遇到过，但这次的触发条件和上次不一样。
这类改动我都写进变更记录，过两周再出问题时能对上号。
别只看报错消失，验证要多做一步。curl 能正常返回 200，-v 输出里显示解析到的 IP 与 getent 一致，不再出现 Could not resolve host。
补一句。curl 的解析顺序受 nsswitch.conf 和编译选项影响，容器里要重点看 resolv.conf 的 search 域有没有写错。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。