在 openEuler 上排查 Docker 同桥网络不通：从“全线超时”到定位容器没启动

最新推荐文章于 2026-05-17 16:47:08 发布

原创

最新推荐文章于 2026-05-17 16:47:08 发布 · 1k 阅读

标签

#docker #网络 #容器

在 openEuler 上排查 Docker 同桥网络不通：从“全线超时”到定位容器没启动

一、现象与环境

二、排查思路总览

三、关键症状定位：同桥“全线超时”

四、openEuler 特有的“坑位”：桥与防火墙联动

1）先确认/放开内核和 firewalld

2）iptables 的 FORWARD 规则补齐

3）**反向路径过滤（rp_filter）**一网打尽

4）核心修复：关闭“桥层 → iptables/nft”联动

五、验证网络恢复（你的“核心命令”）

六、最后的真相：OpenWebUI 容器没启动

七、附：Postgres 侧看到的另一个坑（账号）

八、Checklist：openEuler 上 Docker 同桥互通排障清单

九、持久化建议

十、结语

在 openEuler 上排查 Docker 同桥网络不通：从“全线超时”到定位容器没启动

这是一篇记录式技术笔记，复盘一次在 openEuler 24.03 (LTS-SP2) 上排查 docker-compose 部署的 OpenWebUI/Milvus/MinIO/Postgres 集群“容器间网络不通、应用反复重启”的全过程。
关键收获：先把“网络层”排干净，再盯应用自身进程状态；在 openEuler 上，bridge ↔ iptables/nft 的联动是第一嫌疑。

一、现象与环境

现象：
- openwebui 与 Milvus/MinIO/Postgres 互相报“连不上”；OpenWebUI 访问 8080 不通。
- docker run --rm --network openwebui busybox ... nc 同桥互测，最初全部超时。
环境：
- OS：openEuler 24.03 (LTS-SP2)
- Docker：自建 bridge 网络 openwebui（子网 172.18.0.0/16）
- 关键容器：openwebui、openwebui-postgres、openwebui-minio 等

二、排查思路总览

确认容器网络拓扑：容器都在同一 openwebui 网络，有分配 172.18.0.x。
同桥探活：用一次性 busybox/nc 在 容器网络内 测各服务端口。
宿主网络策略：依次排除 firewalld / iptables / rp_filter / bridge-nf-* / nft-bridge / ebtables 干扰。
抓包判定路径：必要时 tcpdump 抓桥接口，看包是否进桥、是否返回。
应用自身：当网络确认畅通但端口还是“closed”，就检查服务是否真正启动、是否监听 0.0.0.0。
最终结论：本例中，网络层问题解决后，OpenWebUI 访问不了的直接原因其实是容器没启动（或启动失败后退出），不是网络。

三、关键症状定位：同桥“全线超时”

首先在 openwebui 网络里跑一次性容器做端口探测（务必在容器网络内，而非宿主）：

docker run --rm --network openwebui busybox sh -c '
  nslookup openwebui-postgres || true
  nslookup openwebui-minio    || true
  nc -zvw3 openwebui-postgres 5432 && echo "PG OPEN" || echo "PG CLOSED";
  nc -zvw3 openwebui-minio    9000 && echo "MINIO OPEN" || echo "MINIO CLOSED"
'

最初看到的是 全部 CLOSED/timeout；ping 网关 172.18.0.1 却是 OK，说明 L3 路由在，桥内转发被拦的概率很高。