https握手失败时nginx应禁用reset_timedout_connection、精简lingering_close参数，并通过ssl_preread和debug_ssl日志定位根本原因，而非依赖lingering_close处理握手阶段问题。
HTTPS 握手失败时，Nginx 若直接关闭套接字，容易触发 RST，导致客户端无法收到明确错误（如 400 Bad Request 或 TLS alert），甚至被中间设备拦截或误判为攻击。lingering_close 不是为 HTTPS 握手阶段设计的——它只在 HTTP 请求已开始处理、进入响应阶段后才生效。但正因如此，**调优 lingering_close 的关键，是在 TLS 握手失败后、HTTP 层尚未介入前，确保底层 TCP 连接仍能被安全、可控地回收，避免残留连接堆积或 RST 泛滥**。
明确 lingering_close 的作用边界
lingering_close 仅对已完成 TLS 握手、已解析出有效 HTTP 请求（哪怕只是部分）的连接起效。它不干预：
- TLS 握手未完成（如 ClientHello 后证书校验失败、SNI 不匹配、协议版本不支持）
- TLS Alert 发送后立即断连（如 handshake_failure、bad_certificate）
- HTTP 请求头未收全即中断（如超时、过大、格式错误）
这些场景下，连接由 OpenSSL 或 Nginx SSL 模块直接终止，lingering_close 完全不参与。因此，调优目标不是“让 lingering_close 处理握手失败”，而是：**避免握手失败后的连接被粗暴 close()，同时防止 linger 行为干扰真正需要它的 HTTP 响应阶段**。
HTTPS 场景下必须关闭 reset_timedout_connection
当 TLS 握手超时（如客户端迟迟不发 ClientHello 或中途卡住），Nginx 默认可能触发 reset_timedout_connection on（尤其在高负载或配置疏漏时）。这会直接向客户端发 RST，掩盖真实原因，且与后续 HTTP 层的 lingering_close 逻辑冲突。
务必在 http 块中显式设置：
reset_timedout_connection off;这样，握手超时连接会走 FIN 正常关闭路径，既减少 RST 报文，也避免与 lingering_close 的等待逻辑产生竞争或资源争用。
精简 lingering_time 和 lingering_timeout，降低 TLS 失败连接的滞留风险
虽然 lingering_close 不处理握手失败，但若某连接侥幸通过 TLS 握手、却在读取首行或 headers 时出错（例如 malformed request），它就会进入 lingering 状态。此时过长的 linger 时间（如默认 30s）会让本该快速释放的失败连接白白占用 worker 连接数。
推荐配置（适用于 HTTPS 服务）：
- lingering_close on;（保持启用，覆盖绝大多数真实 HTTP 错误场景）
- lingering_time 5;（总等待上限缩至 5 秒，足够传完短错误页，又不拖慢连接回收）
- lingering_timeout 1000;（单次 recv 超时设为 1 秒，平衡探测灵敏度与系统调用开销）
该组合可显著缩短异常请求的 socket 占用时间，间接提升 TLS 握手失败连接的总体周转率——因为更少的 linger 连接意味着更多空闲 fd 可用于新握手。
配合 ssl_preread 和日志定位真实握手问题
要真正保障 HTTPS 握手失败时的安全关闭，需跳出 lingering_close 的范畴，从源头增强可观测性：
- 启用 ssl_preread on;（在 stream 模块），可在不终止 TLS 的前提下提取 SNI、ALPN 等信息，便于在握手早期做日志记录或限流
- 开启 error_log ... debug_ssl;，捕获 OpenSSL 层级的握手错误（如 SSL_R_UNKNOWN_PROTOCOL、SSL_R_NO_SHARED_CIPHER）
- 在 access_log 中添加 $ssl_protocol $ssl_cipher $ssl_handshake_status，区分是协议不兼容、证书问题还是客户端中断
掌握这些信息后，你就能判断：哪些失败该由防火墙拦截，哪些该返回明确 TLS alert，哪些只需静默断连——而不是依赖 lingering_close 去“补救”本不该它处理的阶段。
