为什么Python脚本在高并发请求下返回502_优化Gunicorn配置与并发模型-Python教程-PHP中文网

502 Bad Gateway主因是Gunicorn worker超时或阻塞：同步模型下IO等待导致worker全卡死；gevent未正确monkey patch或存在阻塞调用；timeout与graceful_timeout配置冲突；worker数与worker_connections失衡；文件描述符或backlog限制不足。

为什么python脚本在高并发请求下返回502_优化gunicorn配置与并发模型

502 Bad Gateway 通常不是 Python 应用本身挂了，而是 Gunicorn 的 worker 进程没在规定时间内响应 Nginx —— 根本原因八成是 worker 被堵死、超时被杀，或根本没空处理新请求。

worker 被卡住：IO 等待没释放进程

同步 worker（sync）模型下，每个请求独占一个 worker 进程。如果应用里有数据库查询、HTTP 调用、文件读写等 IO 操作，进程就会原地等待，无法处理其他请求。流量一上来，所有 worker 全在等，Nginx 发来的请求全积压，最终触发 timeout，返回 502。

典型现象：gunicorn.error 日志里反复出现 Worker timeout (pid:xxx)
适用场景：纯 CPU 计算型任务（极少）；否则不建议生产环境用 sync
验证方式：用 ps aux | grep gunicorn 查看 worker 进程状态，大量处于 S（sleep）而非 R（running）
解决方向：换异步 worker 类，让单个进程能并发处理多个请求

gevent worker 配置不当：补丁漏了或阻塞调用未适配

用 gevent 是最常见解法，但光加 -k gevent 不够。gevent 依赖 monkey patch 把标准库的阻塞调用（如 socket、ssl、threading）替换成协程友好的版本。漏掉 patch，IO 仍会阻塞整个 worker。

必须在应用入口最顶部执行：from gevent import monkey; monkey.patch_all()
某些 C 扩展（如旧版 psycopg2）需额外 patch：monkey.patch_psycopg()
避免在协程中执行耗时 CPU 操作（比如大数组排序、图像处理），会拖垮整个 worker
检查是否误用了线程/进程（threading.Thread 或 multiprocessing.Process），它们不兼容 gevent

超时参数设置冲突：timeout 和 graceful_timeout 差太小

--timeout 控制单个请求最长处理时间，--graceful-timeout 控制 worker 收到退出信号后最多还能干多久。Kubernetes 滚动更新或手动 reload 时，如果 graceful-timeout 小于 timeout，正在处理长请求的 worker 可能被强制 kill，导致该请求直接中断并返回 502。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

安全组合示例：--timeout 120 --graceful-timeout 30（前者 ≥ 后者 × 2 更稳妥）
特别注意：--worker-timeout 是空闲超时，和 502 关系不大，别把它和 --timeout 搞混
若业务含大文件上传或报表导出，--timeout 必须显式加大，不能依赖默认 30 秒

worker 数量与连接数失衡：并发能力虚高

设了 8 个 worker，却没配 worker_connections，Gunicorn 默认只允许每个 worker 处理 1000 个连接（对 gevent 有效）。实际最大并发 = workers × worker_connections。如果这个值远低于 Nginx 的 worker_connections，请求会在 Nginx 层排队，超时后照样 502。