-p在host模式下无效，因容器直接共享宿主机网络命名空间，端口映射依赖的iptables/NAT机制被绕过；此时容器监听0.0.0.0:80即等同宿主机监听，-p参数被忽略且docker会发出警告。
不需要。当你在 Docker Desktop 中使用 --network host 启动容器时，-p 或 -P 指定的端口映射会被完全忽略——容器直接复用宿主机的网络栈，所有监听行为都发生在宿主机真实接口上。
为什么 -p 在 host 网络下无效
Docker 的端口映射本质是通过 iptables（Linux）或 hyperkit 转发规则（macOS）做 NAT，而 host 模式绕过了整个 Docker 网络层。容器进程启动后直接调用 bind(0.0.0.0:80)，等价于你在宿主机上原生运行一个服务。
常见错误现象包括：
- 执行
docker run --network host -p 8080:80 nginx后，docker ps的PORTS列为空 - 容器内服务监听了
0.0.0.0:80，但宿主机curl http://localhost:80失败——实际可能是 Nginx 配置未监听0.0.0.0，或被宿主机已有进程占用了 80 端口 - 误以为
-p 8080:80能把容器的 80 映射到宿主机 8080，结果发现访问 8080 无响应，而访问 80 却通了
--network host 的典型使用场景
适用于对网络延迟敏感、需绑定特权端口（如 80/443）、或需直接获取客户端真实 IP 的服务。比如：
- 反向代理（Nginx / Traefik）需要读取
X-Real-IP或使用proxy_protocol - 监控 agent（如
telegraf）需采集宿主机网络指标 - 本地开发调试时想快速验证服务是否能真正 bind 成功，绕过 Docker 网络抽象
注意：Windows/macOS 上的 Docker Desktop 使用的是轻量级 Linux VM（hyperkit / WSL2），--network host 实际绑定的是该 VM 的网络，**不是 Windows/macOS 宿主机本身**。所以你在 macOS 上跑 nginx --network host，监听的是 VM 的 80，还需额外确保 VM 的 80 被转发到 macOS 的 80（Docker Desktop 默认不自动做这层转发）。
替代方案：什么时候该放弃 host 模式
如果你只是想省掉 -p 手动指定，但又希望服务对 macOS/Windows 主机可访问，host 模式反而更麻烦。此时应优先考虑：
- 用默认 bridge 网络 +
-p 80:80：Docker Desktop 会自动将 bridge 容器端口转发到 macOS/Windows 主机，无需额外配置 - 用
docker-compose.yml统一管理多端口：ports: ["5001:5001", "8000:8000"]，比反复敲-p更可靠 - 若需绑定 80/443 且用 bridge，可在 Docker Desktop 设置里开启「Use the WSL2 based engine」并确保 WSL2 分发版已配置
net.ipv4.ip_forward=1（Linux 侧），再配合-p 80:80
容易被忽略的关键点
host 模式下，容器与宿主机共用 /etc/hosts、/proc/sys/net、防火墙状态等。这意味着：
- 容器内
ping或ss -tln看到的是宿主机视角的连接，不是隔离视图 - 若宿主机有
ufw或firewalld，它会直接影响容器服务的可达性 - 多个 host 模式容器不能同时监听同一个端口（比如两个 nginx 都想 bind
:80），会触发address already in use
