PowerShell5.1中Invoke-WebRequest访问Pode HTTPS仅首次成功

该问题核心是服务端Pode框架的HTTPS长连接处理逻辑存在实现Bug，与.NET Framework 4.x内置的HTTP连接池复用机制不兼容，不属于客户端环境配置错误，也不是Windows SChannel、.NET Framework本身的原生缺陷。

具体逻辑对应如下：

• PowerShell 5.1底层依赖.NET Framework 4.x的HttpWebRequest实现，默认会对同一目标端点的HTTPS连接启用Keep-Alive，将建立好的TLS连接放入ServicePoint连接池复用，减少重复握手开销。
• Pode采用自研HTTP解析栈，通过SslStream处理TLS流量时，在完成第一次请求响应的发送后，没有严格遵循HTTP 1.1规范处理长连接帧边界：要么错误丢弃了SslStream读缓冲区的剩余数据，要么半关闭了连接但没有按规范返回Connection: close响应头告知客户端连接不可复用。
• 当.NET Framework 4.x从连接池取出该“看起来仍存活”的连接发送第二次请求时，Pode端无法正确解析复用连接上的新请求帧，也不会返回任何响应，客户端就会一直等待直到触发超时，未设置超时参数时就会无限挂起。

你观察到的所有现象都可以和该根因对应：

• 问题同时影响Invoke-WebRequest、Invoke-RestMethod、System.Net.WebClient：因为三者底层都走.NET Framework 4.x的同一套HttpWebRequest/ServicePoint连接池逻辑。
• 不带客户端证书仍复现：问题和客户端证书校验逻辑无关，核心触发条件是连接复用。
• 本地请求、无代理/DPI环境仍复现：问题出在TCP层之上的HTTP/TLS帧处理逻辑，和网络中间设备无关。
• 指定代理后问题消失：本地代理会和客户端建立独立连接，且代理默认每次向服务端发起请求都会新建独立TLS连接，不会触发连接复用逻辑。
• PowerShell 7.x正常：PowerShell 7基于.NET 6+构建，底层用SocketsHttpHandler实现HTTP逻辑，连接复用前会主动做通道可用性校验，帧解析逻辑对非规范服务端的兼容性更高，不会触发挂起。
• 访问其他Web服务器正常：IIS、Nginx、Kestrel等成熟Web服务都严格遵循HTTP 1.1长连接处理规范，不存在帧边界处理错误。
• 手动指定TLS版本无效：问题和TLS版本协商无关。

服务端永久修复（推荐） #

直接修复Pode框架的连接处理逻辑：

1. 单请求处理完成后，不要重置或丢弃SslStream的读缓冲区，保持读状态正常等待下一个请求；
2. 如果服务端要主动断开连接，必须先向客户端返回Connection: close响应头，再按顺序依次关闭SslStream、TCP Socket，不能跳过通知直接半关闭连接。

如果暂时无法修改框架源码，可临时配置Pode给所有响应统一添加Connection: close头，强制客户端每次请求新建连接，也能避免问题触发。

客户端侧规避（无需修改服务端时使用） #

1. 单次请求层面禁用长连接，给请求显式添加关闭连接的请求头：

   $Certificate = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Thumbprint -eq 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF' }
   $headers = @{ "Connection" = "close" }
   Invoke-WebRequest -Uri 'https://api.example.com/api/v1.0/test' -Certificate $Certificate -TimeoutSec 10 -Headers $headers
   

2. 全局针对目标端点禁用连接池复用：

   $sp = [System.Net.ServicePointManager]::FindServicePoint("https://api.example.com/")
   $sp.ConnectionLeaseTimeout = 0
   $sp.MaxIdleTime = 0
   

3. 直接换用PowerShell 7.x环境执行请求，如你测试验证的结果，.NET 6+底层HTTP实现不会触发该兼容性问题。

• 责任侧：服务端Pode框架的自研HTTP/TLS处理逻辑不符合HTTP 1.1规范，属于代码Bug
• 客户端侧无配置错误，.NET Framework 4.x只是因为连接复用逻辑对非规范服务端兼容性更低，刚好触发了该缺陷。

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