docker compose 本身不支持跨主机通信，必须依赖外部网络方案（如 swarm overlay、kubernetes cni 或 flannel），其防火墙穿透核心是放行对应方案的底层流量：swarm 需开放 udp 7946 和 4789；k8s 需开放 ip 协议号 4 或 udp 8472；自建 vxlan 需基于容器网段添加 firewalld source 规则，并确保 ip_forward=1、forward 链放行、bridge-nf-call-iptables=0。
多宿主机环境下，Docker Compose 本身不原生支持跨主机通信——它默认只管理单机上的容器网络。真正实现跨宿主机互通，必须借助外部网络方案（如 Docker Swarm Overlay、Kubernetes CNI 或第三方 SDN），而防火墙穿透是其中最关键的落地环节。核心不是“让 Compose 穿透防火墙”，而是让底层网络方案的流量被防火墙正确识别和放行。
明确通信路径：先选网络方案，再定防火墙策略
Compose 只负责编排，跨主机通信依赖底层网络驱动。不同方案对应完全不同的防火墙开放逻辑：
- Docker Swarm Overlay 网络：依赖 VXLAN 封装，需在所有节点开放 UDP 端口 7946（节点发现）和 4789（VXLAN 数据）；防火墙必须允许这两个端口的双向通信
- Kubernetes + Calico/Cilium：通常使用 BGP 或 eBPF 转发，重点开放各节点间 IP 协议号 4（IP-in-IP）或 UDP 8472（VXLAN），并确保节点间 TCP 6443（kube-apiserver）、10250（kubelet）等控制面端口可达
- 自建 VXLAN 或 Flannel host-gw：需手动打通节点间子网路由，并在防火墙中添加 源/目标为容器网段（如 10.244.0.0/16）的 ACCEPT 规则，且不能仅靠接口名（如 flannel.1）——接口可能动态创建，应基于 IP 段控制
firewalld 配置要点：避免 zone 误判导致静默丢包
firewalld 对桥接接口和虚拟设备的 zone 归属容易出错，尤其在多节点环境中：
- 执行
firewall-cmd --get-active-zones，确认每个节点上 docker0、flannel.1、vxlan.calico 等虚拟接口是否落入 trusted 或 internal zone；若在 public zone，默认拒绝所有入向连接 - 不要只加接口，更要加容器网段：
firewall-cmd --permanent --zone=trusted --add-source=10.244.0.0/16（替换为你实际的 Pod 或容器 CIDR） - Overlay 网络的 VXLAN 流量走的是物理网卡（如 eth0），不是 docker0——必须对物理接口所在 zone 开放 UDP 4789 和 7946，否则封包根本进不了内核网络栈
iptables 层关键检查：FORWARD 链与内核参数协同生效
即使 firewalld 放行，内核转发和 iptables FORWARD 链仍可能拦截跨主机流量：
- 确认
cat /proc/sys/net/ipv4/ip_forward在所有节点返回 1；某些安全加固脚本会重置该值 - 运行
iptables -L FORWARD -n，检查是否有 ACCEPT 规则覆盖容器子网到物理网卡的转发路径，例如：ACCEPT all -- 10.244.0.0/16 anywhere PHYSDEV match --physdev-is-bridged - 关闭
bridge-nf-call-iptables（设为 0）：避免桥接流量误入 iptables，干扰 VXLAN 解封装；命令：sysctl -w net.bridge.bridge-nf-call-iptables=0并写入/etc/sysctl.conf
验证与定位：抓包比 ping 更可靠
跨主机通信失败时，ping 成功率高但应用不通，往往因 UDP 或特定协议被拦。建议分层验证：
- 在源节点执行：
tcpdump -i eth0 port 4789 -nn，确认 VXLAN 封包是否发出；在目标节点同命令，确认是否收到——收不到说明防火墙或路由问题 - 进入容器执行
ip route get 10.244.1.5（目标容器 IP），看路由下一跳是否指向正确的节点 IP；若指向本地网关，说明 overlay 路由未生效 - 用
nc -u 4789测试 UDP 连通性；TCP 端口通不代表 UDP 通，WebRTC、Jitsi 等场景尤其要注意
