worker_rlimit_core 必须置于 nginx.conf 全局块、events 前，配合系统 ulimit、systemd LimitCORE、working_directory 权限与路径配置及 /proc//limits 验证，才能确保 core 文件正确生成并用于 GDB 定位崩溃点。
worker_rlimit_core 是 Nginx 主配置中用于控制 worker 进程 core dump 大小上限的关键指令，但它只在全局块（main context）生效——放错位置会直接启动失败。线上环境启用它不是“开个开关”那么简单，需要系统层、Nginx 配置、路径权限、验证闭环四步协同，否则生成的 core 文件要么压根不落地，要么无法定位到真正崩溃点。
必须写对位置：仅限全局块，且要在 events 之前
该指令只能出现在 nginx.conf 最顶层，即 user、pid、events 等指令所在的作用域。常见错误是把它塞进 http 或 server 块里，Nginx 启动时会明确报错：
正确写法示例：
worker_rlimit_core 2G;-
working_directory /var/tmp/nginx/coredumps;（推荐搭配使用，指定 core 文件写入目录） - 这两行必须放在
events { ... }块之前
系统级限制必须同步放开
Nginx 的设置只是进程级软限制，最终能否生成 core，取决于系统 ulimit 和内核 core_pattern：
- 运行 Nginx 前，确保 shell 中执行过
ulimit -c unlimited（临时）或在/etc/security/limits.conf中添加* soft core unlimited（永久） - 检查
/proc/sys/kernel/core_pattern内容。若为|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h这类管道形式，core 会被 systemd 拦截，Nginx 的working_directory将失效 - 若用 systemd 管理 Nginx（如 CentOS/RHEL 默认），还需在
/usr/lib/systemd/system/nginx.service或/etc/systemd/system/nginx.service.d/override.conf中加入：LimitCORE=infinity或LimitCORE=2G，然后执行systemctl daemon-reload && systemctl restart nginx
路径与权限：让 core 文件真正落盘
working_directory 指定的目录不是可选项，而是稳定落地的核心保障：
- 路径需为本地磁盘（避免 NFS 或 tmpfs），且剩余空间充足（建议预留 ≥5× 最大 core 限制）
- 该目录必须对 Nginx worker 用户（如
www-data或nginx）有读、写、执行权限：chown nginx:nginx /var/tmp/nginx/coredumpschmod 755 /var/tmp/nginx/coredumps - 不设
working_directory时，core 默认生成在 master 进程启动时的工作目录，线上环境极易因权限或路径不可控导致写入失败
验证是否真正生效
重启 Nginx 后，不能只看配置有没有报错，要查进程实际限制：
- 找一个正在运行的 worker 进程 PID：
ps aux | grep 'nginx: worker' - 查看其 core size 限制：
cat /proc//limits | grep "Max core file size" - 预期输出应为类似：
Max core file size 2147483648 2147483648 bytes（即 2G） - 若显示
0，说明被系统 ulimit 覆盖，或 systemd 未正确加载 LimitCORE
后续分析：用 GDB 定位崩溃点
拿到 core 文件后，分析流程简洁但关键：
- 确保你有带调试符号的 Nginx 可执行文件（生产环境建议保留
nginx-debug或编译时加--with-debug） - 执行：
gdb /path/to/nginx-binary /var/tmp/nginx/coredumps/core.12345 - 进入 GDB 后立即输入：
bt full查看完整调用栈和局部变量 - 重点关注栈顶（#0）的函数名、源码行号（如有符号）、寄存器状态（
info registers），这通常就是崩溃触发点
