Nginx 中不存在 http2_chunk_size 参数；优化流式响应需禁用 proxy_buffering、启用 tcp_nodelay、关闭 sendfile 和 gzip，并通过实测验证 DATA 帧连续性。
在 Nginx 中，并没有 http2_chunk_size 这个官方配置参数。这是常见的误解，源于对 HTTP/2 帧机制和 Nginx 流式响应行为的混淆。真正影响流式响应（如 Server-Sent Events、长连接 JSON 流、gRPC 流等）性能的关键，是 Nginx 的缓冲与发送策略，而非某个“chunk size”开关。
HTTP/2 本身不定义“chunk size”
HTTP/2 使用二进制帧（DATA、HEADERS 等）传输数据，帧大小默认上限为 16KB（可通过 SETTINGS 帧协商），但这是传输层分帧限制，不是应用层语义上的“响应块”。Nginx 不暴露帧级控制接口，也不提供 http2_chunk_size 指令——该参数在官方文档、源码及所有稳定版本中均不存在。
真正影响流式响应延迟和吞吐的核心配置
要优化流式响应（尤其是低延迟场景），应关注以下实际可调参数：
- proxy_buffering off;：禁用上游响应缓冲。若开启（默认 on），Nginx 会等后端返回完整响应或缓冲区满才转发，彻底破坏流式语义。
-
proxy_buffer_size 和 proxy_buffers：即使 buffering=off，Nginx 仍用 buffer_size 缓存响应头；若需极小延迟，可设为
proxy_buffer_size 4k;（最小合理值）。 - tcp_nodelay on;：禁用 Nagle 算法，避免小包合并等待，对高频小帧（如 SSE 心跳）很关键。
- sendfile off;：流式响应通常含动态内容，必须关闭 sendfile（零拷贝），否则无法实时透传。
-
gzip off;：压缩需全量缓存再编码，破坏流式；若必须压缩，改用
gzip_min_length 1;+gzip_http_version 1.1;并确保后端已压缩。
验证是否真正流式生效的方法
仅看配置不够，需实测行为：
- 用
curl -v观察响应头是否含transfer-encoding: chunked（HTTP/1.1）或确认 HTTP/2 DATA 帧是否连续发出（用 Wireshark 或nghttp -v）。 - 后端用
time.Sleep(1s); fmt.Fprint(w, "data: ...\n\n")每秒输出一行，前端用 EventSource 连接，检查是否秒级收到——若延迟 >2s，大概率是 buffering 或 tcp_nodelay 未生效。 - Nginx 日志中启用
$upstream_http_content_length和$request_time，对比后端写入时间与客户端接收时间差。
常见误操作与替代方案
有人试图通过 chunked_transfer_encoding on;（仅 HTTP/1.1）或伪造 header 强制分块，这在 HTTP/2 下无效且可能触发协议错误。正确做法是：
- 确保后端响应头含
content-type: text/event-stream或明确无content-length； - Nginx 配置中显式设置
add_header X-Content-Type-Options nosniff;避免浏览器 MIME sniff 干扰； - 若需精细控制帧节奏（如限速流），应在应用层实现（如 Go 的
http.Flusher+time.Ticker），Nginx 不适合做流控节点。
