后端崩溃最典型导致Nginx返回502 Bad Gateway或504 Gateway Timeout；需先通过systemctl status、journalctl和dmesg确认服务是否已死及崩溃原因（如OOM、异常退出或启动失败），再结合Nginx error.log中“upstream prematurely closed connection”等线索验证，并启用健康检查与自动重启机制。
后端崩溃会直接导致 Nginx 返回特定状态码，最典型的是 502 Bad Gateway 和 504 Gateway Timeout，有时也会伴随大量 499（客户端因等待过久主动断开）或异常 500。排查关键不是看 Nginx 配置有没有错，而是确认“上游是否真的挂了”，并定位崩溃原因。
先锁定是后端崩溃，不是配置或网络问题
502/504 大量出现时，要快速排除干扰项：
- 执行
systemctl status your-backend.service，若显示inactive (dead)或failed，基本可判定服务已退出 - 用
journalctl -u your-backend.service -n 30查最后日志——重点找Segmentation fault、Killed by signal、exit code=137（即被 OOM Killer 杀掉）、或无任何日志直接中断（说明进程被强制终止） - 运行
dmesg -T | grep -i "killed process"，若输出含后端进程名（如java、node、gunicorn）和内存信息，就是 OOM 导致的崩溃 - 检查 Nginx error.log 中同一时间点的报错：若集中出现
upstream prematurely closed connection（502）或upstream timed out（504），且没有Connection refused，说明连接能建上但响应失败或超时，符合后端崩溃特征
区分崩溃类型：OOM、异常退出、启动失败
不同崩溃原因对应不同日志线索和修复路径：
-
OOM 崩溃：dmesg 显示
Killed process XXX (python3) total-vm:... anon-rss:...；应用日志戛然而止；ps aux --sort=-%mem可见该进程 RSS 接近内存上限 -
异常退出：journalctl 中有 panic、unhandled exception、core dumped 等关键词；Java 应用可能有
OutOfMemoryError: Java heap space；Node.js 可能报FATAL ERROR: Ineffective mark-compacts -
启动失败：systemctl status 显示
activating (start)后迅速转为failed；journalctl 显示端口占用、配置加载失败、依赖库缺失等初始化错误
验证 Nginx 是否感知到后端不可用
Nginx 本身不会“发现”后端崩溃，它只在每次请求时尝试连接或发包。因此需确认其健康反馈机制是否启用：
- 检查 upstream 块中是否配置了
max_fails=1 fail_timeout=10s—— 若没配，Nginx 会在每次请求都重试已死的后端，加剧 502 - 用
curl -I http://127.0.0.1:后端端口直连测试，若返回Connection refused，说明进程确实没监听；若超时或无响应，可能是进程僵死未退出 - 查看
ss -tn state established '( dport = :后端端口 )'，如果连接数为 0 且服务应处于监听状态，大概率进程已退出
临时恢复与根因加固方向
应急恢复要快，但不能只重启了事：
- 立即执行
systemctl restart your-backend.service拉起服务，并观察是否稳定；若反复崩溃，说明存在根本问题 - 在 systemd service 文件中添加
Restart=always和RestartSec=5，避免单次崩溃导致长时间不可用 - OOM 场景下，优先限制内存：Docker 加
--memory=1g，systemd 加MemoryMax=1G，再配合应用层堆大小控制（如 JVM 的-Xmx） - 异常退出场景下，检查应用日志中的堆栈，升级有缺陷的依赖库，或增加启动前健康检查（如 readiness probe）
