将ssl_buffer_size设为1400字节并同步启用tcp_nodelay on、ssl_protocols tlsv1.3和ssl_stapling on，是降低tls首包延迟最有效组合；它确保首个http响应“一包发出”，避开分片、延迟确认和nagle合并，适配弱网常见mss（1360–1400），需通过抓包与ttfb实测验证。
直接把 ssl_buffer_size 设为 1400 字节，并同步开启 tcp_nodelay on、ssl_protocols TLSv1.3 和 ssl_stapling on，是减少 TLS 封包延迟最有效且可落地的组合。它不加快握手本身，而是让握手完成后的首个 HTTP 响应“一包发出”，避开分片、延迟确认和 Nagle 合并三重卡点。
为什么 1400 是关键值
公网路径实际 MSS（最大分段长度）常为 1360–1400 字节（受隧道封装、云厂商 LB、运营商网关影响）。设为 1400 可确保：
- TLS record 明文 + 5 字节头 + 加密填充 ≈ 1405 字节，稳居单个 TCP 段内，不触发 IP 分片
- 避免因等待填满缓冲区而延迟发送——比如一个 1.2KB 的 HTML 首响应，在默认 4096 缓冲下可能卡住几十毫秒
- 弱网（4G/5G、偏远 Wi-Fi）下，首包不被拆分，重传更快、成功率更高
必须配套启用的核心配置
单独改 ssl_buffer_size 几乎无效，以下三项需同时生效：
-
tcp_nodelay on;：禁用 Nagle 算法，防止多个小 TLS record 在 TCP 层被合并或等待 200ms 才发 -
ssl_protocols TLSv1.3;：强制 1-RTT 握手，缩短握手耗时，让 buffer 优化真正作用于业务响应 -
ssl_stapling on; ssl_stapling_verify on;：服务端主动携带 OCSP 响应，避免客户端额外查询阻塞首包
按业务路径分级设置更精准
不必全局一刀切，Nginx 1.11.5+ 支持在 location 块中覆盖：
-
location /api/ { ssl_buffer_size 1024; }：轻量 JSON 接口（≤800B），进一步压缩首 record -
location = / { ssl_buffer_size 1400; }：首页 HTML（含 meta/title/内联资源），适配多数弱网路径 -
location ~ \.(js|css|woff2|png)$ { ssl_buffer_size 4096; }：静态资源走吞吐优先，首包不敏感
验证是否真正生效
不能只看配置是否加载，要抓包确认行为变化：
- 在 Nginx 出口用
tshark -i any 'tls.record.content_type == 23 and tcp.len > 0'抓包，检查 TLS Application Data 的 Length 是否稳定在 1395–1405 字节 - 重点观察 TLS
Finished后的第一个 TCP 包是否已携带 HTTP 响应首行（如HTTP/1.1 200 OK） - 用
curl -w "TTFB: %{time_starttransfer}\n" -sk https://domain/api/health多轮实测，对比调优前后变化
