在 docker compose 中配置 dns_search 和 dns 可实现短名称解析，需指定内网 dns 地址（如 192.168.10.5）和搜索域（如 dev.company.local），并配合自定义桥接网络使用，避免使用默认 bridge 网络和公网 dns 优先导致的解析失败。
在 Docker Compose 中配置自定义 DNS 搜索域，核心目标是让服务能用短名称（如 db 或 cache）直接解析到内网服务，避免写全限定域名（如 db.dev.company.local），从而提升服务发现效率和代码可读性。
在 docker-compose.yml 中声明 dns_search 和 dns
这是最常用、最推荐的方式，配置随项目一起版本化，清晰可控：
- 在服务级别或全局 networks 下添加 dns_search 字段，填入你的内部域名后缀，例如 dev.company.local
- 同时指定内网 DNS 服务器地址（不能是 127.0.0.1），比如 192.168.10.5，确保容器能直连该地址
- 不要把公网 DNS（如 8.8.8.8）放在第一位——它无法解析内部域名，反而会引入超时等待
示例片段：
services:
web:
image: nginx
dns: ["192.168.10.5"]
dns_search: ["dev.company.local", "svc.cluster.local"]
配合自定义桥接网络使用效果更佳
Docker 默认 bridge 网络不支持服务名自动解析，必须用用户定义网络才能启用内置 DNS：
- 定义一个 bridge 类型的自定义网络（如 app-net）
- 所有微服务都加入该网络，Docker 会为每个服务名自动注册 A 记录
- 加上 dns_search 后，调用 db 就等价于 db.dev.company.local，无需改代码
避免常见陷阱
很多性能问题其实源于配置细节错误：
- 宿主机上能 ping 通的 DNS 地址，在容器里可能路由不通——务必确认该 DNS IP 在容器网络命名空间中可达
- 多个 dns_search 域按顺序尝试，建议把最常用的放前面
- 如果用了 Kubernetes 或 CoreDNS，且集群已配置存根域（如 consul.local → 10.150.0.1），Compose 容器应统一指向 CoreDNS 地址，而非绕过它直连内网 DNS
调试与验证方法
启动后快速确认是否生效：
- 进入容器：docker compose exec web sh
- 检查 /etc/resolv.conf 是否包含预期的 search 行和 nameserver
- 执行 nslookup db，看是否返回内网 IP；再试 nslookup db.nonexistent，确认失败快（无冗余等待）
