502错误主因是uWSGI默认60秒超时主动断连，Nginx收不到响应而报错；需同步调大uWSGI的http-timeout与socket-timeout（如设为300），并配置Nginx的proxy_connect_timeout、proxy_send_timeout和proxy_read_timeout为相同值。
uWSGI默认60秒超时直接触发502
Flask本身不处理反向代理超时，真正掐断请求的是uWSGI——它默认http-timeout和socket-timeout都是60秒。一旦你的视图函数执行超过这个时间（比如导出大Excel、调用外部API、批量处理数据），uWSGI会主动关闭连接，Nginx收不到完整响应头，立刻报upstream prematurely closed connection while reading response header from upstream，最终返回502。
必须显式延长这两个值，且建议设为相同：
-
http-timeout=300：控制HTTP请求整体生命周期（从接收首字节到发完响应） -
socket-timeout=300：控制底层socket读写空闲等待时间，尤其影响长轮询或流式响应 - 旧版uWSGI可能只认其中一个，所以两个都写更稳妥
Nginx的proxy_*_timeout也得同步调大
即使uWSGI撑住了，Nginx仍可能在半路截断。它的三个关键超时默认全是60秒，且彼此独立：
-
proxy_connect_timeout 300：Nginx连uWSGI（或后端服务）建立TCP连接的最长等待时间 -
proxy_send_timeout 300：Nginx向uWSGI发完请求后，等待uWSGI开始返回响应的最长时间 -
proxy_read_timeout 300：Nginx从uWSGI读取响应体时，两次数据包之间的最大空闲时间
注意：proxy_read_timeout不是整个响应耗时上限，而是“连续读操作之间”的间隔限制。如果后端每10秒推一次进度，但某次卡了65秒没发新数据，Nginx就会断连——这时候需要调高它，或者让后端改用Transfer-Encoding: chunked保持连接活跃。
进程/线程配置不当也会间接引发502
超时只是表象，资源耗尽才是根源。以下配置容易埋雷：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
processes=4+threads=2：共8个并发单元，但若每个请求占大量内存或阻塞IO，实际并发数远低于此 - 没配
max-requests=1000：长运行进程可能因内存泄漏逐渐变慢，最终超时 - 没开
vacuum=true：worker退出后不自动清理内存，残留状态影响后续请求 - Python虚拟环境路径写错（如
home=/path/to/venv不存在）：uWSGI启动失败但不报明显错误，Nginx连不上就502
验证方式：用sudo netstat -anpt | grep :6666（假设uWSGI监听6666）确认进程是否真在运行；查/var/log/uwsgi.log有没有ImportError或unable to load app类错误。
权限与socket文件路径不一致是隐藏杀手
502不一定源于超时，也可能是Nginx根本连不上uWSGI。常见于Unix socket场景：
- uWSGI生成的
.sock文件属主是ubuntu，但Nginx worker进程以www-data身份运行 → 权限拒绝 - 解决方法：在uWSGI配置里加
chmod-socket=666，并确保uid=www-data和gid=www-data与Nginx一致 - 路径不匹配：Nginx配置中
uwsgi_pass unix:/tmp/app.sock，而uWSGI实际写到/run/uwsgi/app.sock→ 连接被拒 - 验证命令：
namei -l /tmp/app.sock逐级检查路径权限，ls -l /tmp/app.sock确认socket文件存在且可访问
这类问题在Ubuntu/Debian上特别高频，因为Nginx默认用户是www-data，而普通用户部署常忽略组权限同步。
