send_timeout仅控制已建立连接后发送响应的空闲超时，无法感知TLS握手异常；应使用ssl_handshake_timeout、限连限流及OpenResty/Lua等方案实现真正的加密链路熔断。
真正需要的是 TLS 层和连接管理层面的主动防护机制，而非依赖 `send_timeout`。以下是更合理、可落地的调优与替代方案：
明确 send_timeout 的真实作用与局限
`send_timeout 30;` 表示：Nginx 向客户端发送响应期间，若连续 30 秒未成功发出任何数据（例如因客户端接收缓冲区满、网络中断、中间设备拦截等），则主动关闭该连接。
- 它发生在 HTTP 响应体写入阶段，对 TLS 握手、证书校验、密钥交换等前期加密流程完全无感知
- 无法区分“慢客户端”和“僵尸加密链路”（如 TLS ClientHello 发出后无响应、ServerHello 后卡在 ChangeCipherSpec）
- 不会触发日志标记为“TLS 异常”，也不会联动限流或熔断策略
识别并阻断僵尸加密链路的关键手段
僵尸加密链路通常表现为：TCP 连接已建立（SYN/SYN-ACK/ACK 完成），但 TLS 握手停滞在某一步（如无 ClientHello、ClientHello 无回应、CertificateVerify 超时）。此时需在更早阶段干预：
- 启用 `ssl_handshake_timeout`（Nginx 1.19.0+）：直接限制 TLS 握手总耗时，超时即断连并记录 `SSL_do_handshake() failed`。这是最贴近需求的原生配置
- 调小 `keepalive_timeout` + 禁用长连接复用：对高风险入口（如公网 API），设 `keepalive_timeout 5s;`，避免僵尸连接长期占用 worker 进程
- 结合 `limit_conn` 与 TLS SNI 或 Client IP：对单个 SNI 域名或 IP 地址限制并发 SSL 握手请求数，防握手风暴耗尽资源
- 使用 `ngx_http_ssl_module` 日志变量做异常聚合：通过 `$ssl_protocol`、`$ssl_cipher`、`$status` 配合日志分析，识别频繁失败的 cipher suite 或协议版本，针对性屏蔽
进阶：用动态模块实现真正的加密链路熔断
若需精细化控制（如连续 3 次 TLS 握手失败即封禁该 IP 5 分钟），标准 Nginx 不支持，需扩展：
- 使用 OpenResty + lua-resty-limit-traffic：在 `ssl_certificate_by_lua*` 阶段捕获 `ssl:handshake()` 异常，记录失败次数并触发限流/封禁
- 接入 eBPF/XDP 层检测（如 Cilium）：在内核态识别 TLS 握手异常包模式（如重复 ClientHello、无 ServerHello 回复），毫秒级丢弃
- 部署专用 TLS 代理（如 Envoy + Tap Filter）：开启 TLS 监控，将握手指标（handshake_time_ms、failure_reason）上报 Prometheus，配合 Alertmanager 触发自动化处置
不复杂但容易忽略：僵尸加密链路的本质是 TLS 协议栈卡死，不是 HTTP 数据发送慢。把防御点放在 `send_timeout` 上，就像用灭火器防电路短路——方向错了。
