--network host使容器直接共享宿主机网络命名空间，不分配独立IP、不走NAT、端口直通宿主机，但丧失网络隔离与DNS服务，适用于监控、调试等高性能场景。
直接用 --network host 启动容器，就能让容器共享宿主机的网络命名空间，不走桥接、不分配独立 IP、不经过 NAT，所有端口都直接暴露在宿主机上。
host 模式的核心特点
容器内看到的网络配置和宿主机完全一致：同一个 lo 接口、同一套路由表、相同的 iptables 规则、一样的监听端口。这意味着：
-
端口映射失效：使用
-p 8080:80不起作用，容器必须自己监听宿主机实际可用的端口 - 无网络隔离：容器可直接访问宿主机上运行的所有服务（如 localhost:5432 的 PostgreSQL），也容易因端口冲突导致启动失败
- 性能更高：省去 veth pair + docker0 + iptables DNAT/SNAT 等环节，适合高吞吐或低延迟场景（如实时日志采集、监控代理）
典型使用方式
启动命令示例：
docker run -d --network host --name nginx-host nginx
此时容器内执行 netstat -tlnp 或 ss -tln，能看到和宿主机完全一致的监听状态；访问 http://localhost:80 即是访问该容器的服务。
若需限制容器仅访问特定服务（比如只连宿主机的 Redis），建议配合 iptables 或宿主机防火墙策略控制出向流量，而非依赖网络模式本身做隔离。
Linux 下注意事项
host 模式在 Linux 原生环境中直接生效；但在 macOS 和 Windows 上，Docker Desktop 运行于虚拟机中，--network host 实际共享的是虚拟机的网络栈，不是你 Mac/Windows 主机的网络。因此：
- 容器无法通过
localhost直接访问 macOS/Windows 上本地启动的服务（如本机 VS Code Server、本地 MySQL） - 如需访问宿主机服务，应改用
host.docker.internal（Docker Desktop 自动注入的 DNS 名） - 若必须用 host 模式且依赖宿主机端口，建议在 macOS/Windows 上改用 WSL2 + 原生 Docker 引擎
什么情况下不该用 host 模式
以下场景推荐避开 host 模式：
- 多个容器需要同时监听同一个端口（如都用 8080），必然冲突
- 部署环境要求容器间网络隔离（如测试环境需模拟多节点通信）
- 容器镜像不可信，担心其修改宿主机网络配置或监听敏感端口
- 使用 Docker Compose 且依赖内置 DNS（host 模式下
service-name解析会失效）
