nginx worker进程频繁重启通常由内存泄漏引发，需通过top观察%mem持续上升、dmesg确认“killed process nginx”、注释第三方模块定位问题源，并结合debug日志与valgrind验证。
nginx worker 进程频繁重启，通常不是配置没生效或服务卡顿这类小问题，而是系统在发出严重警告——某个环节正持续失控。最常见、也最危险的根源是内存泄漏，它会让 worker 进程越跑越“胖”，直到被系统强制杀死，然后自动拉起新进程，形成高频重启循环。
确认是否真存在内存泄漏
不能只看“重启了”，得看“为什么重启”。打开终端，运行：
-
top → 按 Shift + M 按内存排序，盯住 nginx worker 进程（通常是多个，如
nginx: worker process），观察它们的%MEM列是否随时间持续上升、不回落； - free -h 和 cat /proc/meminfo | grep -i "oom\|commit"，辅助判断整机内存压力；
-
dmesg | grep -i "killed process" | grep nginx，若输出类似
out of memory: Killed process 12345 (nginx)，基本坐实是 OOM 导致的强制终止。
快速定位泄漏源头
别急着重装或升级，先缩小范围：
-
临时关闭所有第三方模块：编辑
/etc/nginx/nginx.conf，把所有load_module行注释掉，再nginx -t && systemctl reload nginx，观察重启频率是否下降； -
检查 Lua 脚本（如有）：Nginx + OpenResty 环境下，未正确
ngx.ctx清理、全局 table 持久化、C API 调用后未释放资源，都极易引发泄漏； -
翻 error.log 的 debug 日志：把
error_log /var/log/nginx/error.log debug;加入配置，重启后复现流量，日志里会暴露模块加载、内存分配、连接异常等底层行为，重点搜malloc、free、lua_相关关键词。
验证与缓解措施
定位到可疑模块或脚本后，不要直接上线修复，先做隔离验证：
- 用
valgrind --leak-check=full --log-file=/tmp/valgrind.log nginx -g "daemon off;"在测试环境模拟启动（注意：仅限非生产环境，性能损耗极大）； - 若确认是某版本 nginx 自身 bug（如某些 1.21.x 中的 stream 模块泄漏），可降级到已知稳定的 LTS 版本（如 1.20.2）；
- 短期缓解可用 systemd 设置自动重启保护：
Restart=on-failure+RestartSec=5，但这是兜底手段，不是解决方案。
高频重启本质是系统在自救。盯住内存曲线、关掉可疑模块、查清 error.log 里的 debug 线索，三步做完，90% 的泄漏问题就能浮出水面。真正难的不是修，是别让它发生——上线前做压测、禁用未经验证的模块、Lua 脚本必做资源释放审计。
