502 错误中由内存溢出（OOM）引发的后端崩溃，特点是上游服务进程突然消失、日志里出现“killed by OOM killer”或“Out of memory”，但 Nginx 本身运行正常。这类问题不会在 Nginx 配置里留下明显痕迹，必须从系统层反向追踪——因为不是 Nginx 拒绝响应，而是它想转发请求时，上游已经没了。
看上游服务是否被系统强制杀死
内存耗尽时，Linux 内核的 OOM Killer 会主动干掉占用内存最多的进程。先确认后端服务（如 Python/Java/Node.js 进程）是否曾被杀：
- 执行 dmesg -T | grep -i "killed process"，查找类似 "Killed process 12345 (python3) total-vm:8567892kB, anon-rss:7245678kB, file-rss:0kB" 的记录
- 检查上游服务日志末尾是否有异常退出、无堆栈、无 graceful shutdown 提示（比如 FastAPI 停在中间没打印 "Shutting down"）
- 用 systemctl status your-app.service 查状态，若显示 failed 且 Active: inactive (dead)，再结合 journalctl -u your-app.service -n 50 看最后几行是否含 OOM 或 segmentation fault
查进程实际内存使用与限制
很多崩溃发生在容器或 systemd 服务设置了内存上限但未暴露告警：
- 如果是 Docker 容器，运行 docker inspect <container> | grep -A 5 Memory，确认是否设置了
memory或memory-swap限制 - 如果是 systemd 服务，检查 /etc/systemd/system/your-app.service 中是否有
MemoryLimit=、MemoryMax=或LimitMEMLOCK=等配置 - 直接观察实时内存：用 top -b -n1 | grep -E "(PID|your-app-name)" 或 ps aux --sort=-%mem | head -10 看 RSS 是否逼近系统总内存
验证 Nginx 日志中的线索是否匹配 OOM 特征
Nginx error.log 不会直接写“OOM”，但会留下典型行为痕迹：
- 出现 "upstream prematurely closed connection while reading response header" —— 表明上游进程在发响应前就退出了，符合 OOM 杀进程后 socket 突然断开的特征
- 同一时间点大量 502 报错，且错误日志中 没有 “Connection refused” 或 “Connection timed out”，说明连接能建上，只是读响应时失败
- 配合 tail -f /var/log/nginx/error.log 和 dmesg -T -w 同时观察：如果 Nginx 报错瞬间 dmesg 打印出 killed process，基本可锁定
临时缓解与长期加固建议
OOM 导致的 502 是资源瓶颈问题，不能靠调 Nginx 参数解决，重点在上游可控性：
- 给上游服务加健康检查和自动重启：例如 systemd 中设置
Restart=always、RestartSec=5，避免挂了没人拉起 - 限制单次请求内存消耗：Python 服务加
resource.setrlimit(resource.RLIMIT_AS, (max_bytes, -1))；Java 加-Xmx2g -XX:+UseG1GC显式控堆 - Nginx 层做轻量兜底：在 location 块中加
proxy_next_upstream error timeout http_502;（如有多个上游），避免单点崩溃全量失败
