Nginx中HTTPS短连接引发TCP RST问题的分析与解决方案

问题现象

在使用Nginx作为HTTPS服务器时，当客户端使用短连接（通过Connection: close头或HTTP/1.0协议）时，Nginx会在连接关闭过程中发送TCP RST（重置）包。这一现象在AWS Route53健康检查和负载均衡器目标组健康检查场景中尤为明显，尽管所有健康检查都返回200 OK状态码，但网络抓包显示存在大量TCP RST包。

问题重现

通过以下curl命令可以重现该问题：

curl https://example.com -H "Connection:close" -vk

抓包分析显示，完整的TLS握手和HTTP通信过程正常，但在连接关闭阶段，Nginx会发送TCP RST包。具体表现为：

1. Nginx发送HTTP 200响应、SSL关闭通知和TCP FIN包
2. 客户端发送ACK确认，然后发送SSL关闭通知
3. Nginx响应TCP RST
4. 客户端发送FIN ACK
5. Nginx再次响应TCP RST

技术分析

深入分析发现，Nginx在处理HTTPS连接关闭时存在以下行为：

1. SSL关闭通知处理：Nginx默认设置c->ssl->no_wait_shutdown = 1，表示不等待对端的SSL关闭通知。这是基于大多数浏览器不发送"close_notify"警报的假设（尽管Opera和较新版本的Mozilla会发送）。

2. 内核层行为：当客户端遵循RFC 2246标准发送SSL关闭通知时，Nginx应用层不处理此消息，而是交由内核处理，导致内核生成TCP RST。

3. 套接字状态转换：

   • 第一个RST是由于PSH包发送到TIME_WAIT状态的套接字
   • 第二个RST是由于ACK包发送到已销毁的套接字

RFC标准解读

根据RFC 8446第6.1节规定：

双方不需要等待接收"close_notify"警报就可以关闭连接的读取端，尽管这样做可能会引入截断的可能性。

这表明Nginx当前的行为在标准允许范围内，但从用户体验角度并非最佳实践。

解决方案

1. 推荐方案：在Nginx配置中添加以下指令，强制启用连接延迟关闭：

lingering_close always;

2. 代码层面改进建议：虽然当前行为符合标准，但从服务器优雅性和兼容性考虑，可以移除no_wait_shutdown设置，让Nginx能够处理SSL关闭通知，避免产生TCP RST。

影响评估

该问题主要影响以下场景：

1. 使用短连接的HTTPS客户端（如健康检查服务）
2. 严格遵循TLS标准的客户端实现
3. 对TCP连接状态有严格监控的网络环境

最佳实践

对于生产环境中的Nginx HTTPS服务，特别是需要与各类客户端和健康检查服务交互的场景，建议：

1. 始终配置lingering_close always
2. 监控网络中的RST包数量
3. 对于关键业务，考虑使用HTTP/2或保持长连接
4. 在健康检查配置中，如果可能，使用TCP检查而非HTTPS检查

通过以上配置和优化，可以显著提高Nginx HTTPS服务的兼容性和稳定性，避免不必要的连接重置问题。