部分AWS WorkSpace调用API Gateway返回403 Forbidden故障排查

首先明确核心特征：同API调用在个人设备、7台WorkSpace上正常，5台WorkSpace返回403时CloudWatch无对应日志，同账号下Lambda Function URL全设备调用正常，说明基础公网连通性无问题，故障点集中在WorkSpace出网差异、API Gateway边缘层拦截两个维度，按优先级排查即可：

WorkSpace侧排查（优先级最高） #

• 代理配置差异：这是该场景下最高发的原因。PowerShell的Invoke-RestMethod默认继承系统WinHTTP/用户级代理配置，5台故障WorkSpace如果配置了企业代理，且代理策略未放通execute-api.eu-west-1.amazonaws.com域名、或透传请求时丢失了必要头信息，会直接由代理返回403，请求根本不会发到AWS侧，自然没有CloudWatch日志。而Lambda Function URL域名不在代理拦截列表内，所以全设备正常。
  排查方式：故障机PowerShell执行netsh winhttp show proxy查看WinHTTP代理，同时核对系统网络设置中的用户代理配置，和正常WorkSpace做对比；测试时可以在调用命令后加-NoProxy参数跳过代理直接请求，如果恢复正常即可定位根因。
• 本地端点防护/防火墙拦截：故障机如果被单独下发了EDR、主机防火墙规则，拦截了对应API域名的请求，会直接在本地返回伪造的403响应。可以临时关闭主机防火墙、退出EDR后测试，同时用抓包工具确认请求的目的IP是否和正常机解析到的API Gateway IP一致。
• TLS版本不匹配：如果5台WorkSpace的系统补丁版本不一致，PowerShell默认可能使用TLS1.0/1.1发请求，API Gateway边缘节点默认拒绝低版本TLS连接会返回403。测试时可以在调用代码前加[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12强制使用TLS1.2，看是否恢复。
• 本地解析篡改：检查故障机的C:\Windows\System32\drivers\etc\hosts文件，确认没有把目标API域名解析到错误的拦截IP；同时在故障机和正常机分别执行Resolve-DnsName blahblah.execute-api.eu-west-1.amazonaws.com，对比返回的解析IP是否一致。

API Gateway侧排查（优先级次高） #

不要因为CloudWatch无日志就完全排除API Gateway侧问题，以下两种边缘拦截场景默认不会生成CloudWatch访问日志：

• API资源策略IP拦截：如果你的API Gateway配置了源IP白名单的资源策略，5台故障WorkSpace如果走了不同的出口NAT IP、不在白名单范围内，会直接在API Gateway边缘层被拦截返回403，不会触发访问日志。排查时可以在故障机访问公网IP查询接口拿到出口公网IP，和正常WorkSpace的出口IP对比，再核对API资源策略的白名单范围。
• WAF边缘拦截：如果API Gateway绑定了WAF WebACL，WAF规则匹配拦截的请求，在未开启全量日志配置的情况下，也不会同步日志到API Gateway的CloudWatch日志组。可以查看对应WAF的监控指标，确认故障时间点是否有匹配故障机出口IP的拦截记录。

快速定位测试代码 #

直接在故障机PowerShell执行以下代码，跳过代理、强制TLS1.2发起请求，可快速排除大部分WorkSpace侧问题：

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$apiUrl="https://blahblah.execute-api.eu-west-1.amazonaws.com/Test/pets"
Invoke-RestMethod $apiUrl -Method Get -ContentType 'application/json' -NoProxy

如果执行上述代码调用正常，直接排查故障机的代理、本地安全软件配置即可；如果依然返回403，再核对出口IP和API侧的拦截策略。

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