HttpClient调用亚马逊Web服务：开Fiddler正常，无Fiddler返回403故障排查

Fiddler作为本地系统代理接管流量时，会自动按照HTTP规范剥离逐跳请求头、统一使用合规的TLS版本与上游服务通信，这一行为刚好掩盖了你代码中的两个隐蔽问题，导致只有直连场景下触发亚马逊API网关的403拦截。

核心问题点与对应修复 #

• 签名计算范围与实际发送的请求头不匹配
  你当前AWS SigV4签名中声明的已签名头列表为accept;host;user-agent;x-amz-access-token;x-amz-date，但直连场景下HttpClient会自动追加Connection: Keep-Alive这类逐跳头到请求报文里。
  对比你提供的两份抓包报文可以看到容易被忽略的差异：Fiddler转发的成功请求最后一行到Host头就结束了，而直连的失败请求里多了一行Connection: Keep-Alive头。这是因为Fiddler转发时会自动移除所有逐跳头，让实际发往亚马逊服务器的报文和你签名时计算的头集合完全一致，不会触发签名校验失败；而直连时多出来的未纳入签名范围的头，会直接导致AWS网关校验签名失败返回403。
  修复操作：
  1. 构建请求时显式关闭HttpClient自动追加逐跳头的逻辑：

     // .NET Framework 场景
     HttpWebRequest request = (HttpWebRequest)WebRequest.Create(targetUrl);
     request.ServicePoint.Expect100Continue = false;
     request.KeepAlive = false;
     
     // .NET Core/.NET 5+ 场景
     HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, targetUrl);
     request.Version = HttpVersion.Version11;
     request.Headers.ConnectionClose = true;
     

  2. 所有请求头都在计算签名前显式赋值，不要依赖框架的默认自动追加行为，确保签名计算时的头集合和实际发出的报文头100%重合。
• TLS协议配置错误触发网关拦截
  你当前的TLS支持列表同时包含了Ssl3、TLS1.0、TLS1.1等亚马逊API网关已经废弃的旧协议，直连时系统会按照协议优先级协商，很可能选中不被支持的旧TLS版本完成握手——这类请求不会走到应用层逻辑，会被网关直接返回403。
  Fiddler作为代理转发请求时，会强制使用TLS1.2以上版本和亚马逊服务器通信，完全掩盖了你本地的TLS配置问题，因此代理场景下请求可以正常通过。
  修复操作：
  1. 移除TLS配置中的老旧协议支持，仅保留亚马逊要求的合规版本：

     // 删除Ssl3、Tls1.0/1.1的配置，仅保留支持的协议版本
     ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
     

  2. 全局设置ServerCertificateValidationCallback返回true的逻辑仅可用于本地调试，生产环境必须移除，否则会存在中间人攻击的安全风险。

验证排查方法 #

• 直连时不要只对比应用层HTTP报文，逐行核对实际发送的请求头，重点排查是否有不在签名头列表里的额外头被自动追加发出。
• 用和代码完全一致的签名、Token通过curl工具直连请求目标接口，排除网络层异常。
• RestSharp可以正常调用是因为它默认会自动剥离未纳入签名的逐跳头，且强制使用合规TLS版本通信，刚好规避了你手写HttpClient代码里的两个问题，不能直接因为RestSharp能用就判定问题不在签名或TLS配置上。

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