企业内部VPN访问API Gateway时preflight预检失败问题排查

• 先确认报错层级：打开浏览器开发者工具的Network面板，筛选出失败的OPTIONS预检请求，看失败原因是网络层断开，还是拿到了API返回的错误状态码。如果是ERR_CONNECTION_RESET、ERR_TIMED_OUT这类网络错误，说明请求根本没到API Gateway，问题出在VPN链路；如果是拿到了4xx/5xx响应，再核对响应头和响应体内容。
• 对比VPN/非VPN环境的DNS解析结果：连接VPN时执行nslookup <你的API Gateway默认调用域名>，和断开VPN的解析结果对比。边缘优化API Gateway绑定CloudFront公网节点，如果VPN环境下解析出来的是企业内部私网IP，说明存在DNS劫持，请求被导流到了内部代理。
• 排查VPN侧的拦截规则：企业VPN通常会挂透明安全代理，重点确认三类规则：1）是否直接拦截HTTP OPTIONS方法的跨域请求；2）是否会篡改/剥离响应里的Access-Control-*系列跨域头；3）是否对该域名的请求触发302门户认证跳转——OPTIONS请求默认不会携带认证Cookie，遇到302跳转无法完成认证，会直接触发加载失败。
• 验证CORS配置兼容性：部分VPN出口会修改请求的Origin字段，把前端真实来源改成代理自身的域名，如果API Gateway的CORS白名单没覆盖这个被篡改的Origin，会返回403响应，浏览器在预检阶段拿到不带合法CORS头的403时，会直接提示「Failed to load response」，不会显示具体错误码。可以在VPN环境下用curl直接模拟预检请求验证：

curl -v -X OPTIONS "你的API完整请求路径" \
  -H "Origin: 你的前端页面域名" \
  -H "Access-Control-Request-Method: 实际请求用的方法比如POST" \
  -H "Access-Control-Request-Headers: 实际请求携带的自定义头比如content-type,authorization"

对比非VPN环境下的返回结果，看跨域头是否一致。

• 如果是VPN侧DNS劫持/代理拦截：联系企业IT网络团队，将API Gateway的调用域名加入VPN直连白名单，不走内部透明代理，同时关闭该域名的DNS劫持，让解析请求直接指向公网CloudFront节点。
• 如果是VPN篡改请求Origin头：两种处理方式，一是协调网络团队关闭针对该域名的Origin头篡改规则；二是在API Gateway的CORS配置中，把VPN代理篡改后的Origin加入允许白名单。
• 如果是触发VPN的302认证跳转：将API Gateway域名加入VPN认证豁免列表，访问该域名时不需要跳转到企业统一认证门户。
• 快速验证方法：在VPN连接状态下修改本地hosts文件，把API Gateway域名直接指向非VPN环境下解析到的CloudFront公网IP，绕开VPN的DNS和代理链路，如果此时预检请求恢复正常，即可确认问题完全出在VPN侧，和API Gateway、Lambda的配置无关。

核心判断逻辑：边缘优化类型的API Gateway是公网全球分发的服务，非VPN环境下访问完全正常的话，API侧本身的配置出错概率极低，90%以上的同类问题都是企业VPN的代理、安全规则、DNS配置导致的。

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