将 ssl_buffer_size 设为 1400 字节并同步启用 tcp_nodelay on、ssl_protocols tlsv1.3 和 ssl_stapling on，可在移动端弱网下显著降低 ttfb；因该值精准匹配典型链路 mss（1360–1400），避免 tls record 分片与 ack 延迟。
直接把 ssl_buffer_size 设为 1400 字节，并同步开启 tcp_nodelay on;、ssl_protocols TLSv1.3; 和 ssl_stapling on;，就能在移动端弱网下显著压缩首字节时间（TTFB）。这不是“越小越好”，而是让首个 TLS record 明文长度精准匹配典型链路 MSS（常被压至 1360–1400），确保一包发完、不分片、不卡 ACK。
为什么 1400 是移动端首选
移动网络路径中，基站、运营商网关或云负载均衡常将 TCP MSS 压低到 1360–1400 字节。若 ssl_buffer_size 超过该值，加密后的 record 就会被内核拆成两个 TCP 段：
- 第一段发出后，第二段可能等 ACK 或超时才发，弱网下 TTFB 多拖 200ms+
- 1400 字节留出足够余量（TLS 头约 5–50 字节 + 压缩波动），刚好塞进一个 TCP 段
- 实测在 4G/5G 切换、Wi-Fi 信号波动场景中，比默认 4096 缩短首包到达时间 30%–50%
按响应类型微调更稳
- 纯 API 接口（如
/api/login，返回 JSON ≤800 字节）：可试ssl_buffer_size 1024;，但需确认响应体长期稳定，否则 801 字节就触发二次缓冲 - 首屏 HTML（含内联 CSS/JS，实测 1.2–1.8KB）：优先用
1400；若内容动态性强、Gzip 压缩率波动大，升至2048避免 record 数从 1 跳到 2 - 静态资源（
.js、.css、字体等）：保持4096或更高，首包不敏感，吞吐优先
三项必须同步启用的配置
-
tcp_nodelay on;：禁用 Nagle 算法，防止小 record 在 TCP 层排队等待拼包 -
ssl_protocols TLSv1.3;：强制 1-RTT 握手，让ssl_buffer_size的优化真正作用于业务响应，而非被握手耗时掩盖 -
ssl_stapling on;：服务端主动携带 OCSP 响应，避免客户端握手后立即发起证书状态查询，造成首包逻辑阻塞
验证是否真正生效
- 抓包看
TLS Application Datarecord 的Length字段是否稳定在设定值 ±50 字节内（Wireshark 过滤tls && tcp.len > 0） - 检查 TLS
Finished后第一个 TCP 包是否已携带HTTP/1.1 200 OK或 HTTP/2HEADERS帧 - 用
curl -w "TTFB: %{time_starttransfer}\n" -k https://yoursite/在模拟弱网（如tc qdisc add dev eth0 root netem delay 100ms loss 2%）下多轮采样对比
不复杂但容易忽略
