容器无法直接修改宿主机内核参数，因默认丢弃cap_sys_admin能力且不挂载/proc/sys；仅可通过--sysctl设置net.*等白名单参数，或慎用--cap-add=sys_admin（高风险）、--network=host（绝对禁止）。
容器默认无法直接修改宿主机内核参数，因为 Docker 通过 namespaces 和 cgroups 实现隔离，其中 net、pid、uts、user 等 namespace 默认是私有的，而 sysctl 参数属于内核运行时配置，受 netns/utsns 以及能力（capabilities）双重约束。
关键限制机制：默认禁止 + 显式授权
容器启动时，默认以 CAP_SYS_ADMIN 能力被丢弃，且不挂载宿主机的 /proc/sys。这意味着：
- 普通容器执行
sysctl -w net.ipv4.ip_forward=1会报错：Operation not permitted -
cat /proc/sys/net/ipv4/ip_forward只能读取当前 network namespace 的值（初始为默认值，非宿主机值） - 即使挂载了宿主机
/proc/sys（如-v /proc/sys:/proc/sys:ro），写操作仍因缺少 capability 被拒绝
若需允许修改，必须显式授权（慎用）
仅在明确需要且可信环境中才考虑放开，常见方式有：
-
启用特定 sysctl 参数（推荐）：用
--sysctl启动时一次性设置，Docker 会将其注入容器 network namespace。例如：docker run --sysctl net.ipv4.ip_forward=1 --sysctl net.core.somaxconn=65535 nginx
注意：仅支持net.*、fs.*、kernel.msg*等白名单路径，且不能覆盖只读参数 -
授予 CAP_SYS_ADMIN（高风险）：加
--cap-add=SYS_ADMIN，等效于“给容器 root 权限改内核”，可能突破 namespace 隔离，导致宿主机内核状态被污染，生产环境严禁 -
使用 host network 模式（更危险）：加
--network=host会使容器共享宿主机 network namespace，此时--sysctl无效，所有sysctl -w直接作用于宿主机，绝对禁止用于多租户或不可信镜像
验证是否真正受限
可进入容器检查：
- 运行
capsh --print | grep cap_sys_admin—— 若无输出，说明未获得该能力 - 尝试
sysctl -w kernel.shmmax=67108864—— 应返回error: permission denied on key 'kernel.shmmax' - 查看
cat /proc/1/status | grep CapEff中的有效 capability 位图，确认SYS_ADMIN位为 0
安全建议
绝大多数应用无需修改内核参数。真有需求时：
- 优先用
--sysctl设置白名单参数，启动即生效，不可运行时变更，最安全 - 避免使用
--cap-add=ALL或--privileged，它们等于放弃隔离 - Java、Nginx 等中间件的性能调优，应通过应用自身配置（如
worker_rlimit_nofile）或容器资源限制（--ulimit）实现，而非触碰/proc/sys - 宿主机级内核参数（如
vm.swappiness）必须由运维统一管理，容器不应参与
