这问题我碰到过好几次了，核心就是Nginx的超时阈值没跟上后端的处理时长，加上同步生成文件的逻辑不太适合长耗时任务。给你几个可行的方案，从快速修复到长期优化都有：

如果想先快速解决当前的504问题，直接修改Nginx的代理超时参数就行——重点是给Python后端留足生成文件的时间。

找到你的Nginx配置文件（通常在/etc/nginx/nginx.conf或者站点配置目录/etc/nginx/sites-available/下），在对应的server或location块里添加/修改以下参数：

location /your_download_endpoint {
    proxy_pass http://your_python_backend_address; # 比如http://127.0.0.1:8000
    
    # 调整各类超时时间，根据你的实际需求改
    proxy_connect_timeout 180s;    # 和后端建立连接的超时
    proxy_send_timeout 180s;       # Nginx向后端发送请求的超时
    proxy_read_timeout 300s;       # Nginx等待后端响应的核心超时，改成5分钟足够大部分场景
}

修改完后，重启Nginx让配置生效：

sudo systemctl restart nginx

虽然调超时能解决问题，但让用户盯着页面加载三五分钟体验太差，而且超时设得太大也会增加服务器的资源占用风险。更专业的做法是把文件生成改成异步流程：

• 第一步：接收请求后立即响应：当用户提交复杂数据请求时，Python后端不要直接开始生成文件，而是返回一个“任务已提交，生成完成后会通知你”的响应，同时把生成任务放进异步队列（比如用Celery+Redis/RabbitMQ，或者简单的后台线程——不过线程要注意进程安全，避免资源竞争）。
• 第二步：后台生成文件：异步任务在后台运行，生成完成后把文件存到服务器的静态目录或者对象存储（比如本地的/var/www/static/downloads/）。
• 第三步：通知用户下载：文件生成好后，通过邮件、站内消息或者前端轮询接口的方式通知用户，用户点击通知里的链接，直接下载已经生成好的静态文件——这时候Nginx直接处理静态请求，完全不会有超时问题。

• 如果你的Python后端是用uWSGI或Gunicorn部署的，别忘了同步调整它们的超时参数：比如uWSGI的harakiri参数（超时自动杀死进程），也要改成和Nginx匹配的时长，比如harakiri = 300。
• 尽量优化后端的文件生成代码：比如用更高效的数据处理库（比如Pandas代替原生循环）、减少磁盘IO次数、压缩中间数据，能缩短处理时间就最好。

内容的提问来源于stack exchange，提问作者Jeff