是的，绝大多数情况下就是Gunicorn的--timeout设得太低；默认30秒，若请求如导出报表、调第三方API等耗时超限，worker会被SIGKILL并返回504，需根据最长合法耗时合理设值（如82秒设90），但过高会拖垮服务，且须同步调大Nginx proxy_read_timeout等上游超时。
Flask应用在Gunicorn下突然返回504，是不是timeout太小？
是的，绝大多数情况下就是--timeout（或timeout配置项）设得太低。Gunicorn默认timeout是30秒，只要工作进程在30秒内没把响应交给主进程，它就会直接杀掉该worker并返回504。这不是Flask的问题，而是Gunicorn的保护机制在起作用。
常见触发场景包括：同步调用外部API、读写慢速数据库、处理大文件上传、执行复杂计算——这些操作若卡在Python线程里，Gunicorn根本等不到结果。
-
--timeout单位是秒，必须是整数，不能带小数（如--timeout 45.5会报错） - 该值应略大于你最长可能耗时的请求（比如最慢的报表导出要82秒，建议设为90）
- 设太高有风险：一个卡死的worker会长期占用资源，可能拖垮整个服务
- 只对同步Worker类型（
sync，默认）生效；gevent或eventlet需配合各自超时机制
怎么改gunicorn的timeout参数？三种常用方式
别改Flask的app.run()——那只是开发服务器，上线不用它。Gunicorn的timeout必须在启动时指定。
- 命令行启动：
gunicorn --bind :8000 --timeout 120 myapp:app
- 配置文件（如
gunicorn.conf.py）：timeout = 120
然后运行gunicorn -c gunicorn.conf.py myapp:app - Docker或systemd中：确保
exec命令里包含--timeout，例如Dockerfile的CMD ["gunicorn", "--timeout", "120", "--bind", "0.0.0.0:8000", "myapp:app"]
注意：环境变量GUNICORN_CMD_ARGS也能传参，但不推荐用于timeout——容易被覆盖且不易审计。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
调大timeout后还是504？检查这几个地方
不是所有504都归咎于Gunicorntimeout。前端Nginx、云服务商LB、甚至客户端本身都可能先超时。
- Nginx的
proxy_read_timeout必须 ≥ Gunicorntimeout，否则Nginx自己先断连，返回504（日志里会出现upstream timed out） - AWS ALB/ELB默认空闲超时是60秒，若Gunicorn设了90秒，但ALB只等60秒，照样504
- Flask内部用了
requests调第三方API？它的timeout参数（如requests.get(url, timeout=30)）和Gunicorn无关，但会提前抛异常，导致响应失败 - 数据库连接池耗尽或锁表，请求卡在
session.commit()上——这时加timeout只是让失败来得更晚，得查DB层
真正需要长超时的请求，别只靠调timeout
硬扛120秒不是优雅解法。用户等两分钟大概率已刷新页面，后端还在傻跑。
- 对导出、渲染、批量任务类请求，改用异步模式：接收请求后立即返回
202 Accepted+ 任务ID，后台用Celery或RQ处理，前端轮询结果 - 上传大文件？用分片上传 + 预签名URL，绕过整个WSGI请求生命周期
- 必须同步？至少加
signal.alarm()做二级超时，避免Gunicorn粗暴kill导致资源泄漏 - 监控关键路径耗时：用
flask-talisman或自定义before_request/after_request打点，确认瓶颈真在代码而非网络或DB
超时参数只是兜底开关，不是性能优化手段。调之前，先确认那个“慢请求”到底慢在哪一层——这点最容易被忽略。
