容器互通失败主因是防火墙拦截内部流量：需检查iptables FORWARD链、firewalld zone策略及bridge-nf-call-iptables内核参数，确认veth对与网桥直连路径是否被阻断。
在复杂防火墙环境下，Docker Compose 容器内部互通失败，往往不是网络配置本身出错，而是流量被中间策略拦截或绕过。关键在于区分“容器间通信”和“容器到宿主机/外部通信”——前者走的是 Docker 内部虚拟网桥（如 br-xxxx 或 docker0），不经过宿主机 iptables 的 INPUT/OUTPUT 链，但可能受 FORWARD 链、firewalld zone 策略或内核参数限制。
确认通信路径是否真正走内部网络
默认情况下，同一自定义 bridge 网络中的容器通过 veth 对 + 网桥直连，数据包不进入宿主机协议栈的 INPUT/OUTPUT，只经过 FORWARD。因此：
- 检查
iptables -L FORWARD -n：若策略为DROP且无放行规则（如ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED），容器间 ping 或 curl 会静默失败 - 运行
sysctl net.bridge.bridge-nf-call-iptables：若返回1，表示网桥流量会被 iptables 处理；生产环境建议设为0（sysctl -w net.bridge.bridge-nf-call-iptables=0），避免桥接流量误入防火墙链 - 用
tcpdump -i docker0 icmp在宿主机抓包：若容器 A ping 容器 B 时，docker0上完全看不到 ICMP 请求/响应，说明流量根本没走到网桥层——可能是服务未加入同一网络，或 compose 文件中 networks 配置有误
排查 firewalld 对 bridge 接口的 zone 管控
firewalld 默认将 docker0 和自定义网桥接口（如 br-abc123）归入 public 或 trusted zone。若落在 public，默认拒绝所有入向连接（包括容器间）：
- 执行
firewall-cmd --get-active-zones查看各接口所属 zone - 若
docker0或自定义网桥在publiczone，运行：firewall-cmd --zone=trusted --add-interface=docker0 --permanentfirewall-cmd --reload - 也可直接将整个 Docker 网络段加入信任：
firewall-cmd --zone=trusted --add-source=172.20.0.0/24 --permanent（替换为你实际子网）
验证容器网络命名空间与路由行为
即使网络声明正确，某些安全加固系统（如 SELinux enforcing + container_runtime_t 策略）或自定义 CNI 插件可能干扰容器间 ARP 解析或 IP 转发：
- 进入容器执行
ip route：确认默认网关是 Docker 网络的网关（如172.20.0.1），而非0.0.0.0或宿主机地址 - 执行
cat /proc/sys/net/ipv4/ip_forward：必须为1（Docker 启动时通常自动设置，但某些安全策略会重置） - 测试 ARP 是否通：
docker exec -it web arping -c 3 backend（backend 是服务名）
若无响应，说明 L2 层未通，大概率是网桥未生效或容器未真正接入同一网络
绕过防火墙干扰的轻量级验证法
当无法临时调整防火墙策略时，可用最小闭环快速定位问题根源：
- 停掉所有服务：
docker-compose down - 手动创建一个干净 bridge 网络：
docker network create --driver bridge --subnet=172.30.0.0/24 testnet - 启动两个基础容器并指定该网络：
docker run -d --name c1 --network testnet --rm alpine sleep 3600docker run -it --network testnet --rm alpine ping -c 3 c1 - 若手动方式能通，说明原 compose 配置或项目网络存在隐性冲突（如子网重叠、attachable 缺失、Swarm 模式干扰等）
