host模式下容器无独立ip、不经过docker0和docker链，网络异常实为宿主机环境问题；需确认network_mode确为host、端口监听地址为0.0.0.0而非127.0.0.1、宿主机防火墙及dns配置正常。
用 host 模式时，容器直接复用宿主机的网络栈，没有独立 ip、不走 docker0 网桥、也不经过 iptables 的 docker 链。所以“网络异常”往往不是 docker 层面的问题，而是应用本身或宿主机环境出了状况。排查重点要从“隔离层消失”这个前提出发，转向宿主机真实网络上下文。
确认是否真在 host 模式下运行
很多人以为加了 --network host 就一定生效，其实有几种常见失效情况：
- 使用 docker-compose.yml 时写成
network_mode: "host"是对的，但若误写为networks: ["host"]（当成自定义网络名），Docker 会静默忽略，退回到默认 bridge 模式 - 在 rootless Docker 或某些容器运行时（如 Podman）中，host 模式行为受限或被禁用
- 启动后用
docker inspect 容器名 | grep NetworkMode查看输出，必须是"host"，而不是"bridge"或空值
检查端口冲突与监听地址
host 模式下，容器内进程绑定的端口就是宿主机端口。连不上，大概率是端口没起来，或绑错了地址：
- 进容器执行
ss -tlnp | grep :80（或netstat -tlnp），确认服务确实在监听，且 Local Address 是 0.0.0.0:80 或 [::]:80，而非 127.0.0.1:80 —— 后者只允许本地回环访问，外部请求会被拒绝 - 宿主机上执行
ss -tlnp | grep :80，看该端口是否已被其他进程占用（比如另一个 Nginx、Apache 或残留的旧容器） - 如果应用默认只监听 127.0.0.1，需修改配置（如 Node.js 的
app.listen(80, '0.0.0.0')，Spring Boot 的server.address=0.0.0.0）
验证宿主机自身网络状态
既然容器和宿主机共用网络栈，那容器里能做的事，宿主机上也该能做，反过来也成立：
- 在宿主机上 curl
http://localhost:80，如果失败，说明服务根本没跑通，跟 Docker 无关 - 从另一台机器 ping 宿主机 IP，再 telnet 或 curl 宿主机 IP:80 —— 如果通，说明问题出在客户端；如果不通，检查宿主机防火墙（
iptables -L -n或ufw status）、云厂商安全组、物理网络 - 注意：host 模式下
curl http://127.0.0.1:80和curl http://宿主机IP:80效果一致，不需要额外配置网关或路由
排除 DNS 与系统级干扰
host 模式虽然省去了网络命名空间隔离，但 DNS、/etc/hosts、nsswitch.conf 等仍由宿主机决定：
- 容器内执行
cat /etc/resolv.conf，内容应和宿主机完全一致；若有差异，说明 Docker daemon 被手动覆盖了 DNS 配置（如/etc/docker/daemon.json中设了"dns"字段），这在 host 模式下反而可能造成解析异常 - 检查宿主机是否启用了
systemd-resolved或dnsmasq，某些版本存在与容器进程的 socket 冲突，可临时停用测试：sudo systemctl stop systemd-resolved - 确认容器内未挂载只读的 /etc 或覆盖了 hosts 文件（例如用了
--add-host或 volume bind mount）
