dockerfile 不适合设置 sysctl 参数，因为构建阶段的 run 指令在无网络命名空间的临时容器中执行，修改不会保留到运行时；必须改用 docker run --sysctl 或 docker-compose.yml 中的 sysctls 字段在启动时注入。
在 Dockerfile 中直接修改内核参数（如用 RUN sysctl -w）看似可行，但实际无效且不推荐。因为容器启动时内核命名空间尚未建立，此时执行的 sysctl 仅作用于构建阶段的临时容器，不会保留到运行时；更重要的是，多数网络参数（如 net.core.somaxconn）必须在容器初始化网络命名空间后、进程启动前注入，Dockerfile 无法满足这一时机要求。
为什么 Dockerfile 不适合设 sysctl 参数
Docker 构建过程是静态镜像制作阶段，所有 RUN 指令都在 build container 中执行，该环境没有真正的网络命名空间，也不具备运行时的内核参数 namespace 上下文。即使命令成功返回，写入的值也不会出现在最终容器的 /proc/sys/ 下。官方明确限制：只有启动时通过 --sysctl 或 sysctls 字段传入的参数，才会被 Docker 守护进程校验并安全注入目标命名空间。
正确做法：用启动时参数替代 Dockerfile 修改
应将内核参数配置从构建阶段移到运行阶段，这是 Docker 设计的原生支持方式：
-
命令行启动：直接使用
--sysctl多次指定，例如：docker run --sysctl net.core.somaxconn=65535 --sysctl net.ipv4.tcp_tw_reuse=1 -d nginx -
Compose 部署：在
docker-compose.yml中声明sysctls字段，值必须为字符串：services: app: image: nginx sysctls: net.core.somaxconn: "65535" net.ipv4.tcp_tw_reuse: "1" -
只设 namespaced 参数：确保参数属于
net.*、fs.mqueue.*或kernel.shm*等已隔离类别；像vm.max_map_count这类全局参数，Docker 会拒绝设置，必须改宿主机。
配套必须同步调整的资源限制
光调 sysctl 不够，TCP 连接能力还受两个硬性资源制约，需一并处理：
-
文件描述符上限：用
--ulimit nofile=65536:65536或 Compose 的ulimits字段提升单进程 fd 数，否则连接数很快触顶 -
conntrack 表容量：若用 bridge 网络，宿主机需执行
sudo sysctl -w net.netfilter.nf_conntrack_max=1048576并写入/etc/sysctl.conf持久化 -
验证是否生效：进入容器后运行
cat /proc/sys/net/core/somaxconn和ulimit -n，输出应与设定一致
例外情况：极少数可写入镜像的参数
仅当参数本身不依赖命名空间、且应用启动前需预置时，才可在 Dockerfile 中谨慎使用：
-
fs.file-max或kernel.pid_max等全局参数——但它们影响的是整个宿主机，Dockerfile 中执行等同于在宿主机上运行，不可控且不安全，不建议 -
net.ipv4.ip_forward=1这类常驻配置——仅对 host 网络模式有意义，且仍推荐由运维统一管理宿主机 sysctl，而非分散在镜像中 - 真正安全的做法是：把参数设为文档说明或启动脚本检查项，在容器 entrypoint 中做
sysctl -n校验并报错提示，而不是强行写入
