worker_rlimit_core 本身不用于“关闭”核心转储，而是控制每个 worker 进程可生成 core 文件的最大大小。想在高负载下“安全关闭异常内存转储”，本质是主动禁用 core dump 生成能力，而非调大或限制它。
真正安全、可控的做法是：将 worker_rlimit_core 设为 0，并同步关闭系统级 core dump 机制。否则，即使 Nginx 配置了限制，系统仍可能在崩溃时强行生成（尤其被 systemd 拦截后），反而增加磁盘 I/O、延迟甚至服务卡顿。
✅ 正确关闭 core dump 的三步闭环
1. Nginx 层：显式禁止 core 生成
在 nginx.conf 最外层（events 块之前、http 块之外）添加：
worker_rlimit_core 0;
⚠️ 注意：不能写在 http/server/location 内，否则启动失败；设为 0 表示明确禁止，比 unlimited 或 100M 更彻底。
2. 系统层：关闭 ulimit 和 systemd 限制
- 临时禁用（当前会话）：
ulimit -c 0
- 永久禁用（推荐）：
编辑/etc/security/limits.conf，添加（用户名按实际替换，如nginx）：nginx soft core 0 nginx hard core 0
- 若用 systemd 启动（主流），还需创建
/etc/systemd/system/nginx.service.d/override.conf：[Service] LimitCORE=0
然后执行：
systemctl daemon-reload && systemctl restart nginx
3. 内核层：重置 core_pattern，防止 systemd 拦截绕过
检查当前策略：
cat /proc/sys/kernel/core_pattern
若输出含 |/usr/lib/systemd/systemd-coredump，说明 core 被 systemd 拦截——此时 worker_rlimit_core 0 可能失效。
安全做法是清空它，改回无操作模式：
echo "core" | sudo tee /proc/sys/kernel/core_pattern # 或更彻底地禁用（需 root）： echo "" | sudo tee /proc/sys/kernel/core_pattern
? 提示：空值或纯文件名（不含
|）表示直接落盘；含|表示交由程序处理，此时 Nginx 的限制完全不生效。
❌ 常见误区（高负载下尤其危险）
-
只设
worker_rlimit_core 100M却不关系统限制 → 崩溃时仍可能生成大文件，挤占磁盘、触发 I/O stall -
依赖
working_directory但没关core_pattern→ systemd 会无视该路径，把 core 写进/var/lib/systemd/coredump/，且默认压缩，消耗 CPU -
重启 Nginx 但没 reload systemd 或验证
/proc/PID/limits→ 实际进程仍继承旧的ulimit -c，限制未落地
验证是否真正关闭：
# 查一个 worker 进程 PID pid=$(pgrep -f "nginx: worker" | head -1) # 检查 core limit 是否为 0 cat /proc/$pid/limits 2>/dev/null | grep "Max core file" # 输出应类似：Max core file size 0 0 bytes
? 高负载场景下的额外建议
-
避免调试期配置残留：生产环境上线前，务必清理
working_directory相关配置（如working_directory /var/tmp/nginx/coredumps;），它仅在启用 core 时有意义，留着易引发权限或路径误解 -
监控替代方案：关闭 core 后，用
nginx -t+systemctl status nginx+journalctl -u nginx -n 50 --no-pager快速定位启动/崩溃问题，比等 core 分析更快 -
OOM 场景特别注意：Linux OOM Killer 触发时，即使
worker_rlimit_core 0，也可能强制生成 core。此时更应优化worker_processes和内存使用（如调小proxy_buffer_size），而非依赖 core 控制
不复杂但容易忽略。
