结论：--network=host模式下容器完全复用宿主机网络命名空间，无任何网络隔离；所谓“host-network-false”非docker合法参数，真实现隔离须改用bridge、none或自定义隔离网络。
host 网络模式下根本不存在“隔离”这回事
直接说结论：--network=host 模式下，容器**完全复用宿主机的网络命名空间**，没有隔离可言。所谓 “Host-Network-False” 并非 Docker 的合法参数或配置项，Docker CLI、daemon 配置或 dockerd.json 中均无该字段。试图在启动命令或配置里写 --host-network-false 或类似变体，只会报错 unknown flag 或被静默忽略。
想隔离容器与宿主机？别用 host，改用 bridge 或 none
真正实现容器与宿主机网络隔离的方式，是**避开 --network=host**，转而使用默认或自定义的 bridge 网络，或更彻底的 none 模式：
-
bridge（默认）：容器拥有独立的网络命名空间 +veth虚拟网卡 +docker0网桥，端口不自动暴露，需显式-p映射；宿主机上netstat -tlnp看不到容器监听的端口（除非映射了） -
none：容器只有lo回环接口，无 IP、无路由、无 DNS，彻底断网；适合离线计算类任务 - 自定义
bridge网络 +--network-isolate（Docker 27+）：在用户定义网络中启用 ARP/ICMP 屏蔽，进一步阻断隐式发现行为
为什么有人误以为存在 “Host-Network-False”？
常见混淆来源有三类：
- 把 Kubernetes 的
hostNetwork: falseYAML 字段直接套用到 Docker CLI —— 两者配置体系不兼容 - 看到旧版文档中
--net=host的反向写法（如--net=bridge），误推导出--host-network=false - 在
dockerd.json中搜索不存在的键名，比如误配"host-network": false，该字段不会生效，且 daemon 启动时不会报错，极易埋下隐患
验证是否真隔离：看网络命名空间 inode
最可靠的方式不是查参数，而是比对内核对象：
先获取容器 PID：docker inspect -f '{{.State.Pid}}' my-container
再对比命名空间 inode：ls -li /proc/$(PID)/ns/net 和 ls -li /proc/1/ns/net
若两个 inode 编号相同 → 容器和宿主机共享网络栈（即用了 host 模式）；若不同 → 已隔离（bridge 或 none 成效已落地）
这个检查步骤常被跳过，但恰恰是判断隔离是否生效的唯一硬指标——参数写得再“像隔离”，inode 不同才是真隔离。
