docker容器与宿主机通信依赖veth pair、docker0网桥和iptables规则三者协同：容器发包经eth0→veth pair→宿主机veth接口→docker0网桥→iptables转发，访问宿主机服务时直接使用172.17.0.1即可。

直接从通信链路本身入手，比先背概念更有效。Docker 容器和宿主机通信不是抽象机制，而是由几个确定的组件按固定路径协作完成的——抓住 veth pair、docker0 网桥 和 iptables 规则 这三个关键点，就能串起整个架构。

看清数据包实际走哪条路

容器发请求时，不是“连上宿主机”就完事，而是一步步转发：

• 容器内进程把包发给 eth0（它其实是 veth 设备在容器侧的一端）
• 包通过 veth pair “穿墙”到宿主机命名空间，落到对应 vethxxx 接口
• 宿主机内核收到后，根据路由表判断目标：如果是宿主机本地服务（比如 172.17.0.1），就直接交给 docker0 网桥处理；如果是外网地址，则走 SNAT + 物理网卡出去
• 访问宿主机服务时，容器里用 172.17.0.1（docker0 的 IP）即可，这是最稳定、最通用的方式

动手验证比读文档更管用

打开终端，三步确认当前通信是否按预期工作：

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 运行 ip addr show docker0，记下输出里的 inet 地址（通常是 172.17.0.1/16）
• 启动一个容器：docker run -it --rm alpine ping -c 3 172.17.0.1，看能否通
• 进容器执行 ip route，观察默认路由是否指向 172.17.0.1 —— 这说明它天然知道怎么回宿主机

区分模式，避免踩坑

不同网络模式下，通信逻辑完全不同，不能混用理解：

• bridge 模式（默认）：容器有独立 IP（如 172.17.0.2），靠 docker0 和 iptables 转发；宿主机服务必须监听在 0.0.0.0 或 172.17.0.1 上才能被容器访问
• host 模式：容器直接共享宿主机网络栈，没有隔离，localhost 在容器里就等于宿主机 localhost，但无法使用 -p 映射
• 自定义 bridge 网络：docker0 不参与，新网桥有自己的子网和网关 IP，需查 docker network inspect 获取网关地址

调试时盯住两个地方

通信失败，90% 的问题出在这两处：

• 宿主机服务绑定地址：如果服务只监听 127.0.0.1（localhost），容器无论如何都访问不到；必须改成 0.0.0.0 或具体网桥 IP（如 172.17.0.1）
• 防火墙或 iptables 规则拦截：尤其在 CentOS/RHEL 系统上，firewalld 可能默认拒绝来自 docker0 子网的连接，临时关闭或加白名单更直观