最推荐在服务级别显式配置dns和dns_search字段，将内网DNS（如192.168.10.5）置首并设内网后缀（如svc.cluster.local），确保低延迟解析；网络级dns继承适用于批量管理；需避坑host模式下dns无效、DDNS-GO误配dns等。
在 Docker Compose 编排中配置 DNS 解析服务器来加速内网互联，关键不是“加一个 DNS 服务”，而是让所有业务容器统一、稳定、低延迟地使用内网 DNS（比如 CoreDNS 或 dnsmasq），避免走宿主机或公网 DNS 导致解析慢、失败或绕路。
服务级显式配置 dns + dns_search（最推荐）
这是最直接、可复用、易维护的方式。每个需要内网通信的容器都明确指定 DNS 服务器和搜索域：
- 将内网 DNS 地址（如 192.168.10.5）放在
dns列表首位，确保优先查询 - 追加至少一个公网 DNS（如 114.114.114.114 或 8.8.8.8）作兜底，防止内网 DNS 故障时完全失联
- 设置
dns_search为内网域名后缀（如 svc.cluster.local 和 internal），这样 Java 或 Nginx 调用curl auth会自动尝试auth.svc.cluster.local和auth.internal - 该配置会准确写入容器
/etc/resolv.conf，不受宿主机 systemd-resolved 等干扰
网络级统一继承（适合批量管理）
若多个服务共用同一套 DNS 策略，可在自定义网络定义中集中配置，服务接入即生效：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 定义桥接网络时直接写
dns和dns_search字段 - 所有加入该网络的服务自动获得相同 DNS 设置，无需重复声明
- 修改只需改一处，便于后期统一升级或切换 DNS 后端
- 注意：host 网络不支持此方式，仅适用于
bridge或overlay驱动
配合内嵌 DNS 实现服务名直连（零配置基础能力）
Docker 自带的内嵌 DNS（地址 127.0.0.11）已默认启用，它能自动解析同网络下的服务名（如 db、cache）：
- 只要服务在同一自定义
bridge网络中，无需额外配置就能通过服务名通信 - 它不处理公网域名，所以仍需搭配
dns字段提供递归解析能力 - 若发现解析慢，检查是否因 IPv6 查询回退或并发限制——可加
dns_opt: ["timeout:2", "attempts:2"]优化
避坑要点：别让 DNS 成为瓶颈
常见导致内网 DNS 加速失效的操作：
- 在
services下误给 DDNS-GO 或监控类容器配dns字段——它不需要解析别人，只上报自己 IP - 用默认
bridge网络却不显式配置dns，结果容器继承了不可靠的宿主机 DNS - 未设
dns_search，导致 Spring Boot 应用硬编码完整域名，失去灵活性 - 在
docker-compose.yml中同时写network_mode: host和dns——host 模式下dns字段被忽略
