proxy_send_timeout需设为足够长（如86400秒），因其控制两次成功发送间的最大空闲时间，而非单次发送耗时；默认60秒易导致大数据帧传输中断，必须配合proxy_buffering off等配置确保帧实时转发。

要让 WebSocket 大数据帧不被 Nginx 中断，proxy_send_timeout 必须设得足够长——它不是限制单次发送耗时，而是控制“从上一次成功发送到下一次发送之间允许的最大空闲时间”。只要后端正在持续输出（比如分片发送大消息），但某一片迟迟没发完，超时一到，Nginx 就会直接关闭连接，客户端收到 502 或连接重置。

为什么默认值 60 秒对大数据帧很危险

WebSocket 发送一个几 MB 的二进制帧，或服务端在弱网、高负载下分片慢一点，单帧传输就可能超过 60 秒。Nginx 不区分“正在发”和“卡住了”，只要两次 write() 调用间隔超时，就断连。这不是后端崩溃，而是代理层误判。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

合理设置 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 触发了。