AWS API Gateway跨域（CORS）问题：仅控制台向导方式生效

安全阿岳

2026-7-17

问题分析与解决方案

以下是几种可能导致这种差异的核心原因及对应排查方向：

资源路径的隐性不匹配
通过创建资源向导启用CORS时，API Gateway会自动对齐资源路径格式（比如是否包含尾部斜杠）与请求的预期路径。但手动创建、通过Actions菜单或CLI操作时，很容易出现路径细微差异——比如你创建的资源路径是/api/v1/resource，但实际请求用了/api/v1/resource/，这会导致OPTIONS方法的CORS配置无法匹配到请求路径，直接触发跨域错误。
OPTIONS方法的集成配置不全
向导启用CORS的流程会自动为OPTIONS方法配置Mock集成，并完整设置Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等响应头的映射。手动创建OPTIONS方法时，可能误选了Lambda/HTTP等集成类型，或者没有在响应头中正确配置所有必要字段；用CLI创建时，可能遗漏了--integration-type MOCK参数，或者响应头的配置语句不完整，导致浏览器无法识别合法的跨域响应。
忘记重新部署API阶段
资源向导在完成配置后会自动触发API部署到指定阶段，但手动、Actions菜单或CLI操作后，很多人会忽略这一步。API Gateway的所有配置变更（包括CORS）必须部署到对应阶段才会生效，未部署的话，请求会沿用旧的配置，自然出现CORS错误。
自定义域名路径映射未同步
如果你的API绑定了自定义域名，向导创建资源时可能自动同步了自定义域名的路径映射，但手动/CLI创建后，你需要手动更新路径映射规则。如果路径映射没有指向新创建的资源，请求实际访问的是未配置CORS的旧路径，导致报错。
WAF或边缘层的拦截/篡改
若API关联了WAF规则，手动/CLI创建的资源可能触发了某些拦截规则，导致OPTIONS请求被阻断，或者响应头被修改。而向导创建的资源可能因为默认的路径命名规则避开了这些规则，从而正常工作。可以检查WAF的日志，确认是否有OPTIONS请求被拦截。