必须同时配置worker_rlimit_core、systemd LimitCORE、ulimit -c unlimited、core_pattern路径及working_directory权限，且Nginx需启用--with-debug编译选项，否则无法生成可用core文件用于gdb调试。
要让 Nginx 在 worker 进程因内存越界（如堆溢出、栈溢出、use-after-free）崩溃时生成可用的 core 文件，worker_rlimit_core 只是起点，不是全部。它本身不捕获崩溃原因，而是为系统生成 core 文件“开一道门”——这道门能否真正打开，取决于编译支持、系统限制、路径权限和内核行为四者闭环配合。
确保 Nginx 带调试符号编译
没有调试符号的 core 文件对 gdb 几乎无用：函数名显示为 ??，行号丢失，无法定位越界访问点。
- 运行
nginx -V 2>&1 | grep -o with-debug，有输出才表示已启用 --with-debug - 若无，需重新编译：在
./configure中加入--with-debug，再执行make && make install - 生产环境可保留 debug 版本二进制，排查时临时切换，无需长期开启 debug 日志
正确配置 worker_rlimit_core 和 working_directory
该指令必须放在 nginx.conf 最外层（main 上下文），且严格位于 events 块之前，否则启动失败或静默忽略。
- 示例写法（nginx.conf 顶部）：
worker_rlimit_core 2G;<br>working_directory /var/tmp/nginx-core;
-
working_directory不是可选项，而是关键保障：它指定 core 文件实际落盘路径，避免被 systemd 拦截或写入 tmpfs/NFS - 确保该目录存在、属主为 Nginx 启动用户（如 nginx 或 www-data）、权限为 755、挂载在本地物理磁盘上
- 预留空间建议 ≥ 5× 设置值（如设 2G，目录至少留 10G 空闲）
打通系统级 Core Dump 全链路
Linux 内核是否允许生成 core、写到哪、能多大，不由 Nginx 单方面决定。
- 检查当前限制：
ulimit -c，若为 0 则禁止；临时启用：ulimit -c unlimited - systemd 用户：在
/etc/systemd/system/nginx.service.d/override.conf中添加[Service]<br>LimitCORE=infinity
，然后systemctl daemon-reload && systemctl restart nginx - 设置内核 core pattern：
echo '/var/tmp/nginx-core/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern
并写入/etc/sysctl.conf永久生效 - 若
cat /proc/sys/kernel/core_pattern显示以|/usr/lib/systemd/systemd-coredump开头，说明 core 被 systemd 拦截，Nginx 的working_directory将失效，必须改回上述路径模式
验证配置是否真正落地
光写配置不等于生效，必须逐层确认：
- 查一个 worker 进程 PID：
ps -eo pid,comm | grep 'nginx:' | head -1 - 运行
cat /proc/PID/limits | grep core，确认Max core file size的 soft limit 已生效（如 2147483648 表示 2G） - 触发一次测试崩溃（例如用
kill -SEGV $PID），检查/var/tmp/nginx-core/下是否生成文件名含core.nginx的文件 - 用
file core.*确认是 ELF 格式，再用gdb $(which nginx) core.*查看 backtrace 是否含完整函数名与源码行号
