ssl_buffer_size的核心作用是控制TLS记录层单个明文record的最大长度；它不改变握手，仅影响握手完成后首个HTTP响应的分片与发送方式，需按API（首字节敏感，推荐1024/1400）或视频（吞吐优先，推荐4096/8192）差异化配置，并同步启用tcp_nodelay、TLSv1.3和OCSP装订。
ssl_buffer_size 的核心作用，是控制 TLS 记录层单个明文 record 的最大长度。它不改变握手过程，只影响“握手完成后第一个 HTTP 响应”如何被切分、封装和发出。对视频下载和 API 接口这两类典型业务，优化目标截然不同：API 要抢首字节，视频要拼吞吐量。调错值不仅无效，还可能拖慢首包或浪费 CPU。
API 类业务：小响应体 + 高首包敏感度
登录接口、列表请求、状态查询等，首响应常为几百字节的 JSON（如 {"code":0,"data":[...]}）。默认 4KB 缓冲会让 Nginx 等数据填满或响应结束才发包，在弱网或高延迟链路下，首字节可能卡住 20–50ms。
- 推荐值：1024 或 1400 字节 —— 匹配常见路径 MSS（1460），确保首 record 加上 TLS 头（约 5 字节）和 TCP/IP 头后，仍能塞进一个无分片 TCP 段
- 1024 更适合稳定 ≤800 字节的轻量接口；1400 是公网通用起点，兼顾余量与效率
- 避免设为 512：record 数量翻倍，TLS 头开销和加密调用频次上升，边缘设备可能丢包
视频/大文件类业务：大响应体 + 吞吐优先
MP4 分片、HLS ts 文件、ZIP 下载等，首响应虽小（如 200 字节的 HTTP header），但后续数据流巨大。此时首包延迟影响微乎其微，而 record 封装次数、CPU 加密负担、系统调用开销成为瓶颈。
- 推荐值：保持默认 4096，或设为 8192 —— 减少 record 总数，降低单位字节的 TLS 处理成本
- 设为 1400 对整体传输耗时几乎无改善，反而增加约 2.5% 的 TLS 头带宽（每 record 固定 5 字节头）和更多加密运算
- 此场景下，tcp_nopush on 的收益远大于 ssl_buffer_size 微调，应优先启用
必须同步生效的三项配置
单独改 ssl_buffer_size 几乎无效，它依赖底层传输行为协同：
- tcp_nodelay on;：禁用 Nagle 算法，否则小 record 仍会被 TCP 层合并等待，首包延迟照旧
- ssl_protocols TLSv1.3;：1-RTT 握手让首应用数据更早进入 pipeline，使 buffer 策略可测、可控
- ssl_stapling on; ssl_stapling_verify on;：避免客户端因查 OCSP 而阻塞首包，否则再小的 buffer 也发不出
进阶：按 location 差异化配置（Nginx 1.25.1+）
混合业务可精细化控制，无需拆服务：
- location /api/ { ssl_buffer_size 1400; } —— API 路径强制小缓冲
- location /video/ { ssl_buffer_size 8k; proxy_buffering off; } —— 视频路径大缓冲 + 关闭代理缓冲，减少内存拷贝
- location ~ \.(js|css|woff2)$ { ssl_buffer_size 4k; } —— 静态资源取中间值，平衡首字节与复用率
