host模式跳过网络命名空间隔离，因启动时省略clone_newnet标志，使容器直接复用宿主机network namespace，共享ip、端口、路由表及iptables规则，无nat和网桥开销，但丧失隔离性。
Host 网络模式下，容器不创建独立的 Network Namespace，而是直接复用宿主机的网络栈——这意味着容器内进程调用 socket()、bind()、listen() 等系统调用时，操作的就是宿主机内核的同一套网络设施。
Host 模式如何跳过网络命名空间隔离
Docker 启动容器时若指定 --network=host（或 --net=host），底层会省略 CLONE_NEWNET 这个 clone flag。Linux 创建进程时，若未设置该标志，新进程就自动继承父进程（即 dockerd 或 containerd）所在的 Network Namespace，也就是宿主机的默认 namespace。
- 容器内看到的
/proc/sys/net/目录内容与宿主机完全一致 -
ifconfig或ip a显示的是宿主机所有网卡（如 eth0、lo、docker0），而非虚拟网卡 - 路由表、iptables 规则、conntrack 状态全部共享，修改会影响宿主机
系统调用层面的表现
当容器中运行一个监听 80 端口的 Nginx：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 执行
bind(AF_INET, {sin_port=htons(80)}, ...)时，内核直接在宿主机的协议栈中注册该端口 - 没有 NAT、没有端口映射，也不经过
docker0网桥或 veth 设备 - 若宿主机已有进程占用了 80 端口，容器启动会失败（
Address already in use）
实际使用注意事项
虽然系统调用直通宿主机，但需注意权限和行为一致性：
- 容器仍运行在自己的 Mount、PID、UTS 等 Namespace 中，仅 Network Namespace 被跳过
- 若容器以非 root 用户运行，即使 host 模式，仍受 Linux capability 限制（例如无法 bind 1024 以下端口，除非加
--cap-add=NET_BIND_SERVICE） -
localhost在容器内即指宿主机的 127.0.0.1，可直接访问宿主机上监听在127.0.0.1:3306的 MySQL
对比 bridge 模式的关键差异
bridge 模式下，每次 socket 系统调用都发生在容器专属的 Network Namespace 内，内核需做额外上下文切换和网络地址转换；host 模式绕过这些环节，调用路径更短，延迟更低，但也失去网络隔离性。
