宿主机与容器通信本质是veth pair、docker0网桥和网络命名空间协同构建的内核级软通道：veth pair提供点对点虚拟管道，docker0网桥基于MAC地址二层转发，网络命名空间实现隔离边界，三者共同支撑容器通过172.17.0.1访问宿主机服务。
宿主机与容器的通信链路，本质是 Linux 内核级网络虚拟化能力的落地体现。它不依赖外部硬件，而靠 veth pair + 网桥 + 网络命名空间 这三者协同工作，形成一条从容器内部直达宿主机协议栈的“软通道”。
veth pair 是通信的物理管道
veth 设备总是成对出现，一端在容器内（如 eth0），另一端在宿主机上（如 vethabc123）。数据包从容器发出后，直接经由这对虚拟网卡“穿墙”进入宿主机网络空间——这个过程发生在内核内存中，没有真实网线或物理设备参与，转发延迟极低。
- 可通过
ip link show | grep veth查看宿主机上的 veth 接口 - 用
docker inspect 容器名 | grep -A 10 "NetworkSettings"可定位该容器对应的 veth 名称 - 每个 veth pair 是点对点连接，隔离性好，不会干扰其他容器流量
docker0 网桥是流量调度中枢
宿主机上的 docker0 是一个 Linux 网桥（bridge），不是交换机或路由器。它负责把所有接入的 veth 接口逻辑连通，并基于 MAC 地址学习和转发帧。当容器访问宿主机服务时，目标 IP（如 172.17.0.1）实际对应 docker0 的 IP，数据包到达网桥后，直接送入宿主机的网络协议栈处理，无需经过 NAT 或额外路由跳转。
-
ip addr show docker0显示其 IP（通常是 172.17.0.1/16），这就是容器眼中“宿主机”的默认网关 - 该网桥本身不处理三层路由，只做二层转发；宿主机上运行的服务监听在
0.0.0.0或127.0.0.1时，需确认绑定地址是否允许来自 docker0 子网的连接 - 若服务仅监听 127.0.0.1，则容器无法访问——必须改用 0.0.0.0 或具体网卡 IP
网络命名空间是隔离边界
每个容器运行在独立的网络命名空间中，拥有自己的路由表、iptables 规则、lo 接口和 IP 地址。宿主机默认处于另一个命名空间（即 host namespace）。veth pair 正是跨这两个命名空间的唯一桥梁：一端属于容器空间，另一端注册在 host 空间，从而打破隔离又维持边界。
- 容器内执行
ip route，通常看到默认路由指向 172.17.0.1（docker0） - 宿主机执行
ip route show table local，可查到 172.17.0.0/16 被标记为本地直连子网 - 这种设计让容器像局域网内一台普通主机，而 docker0 就是它的“本地网关”
不同系统下访问宿主机的路径差异
Linux 宿主机与容器同属一个内核，走 docker0 网关最直接；macOS 和 Windows 通过 Docker Desktop 运行在轻量虚拟机中，容器与“真正的宿主机”隔了一层，因此不能直接使用 172.17.0.1，而需依赖 host.docker.internal 这个由 Docker Desktop 注入的 DNS 名称，背后由虚拟机内建代理转发请求。
- Linux：直接访问
http://172.17.0.1:端口 - macOS/Windows：使用
http://host.docker.internal:端口（Docker Desktop 20.10+ 默认启用） - 若需兼容多平台，建议在应用配置中抽象宿主机地址，避免硬编码
