容器 IP 能访问，名称却解析失败：检查是否使用默认 bridge

两个 Docker 容器用 IP 能通信，用容器名却提示无法解析。先检查它们是否都在 Docker 内置的 bridge 网络上。这个默认网络不提供用户自定义 bridge 网络的自动名称解析，反复重启容器或把地址写死并不能补上这项能力。

本文针对单个 Docker 主机上的 Linux bridge 容器网络，不适用于 Swarm、Kubernetes、host 或 macvlan 网络。Compose 自动创建的 项目名_default 通常是用户自定义网络，不等于 Docker 内置的 bridge。

确认查的是容器内部通信

先区分请求从哪里发起：容器名解析用于接入同一用户自定义网络的容器之间，不会自动让宿主机、办公电脑或外部 DNS 认识这个名字。

查看两个容器实际接入的网络。下面的名称是示例：

docker inspect web db
docker network inspect bridge

在容器的 NetworkSettings.Networks 中核对网络名，再与网络中的容器列表对应。如果它们只接入内置 bridge，可以继续迁移到共同的用户自定义网络。如果已经接入共同网络，则要检查目标名称、网络别名和应用实际使用的 DNS 配置，不能继续归因默认 bridge。

两个网络名字都含 default，但分别是 appa_default 和 appb_default，也不代表相通。服务需要共同接入一张网络，才能利用这张网络上的名称解析。

将两个容器接入同一个自定义网络

在确认连接关系和影响后，可为现有容器新增共同网络。以下示例假设 app_net 尚不存在，web、db 是已经运行的容器：

docker network create app_net
docker network connect app_net web
docker network connect app_net db

接入后，应用应使用网络中的容器名或明确设置的别名及后端容器监听端口。例如目标为 db 时，使用数据库本身的监听端口，而不是宿主机发布端口。不要为了名称解析新增不必要的公网端口。

这会改变网络连接关系，应先记录原有网络、应用目标地址及出站依赖。不要立即断开旧网络；新增网络也可能影响多网卡容器的路由选择，应同时检查出站访问与现有业务。

新增连接可用于验证，但不会自动改写启动脚本或 Compose 文件。容器以后重新创建时，仍可能只接入原网络。确认有效后，将共同网络写入受维护的部署配置；多个独立 Compose 项目共享网络时，要明确外部网络生命周期。

验收名称与业务连接

在发起请求的容器中，用应用自己的连接检查或镜像已有的 DNS 工具核对名字。精简镜像没有 ping、nslookup 或 getent，不是名称解析失败的证据，不能只为了检查就改变生产镜像。

成功标准是容器内部能把目标名解析到预期网络地址，并连接正确的服务端口；重新创建容器后也保留相同网络关系。解析成功但连接被拒绝时，继续检查后端监听地址、端口和就绪状态。

需要回退时，先恢复应用原目标地址与配置，再移除本次新增的网络连接。只能删除确认已无人使用的新网络，不能清理仍承载其他业务的网络。