proxy_read_timeout 是 Nginx 等待后端响应数据完成的超时时间，影响长耗时、流式或卡顿场景，超时返回 504；需按业务设为 30–60 秒（普通 API）、300–600 秒（报表）或 3600 秒（流式），并注意作用域与指令适用范围。
proxy_read_timeout 是 Nginx 中用于控制与后端服务器建立连接后，**等待后端响应数据的时间上限**。它不决定建立连接本身是否超时（那是 proxy_connect_timeout），也不决定发送请求给后端的耗时（那是 proxy_send_timeout），而是专管“后端开始返回响应后，Nginx 等待它把整个响应体读完”的最大时长。
这个值到底影响什么场景？
常见于以下情况：
- 后端处理逻辑复杂、数据库查询慢、调用外部 API 延迟高，导致响应迟迟未发完
- 后端流式返回大文件或实时日志，单次传输间隔较长
- 后端出现卡顿、线程阻塞，已建立连接但无数据持续返回
一旦超过该时限且无新数据到达，Nginx 会主动关闭与后端的连接，并向客户端返回 504 Gateway Timeout。
如何合理设置 proxy_read_timeout？
没有统一标准值，需结合业务特性调整：
- 普通 REST API（轻量计算）：建议设为 30～60 秒，兼顾稳定性与及时失败反馈
- 报表导出、批量任务类接口：可设为 300～600 秒（5～10 分钟），避免误杀长耗时合法请求
- 流式接口（如 SSE、视频分片）：需设得更长（如 3600 秒），并配合后端定期发送心跳（如空注释
:keepalive）维持连接 - 若后端本身有明确超时策略（如 Spring Boot 的
server.tomcat.connection-timeout），该值应略大于后端设置，避免 Nginx 先断连
常被忽略的关键细节
注意几个易错点：
-
作用域仅限 http / server / location 块，不能在 upstream 块中直接配置（upstream 中只有
keepalive等连接复用参数） - 它只对
proxy_pass生效，对fastcgi_pass、uwsgi_pass等需分别使用对应指令（如fastcgi_read_timeout） - 如果启用
proxy_buffering off，该超时仍生效——Nginx 依然会等后端发数据，只是不缓存而是边收边转 - 和客户端侧的
client_header_timeout、client_body_timeout无关，不要混淆
一个典型配置示例
在 location 块中按需覆盖默认值：
location /api/report {<br> proxy_pass https://backend;<br> proxy_read_timeout 600;<br> proxy_connect_timeout 10;<br> proxy_send_timeout 60;<br> proxy_buffering off;<br> # 其他 header 转发等...<br>}<br>
