HttpClient请求超时后的连接状态与并发限流问题咨询

针对.NET场景下HttpClient超时与服务端并发限流不一致的问题，分点回答如下：

1. HttpClient超时后的连接处理逻辑 #

不同运行时、不同HTTP版本下行为有明确差异：

• .NET Framework场景：请求触发超时后，底层连接会直接标记为不可用，执行关闭逻辑，不会归还连接池复用，和早期Stack Overflow回答描述一致。
• .NET Core 2.1+、.NET 5/6/7/8（默认使用SocketsHttpHandler）场景：
  • 针对HTTP/1.1请求：不管是HttpClient.Timeout触发的全局超时，还是传入的CancellationToken触发的请求取消，只要请求超时发生在响应体未完全读取完成的阶段，对应连接会被标记为污染状态，直接销毁关闭，不会归还连接池——因为HTTP/1.1是基于字节流的复用，一旦请求中途取消，连接上的字节流边界已经错位，无法安全复用。
  • 针对HTTP/2、HTTP/3请求：这类协议支持多路复用，单请求超时只会重置对应的流，不会关闭整个TCP连接，没有其他异常的连接会正常留在连接池复用。

2. 连接关闭后的服务端感知逻辑 #

不存在服务端通过GC回收废弃连接的机制，连接生命周期由Web服务器的连接管理模块独立维护，感知逻辑和服务端实现强相关：

• 如果客户端正常执行TCP四次挥手发送FIN包，或者异常发送RST包断开连接，服务端内核层面会收到连接断开的信号，但业务层不会立刻收到通知：只有当服务端尝试对该连接执行读/写操作时，才会感知到连接已经断开。如果服务端当时正在执行耗时业务逻辑，没有操作Socket，就会一直认为请求还在处理中，持续占用并发计数。
• 服务端通常会配置两类超时回收僵尸连接：一类是请求处理超时（从接收请求开始算，超过阈值没处理完就主动断开），一类是空闲连接超时（连接上长时间没有数据传输就回收）。如果客户端超时时间短于服务端配置的上述超时值，就会出现客户端已经判定请求结束、服务端还占着并发额度的时间窗口，这也是触发429限流拒绝的核心原因。
• 不同Web服务器、反向代理的默认超时值差异很大：比如Kestrel默认请求超时为2分钟，Nginx默认代理读超时为60秒，部分自研网关的超时甚至可能设到5分钟以上。

3. 限流不一致问题的解决方案 #

这个问题本质是分布式场景下的客户端-服务端状态不一致问题，无法完全靠客户端配置100%规避，可按优先级落地以下方案：

• 核心原则：客户端配置的超时时间必须大于服务端接口的最长处理超时时间。比如服务端接口配置的最大处理时长为30秒，客户端超时至少要设到35秒以上，保证服务端先主动结束请求、释放并发计数，从根源上消除状态差窗口。
• 客户端侧留足并发冗余：不要把客户端最大并发数设成和服务端限流阈值一致，建议预留20%-30%的冗余额度给未及时释放的僵尸请求，比如服务端限流10的话，客户端最大并发设为7-8即可。
• 重试逻辑配合退避策略：所有重试必须加指数退避，不要收到429就立刻重试；如果服务端返回Retry-After响应头，严格按头指定的时间等待后再重试。幂等请求可以重试，非幂等请求要先查询请求执行状态再决定后续操作，避免重复写入。
• 可落地的服务端优化（如果可调整服务端配置）：
  • 开启客户端断连主动感知逻辑，比如Nginx默认proxy_ignore_client_abort off配置下，客户端断开后会立刻终止上游请求、释放并发额度；Kestrel可以配置连接检查回调，在客户端断连时立刻终止执行中的请求逻辑。
  • 给接口配置合理的最长处理超时，避免请求无限制执行占用并发额度。
  • 限流维度优先选择"活跃处理中请求数"而非TCP连接数，断连后第一时间从计数中移除对应请求。

误区纠正：.NET Core+场景下HTTP/1.1请求超时后确实会关闭连接，和.NET Framework的行为差异仅存在于HTTP/2+多路复用场景，问题核心从来不是客户端有没有关连接，而是服务端无法实时感知连接断开事件。

内容的提问来源于stack exchange，提问作者adrianm