ssl_buffer_size默认4KB会延迟首字节发送，因Nginx需等待填满缓冲区或响应结束才封装TLS记录；在低带宽高延迟场景下，该机制导致首包卡在缓冲区，增大TTFB；设为1400–1460字节能适配MSS，使首记录更快发出。
ssl_buffer_size 不是“越小越好”，但在低带宽、高延迟或首包敏感场景下，设为 1400–1460 字节确实能稳定压低首字节时间（TTFB），尤其对小响应体（如 API、图标、HTTP/2 首帧）效果明显。
为什么默认 4KB 在低带宽下反而拖慢首包
默认 ssl_buffer_size 通常为 4096 字节，Nginx 会等响应数据攒够这个量，或等到响应结束，才封装成一个 TLS record 发出。在低带宽链路（如移动网络、卫星链路）中，客户端首字节等待时间会被放大——不是因为发得慢，而是“卡在缓冲区没发”。
- 小响应（send_timeout 或响应关闭才发包
- HTTP/2 场景：首帧（SETTINGS、HEADERS）体积常仅几百字节，过大的 buffer 会让这些关键帧被延迟发送
- 与
tcp_nopush冲突：若启用该指令，Nginx 会进一步凑满 TCP MSS 才发包，此时调小ssl_buffer_size效果打折
1400–1460 字节怎么选：看你的网络路径 MTU
目标是让单个 TLS record 明文 + TLS 头（≈41 字节）+ TCP/IP 头（≈40 字节）能塞进一个无分片的 IP 包。以太网标准 MTU=1500，MSS≈1460；部分运营商或隧道链路（如 PPPoE、IPv6）MTU 可能低至 1400 或 1360。
- 优先试
ssl_buffer_size 1400;：兼容性最广，适合不确定链路 MTU 的场景 - 确认路径无分片后可试
ssl_buffer_size 1460;：Wireshark 抓包看 TLS record length 是否稳定 ≤1460，且 TCP 层无 “TCP segment of a reassembled PDU” 标记 - 避免设为 512 或 1k：record 数量激增，TLS 加解密开销上升，小包风暴可能压垮边缘路由器
必须配合的三项配置，否则调参无效
ssl_buffer_size 是 TLS 记录层开关，但最终发包行为还受传输层和协议栈控制。不配齐以下三项，实测 TTFB 可能毫无改善，甚至更差：
-
tcp_nodelay on;：禁用 Nagle 算法，确保小包不等待合并，与小ssl_buffer_size协同生效 -
ssl_protocols TLSv1.3;：TLS 1.3 默认 1-RTT 握手，首包逻辑更干净；若必须支持 TLS 1.2，至少禁用TLSv1和TLSv1.1 -
ssl_session_cache shared:SSL:10m;：保证会话复用率，避免频繁完整握手干扰首包时序；10m ≈ 4000 会话，足够中小规模服务
怎么验证改对了：别只看 curl -w
curl -w "%{time_starttransfer}\n" -s -o /dev/null https://yoursite.com/api/health 能看 TTFB，但它是端到端结果，受 DNS、TCP 建连、服务器处理等干扰。真要确认 ssl_buffer_size 生效，得看 TLS 层：
- 用
openssl s_client -connect yoursite.com:443 -tls1_3连上后手动发请求，观察返回的SSL handshake has read ... bytes and written ... bytes中“written”是否明显变小 - Wireshark 过滤
tls.record.length ，对比修改前后首条 TLS record 的 length 字段值 - 注意：若后端是 fastcgi/uwsgi/proxy_pass，且启用了
proxy_buffering off;，首包行为还受上游响应流控影响，此时ssl_buffer_size作用会被削弱
真正难调的不是数值本身，而是你得在 TLS 记录大小、TCP 发包时机、后端响应节奏三者间找平衡点——尤其是当业务混用大静态资源和小 API 时，单一 ssl_buffer_size 值很难通吃，这时候得考虑按 location 分流设置。
