ssl_buffer_size的核心目标是让首个TLS record刚好塞入一个TCP段，避开分片、Nagle算法和延迟确认；黄金法则是设为略小于或等于路径MSS（通常1400–1460字节），并须同步开启tcp_nodelay、TLSv1.3及OCSP Stapling。
ssl_buffer_size 的核心目标不是“越小越好”，而是让首个 TLS record 刚好塞进一个 TCP 段，避开分片、Nagle 算法和延迟确认这三类首包杀手。它的黄金法则是：**设为略小于或等于网络路径的可用 MSS（通常就是 1400–1460 字节）**。
为什么盯住 MSS，而不是 MTU？
MSS（Maximum Segment Size）是 TCP 层能塞进单个段的最大数据长度，不包括 IP 和 TCP 头部；MTU（1500 字节常见）是链路层最大传输单元，包含所有头部。实际可用的应用数据空间 ≈ MTU − 20（IP头） − 20（TCP头） = 1460 字节。若 ssl_buffer_size > 1460，哪怕只大 1 字节，Nginx 加密后的 record 就可能被 TCP 栈拆成两个段——首段发完后，第二段要等 ACK 或超时才发，首包时间直接拉长。
如何确定你的真实 MSS？
- 本地直连环境（如 IDC 内网）：默认按 1460 处理即可，以太网标准 MTU 下最稳妥
- 经公网或云厂商 LB（如阿里云 SLB、腾讯云 CLB）：部分中间设备会压低 MSS（如降到 1360），建议用 tcpdump 或 Wireshark 抓客户端到 Nginx 的 SYN 包，看 TCP Options 中的 MSS 值
- 启用了 IPv6 或隧道（如 GRE、IPsec）：MSS 会进一步缩减，必须实测；可用命令
ping -M do -s 1472 example.com探测路径 MTU（1472 + 28 字节头 = 1500）
配置值选择指南（按响应特征）
- API 服务 / JSON 首响应 ≤ 1KB：设为 1024 或 1400。短 record 能在 TLS 握手完成瞬间就封装发出，首字节延迟降低明显
- 首屏 HTML（含内联 CSS/JS，约 1.2–1.8KB）：推荐 2048。比 1400 更容错，避免因压缩或动态内容微小波动导致 record 数激增
- 纯静态资源（图片、字体、大 JS）且首包不敏感：可维持默认 4096，节省 TLS 头开销与 CPU
必须同步做的三件事
- 开启 tcp_nodelay on;：禁用 Nagle 算法，防止小 TLS record 在 TCP 层被合并等待
- 确保使用 TLSv1.3：1-RTT 握手大幅缩短前置耗时，让 ssl_buffer_size 的收益更可测
- 搭配 ssl_stapling on;：避免客户端自行查询 OCSP 导致首包阻塞，否则 buffer 调优白做
