后端服务未启动是502最直接常见原因：Nginx运行正常但上游无监听，日志报“Connection refused”；需用systemctl status、docker ps、telnet及ss/netstat验证进程与端口真实状态，并排查启动失败隐因。
后端服务没启动，是 502 最直接、最常见也最容易被忽略的原因。Nginx 本身运行正常，但转发请求时发现上游压根没人监听，就会立刻返回 502 Bad Gateway，日志里通常写着 connect() failed (111: Connection refused)。
确认后端服务是否真的在运行
别只看进程名，要验证真实状态：
- 用
systemctl status your-app.service查服务状态，重点看 Active: 后面是不是active (running)；如果显示inactive (dead)或failed，说明没起来 - 如果是 Docker 容器，执行
docker ps | grep your-app，没输出就代表容器没运行；再用docker ps -a看有没有刚退出的容器（Exited状态） - 直连测试：在 Nginx 所在机器上运行
telnet 127.0.0.1 8000（把 8000 换成你 upstream 配置的真实端口），如果提示Connection refused，基本锁定后端未监听
检查监听地址和端口是否匹配
Nginx 的 proxy_pass 指向哪里，后端就必须监听在哪里：
- 后端服务默认可能只监听
127.0.0.1:8000，但 Nginx 配置的是http://localhost:8000——这看似一样，但某些系统下localhost解析为 IPv6 的::1，导致连不上；建议统一用127.0.0.1 - 检查后端是否绑定了
0.0.0.0:8000而不是仅127.0.0.1:8000，尤其当 Nginx 和后端不在同一台机器时 - 用
ss -tlnp | grep :8000或netstat -tuln | grep :8000查看端口实际监听情况，确认 PID 对应的是你的服务进程
排查服务启动失败的隐藏原因
服务看似“启动了”，其实几秒后就静默退出，Nginx 请求时已无进程：
- 查完整启动日志：
journalctl -u your-app.service -n 100 --no-pager，留意是否有配置文件路径错误、数据库连接失败、端口被占、权限不足等报错 - 检查依赖是否就绪：比如后端需要 Redis 或 MySQL，但这些服务没启动或网络不通，会导致应用启动失败
- 查看 systemd 启动超时：如果应用冷启动慢，而
TimeoutStartSec设置过短（如默认 90s），systemd 会直接 kill 掉进程，日志里会出现start operation timed out
快速恢复与预防措施
先让服务跑起来，再加固稳定性：
- 手动启动试试：
systemctl start your-app.service，观察是否立即失败；失败就看上面的日志 - 加自动重启策略：在 service 文件中加入
Restart=on-failure或Restart=always，配合RestartSec=3，避免挂了没人管 - 加健康检查：在 Nginx 的 upstream 块里启用
health_check（需 stream 模块或第三方模块），或用外部工具定期探测后端端口是否可连
