兄弟，你的Gunicorn命令里的--timeout 300参数本身是正确的，但你遇到的504 Gateway Time-out大概率不是Gunicorn本身的问题，而是前端反向代理（比如Nginx）的超时限制在搞鬼！咱们一步步来排查解决：

1. 先确认Gunicorn的超时是否生效 #

先排除Gunicorn本身的问题，你可以写一个测试接口模拟长时间处理：

from fastapi import FastAPI
import time

app = FastAPI()

@app.get("/test-timeout")
async def test_timeout():
    time.sleep(300)  # 模拟5分钟的后台处理
    return {"status": "success", "message": "处理完成"}

然后直接通过Gunicorn的端口（比如8000）用curl调用：

curl http://localhost:8000/test-timeout

如果这个请求能正常返回结果，说明Gunicorn的--timeout 300已经生效，问题出在前端的网关/代理上；如果Gunicorn这边直接返回超时错误，那你再检查Gunicorn的日志，看有没有worker被强制杀掉的记录（比如Worker exited due to signal 9），这时候可能需要确认参数是否正确传递，或者Gunicorn版本有没有特殊问题。

2. 重点调整反向代理（比如Nginx）的超时配置 #

504错误本质是网关（比如Nginx）等不及后端Gunicorn的响应，提前断开了连接。你需要在Nginx的server配置块里添加以下超时参数：

# 代理相关超时
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;

# 如果用了fastcgi协议（较少见），也要加对应超时
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;

修改后重启Nginx：

sudo systemctl restart nginx

3. 额外注意事项 #

• 如果你用了其他网关、负载均衡（比如Cloudflare、AWS ALB等），也要同步调整这些服务的超时时间，确保整个链路的超时都大于你的后台处理时间；
• 你的--keep-alive 300是设置长连接的保持时间，和请求处理超时无关，但这个配置本身没问题；
• 如果你的后台处理是异步任务，建议考虑用Celery之类的任务队列来异步处理，前端返回任务ID，之后轮询结果，这样不用让HTTP请求一直挂着，更稳定。

备注：内容来源于stack exchange，提问作者CoronaVirus