必须关闭proxy_buffering off，并配套调大proxy_buffer_size至128k、设proxy_max_temp_file_size 0、proxy_busy_buffers_size 256k，启用upstream keepalive、延长proxy_read_timeout和keepalive_timeout，禁用阻塞模块，优化内核TCP参数与事件模型。
Nginx 异步事件驱动模型本身不改变流式响应的语义，但能显著提升其高吞吐处理能力——关键在于让“边收边转”过程全程非阻塞、零落盘、低延迟调度，避免传统代理在大流量下因缓冲失配或同步等待导致的吞吐塌缩。
流式响应需禁用 proxy_buffering，但必须配套缓冲策略
流式场景（如 SSE、视频分片、日志 tail）要求响应体不缓存、立即转发。此时 proxy_buffering off 是前提，否则 Nginx 会等待完整响应再发，违背流式本意。但关闭缓冲后，若未合理配置，极易触发隐式阻塞：
- 必须设 proxy_buffer_size 128k：确保响应头（含长 Cookie、自定义字段）不因过小而报 “upstream sent too big header”
- 禁用临时文件：proxy_max_temp_file_size 0，防止 fallback 到磁盘写入，彻底规避 I/O 瓶颈
- 调大 proxy_busy_buffers_size 至 256k 或更高：即使 buffering 关闭，该参数仍影响发送阶段的缓冲链管理，过小会导致频繁系统调用
连接复用与超时协同，保障持续流不中断
流式响应周期长、速率波动大，连接空闲期易被误判为异常断开。需精准控制两端生命周期：
- 上游 keepalive 必须启用：upstream { keepalive 64; }，配合 proxy_http_version 1.1 和 proxy_set_header Connection ''，复用后端连接，避免每帧都重握手
- 延长读超时：proxy_read_timeout 120（根据最大预期帧间隔设定），防止后端偶发延迟触发连接中断
- 客户端侧保持长连接：keepalive_timeout 75s，keepalive_requests 1000，减少浏览器反复建连开销
事件循环不被阻塞，是流式高吞吐的底层保障
即使配置正确，业务逻辑或系统层干扰仍可能卡住事件循环，使流式转发退化为串行处理：
- 禁用 auth_request 或复杂 rewrite：它们在事件回调中同步执行，会暂停当前连接的读写调度
- 日志写入必须缓冲：access_log /path/log main buffer=64k flush=5s，避免慢磁盘拖慢整个 worker
- 确认使用 epoll（Linux）且 multi_accept on：确保突发流请求能一次 accept 多个连接，不堆积在队列尾部
系统级协同：内存、CPU 与网络栈对齐流式节奏
单靠 Nginx 配置无法突破内核和硬件限制。高吞吐流式依赖底层资源高效就绪：
- worker 进程绑定 NUMA 节点：worker_cpu_affinity auto，并配合 oeAware-manager numa_mem_access 插件优化内存分配路径，降低远程访问延迟
- 调大 TCP 缓冲区：net.ipv4.tcp_rmem = 4096 262144 1048576，适应流式数据突发性，避免因接收窗口不足丢包重传
- 启用 tcp_nodelay on：对首帧延迟敏感的流（如实时监控），禁用 Nagle 算法，确保小包即时发出
