直接限制Nginx进程生成core dump是防止敏感内存数据泄露的关键：需在systemd service中设LimitCORE=0，禁用ulimit宽松配置，配置core_pattern至安全路径，运行时调用prctl(PR_SET_DUMPABLE, 0)和madvise(..., MADV_DONTDUMP)，并启用systemd-coredump压缩与磁盘保护。
直接限制 Nginx 进程生成核心转储（core dump）文件，是防止密钥、令牌、密码等敏感内存数据意外泄露的关键一环。Nginx 本身不主动触发 core dump，但当 worker 进程因段错误、非法指令等崩溃时，内核会按系统策略自动生成——若未管控，可能把整个堆栈、TLS 私钥、JWT token 全写进磁盘。
关闭或严格限制 Nginx 的 core dump 能力
Nginx 默认继承系统 ulimit 设置，需在进程启动前就切断 dump 路径：
- 在 nginx.service 单元文件中添加 LimitCORE=0，彻底禁用所有 worker 进程的 core dump（推荐生产环境首选）
- 或设为小上限，如 LimitCORE=1M，避免填满磁盘又保留极简调试信息
- 确保 /etc/security/limits.conf 中 nginx 用户（如 www-data 或 nginx）无
* soft core unlimited类宽松配置 - 检查 /proc/sys/kernel/core_pattern 是否指向安全路径（如
/var/crash/%e.%p.core），且该目录权限为700、属主为 root
运行时主动屏蔽敏感内存区域
仅靠全局禁用不够，还需让 Nginx 自身拒绝 dump 关键内存段：
- 在启动脚本或 systemd service 的
ExecStartPre中加入：
echo 0 > /proc/sys/kernel/core_uses_pid（避免多进程覆盖同一文件）
echo 0 > /proc/sys/fs/suid_dumpable（禁止 setuid 进程生成 core，防提权后窃取） - 若使用自定义模块或 Lua（如 OpenResty），可在初始化阶段调用：
prctl(PR_SET_DUMPABLE, 0)，使当前 worker 进程完全不可 dump - 对 malloc 分配的敏感缓冲区（如 TLS key buffer），调用 madvise(..., MADV_DONTDUMP) 标记，glibc 2.25+ 支持
替代调试方式替代完整 core 文件
放弃依赖全内存 core dump，改用更轻量、可控的定位手段：
- 启用 systemd-coredump 并配置 /etc/systemd/coredump.conf：
设置MaxUse=100M、KeepFree=500M、Compress=yes，自动压缩 + 磁盘保护 - 开启 Nginx 内建调试日志：
error_log /var/log/nginx/error.log debug;（仅临时开启，记录信号、mmap、SSL handshake 等关键路径） - 配合 gdb -p $(pidof nginx) 实时 attach 分析，或用 bpftrace 捕获 SIGSEGV 前的寄存器与栈帧，无需落地内存镜像
配套系统级防护不遗漏
core dump 防护不是孤立配置，需与 Nginx 内存行为协同：
- 确认 worker_rlimit_core 在 nginx.conf 中未设为
unlimited，建议显式写worker_rlimit_core 0; - 禁用 ssl_session_cache shared 过大配置（如
shared:SSL:512m），避免 master 进程启动即预占数百 MB 内存，间接增加 OOM 风险 - 定期扫描
/var/crash/或 core_pattern 目录，用 file core.* 和 eu-readelf -l core | grep LOAD 快速识别是否含敏感段（如[anon:heap]或高地址映射）
