proxy_send_timeout需设为足够长（如86400秒），因其控制两次成功发送间的最大空闲时间，而非单次发送耗时；默认60秒易导致大数据帧传输中断，必须配合proxy_buffering off等配置确保帧实时转发。
要让 WebSocket 大数据帧不被 Nginx 中断，proxy_send_timeout 必须设得足够长——它不是限制单次发送耗时，而是控制“从上一次成功发送到下一次发送之间允许的最大空闲时间”。只要后端正在持续输出（比如分片发送大消息），但某一片迟迟没发完，超时一到，Nginx 就会直接关闭连接，客户端收到 502 或连接重置。
为什么默认值 60 秒对大数据帧很危险
WebSocket 发送一个几 MB 的二进制帧，或服务端在弱网、高负载下分片慢一点，单帧传输就可能超过 60 秒。Nginx 不区分“正在发”和“卡住了”，只要两次 write() 调用间隔超时，就断连。这不是后端崩溃，而是代理层误判。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
合理设置 proxy_send_timeout 的关键原则
- 该值应 ≥ 后端最大单帧生成+发送耗时，建议设为 86400（24 小时），与 proxy_read_timeout 保持一致
- 不能只靠它“撑住”大数据——必须配合禁用缓冲：proxy_buffering off，否则 Nginx 会攒着帧不发，导致超时触发
- 若后端使用 Swoole、Netty 等框架，需确认其写超时（如 Swoole 的
send_timeout）也大于等于此值，避免前后端超时错位 - 对于极大数据（如百 MB 文件流），建议前端主动分片（例如每片 128KB），并确保每片发送间隔远小于 timeout 值，避免单片拖垮整个连接
配套必须做的配置项
单独调大 proxy_send_timeout 不起作用，以下三项必须同步开启或关闭：
- proxy_buffering off：防止 Nginx 缓存未发出的帧，造成“已调用 send 却无实际网络输出”的假象
- proxy_http_version 1.1 和 proxy_set_header Connection 'upgrade'：确保协议升级链路完整
- proxy_cache_bypass $http_upgrade：避免 CDN 或反向代理缓存 upgrade 请求，导致握手失败
验证是否生效的小技巧
在 Nginx 日志中打开 error_log ... debug;，观察是否有 upstream timed out (110: Connection timed out) 类错误；同时用 tcpdump 抓包，确认 FIN 包是否由 Nginx 主动发出——如果是，大概率就是 send timeout 触发了。
