要让Nginx在systemd下稳定高效，需协同优化worker_processes与重启参数：auto设为CPU核心数，配合Restart=always、RestartSec=5、StartLimitIntervalSec=60、StartLimitBurst=3及Type=notify，并添加MemoryLimit=512M和RestartPreventExitStatus=SIGUSR1等防护机制。
要让 Nginx 在 systemd 托管下既稳定又高效，worker_processes 的设置和 systemd 重启参数 必须协同优化，不能只调一边。worker 进程数影响资源占用与并发能力，而 systemd 的重启策略决定服务崩溃后能否快速恢复、是否引发雪崩。两者搭配不当，轻则日志刷屏、频繁重启，重则压垮系统。
worker_processes 设置要点
这个值不是越大越好，也不是固定写 1 或 auto 就万事大吉：
- auto 是推荐起点：它会读取 CPU 核心数并启动对应数量的 worker 进程，适合大多数场景。四核机器就起 4 个，避免无谓上下文切换
-
高 IO 场景可微调：如果启用了
use epoll和file_aio，且主要处理大文件或静态资源，可尝试设为2 × CPU核心数，但需配合worker_connections一起压测 -
避免超配：worker 进程本身不轻量，每个默认占几 MB 内存；若设为 32（远超物理核心），反而因调度争抢降低吞吐，还可能触发 systemd 的
StartLimitBurst限频机制 -
多实例部署时必须隔离：每个 nginx 实例的
worker_processes应独立设置，并确保各自监听不同端口或使用不同用户，防止 PID 冲突或资源抢占
systemd 重启参数必须组合生效
单靠 Restart=always 容易陷入“崩溃→重启→再崩溃”的死循环。关键是要用好四个联动参数：
-
Restart=always：确保任何退出（段错误、OOM kill、主动 exit）都触发重启 -
RestartSec=5：每次重启前等 5 秒，给磁盘日志落盘、内核清理资源留出时间，避免秒级狂打 -
StartLimitIntervalSec=60与StartLimitBurst=3：1 分钟内最多启动 3 次，超限即停服并标记 failed——这是人工介入的明确信号，不是故障掩盖 -
Type=notify（强推）+nginx -g "daemon on; master_process on;"：让 systemd 真正感知 master 进程存活，而不是只盯前台命令是否退出。否则 reload 后 systemd 可能误判服务已死
资源约束与异常过滤增强稳定性
重启只是兜底，更要防住根源性崩溃：
-
MemoryLimit=512M：限制单个 nginx 实例内存上限，防止配置错误或攻击导致 OOM 波及整个系统 -
RestartPreventExitStatus=SIGUSR1 SIGUSR2：平滑重载（nginx -s reload）发的是 USR1，USR2 是升级二进制时用，这些是正常信号，不应触发重启 -
OOMScoreAdjust=-500：降低被 Linux OOM killer 优先干掉的概率，让其他更不重要的进程先扛雷 - 验证是否生效：
systemctl show nginx --property=Type,MainPID,MemoryLimit，确认 MainPID 持续更新且 MemoryLimit 显示正确数值
配置修改后务必验证闭环
改完 nginx.conf 或 nginx.service，不能只跑 systemctl daemon-reload 就完事：
- 先用
nginx -t检查语法，再systemctl restart nginx - 用
ps -ef | grep nginx看 master 进程 PPID 是否为 1，worker 数量是否符合预期 - 用
ss -lntp | grep :80确认端口仍在监听，curl -I http://127.0.0.1确保返回 200 - 手动 kill -9 主进程，观察 5 秒后是否自动拉起、
systemctl status nginx是否显示 active (running)
