host模式本质是跳过network namespace隔离，容器直接复用宿主机网络栈，共享ip、端口及协议栈，不分配独立ip、不走nat、不依赖端口映射；启用方式为--network=host，但牺牲网络隔离性。
docker 的 host 网络模式 本质上是不启用网络命名空间隔离，而是让容器直接复用宿主机的网络栈。它不是“结合”隔离，而是主动绕过 network namespace 隔离机制——这是关键前提。
host 模式下 Network Namespace 被跳过
普通容器启动时，Docker 默认调用 clone(CLONE_NEWNET) 创建独立 network namespace，从而获得隔离的网卡、路由表、端口空间等。而 host 模式通过 --network=host 参数，告诉 Docker Daemon 不传入 CLONE_NEWNET 标志。结果是：
- 容器进程与宿主机共享同一个 /proc/sys/net/ 目录和内核网络协议栈
- 容器内
ip addr show显示的是宿主机所有真实网卡（如 eth0、lo） - 容器绑定端口（如 :80）直接占用宿主机端口，无需 -p 映射
- iptables 规则、conntrack 表、路由表完全共用，无额外虚拟设备（如 veth pair 或 docker0 网桥）
其他命名空间仍默认启用
即使使用 host 网络，Docker 仍会为容器创建其余 5 类命名空间（PID、UTS、IPC、Mount、User），以维持基本隔离性：
- PID Namespace：容器内 PID 1 是自己的 init 进程，看不到宿主机其他进程（除非显式禁用）
-
UTS Namespace：可独立设置 hostname（
--hostname仍生效） -
Mount Namespace：文件系统挂载点独立，容器内
mount不影响宿主机 - IPC Namespace：消息队列、共享内存等 IPC 资源彼此隔离
-
User Namespace：若启用（
--userns-mode），UID/GID 仍做映射，保障权限安全
为什么选择 host 模式？适用场景与风险
它牺牲网络隔离换取性能与便利，适合对网络延迟敏感或需直接操作宿主机网络设施的场景：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 运行监控代理（如 Prometheus Node Exporter），需采集真实网卡指标
- 部署 SDN 控制平面组件（如 Calico Felix），必须直通物理网络接口
- 调试宿主机网络问题，需要容器内执行
tcpdump -i eth0
但要注意：容器内任意进程都能修改宿主机 iptables、绑定任意端口、监听所有本地地址（0.0.0.0），相当于获得宿主机网络层面的等效 root 权限。生产环境慎用，尤其不可用于多租户或不可信镜像。
验证方式：一眼识别是否真 host
进入容器后执行以下命令，可快速确认是否真正复用宿主机网络：
-
ls -l /proc/1/ns/net→ 输出应与宿主机一致：/proc/1/ns/net -> net:[4026531956]（数字相同） -
cat /proc/self/ns/net | md5sum和宿主机上执行结果比对，hash 值必须完全一致 -
ip link | grep -q "veth" || echo "no veth found"→ host 模式下不应出现 veth 设备
