ssl_handshake_timeout控制tls握手全过程最大等待时间，从clienthello开始到密钥协商完成为止；超时即断连返回400，不进入http处理流程；公网建议5–8秒，内网可设10秒，禁用或超15秒均不可取。
ssl_handshake_timeout 控制的是 TLS 握手全过程的最大等待时间，从 ClientHello 开始到密钥协商完成为止。它不控制连接空闲或会话复用，只在握手阶段生效——超时即断连，返回 400 或直接关闭连接，不会进入 HTTP 处理流程。
为什么这个参数容易被忽略但很关键
多数人只调 ssl_session_timeout 或 keepalive_timeout，却忽略了握手本身可能卡住。真实场景中，以下情况会导致握手迟迟无法完成：
- 客户端网络极差（如弱信号蜂窝网），ClientHello 半途丢失或重传严重
- 老旧设备或定制固件的 TLS 栈实现异常，响应延迟高达数秒甚至十几秒
- 中间设备（如企业防火墙、透明代理）对 TLS 握手包做深度检测或限速
- 客户端发起握手后意外中断（如 App 启动时快速切后台），服务端仍在等待完整消息
生产环境推荐设置范围
该参数需在“防资源耗尽”和“兼容边缘客户端”之间取得平衡：
- 面向公众互联网的 Web 服务：设为 5s–8s。覆盖 99.7% 正常握手（TLS 1.3 典型耗时
- 内网 API 网关或可信终端直连场景：可放宽至 10s，前提是后端有强健康检查与熔断机制
- 绝对不建议设为 0（禁用超时）或超过 15s。Nginx 官方明确警告：过长的握手等待会显著降低并发连接处理能力，高并发突发流量下易引发连接队列积压
排查是否真由握手超时导致问题
不能仅凭“连接失败”就断定是 ssl_handshake_timeout 触发。要结合日志精准定位：
- 开启 error_log warn，搜索 "ssl handshake timeout"。若高频出现（如单 worker 日均超 10 次），需进一步分析
- 对比 $ssl_protocol 和 $request_time 日志字段：筛选出 request_time > 1s 且 ssl_protocol 为空的请求，大概率是握手超时中断
- 注意区分：client_header_timeout 控制 HTTP 请求头接收，ssl_handshake_timeout 只管 TLS 层——两者都可能触发 400，但原因不同，需分开排查
验证配置是否真正生效
设完参数后必须验证，否则等于没配：
- 用 openssl s_client -connect example.com:443 -tls1_2 -debug 手动测试，观察各阶段耗时，定位是证书发送慢还是密钥交换卡顿
- 抓包验证：用 tcpdump 抓取 TLS 握手过程，确认 ServerHello 是否在设定时间内发出
- 模拟弱网测试：用 tc（traffic control）人为注入丢包或高延迟，观察 Nginx 是否按预期在 5–8 秒内断连
