关键在于使用自定义网络+Docker内置DNS实现服务名自动解析，而非仅更换DNS服务器；需避免默认bridge网络、合理配置ndots、禁用--dns覆盖以确保127.0.0.11生效。
开发环境隔离中配置专属容器内部dns解析，关键在于控制解析行为的源头——容器内的 /etc/resolv.conf 和 dns 查询路径策略，而非简单换一个 dns 服务器。docker 默认会注入宿主机的 dns 配置，但在多服务、多网络或跨环境（如本地开发 vs kubernetes）场景下，这容易导致解析失败或泄露内部域名。
用自定义网络 + 内置 DNS 名称解析
Docker 自带轻量级 DNS 服务，只要容器处于同一自定义 bridge 网络，就能通过服务名自动解析——这是最常用、零配置、最可靠的开发隔离方式。
- 在 docker-compose.yml 中声明独立网络（不依赖默认 bridge）
- 所有服务显式加入该网络，例如：
networks: [app-net] - 服务启动后，
curl http://backend:3000/health可直接访问，无需写 IP 或改 resolv.conf - 该 DNS 由 Docker daemon 维护，仅对该网络内服务生效，天然隔离
覆盖容器 DNS 配置（/etc/resolv.conf）
当需要强制使用特定 DNS 服务器（如本地 SmartDNS、dnsmasq 或内部 DNS），可在运行时或 Compose 中指定：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 启动容器时加参数：
--dns 192.168.1.100 --dns-search example.local - 在 docker-compose.yml 的 service 下添加：
dns:<br> - 10.1.2.3<br> - 8.8.8.8<br>dns_search:<br> - dev.example.com<br> - svc.cluster.local
- 注意：Docker 会把指定 DNS 写入容器
/etc/resolv.conf，但不会覆盖options ndots，如有需要需配合extra_hosts或入口脚本修正
拦截并重写 DNS 查询（高级隔离）
适用于需要统一管控、测试不同 DNS 行为、或模拟内网域名解析的场景：
- 在容器内运行轻量 DNS 代理（如 dnsmasq 或 CoreDNS），监听
127.0.0.11或127.0.0.1 - 启动容器时用
--dns 127.0.0.1指向它，并通过extra_hosts或配置文件预设映射 - 例如将
api.staging始终解析为本地 mock 服务：extra_hosts: ["api.staging:172.20.0.99"] - 适合 CI 测试、契约测试、或前端联调时屏蔽真实后端
避免踩坑的三个细节
很多 DNS 解析失败不是配置错了，而是被隐性机制干扰：
-
ndots:5 默认值会干扰短域名：访问
mysql会被补全成mysql.default.svc.cluster.local，开发时建议在 Compose 中加dns_options: ["ndots:1"] - host.docker.internal 不参与内部 DNS 解析：它是 Docker Desktop/Linux 手动注入的 host entry，不属于 DNS 查询链路，不能用于服务发现
-
default network 不支持服务名解析：两个容器都用
--network bridge启动，无法通过名字互访；必须用自定义网络才能启用 Docker 内置 DNS
