在 Docker 容器中调整网络队列、共享内存或端口范围时，很多人会遇到“配置文件已修改，但参数没有变化”“执行 sysctl -p 提示只读文件系统”等问题。🔧 其根本原因通常不是命令写错，而是没有区分容器级参数、宿主机级参数和内核命名空间。本文整理一套可直接执行的配置与排查方法。
一、先理解 sysctl 为什么在容器里表现不同
sysctl 是 Linux 运行时内核参数管理接口，其实际数据主要位于 /proc/sys。容器共享宿主机内核，但通过网络、IPC、PID 等命名空间隔离部分资源，因此只有已经命名空间化的参数，才可能在不同容器中独立设置。
常见的容器可配置项包括部分 net.*、kernel.shm*、kernel.msg*、kernel.sem 和 fs.mqueue.* 参数。不过，具体支持范围会受到宿主机内核版本、Docker 版本及容器网络模式影响。vm.*、fs.file-max 等许多参数属于宿主机范围，通常不能通过普通容器的 sysctl 独立修改。
判断重点不是“容器里能否看到这个参数”，而是“这个参数是否已经被对应的 Linux 命名空间隔离”。能读取并不代表可以写入，也不代表修改后只影响当前容器。
二、推荐的参数配置方式
1. 使用 docker run 的 sysctl 选项
创建容器时可以直接传入参数，例如：
docker run -d --name app --sysctl net.core.somaxconn=4096 nginx
多个参数需要分别添加 sysctl 选项。Docker 会在容器初始化阶段应用配置，如果参数不受支持，启动过程通常会返回权限、无效参数或不允许设置等错误。可参考 Docker 容器运行命令文档。
2. 在 Docker Compose 中统一声明
Compose 项目应在服务的 sysctls 配置中集中维护，例如：
sysctls:
net.core.somaxconn: 4096
net.ipv4.tcp_syncookies: 1
修改 Compose 文件后，仅执行容器内的 sysctl -p 并不能替代重新创建。建议使用 docker compose up -d --force-recreate，随后进入新容器核验实际值。这样可以避免配置只存在于文件中，而旧容器仍沿用原始参数。
3. 宿主机级参数应在主机配置
如果目标参数未命名空间化，应在宿主机的 /etc/sysctl.conf 或 /etc/sysctl.d/*.conf 中配置，再执行 sysctl --system 加载。生产环境建议使用独立文件，例如 /etc/sysctl.d/99-container-tuning.conf，便于审计、回滚和自动化分发。
三、常见“不生效”现象与原因
- 提示 Read-only file system：容器中的 /proc/sys 通常受到写入限制。即使把 /etc/sysctl.conf 挂载进容器，配置文件可见也不代表内核接口可写。
- 提示 Operation not permitted：可能是参数不支持容器级设置，也可能缺少必要能力，或被 seccomp、AppArmor、SELinux 等安全策略阻止。
- 容器启动后数值仍未改变：可能检查了宿主机而非容器命名空间，或者 Compose 更新后没有重新创建容器。
- 删除并重建后配置丢失：参数可能只是在运行中的容器里临时修改，没有写入 docker run 参数、Compose 文件或宿主机持久化配置。
- 使用 host 网络时结果异常：容器与宿主机共享网络命名空间后，部分 net.* 参数不再具备独立配置条件，应重新评估影响范围。
四、按顺序执行的排查流程 🧭
- 确认参数名称：分别在宿主机和容器中执行 sysctl 参数名，排除拼写错误及参数不存在。
- 检查启动配置：使用 docker inspect 容器名，查看 HostConfig 中的 Sysctls，确认 Docker 实际接收到了哪些参数。
- 检查 Compose 展开结果：执行 docker compose config，确认缩进、变量替换和配置合并没有改变 sysctls 内容。
- 确认是否重新创建：对比容器创建时间，避免只重启旧容器。restart 通常不会把新启动参数重新写入容器配置。
- 检查网络模式：执行 docker inspect 查看 NetworkMode，重点关注 host、none 及共享其他容器网络命名空间的情况。
- 判断参数作用域：在测试环境分别读取宿主机和容器中的值。若两端同步变化，应停止继续试写，并按宿主机级参数处理。
- 查看启动错误：结合 docker events、docker inspect 和 Docker 守护进程日志，定位 runtime 创建阶段返回的错误。
五、不要把 privileged 当作通用解决方案
使用 privileged 模式可能绕过部分限制，但它会显著扩大容器权限，而且不能把未命名空间化的参数自动变成容器私有参数。⚠️ 对宿主机级参数的误修改可能影响同一节点上的全部容器，因此不应为了让 sysctl -p 成功而直接开启特权模式。
更稳妥的原则是：容器私有参数通过 Docker 的 sysctl 配置；节点级参数由宿主机统一管理；确需额外能力时采用最小权限，并配合变更记录、灰度验证和回滚方案。
总结
Docker 中的 sysctl 问题，本质上是参数作用域、命名空间和权限边界的问题。排查时应先判断参数属于容器级还是宿主机级，再检查 Docker 是否接收配置、容器是否重新创建以及当前网络模式。✅ 只要坚持“先确认作用域，再选择配置入口，最后核验实际值”的顺序，就能避免大多数配置不生效和误改宿主机参数的问题。
