ssl_handshake_timeout 主要影响 TLS 握手未完成连接的等待时长，设为1~2秒等过短值会增加握手失败率、浪费资源并拖累建连效率，合理范围为公网15–30秒、内网5–10秒，绝不建议≤2秒。
ssl_handshake_timeout 主要影响 TLS 握手未完成的连接在 Nginx 接收阶段的等待时长，它本身不直接限制并发连接数，但在高并发建连场景下，若设置过短，会显著增加握手失败率、浪费资源并间接拖累有效连接建立效率。
作用范围：仅针对“正在握手但尚未完成”的连接
该指令定义 Nginx 在 SSL/TLS 握手过程中，从收到 Client Hello 开始，到成功完成 Server Hello、密钥交换等关键步骤之间所允许的最大等待时间（单位秒）。一旦超时，Nginx 主动关闭该连接，返回 400 Bad Request 或直接断连（取决于日志与客户端行为）。
- 它不控制 TCP 连接建立（三次握手），只管 TLS 层协商
- 不影响已建立 TLS 连接的请求处理或 keepalive 超时
- 对使用 TLS 1.3 的快速握手更敏感——因为其握手本应极快，超时更容易暴露弱网络或客户端异常
高并发下设得太短：引发连锁负面效应
当大量客户端同时发起 HTTPS 请求（如秒杀、爬虫探测、CDN 回源洪峰），若 ssl_handshake_timeout 设置为 1~2 秒甚至更低：
- 网络延迟稍高（如跨洲际、移动弱网）的合法用户握手被粗暴中断，表现为“部分用户打不开网站”
- Nginx 持续分配 worker 进程资源（socket、内存、CPU）给新连接，却在几秒内又释放，造成高频的上下文切换和内存抖动
- 日志中
SSL_do_handshake() failed或ssl handshake timeout错误激增，掩盖真实业务问题 - 某些客户端（尤其旧版 Android WebView 或嵌入式设备）TLS 实现较慢，易被误杀
合理取值建议：平衡安全、兼容与性能
默认值是 30 秒（Nginx 1.19.0+），这个值在绝大多数生产环境中仍适用。调整时需结合实际链路质量：
- 公网服务：建议保持 15–30 秒；若观察到大量超时且集中在特定地区，优先排查网络而非砍超时
- 内网或边缘节点（如 Nginx 前置在 Kubernetes Ingress）：可降至 5–10 秒，因网络可控性高
- 绝对不要设为 ≤ 2 秒——这相当于主动拒绝弱网用户，且对防攻击收效甚微（真正的慢速攻击通常绕过 handshake 阶段）
- 配合
ssl_protocols和ssl_ciphers优化（如禁用 TLS 1.0/1.1、启用ssl_early_data）比调低 handshake timeout 更能提升建连效率
比调 timeout 更有效的高并发建连优化方向
真正制约 HTTPS 并发建连能力的，通常是底层资源与协议配置，而非 handshake 超时本身：
- 确保
worker_connections与系统ulimit -n匹配，并开启multi_accept on - 启用
ssl_buffer_size 4k减少小包数量，降低 TLS 分片开销 - 使用 OCSP Stapling（
ssl_stapling on）避免客户端额外 DNS 查询与证书校验延迟 - 对静态资源启用 HTTP/2 或 HTTP/3（需 QUIC 支持），复用连接，减少重复握手需求
