proxy_send_timeout在长连接场景下基本不生效，它仅适用于非长连接，控制nginx向后端发送请求体时单次等待确认的超时；长连接稳定依赖proxy_read_timeout、keepalive_timeout、proxy_buffering off及tcp keepalive等机制。
proxy_send_timeout 在长连接场景下基本不生效，它专为非长连接（每次请求新建 TCP 连接）设计，只控制 Nginx 向后端发送请求体过程中，等待后端确认接收的单次间隔超时。一旦启用 HTTP/1.1 keepalive 或 HTTP/2，连接复用后，该指令就失去作用。
所以，保障长连接中数据双向稳定发送，不能靠调高 proxy_send_timeout，而应聚焦真正起效的机制：
明确长连接中 proxy_send_timeout 的定位
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 它不控制客户端 ↔ Nginx 的上传
- 不控制 Nginx ↔ 后端的响应读取（那是 proxy_read_timeout）
- 不控制连接建立（那是 proxy_connect_timeout）
- 更不控制 WebSocket、SSE 或流式响应的持续通信节奏
长连接下真正影响双向传输稳定的参数
- proxy_read_timeout：决定 Nginx 从后端读取响应数据时，两次数据包之间的最大空闲等待时间。对长连接流式接口（如导出、日志尾部、SSE）最关键，建议设为 300–86400（如 WebSocket 场景常用 86400）
- keepalive_timeout（upstream 级）：控制 Nginx 与后端 keepalive 连接的最大空闲保持时间，需配合后端的 keepalive 设置（如 Tomcat 的 keepAliveTimeout、Netty 的 idleStateHandler）
- proxy_buffering off：关闭缓冲后，Nginx 直通转发响应流，避免因缓冲区满或延迟 flush 导致“假卡顿”
- tcp_keepalive（系统级）：Linux 的 net.ipv4.tcp_keepalive_time/net.ipv4.tcp_keepalive_intvl 可防止中间设备（如 NAT、防火墙）静默断连
针对不同长连接类型的操作建议
- WebSocket：必须显式设置 proxy_read_timeout 86400 和 proxy_send_timeout 86400（虽后者在复用连接中实际不触发，但惯例配置可防误判），并透传 Upgrade/Connection 头，启用 ip_hash 或 sticky cookie
- HTTP/2 流式 API：依赖 proxy_read_timeout 控制响应流间隙；确保后端及时 flush，Nginx 开启 http_v2 模块且 proxy_http_version 设为 2.0
- Keepalive 普通 HTTP 接口：重点调大 upstream 的 keepalive 指令（如 keepalive 32；keepalive_requests 1000；keepalive_timeout 60s），而非 proxy_send_timeout
一句话总结
长连接的数据双向稳定，靠的是连接复用机制 + 读超时保护 + 底层 TCP 心跳 + 后端主动 flush，不是靠 proxy_send_timeout“硬拖时间”。把它设高，既无效，还可能掩盖真实瓶颈。
