worker_rlimit_core 是 Nginx 主进程控制 worker 进程 core dump 大小上限的关键指令，必须置于 main 上下文、events 前，配合 working_directory 和系统级 ulimit、systemd、core_pattern 三重配置方可生效。
worker_rlimit_core 是 Nginx 主进程中用于控制 worker 进程生成 core dump 文件大小上限的关键安全调试指令。它本身不提升运行时安全性，但在发生崩溃（如因内存破坏、use-after-free 或栈溢出等漏洞触发）时，是获取可复现、可分析崩溃现场的**唯一可靠入口**。配置不当会导致 core 文件根本无法生成，或生成后路径错乱、权限拒绝、被系统拦截，最终让安全分析失去依据。
必须放在全局块，且在 events 前
该指令仅在 nginx.conf 的 main 上下文（即最外层）生效。任何嵌套在 http、server、location 或 events 块中的写法都会导致 Nginx 启动失败，并报错：
“worker_rlimit_core” directive is not allowed here正确位置示例：
user nginx;
pid /run/nginx.pid;
worker_rlimit_core 2G; # ← 此处有效
working_directory /var/tmp/nginx/coredumps; # ← 推荐紧随其后
events {
worker_connections 1024;
}
注意：worker_rlimit_core 和 working_directory 必须成对出现在 events 块之前；单独设置前者而忽略后者，core 很可能写入到不可控路径（如 /），造成权限失败或磁盘填满。
同步解除系统级限制
Nginx 的设置只是进程软限制，实际能否落地取决于操作系统层面三重关卡：
- shell 启动限制：若用 systemctl start nginx，需确保 systemd service 文件中已配置 LimitCORE；若手动启动（如 sudo -u nginx nginx），则启动前需执行 ulimit -c unlimited
-
systemd 服务限制：编辑 /etc/systemd/system/nginx.service.d/override.conf，加入：
[Service] LimitCORE=infinity
然后运行 systemctl daemon-reload && systemctl restart nginx -
内核 core_pattern：检查 /proc/sys/kernel/core_pattern。若内容为 |/usr/lib/systemd/systemd-coredump %P...，说明所有 core 被 systemd 拦截，Nginx 的 working_directory 完全失效。应改为直接写磁盘路径，例如：
echo "/var/tmp/nginx/coredumps/core.%e.%p.%t" | sudo tee /proc/sys/kernel/core_pattern
（需配合 sysctl kernel.core_pattern=... 永久生效）
路径与权限必须可控
working_directory 指定的目录不是“建议”，而是生产环境 crash 分析的**可信锚点**：
- 路径必须是本地物理磁盘（禁用 NFS、tmpfs、/dev/shm）
- 剩余空间 ≥ 3× 配置的 worker_rlimit_core 值（例如设为 2G，则预留至少 6G）
- 目录归属必须为 Nginx worker 用户（如 nginx:nginx），且具备 rwx 权限：
sudo mkdir -p /var/tmp/nginx/coredumps sudo chown nginx:nginx /var/tmp/nginx/coredumps sudo chmod 755 /var/tmp/nginx/coredumps
- 禁止使用带变量扩展的路径（如 %p、%e），避免因解析失败导致 core 写入失败或覆盖其他文件
验证是否真正生效
重启 Nginx 后，不能只看配置语法是否通过（nginx -t），必须验证运行时限制是否真实加载：
- 查一个 worker 进程 PID：ps aux | grep 'nginx: worker'
- 读取其 limits：cat /proc/12345/limits | grep "Max core file size"
- 正常输出应类似：Max core file size 2147483648 2147483648 bytes（即 2G）
- 若显示 0，说明被系统 ulimit 覆盖、systemd 未生效、或 core_pattern 重定向导致限制被绕过
确认生效后，可手动触发一次崩溃测试（如 kill -SEGV `cat /run/nginx.pid`），观察 /var/tmp/nginx/coredumps 下是否生成 core.* 文件，并用 gdb 验证可加载分析。
