proxy_read_timeout是Nginx与后端间读空闲超时，非总连接时长；应据业务心跳设为2–3倍心跳间隔，如90–120s，并同步配置proxy_send_timeout、upstream keepalive及系统TCP参数。
在 WebSocket 场景下，proxy_read_timeout 不是“连接总时长限制”，而是“两次成功读取之间的最大空闲时间”。它决定 Nginx 在等待后端发送数据时，能容忍多久没有新数据到达。设得太短会误杀静默但合法的长连接；设得过大又可能掩盖后端异常或耗尽连接资源。最佳实践不是盲目拉长，而是结合业务心跳节奏、系统约束和故障响应需求来设定。
明确 proxy_read_timeout 的真实作用范围
这个参数只控制 Nginx 与后端服务器之间 TCP 连接的读空闲超时，不影响 Nginx 与客户端之间的连接状态。也就是说：
- 它不决定 WebSocket 握手是否成功（那是 Upgrade 头和 101 响应的事）
- 它不控制浏览器到 Nginx 的 TCP keepalive 行为（那是 keepalive_timeout 管的，对 WebSocket 无实质意义）
- 它也不替代应用层心跳——即使设为 0（不限时），若后端崩溃且未发 FIN，Nginx 仍可能因内核 TCP 超时或 OOM 被动断连
根据业务通信模式设定合理值
不要统一填 86400（24 小时）。应参考你实际的数据交互频率：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 在线聊天类应用：用户消息间隔通常在秒级，但可能有数分钟静默。设为 7200s（2 小时） 已足够覆盖绝大多数会话，同时便于快速发现后端挂起
- 实时监控/工控终端：设备按固定周期（如 30 秒）上报，建议设为 120–180s，略大于心跳周期即可，利于及时感知设备离线
- 低频通知通道（如邮件提醒、审批推送）：可接受较长延迟，设为 3600s（1 小时） 是较稳妥的平衡点
必须同步检查的配套配置
单调大 proxy_read_timeout 很难治本，需确保以下三项协同生效：
- proxy_send_timeout 应与之保持一致（如都设为 3600s），避免服务端发包慢被单向切断
- upstream 块中启用 keepalive（例如 keepalive 32），减少频繁建连开销，提升复用率
- 确认系统级 TCP 参数未形成瓶颈：net.ipv4.tcp_keepalive_time 建议不低于 7200，否则内核可能先于 Nginx 断连
优先推荐心跳 + 合理超时的组合策略
比起依赖 Nginx 单方面延长超时，更健壮的做法是：
- 客户端和服务端约定每 25–45 秒交换一次 ping/pong 帧（避开刚好 60 秒边界）
- Nginx 的 proxy_read_timeout 设为心跳间隔的 2–3 倍（如设 90–120s）
- 这样既保证连接活跃可见，又让超时真正成为“故障探测器”，而非“被动等待器”
