根本原因是veth对端未开启hairpin_mode，导致网桥丢弃发往同主机其他容器的流量；需在宿主机侧veth接口执行echo 1 > /sys/class/net/vethxxx/brport/hairpin_mode启用。
为什么容器 ping 不通同主机的另一个容器？
根本原因通常是 veth 对端没开 hairpin_mode，导致发往本机其他容器的包在网桥上被直接丢弃——不是路由问题，也不是防火墙挡了，是网桥默认拒绝“进又出同一端口”的流量。
典型现象：ping 超时、tcpdump 在宿主机网桥接口（如 docker0）能看到入包但没出包；用 curl 访问同主机容器 IP 时卡住或报 Connection refused（如果服务监听了 0.0.0.0 却仍连不上，大概率就是这个）。
- 只影响“容器 → 同主机其他容器 IP”的通信，不影响容器访问宿主机 IP 或外部网络
- 必须在 veth 的宿主机侧接口（即连到网桥那一端，如
vethabc123）上启用，容器内侧接口无效 - 启用后不改变路由路径，只是让网桥允许该 veth 接口既收又发同类目的包
怎么手动开启 veth 的 hairpin_mode？
核心命令就一条：echo 1 > /sys/class/net/<veth-name>/brport/hairpin_mode</veth-name>，但要注意路径存在性和权限。
常见错误：路径不存在（说明该接口没桥接）、写入失败（没 root 权限）、写错接口名（把容器内的 eth0 当成目标）。
- 先确认 veth 名称：用
ip link show | grep veth或查docker network inspect bridge | grep -A5 "Options" - 检查是否已桥接：运行
cat /sys/class/net/<veth-name>/brport/bridge/name</veth-name>，有输出才表示已接入网桥 - 启用命令示例：
echo 1 | sudo tee /sys/class/net/vetha1b2c3/brport/hairpin_mode - 重启后失效，需持久化：写入 systemd service、NetworkManager 配置，或在容器启动脚本中调用（Docker 用户建议改用
--sysctl net.ipv4.conf.all.forwarding=1+ 确保桥接配置正确）
Docker 默认没开 hairpin_mode，但为什么有时还能通？
因为 Docker 在创建容器时，**只有当用户显式使用 host 网络模式或自定义桥接且指定了 --ip 时，才可能漏掉 hairpin 配置**；而默认 bridge 网络下，Docker daemon 实际会自动为每个 veth 启用 hairpin_mode——前提是它能成功写入 sysfs。
所以“不通”往往出现在这些场景：
- 手动创建了 veth 对并桥接到
docker0，但没配 hairpin - Docker daemon 版本较老（
- 使用 CNI 插件（如 Calico、Cilium）替代 docker0，它们默认不启用 hairpin，需单独配置
hairpinMode: true在 CNI 配置中 - 容器使用
host网络模式，此时不走 veth+网桥，hairpin 不生效也不需要
开启 hairpin_mode 会影响性能或安全吗？
几乎无性能损耗：hairpin 是网桥层极轻量的转发决策，不引入额外拷贝或协议栈穿越；实测吞吐和延迟变化在误差范围内。
安全上，它只放宽“同一物理端口进出”的限制，并不开放新端口、不绕过 iptables 或 nftables 规则——所有包仍受 FORWARD 链控制。
- 真正要注意的是：开启 hairpin 后，若容器监听
0.0.0.0:80，同主机其他容器就能直连它 IP:80，相当于暴露了内部服务——这本身是设计意图，但容易被当成“意外泄露” - 某些合规环境要求容器间通信必须经由 Service Mesh 或 API 网关，这时反而要禁用 hairpin，强制流量走 sidecar
- 别混淆
hairpin_mode和rp_filter：后者是反向路径校验，关它可能引发其他问题，和 hairpin 无关
最常被忽略的一点：hairpin_mode 只作用于二层网桥转发，如果你用的是 IPv6 + SLAAC 或启用了 ipv6forwarding 但没配好邻居发现，那即使 hairpin 开了，ICMPv6 RA 或 NDP 包也可能卡住——这时候问题已经不在 hairpin 本身了。
