Nginx 502 错误本质是代理与 Python WSGI 后端（uWSGI/Gunicorn）通信失败，根因必在二者链路：先查 error.log 错误码定位类型（如 111/110/104），再验证后端真实运行状态、监听地址、协议匹配、超时设置及资源健康度。
遇到 Nginx 代理 Python WSGI 服务（如 uWSGI 或 Gunicorn）返回 502，核心思路是：Nginx 已收到请求，但后端没给它一个合法的 HTTP 响应。问题一定出在 Nginx 和 WSGI 进程之间的链路上，而不是用户或网络中间环节。
先看 Nginx 错误日志，锁定具体失败类型
Nginx 的 /var/log/nginx/error.log 是第一线索源，不要跳过这步。重点关注报错末尾的系统错误码：
- connect() failed (111: Connection refused) → WSGI 服务根本没监听，或监听地址/端口不对（比如绑定了 127.0.0.1:8000，但 Nginx 尝试连的是 localhost 或 0.0.0.0）
- upstream timed out (110: Connection timed out) → WSGI 启动了，但没在规定时间内返回响应头，常见于启动卡住、数据库连不上、死锁
- recv() failed (104: Connection reset by peer) → WSGI 进程已启动，但在处理中崩溃退出（如 Python 报段错误、OOM 被杀、配置里 worker 数超限）
检查 WSGI 服务是否真实运行且可访问
别只信 systemctl status，要验证“活连接”：
- 确认进程在跑：
ps aux | grep -E "gunicorn|uwsgi"，看是否有 worker 进程，不是只有 master - 查 systemd 状态和日志：
systemctl status myapp.service+journalctl -u myapp -n 50 -f - 绕过 Nginx 直连测试：
curl -v http://127.0.0.1:8000/health（替换为你实际的监听地址），观察是否返回 200 或有明确错误 - 检查端口监听细节：
ss -tlnp | grep :8000，确认是127.0.0.1:8000还是*:8000；若只监听 127.0.0.1，Nginx 在同一台机器上没问题；若在容器或远程部署，需确保绑定到 0.0.0.0
核对 Nginx 与 WSGI 的协议和连接方式是否匹配
常见错配点：
立即学习“Python免费学习笔记（深入）”；
-
HTTP 模式 vs Socket 模式：如果 uWSGI 配置了
http-socket = 127.0.0.1:8000，Nginx 必须用proxy_pass http://127.0.0.1:8000；若 uWSGI 用socket = /tmp/uwsgi.sock，Nginx 就得用proxy_pass unix:/tmp/uwsgi.sock，且确保 Nginx worker 用户（如 www-data）对该 socket 文件有读写权限 -
防火墙/SELinux 干扰：本地防火墙有时会拦截 127.0.0.1 上的端口通信；SELinux 可能禁止 Nginx 访问网络或 Unix socket，可用
setsebool -P httpd_can_network_connect 1临时放行 -
超时值不协调：Nginx 默认
proxy_read_timeout 60，但你的报表接口可能要 300 秒。务必同步调整：proxy_connect_timeout 30; proxy_send_timeout 30; proxy_read_timeout 300;
检查 WSGI 自身资源与稳定性
很多 502 是后端“表面活着、实际瘫痪”导致的：
- 查看内存和 CPU：
top -p $(pgrep -f "gunicorn.*myapp")，确认没被 OOM Killer 杀掉（检查dmesg -T | grep -i "killed process"） - 检查文件描述符限制：
cat /proc/$(pgrep -f "gunicorn.*myapp")/limits | grep "Max open files"，若接近上限，需调高 ulimit 或优化应用连接池 - 验证数据库等依赖是否就绪：WSGI 启动时若连不上 DB，可能静默失败或阻塞在初始化阶段，此时 curl 测试会超时而非报错
- 临时前台启动 WSGI：
gunicorn --bind 127.0.0.1:8000 --workers 1 --log-level debug myapp:app，观察控制台输出，比看日志更直观
