默认 SocketsHttpHandler 连接复用失败因不满足同源、Keep-Alive 启用、连接未超时三条件；MaxConnectionsPerServer 默认为2，且无主动保活机制，空闲连接易被中间设备断开。
为什么默认的 SocketsHttpHandler 会连接复用失败？
不是所有 HTTP/1.1 请求都会自动复用连接，关键看是否满足「同源 + Keep-Alive 启用 + 连接未超时」三个条件。默认情况下 SocketsHttpHandler 的 MaxConnectionsPerServer 是 2，且 KeepAlivePingDelay 和 KeepAlivePingTimeout 均为 TimeSpan.Zero（即不主动保活），遇到中间代理或负载均衡器主动断连时，连接池里的空闲连接可能已失效，下次复用就会触发 SocketException 或重连开销。
实操建议：
-
MaxConnectionsPerServer应根据后端服务能力调高（如 50～200），但避免盲目设为int.MaxValue，否则在突发流量下易耗尽本地端口或触发服务端限流 - 启用主动心跳：设置
KeepAlivePingDelay = TimeSpan.FromSeconds(30)和KeepAlivePingTimeout = TimeSpan.FromSeconds(5)，让连接池定期探测远端存活状态 - 确保服务端也开启
Keep-Alive（如 Nginx 默认开启，但需检查keepalive_timeout是否大于客户端的PooledConnectionLifetime）
SocketsHttpHandler 连接池生命周期怎么控制？
连接池里每个连接的实际存活时间由三个参数协同决定：空闲超时、总生命周期、以及服务端响应头中的 Connection: keep-alive 指令。若不显式配置，PooledConnectionIdleTimeout 默认是 2 分钟，PooledConnectionLifetime 是 2 分钟，意味着连接最多复用 2 分钟，之后强制新建。
实操建议：
- 若后端稳定且无连接泄漏风险，可将
PooledConnectionIdleTimeout设为TimeSpan.FromMinutes(5)，减少频繁建连；但不要超过服务端的keepalive_timeout（常见为 60～75 秒） -
PooledConnectionLifetime建议设为TimeSpan.FromMinutes(2)～TimeSpan.FromMinutes(4)，避免长连接因服务端重启或网络抖动导致的“幽灵连接” - 禁用连接重用只需设
MaxConnectionsPerServer = 1并配合PooledConnectionIdleTimeout = TimeSpan.Zero，但这是反模式，仅用于调试
HTTP/2 下 Keep-Alive 还需要手动配吗？
不需要。HTTP/2 天然基于单个 TCP 连接多路复用，SocketsHttpHandler 在协商成功 HTTP/2 后会忽略 KeepAlivePing* 系列设置，连接复用由协议层自动管理。但要注意：若服务端只支持 HTTP/2 over TLS（即 h2），而客户端未启用 ALPN 或证书验证失败，降级到 HTTP/1.1 后仍走原有连接池逻辑。
实操建议：
- 确认是否真走 HTTP/2：捕获
HttpRequestMessage.VersionPolicy和响应的HttpResponseMessage.Version，或用 Wireshark 看 ALPN 协商结果 - HTTP/2 下
MaxConnectionsPerServer实际意义变小——一个连接能并发上百请求，设过高反而浪费资源 - 若服务端混合支持 h1/h2，且你观察到大量
HTTP/1.1 408 Request Timeout，可能是 HTTP/1.1 连接池配置过松，而 HTTP/2 连接又因 TLS 握手慢被延迟建立
如何验证连接复用是否生效？
最直接的方式是抓包看 TCP 连接数和 Connection / Keep-Alive 头，但更轻量的是通过 HttpClient 内置计数器。.NET 6+ 提供 DiagnosticSource 事件，监听 System.Net.Http.HttpRequestOut.Start 可拿到 IsReusedConnection 字段。
实操建议：
- 临时加一段日志：在
HttpClient.SendAsync后检查response.Headers.Connection.Contains("keep-alive")，并对比连续请求的response.RequestMessage.RequestUri.Host和端口是否一致 - 用
netstat -an | findstr :观察 ESTABLISHED 连接数是否稳定在低位（比如始终 ≤3），而非随请求数线性增长 - 注意：.NET Core 3.1+ 中
SocketsHttpHandler的连接池是 per-HttpClient实例的，多个HttpClient实例不会共享连接池，这点常被忽略
MaxConnectionsPerServer、PooledConnectionIdleTimeout、KeepAlivePingDelay 这三者按实际网络 RTT 和服务端策略对齐，而不是堆参数。很多性能问题其实出在 HttpClient 实例被频繁 new 出来，或者 DNS 缓存没关导致每次解析都阻塞。 
