小 ssl_buffer_size 能治卡顿，因其控制首个 TLS record 明文长度，设为 1400 字节可适配 MSS、避免延迟 ACK 和空等，需配合 tcp_nodelay on、TLSv1.3 及 OCSP Stapling 协同生效。
在高延时无线网络（如弱信号 4G/5G、卫星链路、偏远地区 Wi-Fi）下，HTTPS 请求出现间歇性卡顿，往往不是带宽不足，而是 TLS 首个应用数据记录（record）迟迟发不出去——ssl_buffer_size 就是控制这个“第一块加密数据”明文长度的关键开关。
为什么小 ssl_buffer_size 能治卡顿
无线链路高延迟（RTT 常超 100ms）会放大两个底层机制的副作用：
- TCP 延迟确认（Delayed ACK）：接收方默认等 40–200ms 或第二个包到达才回 ACK；若首个 TLS record 过大（如默认 4KB），Nginx 可能因没填满 buffer 而暂停发送，导致首包卡住几十毫秒
- 握手后空等窗口：TLS 握手刚完成，但后端响应还没生成完（比如查数据库慢了点），大 buffer 会让 Nginx “攒着不发”，而小 buffer 允许用已有的几百字节立即封装成 record 发出
- 丢包重传更高效：小 record（如 1400 字节）重传快、成功率高；大 record（4KB）一旦丢一个，整块重发，加剧卡顿感
推荐配置值与实操要点
目标是让首个 TLS record 明文 ≤ 当前路径 MSS（通常 1400–1460），确保它能塞进一个 TCP 段，不被分片、不触发等待：
- 首选 1400：适配标准以太网路径（MTU=1500 → IP 头 20 + TCP 头 20 = 1460 可用），留 60 字节余量应对 TLS 头和 padding 波动
- 若实测路径 MSS 更小（例如经云厂商 LB 后降到 1360），可设为 1300；可用
tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0' -c1查 SYN 包中通告的 MSS 值 - 纯轻量 API（返回 JSON < 800B）可试 1024，进一步缩短 record 封装耗时
- 避免 512：过小会显著增加 record 数量，带来额外加解密开销和头部带宽浪费，收益递减
必须同步开启的配套配置
单独调小 ssl_buffer_size 效果有限，三者缺一不可：
- tcp_nodelay on;：禁用 Nagle 算法，防止多个小 TLS record 在 TCP 层被合并等待
- ssl_protocols TLSv1.3;：强制使用 TLS 1.3，1-RTT 握手比 TLS 1.2 快 100–300ms，让 ssl_buffer_size 的收益真正落地
- ssl_stapling on; ssl_stapling_verify on;：启用 OCSP Stapling，避免客户端阻塞验证证书吊销状态
按业务场景分级配置（推荐）
不必全局一刀切，用 location 分级更稳妥：
- 对移动端页面、API 接口等首包敏感路径：
location /api/ { ssl_buffer_size 1400; }location /mobile/ { ssl_buffer_size 1400; } - 对大文件下载、视频流等吞吐优先路径：
location /download/ { ssl_buffer_size 16k; } - 主 server 块保持通用安全基线：
ssl_protocols TLSv1.3;tcp_nodelay on;ssl_stapling on; ssl_stapling_verify on;
