Docker host 网络报 sysctl not allowed in host network namespace

Compose 启动 VPN 或网络服务时，容器尚未启动就报：

OCI runtime create failed: sysctl "net.ipv4.conf.all.src_valid_mark"
not allowed in host network namespace

先看该服务是否同时使用 network_mode: host 和容器级 net.* sysctl。host 模式与宿主机共享网络命名空间，运行时不能把这项设置当成只影响容器的网络参数，因此拒绝创建。

以下针对 Linux Docker 的 host 网络；对应限制按 runc v1.3.2 的网络命名空间校验规则核对。错误中的具体 sysctl 名称应保留，不要把所有 OCI 创建失败都归到这个分支。

对照生效的 host 与 sysctls 配置

用与启动时相同的文件和项目参数查看配置。例如原来使用两份文件，就保留相同顺序：

docker compose -f compose.yaml -f compose.local.yaml config

文件名是示例。输出会解析变量，可能包含敏感配置，留在受控环境中查看。检查出错服务是否含有这种组合：

network_mode: host
sysctls:
  net.ipv4.conf.all.src_valid_mark: "1"

这是冲突配置的片段，不是新的完整部署文件。确认设置来自哪一份文件；在覆盖文件里少写一项，不一定就从合并结果中删除了它。

对于已有容器，可只读查看创建时使用的参数：

docker inspect vpn-container \
  --format '{{.HostConfig.NetworkMode}} {{json .HostConfig.Sysctls}}'

换成实际名称。容器还没创建成功时，以失败命令和合并配置为准，不必为了检查强行创建一个带额外权限的容器。--privileged 也不是绕过这项命名空间校验的办法。

如果应用只是提供供远端客户端连接的服务，并不要求直接使用宿主机网络命名空间，可以评估它支持的普通容器网络方案。去掉 host 模式，使用独立网络，并按应用要求保留支持的容器级网络参数和端口发布。

切换会改变接口、路由和 localhost 的含义。VPN 还涉及客户端可达范围、转发、服务监听及防火墙，不能只删掉 network_mode 就认为整条通信链已修好。端口号和所需能力应沿用该应用版本的部署要求，不要从另一套配置盲目复制。

如果变更后遇到 host 与 ports 的另一个冲突，应另看 host 模式的端口发布规则。该问题处理端口映射，不能解释这里的 sysctl 创建失败。

确实需要 host 模式，应从容器启动配置中移除这个不允许的容器级网络参数，并由宿主机管理者确认该应用是否需要相应宿主参数、当前值是否满足要求，以及修改会影响哪些其他服务。

不能只为了让容器进入 running 就删掉参数后结束处理。应用如果依赖该网络行为，创建成功之后仍可能无法正确转发。宿主参数的变更范围可能覆盖其他接口和服务，需要保存原值、评估路由与策略，并使用既有宿主维护流程处理，不能把一条全局 sysctl 修改作为通用修复命令。

同样，不应为恢复旧配置而降级到历史 containerd 版本。旧环境偶然接受了参数组合，不会改变共享网络命名空间的边界。

改动前保存 Compose 文件、宿主网络状态和持久数据备份。在本地或隔离测试环境确认方案后，再按原项目参数应用；配置变化通常需要重建受影响服务，普通 restart 不会重写创建参数。

先核对创建错误已经消失，再检查应用所需接口、监听、路由和实际客户端连接。VPN 场景应按业务验证所需方向的通信，单向可达不能代替双向要求。

需要回退时，恢复最近可用的容器网络配置及本次获准改变的宿主参数，并重新核对其他服务。宿主参数回退和容器配置回退是两项操作；重新创建容器也不会恢复其可写层中丢失的数据。