504错误源于Nginx代理超时，需同步调大proxy_read_timeout（如300秒）、后端框架超时（如gunicorn --timeout 300）、并防范浏览器中断；推荐异步导出+前端提示+监控耗时。
nginx 代理超时导致导出卡住 504
导出接口跑得久，但 nginx 默认只等 60 秒就断开，后端还没返回就甩出
。这不是后端挂了，是 nginx 主动放弃了。
必须调大——它控制 nginx 等后端响应的最长时间，导出类请求建议设为
（5 分钟）或更高
和
一般不用动，除非后端启动极慢或发数据特别慢
改完记得
，光改配置不重载等于没改
别只改 location 块里的 timeout：如果用了
引入通用 proxy 配置，得去对应文件里一起改，否则会被覆盖
后端框架自身超时也在“抢杀”导出
nginx 是第一道关，但 Django、Flask、Spring Boot 这些框架自己也有请求生命周期限制，它们可能比 nginx 更早中止连接。
Django 的
设置不直接影响导出，但
默认 30 秒，必须显式加长，比如
Flask + uWSGI？检查
参数，默认 30 秒，设成
Spring Boot 的
是连接建立超时，不影响导出；真正要调的是反向代理场景下的
（如果用了异步导出）
Node.js（Express + http-proxy-middleware）？
选项默认 120000ms（2 分钟），导出前得手动设大：
浏览器侧中断常被误判为 504
用户点下导出按钮后切走、关标签页、甚至只是锁屏，Chrome / Safari 可能主动断掉 pending 请求，Nginx 日志里也会记成 504，但实际后端还在跑。
这种情况下 nginx error log 里通常伴随
无法靠服务端参数完全规避，得在前端加提示：“导出进行中，请勿关闭页面”，并用
拦一下误操作
更靠谱的做法是改成异步导出：前端提交任务 → 后端返回 task_id → 轮询或 WebSocket 通知完成 → 再触发下载。这样即使用户离开，任务也不中断
超时值不是越大越好
设成 1 小时看着保险，但会把问题掩盖得更深：内存泄漏、死循环、锁表这些真故障，会在超时前悄悄拖垮整个服务。
按业务预期时间设上限：报表导出通常 2–10 分钟，设
足够；千万级数据导出应走离线任务，不该走 Web 请求链路
配合监控看真实耗时：用
记录日志，定期查 P95/P99，再决定是否调参
注意
不影响 keepalive 连接复用，但过长会占着 worker 进程，高并发下反而降低吞吐
导出超时从来不是单点问题，nginx、中间件、框架、浏览器四层都可能掐断连接，调一个参数容易，但漏掉任意一层，504 就照来不误。
504 gateway time-outproxy_read_timeout300proxy_connect_timeoutproxy_send_timeoutnginx -t && nginx -s reloadincludeTIMEOUTgunicorn --timeout--timeout 300harakiriharakiri = 300server.tomcat.connection-timeoutspring.mvc.async.request-timeouttimeouttimeout: 300000upstream prematurely closed connection while reading response header from upstreambeforeunload600$upstream_response_timeproxy_read_timeout