“Host-Network-False”不是Docker合法参数，无法实现网络隔离；真正有效的隔离方式是使用bridge（默认）、none或自定义bridge网络，并通过对比/proc/PID/ns/net与/proc/1/ns/net的inode号验证是否真实隔离。

“Host-Network-False”不是 Docker 的有效参数，也无法实现网络隔离。
它既不是 Docker CLI 支持的选项，也不在 dockerd 配置（如 daemon.json）中存在。任何尝试使用 --host-network=false、--net=false 或类似写法，都会导致命令报错（如 unknown flag）或被静默忽略。

真正决定容器是否与宿主机共享网络命名空间的，只有明确指定的 网络模式：

Dolphindb Docker

自动化 DolphinDB Docker 部署，支持自动架构检测（ARM64/x86_64），智能内存分配（50% 规则）以及完整数据持久化。

下载

用对网络模式才能实现隔离

- bridge（默认）：容器拥有独立 network namespace，通过 `veth` + `docker0` 网桥通信，端口不自动暴露，需 `-p` 显式映射。这是最常用且具备良好隔离性的方案。 - none：容器仅保留 `lo` 回环接口，无 IP、无路由、无 DNS，彻底断网，适合离线计算或高安全沙箱场景。 - 自定义 bridge 网络：比默认 `bridge` 更可控，支持 `--internal`（禁外部访问）、`--subnet`（定制网段）、Docker 27+ 的 `--network-isolate`（屏蔽 ARP/ICMP 发现），进一步收紧横向通信面。

别被 Kubernetes 配置误导

Kubernetes YAML 中的 `hostNetwork: false` 是 K8s 层的声明，由 kubelet 转译为对应容器运行时行为（如调用 `--network=bridge`）。它不能直接用于 Docker CLI。混用两者是常见误配源头。

验证隔离是否真实生效

光看启动参数不够可靠，必须检查内核对象： - 获取容器 PID：`docker inspect -f '{{.State.Pid}}' ` - 对比网络命名空间 inode：`ls -li /proc//ns/net` 和 `ls -li /proc/1/ns/net` → 若两个 inode 编号不同，说明已隔离；相同则仍是 host 模式，无论参数怎么“写得像隔离”。

为什么 host 模式无法隔离

`--network=host` 下，容器进程直接运行在宿主机 network namespace 中，共用所有网络设备、端口、iptables 规则和路由表。此时容器等同于宿主机上的普通进程，监听 `0.0.0.0:8080` 就等于宿主机在监听——不存在“隔离”这回事。性能提升是以放弃网络边界为代价的。

不复杂但容易忽略。