降低ttfb需协同优化请求接收、ssl传输、连接复用、响应透传四环节：禁用proxy_request_buffering、调小ssl_buffer_size、启用upstream keepalive、关闭proxy_buffering。
要降低全站首字节响应时延（TTFB），不能只调 proxy_buffering 或加缓存，得从请求接收、SSL传输、连接复用、响应透传四个关键环节协同优化。Nginx 的 ngx_http_proxy_module 是核心载体，但必须配合其他模块行为才真正生效。
禁用请求体缓冲，避免上传类请求卡首包
默认开启的 proxy_request_buffering on 会让 Nginx 等客户端把整个 POST/PUT 请求体（比如表单、文件流、JSON）发完才转发给后端——这对实时接口或流式上传是致命延迟源。
- 对 API、WebSocket、大文件分块上传等场景，必须在对应 location 中显式关闭：
proxy_request_buffering off; - 该设置需与
proxy_buffering off和proxy_cache off配合，否则响应仍可能被缓存积压 - 注意：关闭后，若后端不支持流式读取（如传统 PHP-FPM），可能导致 499 或超时，需同步验证后端兼容性
压缩 SSL 记录大小，加速 HTTPS 首包抵达
HTTPS 下 TTFB 高，常因 TLS record 过大导致首响应被“卡住”。ssl_buffer_size 虽不属于 proxy 模块，但和 proxy 流程强耦合——它决定加密后第一个应用数据包的尺寸。
- 设为
1400或1460字节，匹配典型网络路径 MSS，避免分片和延迟确认 - 必须同步启用：
tcp_nodelay on;（禁用 Nagle）、ssl_protocols TLSv1.3;（1-RTT 握手）、ssl_stapling on;（跳过 OCSP 查询） - 可按路径差异化配置：API 接口用
1024，首页 HTML 用2048，大文件下载保留16k
启用长连接复用，削减 TCP 握手开销
高频访问下，反复建连是 TTFB 主要贡献者之一。proxy 模块通过 upstream 的 keepalive 实现连接池复用。
- 在 upstream 块中配置：
keepalive 32;（保持 32 个空闲连接） - 在 location 中强制 HTTP/1.1 并清理连接头：
proxy_http_version 1.1;+proxy_set_header Connection ""; - 实测显示，QPS 50 场景下 TTFB 可从 380ms 降至 210ms 左右
绕过响应缓冲，实现流式透传
即使后端已快速生成响应，Nginx 默认仍会攒够缓冲区（如 4k）或等待 10ms 再发——这叫 postpone_output 行为，虽不可直接配置，但可通过 proxy 设置规避。
- 对实时接口、SSE、健康检查等低延迟敏感路径，加：
proxy_buffering off; - 搭配
proxy_cache off;和proxy_http_version 1.1;，确保响应不滞留、不合并 - 若使用 gzip，建议关闭
gzip_vary off;并避免对小响应启用压缩，防止额外延迟
