proxy_read_timeout控制Nginx收到响应头后两次读操作间的最大空闲时间，非整个请求生命周期；需配合HTTP/1.1透传、proxy_send_timeout≥其值、upstream keepalive及客户端协同调整。
proxy_read_timeout 在长轮询（Long Polling）场景下，不是简单调大就能用好——它必须配合协议特性、客户端行为和后端实现共同生效。关键在于：它控制的是 Nginx 从 upstream 收到响应头后，等待后续数据（比如事件消息）到达的**两次读操作之间的最大空闲时间**，而非整个请求生命周期。
明确它的实际作用范围
在长轮询中，后端通常不会立刻返回完整响应，而是挂起连接，直到有新事件或超时才写入一次响应体。此时：
- proxy_read_timeout 不管“等第一个字节”的时间——那是 proxy_connect_timeout 和后端处理逻辑的事；
-
它只管“首字节已收到，但之后迟迟没新数据来”这段空闲期，比如后端已返回
200 OK和 headers，但 body 还没写，Nginx 就开始倒计时这个 timeout； - 若后端在超时前写入了任意数据（哪怕只是一个换行或空格），计时器会重置，继续等待下一次空闲。
长轮询路径需配套的关键配置
单设 proxy_read_timeout 容易失效，以下三项必须同步调整：
-
启用 HTTP/1.1 与 Connection 头透传：确保
proxy_http_version 1.1和proxy_set_header Connection ''已设置，否则 Nginx 可能主动关闭连接； - proxy_send_timeout ≥ proxy_read_timeout：防止 Nginx 在向后端转发请求时中途断开（尤其当客户端带大 header 或 slow start）；
-
upstream keepalive 开启：例如
keepalive 32，避免每次长轮询都重建 TCP 连接，减少握手开销和 TIME_WAIT 堆积。
数值设定要匹配业务节奏，而非堆高
典型长轮询等待窗口是 20–60 秒，proxy_read_timeout 应比后端最长挂起时间多出 5–10 秒缓冲：
- 若后端用
context.WithTimeout(ctx, 30*time.Second)控制单次等待，则 Nginx 设为35s或40s即可； - 不建议盲目设成 300s 或 3600s——过长会占用 worker 连接，影响并发能力；
- 务必检查云负载均衡器（如阿里云 SLB、AWS ALB）的 idle timeout，它可能比 Nginx 更早切断连接（ALB 默认仅 60 秒）。
客户端与后端协同才能稳住连接
服务端配置只是半边，还需两端对齐：
-
客户端 fetch 需禁用自身 timeout：例如
fetch(url, { signal: AbortSignal.timeout(0) })或显式设为足够大值，避免前端先放弃； -
后端不能提前 writeHeader 或 flush 空响应：Go 中应避免在 handler 开头就调
w.WriteHeader()，而应在真正有数据或超时时一次性写出； -
推荐加轻量心跳帧：后端可在超时前 2–3 秒写入一个换行或注释行（如
data: \n），重置 Nginx 的 read idle 计时器，又不干扰客户端解析。
