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 小时）。应参考你实际的数据交互频率：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 在线聊天类应用：用户消息间隔通常在秒级，但可能有数分钟静默。设为 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）
• 这样既保证连接活跃可见，又让超时真正成为“故障探测器”，而非“被动等待器”