daemon.json不能配置容器级sysctl参数，仅支持全局设置如default-ulimits；容器级sysctl必须在docker run、docker-compose或kubernetes pod中显式指定，否则无效。
daemon.json 不能直接配置容器级的 sysctl 参数。这是关键前提。
Docker 守护进程的 daemon.json 用于全局控制 Docker 行为（如镜像源、日志、网络网段、默认 ulimit 等），但它不支持在其中设置容器启动时要注入的 --sysctl 值。那些可 namespaced 的网络参数（如 net.core.somaxconn、net.ipv4.tcp_tw_reuse、net.ipv4.conf.lo.rp_filter）必须在容器启动阶段显式指定，而非通过 daemon 全局配置。
不过，daemon.json 可以配合 sysctl 调优做两件重要事：
✅ 1. 预设默认 ulimit（与 sysctl 协同生效）
TCP 连接数受 sysctl 和文件描述符双重限制。你可以在 daemon.json 中统一设定容器默认 nofile 上限：
{
"default-ulimits": {
"nofile": {
"Name": "nofile",
"Hard": 65536,
"Soft": 65536
}
}
}
重启生效：
sudo systemctl restart docker
⚠️ 注意：这仅影响
ulimit -n，不影响/proc/sys/下的内核参数。
✅ 2. 避免冲突性全局配置（间接保障 sysctl 生效）
某些 daemon 级设置会干扰容器 --sysctl 的行为，需规避：
-
network-mode: host下--sysctl完全失效（因共享宿主机网络命名空间） -
privileged: true不必要开启——它绕过 namespace 隔离，反而让--sysctl失去意义且不安全 - 不要在
daemon.json中写default-sysctls（Docker 不支持该字段，属常见误传）
❌ 为什么不能在 daemon.json 里配 sysctl？
- Docker 源码明确限定：
--sysctl是 per-container 启动参数，由containerd在创建容器时注入到spec.linux.sysctl，而daemon.json不解析或透传该字段。 - 所有尝试添加
"sysctls": {...}或"default-sysctls"到daemon.json的写法均无效且可能引发 JSON 解析失败，导致dockerd启动异常。
✅ 正确做法：按场景选对位置
| 场景 | 推荐方式 | 示例 |
|---|---|---|
| 单次调试/测试 | docker run --sysctl |
docker run --sysctl net.ipv4.conf.lo.rp_filter=0 -d nginx |
| 编排部署（推荐） |
docker-compose.yml 的 sysctls 字段 |
sysctls:<br> net.core.somaxconn: "65535"<br> net.ipv4.tcp_tw_reuse: "1" |
| Kubernetes | Pod securityContext.sysctls
|
sysctls:<br>- name: net.ipv4.conf.lo.rp_filter<br> value: "0" |
所有这些方式都作用于容器命名空间，安全、隔离、立即生效。
? 验证是否成功
进容器后执行：
cat /proc/sys/net/core/somaxconn # 应等于你设的值 cat /proc/sys/net/ipv4/conf/lo/rp_filter # 应为 0 ulimit -n # 应为 65536
不复杂但容易忽略：sysctl 是容器维度的事，daemon.json 是守护进程维度的事——各司其职，混用就会失效。
