client_header_timeout不能防御慢速TLS握手攻击，它仅在TLS握手完成后计时，用于控制HTTP请求头接收超时；真正防御慢速TLS握手的是ssl_handshake_timeout，需设为5–15秒并配合协议优化与连接限流。

client_header_timeout 不能规避慢速 TLS 握手攻击。

它只在 TLS 握手完成之后才开始计时，作用对象是 HTTP 请求头（比如 GET / HTTP/1.1\r\nHost: example.com\r\n...），从收到第一个字节起，到完整读取 \r\n\r\n 分隔符为止。而慢速 TLS 握手发生在更底层：TCP 连接建立后、加密协商尚未结束的阶段——此时 Nginx 还没进入 HTTP 解析流程，client_header_timeout 根本不生效。

真正用来防御慢速 TLS 握手的，是 ssl_handshake_timeout。

---

✅ 正确应对慢速 TLS 握手的关键配置

• 设 ssl_handshake_timeout 为合理值
  推荐 10s：覆盖绝大多数正常客户端（含弱网重试），又能快速中断每秒只发几个 TLS 记录字节的恶意握手（如 sslsplit、slowhttptest 模拟的慢握手）。

  • 内网或可信终端可压至 5–7s
  • 面向老旧设备或高丢包链路可放宽至 15s

• 禁用老旧协议，缩短握手往返

  

  Nginx Hosting

  通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

  下载

  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers off;  # 启用 TLS 1.3 的 1-RTT/0-RTT 优势

• 限制单 IP 新建握手频率
  防止握手洪泛耗尽 worker：

  limit_conn_zone $binary_remote_addr zone=sslhandshake:10m;
  limit_conn sslhandshake 5;  # 单 IP 每秒最多 5 次新握手

• 启用 multi_accept 并调高 worker_connections
  避免握手积压阻塞 accept 队列，尤其在高并发入口层。

• 开启日志监控异常握手
  在 error_log 中关注：

  SSL_do_handshake() failed
  no suitable signature algorithm
  client sent invalid compressed data

  结合 $ssl_protocol 和 $remote_addr 做 fail2ban 封禁。

---

❌ 为什么 client_header_timeout 不该被误用

• 默认值通常为 60s，对慢速 TLS 握手完全无效
• 若错误地把它调低（如设成 3s），只会误杀合法 HTTPS 请求：TLS 握手本身要耗时（通常 50–200ms），加上网络抖动，实际留给 HTTP 头的时间可能不足，导致大量 408 错误
• 它防的是“慢速头攻击”（Slow Headers），不是“慢速 TLS 握手”

---

? 如何验证 ssl_handshake_timeout 是否生效

用 openssl s_client 或 slowhttptest 模拟超时握手：

# 模拟握手延迟 >10 秒 → 应被 Nginx 主动断开，而非等待超时
slowhttptest -c 1 -H -i 10 -r 1 -t GET -u https://your-api.com/ -x 10

观察连接是否在设定秒数内被 RST 中断，并检查 error log 是否有 SSL handshake timeout 类日志。

不复杂但容易忽略