是的，绝大多数情况下就是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——容易被覆盖且不易审计。
调大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
超时参数只是兜底开关，不是性能优化手段。调之前，先确认那个“慢请求”到底慢在哪一层——这点最容易被忽略。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
