先把当时的情况摆出来。后台导出报表时页面返回 504 Gateway Time-out，日志里写上游读取超时，把超时时间改大之后偶尔还是会失败。
原因不止一个，得分开看。后端处理本身超过设定的读取超时。也可能是后端连接池打满，请求在排队。
还有一种情况，前置代理或者负载均衡的超时更短，先断了。
先确认超时来自哪一层
grep -n 'upstream timed out' /var/log/nginx/error.log接着看后端实际处理耗时
tail -200 /var/log/nginx/access.log | awk '{print $NF}' | sort -n | tail调大读取超时
grep -n proxy_read_timeout /etc/nginx/conf.d/app.conf剩下的就是核对前置层的超时设置
nginx -T | grep -n timeout报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
白天有业务在跑，能验证的部分都压到了晚上做。
当时还开着另一个排查窗口，两边日志对照着看才定位到。
恢复的判定其实很直接。导出任务能在超时前完成，错误日志里不再出现上游超时记录。
超时只治表面，导出类任务更该改成异步队列；每次放宽超时都会连带占用更多连接资源。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。