直接修改容器内/etc/resolv.conf无效，因其由Docker启动时自动生成并覆盖；有效方法是控制其生成逻辑：优先使用127.0.0.11内置DNS转发器，精简search域，配置可信低延迟上游DNS，或通过挂载定制resolv.conf强制替换。
直接修改容器内的 /etc/resolv.conf 通常无效——它在容器启动时由 Docker 自动生成并覆盖。真正有效的调优，是控制这个文件“怎么生成”，而不是进去手动改。核心思路就三点：让 nameserver 指向最快路径、精简 search 域减少试错轮次、避免无效上游转发。
确认当前 DNS 解析链路是否走对路
先进容器看真实配置：
-
docker exec -it 容器名 cat /etc/resolv.conf—— 第一行必须是nameserver 127.0.0.11，这才是 Docker 内置 DNS 转发器，支持毫秒级服务发现 - 如果看到
127.0.0.1或宿主机 IP，说明被 --dns 参数或 daemon.json 强制覆盖，反而绕开了优化路径 - 用
nslookup -debug web-svc 127.0.0.11确认是否直连内置 DNS；响应时间稳定在 5ms 内才算正常
精准控制 search 域，砍掉无效补全
search 域决定短名（如 db）如何自动拼接成完整域名。每多一个域，失败就多等 1–3 秒。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 只设一个最常用域：比如项目统一用
dev.local，就配--dns-search dev.local - docker-compose 中写死：
dns_search: ["dev.local"]，别用空格分隔多个值 - 跨网络访问务必用 FQDN：查
cache.app-net，不查cache，跳过 search 补全环节
上游 DNS 必须可信且低延迟
Docker 内置 DNS（127.0.0.11）查不到容器名时，会把请求转发给上游 DNS。这一步卡住，整条链就慢。
- 禁用公共 DNS 做上游：8.8.8.8 查
api.dev.local必然超时，换成内网 DNS（如192.168.10.5），10ms 内返回 NXDOMAIN - 全局配置：改
/etc/docker/daemon.json，加"dns": ["192.168.10.5"]，重启 Docker - 严禁混搭多个上游：写
"dns": ["192.168.10.5", "8.8.8.8"]会导致第二个永远等超时才轮到，不如只留一个
需要彻底接管？用挂载法硬替换
当必须绕过 Docker 自动生成逻辑（比如某些遗留应用强依赖特定 resolv.conf 格式），可用文件挂载强制覆盖：
- 在宿主机准备定制文件：
/etc/docker/dns/resolv.conf，内容含nameserver 223.5.5.5和options timeout:1 attempts:2 rotate - 启动时挂载：
docker run -v /etc/docker/dns/resolv.conf:/etc/resolv.conf ... - 注意：该方式在自定义网络下仍生效，但可能影响容器间服务发现，慎用于生产集群
