必须关闭 proxy_request_buffering，否则大文件上传会因Nginx缓存整个请求体导致高延迟、内存暴涨、413错误或超时；需同步设置 client_max_body_size、client_body_timeout、proxy_read_timeout 和 client_body_buffer_size，并透传 Range 等关键头部以支持断点续传。
必须关掉 proxy_request_buffering，否则大文件上传永远卡在“等收完再发”这一步——延迟高、内存爆、还容易 413 或超时中断。
为什么 proxy_request_buffering off 是流式上传的硬性前提
默认 proxy_request_buffering on 时，Nginx 会把整个请求体（比如一个 2GB 的视频分片）先收全，再整体转发给后端。这对流式场景是反模式：后端本可边收边处理，却被 Nginx 强行阻塞在入口。
- 内存占用与文件大小正相关：10GB 文件可能吃掉几百 MB 内存或触发磁盘刷写
- 首字节转发延迟 = 整个上传耗时，AI 推理或直播推流根本无法接受
- 不校验
Content-Length的副作用其实是优点——分块上传、断点续传、弱网重传都更鲁棒
proxy_request_buffering off 单开不够，必须同步调这四个参数
只写一行 proxy_request_buffering off 在生产环境大概率失效，甚至引发连接挂起或 502。
-
client_max_body_size 0或设为具体值（如20G）：否则 413 错误会在 buffering 关闭前就拦截请求 -
client_body_timeout 3600：上传过程可能因网络抖动暂停几秒，超时太短直接断连 -
proxy_read_timeout 3600：后端处理大文件流可能耗时较长，这个超时控制的是 Nginx 等后端响应的时间 -
client_body_buffer_size 0：显式禁用内存缓冲区，避免 Nginx 在极小概率路径下仍尝试缓存
容易被忽略的协议层细节：头部透传与 HTTP 版本
流式上传常依赖特定请求头（如 Range、If-Range）和长连接语义，Nginx 默认行为可能破坏它们。
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 必须加
proxy_http_version 1.1：HTTP/1.0 不支持持久连接，分片上传会每片建一次 TCP 连接 - 显式清空
Connection头：proxy_set_header Connection ''，防止中间设备（如某些 WAF）误判并关闭连接 - 透传关键头：
proxy_set_header Range $http_range和proxy_set_header If-Range $http_if_range，否则断点续传失败
后端没准备好，关 buffering 反而更危险
proxy_request_buffering off 把“流式压力”直接甩给了后端——它必须能处理不完整 body、无 Content-Length、TCP 包边界不齐的原始数据流。
- 确认后端框架未强制读取完整 body（如某些 Python WSGI 中间件会预读）
- gRPC-Web 或自定义二进制协议比 REST + JSON 更适合这种场景
- 如果后端基于 Node.js Express，需用
req.on('data')而非body-parser中间件
真正难的不是配 Nginx，而是让整条链路（Nginx → 负载均衡 → 后端服务 → 存储）都理解“流”的语义，而不是把它当成一个要等齐的“包”。
