host模式通过共享宿主机网络命名空间，绕过docker0网桥、nat、端口映射及veth虚拟网卡等冗余环节，实现零拷贝与低延迟通信，性能接近原生，适用于高实时性场景。
Host 网络能提升效率，核心在于绕过网络协议栈的冗余处理环节。它不走 Docker 自建的虚拟网桥（如 docker0），也不做 NAT、端口映射或包转发，而是让容器直接复用宿主机的网络命名空间——相当于把应用“搬到”宿主机上跑，只是进程隔离，网络完全透明。
Host 网络省掉的关键环节
- 不创建独立的 veth 虚拟网卡对
- 不经过
iptables或nftables的 DNAT/SNAT 规则链 - 不触发内核 netfilter 框架的多次遍历
- 不进行 IP 层与传输层之间的额外拷贝（零拷贝路径更易达成）
- 不分配私有 IP（如
172.17.x.x），避免 ARP 查询和路由查找开销
适合 Host 模式提效的典型场景
- 容器只与宿主机本地服务通信（比如日志采集器直连
localhost:9090的 Prometheus） - 高频小包交互的服务（如监控 agent 上报指标、gRPC 微服务间调用）
- 对 P99 延迟敏感的应用（实时 API 网关、高频交易中间件）
- 单节点部署且无需多实例共存（避免端口冲突即可）
实际效果参考
在千兆以上物理网卡环境下，bridge 模式常见延迟 0.3–0.8ms，host 模式可压到 0.05–0.2ms；吞吐方面，单连接 TCP 流量在 host 模式下更容易逼近宿主机网卡理论上限（例如万兆卡跑满 9.2Gbps+），而 bridge 模式常因 NAT 和桥接开销卡在 7–8Gbps 区间。
使用时要注意的硬约束
- 容器内服务必须主动绑定
0.0.0.0或127.0.0.1，不能只监听127.0.0.1:port后还指望外部访问（host 模式下127.0.0.1就是宿主机本机） - 多个容器不能同时监听同一端口（没有端口隔离，冲突即失败）
- 防火墙规则作用对象变成宿主机本身，需按宿主机视角配置
ufw或firewalld - 容器无法通过
--ip指定 IP，也不能用--network=host+--publish组合（后者被忽略）
不复杂但容易忽略。
