Azure Functions中PowerShell调用API出现连接被强制关闭的问题

本地PowerShell环境使用Invoke-WebRequest发起DELETE API请求可正常执行，部署到Azure Function环境运行时触发报错：Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host。已尝试放开旧版TLS/HTTP协议支持、调大函数超时时间、设置PowerShell Worker并发上限为1，均未解决问题。

• 移除Headers中硬编码的content-length配置
  手动指定content-length = "2"是核心触发原因：DELETE请求无实际请求体时，硬编码的长度值和实际TCP载荷长度不匹配，目标服务的协议校验逻辑会直接判定请求非法、强制断开连接。Azure Function的PowerShell Worker基于.NET HTTP栈实现，对请求头和载荷的长度一致性校验比本地Windows客户端PowerShell严格，本地能跑通不代表该配置合法。
• 修正URI语法错误
  当前代码的URI字符串缺少闭合双引号，会导致请求地址拼接异常：

  # 错误写法
  $uri = "https://www.example.com/api/vl/$test
  # 正确写法
  $uri = "https://www.example.com/api/vl/$test"
  

• 调整TLS配置逻辑，不要放开旧版协议
  此前尝试“放开TLS1.0与HTTP协议支持”的方向和问题根因相反：Azure Function的运行环境默认全局禁用TLS1.0/1.1等不安全协议，手动放开这类旧协议会导致TLS版本协商异常，被目标服务的安全策略直接拦截。正确的配置是在代码最顶部显式锁定TLS1.2支持：

  [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
  

• 临时移除冗余请求头做连通性验证
  对于无请求体的DELETE请求，Headers中配置的accept-encoding = "gzip"、content-type = "application/json"属于冗余配置，部分网关类目标服务会对无请求体但声明JSON内容类型、要求gzip压缩的请求做直接拦截。可以先删掉这两个配置项测试连通性，确认打通后再按需加回。
• 排查出站网络链路
  确认Function应用的VNet集成、服务端点配置没有阻断到目标API的出站流量；如果目标API配置了IP白名单，需要将Function的全量出站公网IP段加入白名单，否则远端会在TCP握手阶段直接强制关闭连接。

此前尝试的host.json超时配置、PSWorkerInProcConcurrencyUpperBound并发配置，仅影响函数执行时长、PowerShell Worker的并发处理能力，和TCP传输层连接被强制关闭的问题无关联，因此调整后无效果属于正常情况。 #

内容的提问来源于stack exchange，提问作者Head and toes