proxy_read_timeout 是 Nginx 作为反向代理时等待后端返回完整响应体的超时时间，触发于响应头已接收但响应体未在设定时间内收完，导致 504 错误；需据业务设为 30–60 秒（REST）、300 秒（大文件）、300–600 秒（SSE），并配合 proxy_buffering off 等配置。
proxy_read_timeout 是 Nginx 作为 HTTP 反向代理时，控制“从后端服务器读取响应的超时时间”的关键参数。它不是客户端请求超时，也不是连接建立超时，而是指 Nginx 已与后端（如应用服务器）成功建立连接后，等待后端返回完整响应数据的最大时长。
这个超时什么时候被触发？
当后端服务处理缓慢、响应分块发送、或长时间流式传输（如 SSE、大文件下载、WebSocket 升级后的通信等），Nginx 在收到响应头之后，若在 proxy_read_timeout 设定的时间内未收完全部响应体（或未收到新数据），就会主动断开与后端的连接，并向客户端返回 504 Gateway Timeout。
常见误判场景：
- 后端已开始写响应，但响应头已发、响应体迟迟未发全 → 触发此超时
- 后端使用 keepalive 且响应是流式（如日志 tail、实时推送），但间隔超过该值 → 中断连接
- 后端卡死、崩溃、或网络中间设备静默丢包 → 同样表现为读超时
如何合理设置 proxy_read_timeout？
没有统一最优值，需结合业务特性调整：
- 普通 REST API（秒级响应）：设为 30–60 秒 已足够，过长会堆积无效连接
- 报表导出、大文件上传/下载：建议按最大预期耗时 + 缓冲（如 300 秒 / 5 分钟）
- 流式接口（SSE、长轮询）：必须大于客户端心跳间隔，常设为 300–600 秒，并配合 proxy_buffering off 和 proxy_cache off
- 调试阶段可临时设高（如 1800），定位是否真为后端慢，而非配置过严
关联配置不能忽略
单独调大 proxy_read_timeout 不一定解决问题，还需检查配套项：
- proxy_connect_timeout：建立 TCP 连接的超时，通常设为 5–10 秒
- proxy_send_timeout：Nginx 向后端发请求体的超时（如上传大 body），影响 POST/PUT
- client_header_timeout / client_body_timeout：控制客户端侧输入，不直接影响后端读取
- proxy_buffering off：对流式响应必关，否则 Nginx 会缓存整个响应再吐给客户端，导致“看似没数据”而超时
- send_timeout：Nginx 向客户端发送响应的超时，和本参数无关，别混淆
验证与排查小技巧
启用 Nginx 错误日志（error_log /var/log/nginx/error.log notice;），观察是否频繁出现：
upstream timed out (110: Connection timed out) while reading response header from upstream
注意日志里明确写了 “reading response header”，说明是卡在首行或响应头阶段，此时应优先检查 proxy_connect_timeout 或后端启动慢；若写的是 “reading response body”，才是 proxy_read_timeout 生效。
