在 Docker 环境中，容器能够使用相同端口而互不冲突，核心原因是网络命名空间隔离。每个容器通常拥有独立的网卡、IP 地址、路由表、端口空间和 DNS 配置，再通过虚拟网卡、网桥及主机转发规则与外部连接。🔍 当跨容器访问失败时，不应只盯着应用日志，而应沿着“服务监听—名称解析—网络连接—路由防火墙—端口发布”的链路逐层排查。
一、理解网络命名空间与通信路径
Linux 网络命名空间为容器提供独立的网络栈。以 bridge 模式为例，容器内的 eth0 通常与宿主机上的 veth 设备成对连接，宿主机一端接入 Docker 网桥。同一用户自定义 bridge 网络中的容器，可以通过网桥直接通信；处于不同网络的容器默认受到隔离。Docker 对 bridge 驱动的具体说明可参考官方 bridge 网络文档。
需要特别区分“容器端口”和“宿主机发布端口”。假设数据库容器监听 3306，另一个容器应访问“数据库服务名:3306”，而不是“宿主机地址:映射端口”。参数 -p 3307:3306 主要用于把宿主机 3307 的流量转发到容器 3306，并不是容器之间通信的必要条件。📌
二、先确认容器是否加入同一网络
跨容器通信失败时，首先执行 docker network ls 查看网络，再使用 docker network inspect 网络名检查双方容器是否同时出现在 Containers 列表中。也可以执行 docker inspect 容器名，查看 NetworkSettings.Networks 下的网络名称、IP 地址和网关。
docker network ls
docker network inspect app-net
docker inspect api
docker inspect db
若两个容器不在同一网络，可执行 docker network connect app-net 容器名进行临时接入；长期方案则应修改 Compose 文件，使相关服务显式加入同一 networks 配置。用户自定义 bridge 网络支持容器名和网络别名解析，通常比默认 bridge 更适合多容器应用，相关差异可查阅Docker 网络概览。
三、检查 DNS 与服务名称解析
如果报错包含“Name or service not known”“Temporary failure in name resolution”或“Could not resolve host”，应进入发起请求的容器检查解析结果，而不是在宿主机上测试。可依次查看 /etc/resolv.conf，并使用 getent hosts 服务名、nslookup 服务名等命令验证 Docker 内置 DNS 是否返回目标地址。🧭
docker exec api cat /etc/resolv.conf
docker exec api getent hosts db
docker network inspect app-net
名称解析失败常见于容器未加入同一用户自定义网络、服务名拼写错误、使用了宿主机专用域名，或容器启动后网络配置发生变化。Compose 场景下应优先使用服务名；不要把动态容器 IP 写死，因为容器重建后地址可能改变。若内部服务名可以解析、外部域名不能解析，则应继续检查宿主机 DNS、Docker daemon DNS 配置及企业代理策略。
四、确认应用监听地址和端口
网络连通并不代表应用可访问。最常见的问题是进程只监听 127.0.0.1，此时服务仅接受本容器回环接口的请求，其他容器无法连接。进入目标容器执行 ss -lntp 或 netstat -lntp，确认服务监听在 0.0.0.0、容器网卡地址或者正确的 IPv6 地址上，同时核对实际监听端口。
docker exec db ss -lntp
docker exec api sh -c "getent hosts db; nc -vz db 3306"
“Connection refused”通常表示目标地址可达，但端口没有进程监听，或者服务尚未完成启动；连接超时则更可能与网络隔离、防火墙、错误路由或数据包被丢弃有关。排查时还应通过 docker ps、docker logs --tail 100 容器名确认进程状态，避免把应用崩溃误判为网络故障。⚠️
五、核查路由、转发与防火墙规则
当同一网络内仍无法访问，可在容器中执行 ip addr 和 ip route，确认接口已启用、地址属于预期子网、默认路由存在。宿主机侧可查看 ip link、ip route 和 bridge link，判断 veth 是否正确接入网桥。若 Docker 网络子网与公司 VPN、局域网或云平台网段重叠，流量可能被错误路由，此时应重新规划无冲突的地址池。
宿主机上的 iptables、nftables、firewalld 或安全软件也可能覆盖 Docker 自动生成的转发规则。应重点检查 FORWARD 链默认策略、DOCKER-USER 链中的拒绝规则以及系统的 net.ipv4.ip_forward 设置。不要为了快速恢复而长期关闭防火墙；更安全的做法是定位具体拦截规则，并按来源网络、目标端口和业务方向进行最小范围放行。🛡️
六、按故障现象建立排查顺序
- 容器不存在或反复重启：先查看 docker ps -a、容器日志和健康检查结果。
- 服务名无法解析：确认双方处于同一用户自定义网络，并核对服务名、容器名和 alias。
- 可以解析但拒绝连接：检查目标进程、监听地址、容器端口和启动时序。
- 连接持续超时：检查网段冲突、路由、DOCKER-USER 链、主机防火墙及云安全策略。
- 容器互通但宿主机外部不可达：核对 -p 或 Compose ports 配置，以及服务是否绑定正确接口。
- 偶发失败：检查容器重建、DNS 缓存、连接池、健康检查和依赖服务就绪状态。
避免几个常见误区
- 不要把 ping 失败直接等同于服务不可达，镜像可能没有 ping 工具，网络也可能禁用 ICMP，应使用 curl、nc 或对应数据库客户端测试真实端口。
- 不要用 localhost 访问另一个普通容器；localhost 始终指向当前容器自己的网络命名空间。
- 不要优先依赖固定 IP，服务名和网络别名更适合容器动态重建的场景。
- host 网络会弱化网络隔离，none 网络会完全禁用常规网络连接，使用前应明确其影响。
总结
Docker 跨容器通信排障的关键，是把问题拆成多个可验证层次：先确认容器和进程正常，再检查网络归属与 DNS，然后验证监听地址、端口和路由，最后排查宿主机转发及防火墙。✅ 通过 docker inspect、docker network inspect、getent、ss、ip route 和真实协议客户端形成固定检查流程，通常能够快速区分配置错误、应用未就绪、名称解析异常与底层网络拦截，从而避免无目的地重启容器或放宽安全策略。
