PowerShell Invoke-RestMethod发送请求报意外错误排查

Windows 10内置的PowerShell 5.1基于.NET Framework 4.x构建，其HTTP请求依赖系统Schannel组件完成TLS握手，存在两类默认兼容性问题：

• 仅手动指定TLS版本无法解决密码套件匹配、TLS扩展协商层面的不兼容，目标服务器（Cisco ISE）会直接拒绝不满足握手要求的连接，触发发送阶段连接关闭错误
• 系统自带的原生curl.exe使用独立的OpenSSL TLS栈，不依赖Schannel的配置逻辑，因此相同请求可以正常执行
• 多台Windows 10设备稳定复现是因为该TLS配置是系统默认值，和个体设备的个性化设置无关
• 指定TLS 1.3时错误变为接收阶段报错，是因为Windows 10的Schannel对TLS 1.3的支持为非完整实现的预览状态，本身存在栈层面缺陷，不属于配置错误。

按落地成本从低到高排序：

• 直接调用curl.exe发起请求（零配置推荐）
  注意必须写完整后缀curl.exe，否则会命中PowerShell内置的Invoke-WebRequest别名，仍然触发报错。示例代码：

  # 提取凭证对象里的用户名密码
  $apiUser = $cred.UserName
  $apiPwd = $cred.GetNetworkCredential().Password
  # 直接调用原生curl发请求
  curl.exe -u "$($apiUser):$($apiPwd)" "https://myiseserver/admin/API/mnt/Session/MACAddress/B8:3B:CC:50:BA:B6"
  

  该方法完全绕开PowerShell原生HTTP栈的兼容性问题，不需要修改任何系统配置，执行即可生效。

• 修复.NET Framework TLS默认配置，保留原生Invoke-RestMethod调用方式
  执行以下配置命令，修改.NET全局强加密设置，让Schannel使用和现代浏览器一致的密码套件优先级与协商逻辑：

  # 配置当前会话的TLS版本
  [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
  # 写入系统注册表开启.NET强加密模式
  $regRoot = 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'
  Set-ItemProperty -Path $regRoot -Name 'SchUseStrongCrypto' -Value 1 -Type DWord -Force
  Set-ItemProperty -Path $regRoot -Name 'SystemDefaultTlsVersions' -Value 1 -Type DWord -Force
  $regRootWow64 = 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319'
  Set-ItemProperty -Path $regRootWow64 -Name 'SchUseStrongCrypto' -Value 1 -Type DWord -Force
  Set-ItemProperty -Path $regRootWow64 -Name 'SystemDefaultTlsVersions' -Value 1 -Type DWord -Force
  

  执行完成后关闭当前PowerShell窗口，重新打开新会话再执行原请求命令即可。注意该修改需要管理员权限执行。

• 升级到PowerShell 7.x版本（长期解决方案）
  PowerShell 7及以上版本基于.NET Core/.NET 5+构建，HTTP栈完全重构，TLS协商逻辑和curl、Chrome等现代客户端一致，不存在该类兼容性问题，安装完成后直接执行原请求命令即可正常运行。

内容的提问来源于stack exchange，提问作者Michał Rzepecki