proxy_read_timeout仅缓解后端已返回响应头但响应体传输慢导致的504错误，需按路径隔离配置、同步调大proxy_send_timeout和send_timeout、启用upstream keepalive，并确保后端超时设为nginx值的0.8倍。
proxy_read_timeout 能缓解后端接口因响应体传输慢导致的 504 错误，但它不解决请求发不出、连接建不上、SQL 执行卡死或内存溢出等问题——只管“后端已返回状态码和头，但还没把完整数据发完”这一段空闲等待。
它真正起作用的场景
- 后端已返回
HTTP/1.1 200 OK和全部响应头 - 正在流式生成大文件（如 Excel、PDF）、执行长耗时聚合查询、或从对象存储拉取大资源
- Nginx 收到头后，等后续响应体数据的两次读操作之间空闲时间超过设定值 → 主动断连，报 504
常见误判：看到 504 就调大它，结果发现日志里 $upstream_response_time 才 8 秒，说明后端根本没开始处理，问题出在 proxy_connect_timeout 或上游排队上。
必须在 location 块中精准配置
全局设高风险大：
- 所有接口都扛着长连接，worker 进程易被占满
- 文件描述符快速耗尽
- 可能被恶意长连接攻击利用
正确做法是只对明确路径隔离，例如：
location /api/v1/export {
proxy_pass http://backend;
proxy_read_timeout 300; # 按实测 P99 × 1.3 设（如 P99=230s → 300s）
proxy_send_timeout 300;
proxy_connect_timeout 10;
send_timeout 300;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
普通接口（如 /api/user, /health）保持默认 60 秒或设为 20～30 秒，利于快速失败与前端降级。
三个关联参数必须同步调整
单改 proxy_read_timeout 基本无效：
-
proxy_send_timeoutproxy_read_timeout → 请求体（如带 token 的大 JSON）还没发完，Nginx 就断了 -
send_timeoutproxy_read_timeout → 用户网络差、下载慢，Nginx 在转发响应体时提前关连接 -
upstream没开keepalive→ 每次都要重连，握手+TLS 多耗 2–5 秒，实际留给业务的时间缩水
建议统一设为相近值（如全 300），并加：
upstream backend {
server 10.0.1.10:8080;
keepalive 32;
}
后端超时必须比 Nginx 小
这是最容易忽略的关键点：
- 若 Nginx
proxy_read_timeout = 300，后端 TomcatconnectionTimeout = 360→ Nginx 总先报 504 - 若后端设成 200，Nginx 设 300 → 后端先静默断连，Nginx 报
upstream timed out (110)或 502
推荐后端超时 = Nginx 值 × 0.8，例如：
- Nginx 设 300 秒 → Spring Boot 配
server.tomcat.connection-timeout=240000 - Gunicorn 配
--timeout 240 - Flask 不要用
timeout=参数（它控制整个请求生命周期，非仅响应阶段）
别忘了客户端和架构层面
- 前端 fetch / axios 要设够 timeout（如
timeout: 310000），否则浏览器自己就中断了 - 更治本的做法是改成异步：返回
task_id+ 轮询/tasks/{id}，导出由后台任务完成，避免长连接阻塞 - 若必须同步，后端应启用
Transfer-Encoding: chunked或定期 flush 空注释（如:keepalive），让 Nginx 认为“连接还活着”，避免空闲超时
不复杂但容易忽略。
