Nginx 502 错误根源在 uWSGI 无响应时，应先确认其进程存活、监听正常、日志无崩溃迹象，并通过 curl 和 ss 验证通信；再据 error.log 错误类型（如 Connection refused、Connection reset、timed out）精准定位是未启动、缓冲不足还是处理卡死，最后同步调大 uWSGI buffer-size 与 Nginx uwsgi_*_timeout 参数。
Nginx 出现 502 错误，且根源在 uWSGI 进程无响应时，关键不是立刻重启服务，而是确认 uWSGI 是否真在运行、是否能正常处理请求、以及 Nginx 是否能稳定连上它。排查要从进程状态、监听行为、日志线索和通信验证四方面入手。
查 uWSGI 进程是否存活且活跃
uWSGI 可能“挂着但不动”，比如卡死、被 OOM 杀掉、或 worker 全部阻塞。不能只看主进程存在，要看实际工作能力：
- 运行
ps aux | grep uwsgi，确认有 master 进程 + 若干 worker 进程（如uwsgi --ini /path/to/uwsgi.ini启动的） - 检查 systemd 状态：
systemctl status your-app.service，注意 Active: active (running) 且 Recent: 中无 crash 或 restart 频繁记录 - 查看 uWSGI 日志（如
tail -50 /var/log/uwsgi/app.log），重点找Segmentation fault、OSError: [Errno 12] Cannot allocate memory、worker N died或长时间无新日志
验证 uWSGI 是否真正监听并可连接
Nginx 报 502 常因连接被拒或连接后断开，需确认 uWSGI 的 socket 行为是否匹配配置：
- 查 uWSGI 配置中监听方式：
grep -E "socket|http-socket" /path/to/uwsgi.ini
✓ 若用 Unix socket（如socket = /tmp/uwsgi.sock），检查文件是否存在、权限是否允许 nginx 用户（通常是 www-data 或 nginx）读写
✓ 若用 TCP（如http-socket = 127.0.0.1:8080），运行ss -tlnp | grep :8080，确认是LISTEN状态且进程属 uWSGI - 从 Nginx 所在机器直接测试通信：
curl -v <a href="https://www.php.cn/link/8291147824f5712d2c342d34df21f193">https://www.php.cn/link/8291147824f5712d2c342d34df21f193</a>（或访问任意已知接口），观察是否返回 HTTP 200，而非 timeout 或 connection refused
看 Nginx error.log 中的具体错误类型
日志里那句报错决定了下一步方向，别跳过：
-
connect() failed (111: Connection refused)→ uWSGI 没监听，或端口/路径配错 -
recv() failed (104: Connection reset by peer)→ uWSGI 接收了请求但主动断开，常见于缓冲区太小、请求体超限、或进程崩溃前瞬间 -
upstream timed out (110: Connection timed out)→ uWSGI 虽连上，但迟迟不返回响应，可能卡在数据库查询、死循环或资源等待
检查 uWSGI 缓冲与超时设置是否匹配 Nginx
典型“假存活”场景：uWSGI 启动了，但默认 buffer-size=4096 太小，大请求直接被丢弃，导致 Nginx 收不到合法响应而报 502：
- 在 uWSGI 配置中显式加大缓冲：
buffer-size = 32768（即 32K） - 同步调整 Nginx 的 uWSGI 超时参数（避免等太久）：
uwsgi_read_timeout 300;、uwsgi_send_timeout 300;、uwsgi_connect_timeout 30; - 若用 Unix socket，还需确保
uwsgi_buffer_size 32k;和uwsgi_buffers 8 32k;在 Nginx location 块中配置
不复杂但容易忽略
