ssl_buffer_size不宜设为4KB，因其会导致小TLS握手包（如300–800字节的ClientHello）被填充或分片，触发TCP重传或PMTUD失败，增加TTFB；推荐1350–1400以适配MTU并留余量。
ssl_buffer_size 为什么不能随便设成 4KB？
因为 TLS 握手阶段的初始数据包（ClientHello、ServerHello 等）通常远小于 1.5KB，而 ssl_buffer_size 控制的是 OpenSSL 写入 socket 的单次缓冲区上限。设得过大（如 4KB），会导致小握手包被强行填充、跨 MTU 分片，触发 TCP 层重传或路径 MTU 发现（PMTUD）失败，反而增加首字节时间（TTFB）。
常见错误现象：curl -v https://example.com 显示 TLS 握手耗时突增 100–300ms；Wireshark 抓包可见 ClientHello 被拆成两个 IPv4 片段（Flags: 0x2000, "Don't Fragment" 未置位但实际分片）。
- 默认值是
4096，适合长连接大流量场景，但对首次 TLS 握手不友好 - 真实有效负载（ClientHello）一般在 300–800 字节之间，取决于证书链长度、扩展数量（如 ALPN、SNI、OCSP Stapling）
- 若后端用 ECDSA 证书 +
ssl_ecdh_curve secp384r1，ClientHello 可能更小；若启用了多个ssl_trusted_certificate或 OCSP 响应内嵌，则可能接近 1200 字节
怎么根据 MTU 算出安全的 ssl_buffer_size？
不是直接套用 MTU 值，而是留足 IP/TCP/TLS 头部开销后，确保单个 TCP 段不超 MTU。典型以太网 MTU=1500，减去：
- IPv4 头部：20 字节（无选项）
- TCP 头部：20 字节（无 SACK、TS 等扩展）
- TLS 记录头：5 字节（Content Type + Version + Length）
- 实际可用载荷 ≈ 1500 − 20 − 20 − 5 = 1455 字节
但还要预留至少 100 字节余量防扩展字段浮动，所以推荐值是 1350～1400。实测中 1350 在绝大多数公网路径下最稳，既避免分片，又不会因过小导致 record 数量激增（影响 TLS 1.3 early data 吞吐）。
验证方法：tcpdump -i any 'port 443 and tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -w handshake.pcap，然后用 Wireshark 查看第一个 TLS ClientHello 的 TCP payload length —— 它应 ≤ ssl_buffer_size 且未分片。
nginx 配置里怎么写才真正生效？
ssl_buffer_size 必须放在 server 块或 http 块中，且仅对启用 SSL 的 listen 指令起作用；它不会继承自上级块的非 SSL 上下文，也不会影响已建立连接的后续应用数据帧（那些由 TCP 栈和 tcp_nodelay 控制）。
- 错误写法：
location / { ssl_buffer_size 1350; }→ 不生效，该指令不在 location 作用域 - 正确写法：
server { listen 443 ssl; ssl_buffer_size 1350; ... } - 若使用
listen 443 ssl http2;，该设置同样适用；HTTP/2 帧封装在 TLS 记录内，不受影响 - 注意：OpenSSL 1.1.1+ 才完全支持该指令；OpenSSL 1.0.2 下设了也无效，Nginx 日志会报
nginx: [warn] ssl_buffer_size is not supported with this version of OpenSSL
什么时候反而不该调小 ssl_buffer_size？
当你的服务大量承载 TLS 1.3 的 0-RTT 请求，且客户端频繁复用 session ticket（比如移动端 App 长连接保活），此时首包之后的早期数据（early data）可能连续发送多段小 record。这时过小的 ssl_buffer_size（如 512）会导致 record 数量翻倍，增大 TLS 层开销和 CPU 加密调用频次。
- 典型场景：iOS App 使用 NSURLSession 默认配置访问 API，开启
ssl_early_data on，观察到 Nginx 的openssl.crypto.encrypt调用次数上升 20%+ - 折中方案：对首次握手敏感的入口（如 landing page、login）用
1350；对 API 子域名单独配server块，设为2048并配合ssl_buffer_size 2048+tcp_nodelay on - 别忽略 CDN：如果前端有 Cloudflare / AWS CloudFront，它们已做 TLS 层优化，你源站再调
ssl_buffer_size效果有限，甚至可能因双层缓冲加剧延迟
真正起作用的永远是端到端路径中最窄的那个 MTU，而不是你本地 ifconfig 看到的 1500。抓包看第一个 ClientHello 是否分片，比任何“金律”都可靠。
