proxy_read_timeout实际约束的是响应头返回后、等待响应体数据到达的两次读操作间最大空闲时间；在长轮询中，它从后端返回200 ok及headers后开始倒计时，期间只要收到任意body数据（如换行符）即重置，不控制建连或首字节延迟。
proxy_read_timeout 不能控制长轮询的总时延，它只管“响应头已到、但响应体还没来”这段空闲等待时间，不是从请求发出开始计时的全局超时。
它实际约束的是哪一段？
在长轮询中，后端通常先返回 200 OK 和 headers，然后挂起连接，等事件发生再写入 body（哪怕只是一个换行符）。此时：
- proxy_read_timeout 才开始倒计时；
- 只要后端在超时前写入任意数据（哪怕空格或注释帧），计时器就重置；
- 它完全不管“等第一个字节”的时间——那是后端处理逻辑和 proxy_connect_timeout 的事。
真正影响总时延的关键环节
长轮询一次完整生命周期涉及多个阶段，每个阶段由不同参数控制：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
建连耗时：由
proxy_connect_timeout控制（如设为 5s）； - 后端准备响应头的时间：取决于业务逻辑，Nginx 不干预；
- 挂起等待事件的时间：由后端主动控制（如 context.WithTimeout），proxy_read_timeout 只作为兜底；
- 云负载均衡器 idle timeout（如 AWS ALB 默认 60s）可能比 Nginx 更早切断连接，必须检查并调大。
如何合理设值才不误杀也不堆积
设值目标是：比后端最长挂起时间多出 5–10 秒缓冲，又远小于系统资源承受极限：
- 若后端用
30s等待事件，则 Nginx 设proxy_read_timeout 35s； - 若后端支持 SSE 并定期发
:keepalive注释帧，可设为86400，但必须配proxy_buffering off； - 避免设为 0 或 3600 —— 前者失去保护，后者易拖垮 worker 连接数。
必须同步打开的配套开关
单设 proxy_read_timeout 几乎无效，以下三项缺一不可：
-
proxy_http_version 1.1+proxy_set_header Connection ''：防止 Nginx 主动关闭连接； -
proxy_send_timeout ≥ proxy_read_timeout：避免请求还没发完就被中断； - upstream 块启用
keepalive 32：复用连接，减少握手开销和 TIME_WAIT。
