关键在于精准匹配后端心跳节奏，proxy_read_timeout应设为心跳间隔的2–3倍，并同步配置proxy_send_timeout、upstream keepalive及系统tcp_keepalive_time参数。

要让 WebSocket 长连接在静默期稳定不中断，关键不是把 proxy_read_timeout 拉得越长越好，而是让它精准匹配后端心跳节奏——它管的只是“Nginx 等后端发下一个数据帧的最大空闲时间”，不是整个会话寿命。

理解它真正控制什么

这个参数只作用于 Nginx 与后端服务之间的 TCP 连接读取阶段：

• 它不干预浏览器到 Nginx 的连接，也不影响 keepalive_timeout
• 它不管 WebSocket 握手（101 响应）是否成功，那由协议头和 HTTP 版本决定
• 它不替代应用层心跳——即使设为 0，后端崩溃未发 FIN，Nginx 仍可能被内核 TCP 超时踢掉
• 日志里出现 upstream timed out (110)，大概率是后端已关连接，而 Nginx 还在等数据

按心跳周期设定合理值

推荐设为后端心跳间隔的 2–3 倍，留出网络抖动和处理延迟余量：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 后端每 30 秒发一次 ping → proxy_read_timeout 90–120s
• 工控设备固定 45 秒上报 → 设为 180s
• 低频审批通知通道（心跳 3600s）→ 3600s 已足够，不必硬上 86400
• 报表导出类接口（非纯 WebSocket，但需长流）→ 单独用 location 块配置 240–300s，避免污染其他路由

必须同步调整的配套项

单改 proxy_read_timeout 是无效的。以下三项缺一不可：

• proxy_send_timeout 必须与它一致，否则大消息或弱网下发送阶段就被切断
• upstream 块中启用 keepalive 32（或按并发调高），避免每次心跳都重建连接
• 检查系统级参数：net.ipv4.tcp_keepalive_time 应 ≥ 7200，防止内核早于 Nginx 主动断连

Ingress 或容器环境的特殊处理

在 Kubernetes 中使用 Nginx Ingress Controller 时：

• 不要直接改 nginx.conf 或 ConfigMap 全局配置，容易被升级覆盖
• 通过 Ingress 资源的 annotation 注入：nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
• 支持按路径粒度控制，比如 /ws/chat 和 /ws/notify 可设不同值