如何利用proxy_read_timeout解决后端慢查询任务-Nginx-PHP中文网

proxy_read_timeout仅控制Nginx收到响应头后等待响应体数据的空闲时间，不负责连接建立、请求发送、响应返回及后端性能问题；须在location块中精准配置，并与proxy_connect_timeout、proxy_send_timeout、send_timeout协同调整，且后端超时应略小于Nginx该值。

如何利用proxy_read_timeout解决后端慢查询任务

proxy_read_timeout 能解决后端慢查询导致的 504 错误，但必须用对位置、设对数值、配对参数，否则只是掩盖问题，甚至引发连接堆积或雪崩。

它管什么、不管什么要分清

proxy_read_timeout 只控制 Nginx 在收到后端响应头（如 HTTP/1.1 200 OK 和 headers）之后，等待响应体数据（比如查询结果、导出文件流）到达的两次读操作之间的最大空闲时间。
它不负责：

建立到后端的 TCP 连接（那是 proxy_connect_timeout 的事）
把请求发给后端（那是 proxy_send_timeout 的事）
把响应传给客户端（那是 send_timeout 的事）
后端 SQL 执行慢、内存溢出、线程阻塞等根本原因

所以，看到慢查询报 504，先别急着调大这个值——得先确认是“真等不到数据”，还是“后端压根没开始回”。

必须在 location 块里单独配

慢查询通常只集中在少数路径，比如 /api/v1/report/query 或 /search/advanced。全局统一调大 proxy_read_timeout（比如全设成 600 秒），会让所有接口都承担长连接风险：

worker 进程被长时间占用，吞吐下降
文件描述符快速耗尽
容易被恶意长连接攻击利用

正确做法是用 location 精准覆盖：

location /api/v1/report/query {
    proxy_pass http://backend;
    proxy_read_timeout 300;     # 按实测 P99 ×1.3 设，比如 P99 是 230s → 300s
    proxy_connect_timeout 10;
    proxy_send_timeout 300;
    send_timeout 300;
}

三个配套参数必须同步调

单改 proxy_read_timeout 几乎无效：

若 proxy_send_timeout 还是默认 60 秒，Nginx 可能在请求还没发完时就断连
若 send_timeout 太小（如 60 秒），用户网络稍差、下载慢一点，Nginx 就主动关 client 连接
若 upstream 没开 keepalive，每次请求都重建连接，握手+TLS 消耗 2–5 秒，实际留给业务的时间大幅缩水

建议统一设为相同值或略高，例如：

proxy_read_timeout 300
proxy_send_timeout 300
send_timeout 300
upstream 块中加 keepalive 32;，并确保 proxy_http_version 1.1; 和 proxy_set_header Connection '';

后端超时必须比 Nginx 小

这是常被忽略的关键点。如果后端 Tomcat 的 connectionTimeout 是 360 秒，而 Nginx 的 proxy_read_timeout 是 300 秒，那 Nginx 总是先报 504；反过来，若后端设成 200 秒，Nginx 却设 300 秒，后端已断连，Nginx 还在等，最终可能报 502 或 504。