CloudFront作为App Runner反向代理配置后/api路径404问题排查

你遇到的404是Express服务直接返回的（从报错文本Cannot XXX /api/xxx可以直接判断，这是Express路由匹配失败的标准报错），核心原因是CloudFront转发请求到App Runner源站时，没有去掉路径中的/api前缀：

• 之前直接调用App Runner时，你的请求路径是/users/sign-in、/users这类，和Express里定义的路由完全匹配，所以能正常响应。
• 配置CloudFront反向代理后，默认会把用户请求的完整路径（包括/api前缀）原样转发给App Runner，后端实际收到的路径是/api/users/sign-in、/api/users，而你的Express路由根本没有定义/api开头的这些路径，自然返回404。

按顺序排查可以快速定位问题：

• 查看接口响应头，如果存在x-powered-by: Express字段，直接排除CloudFront源连接失败、权限配置错误的问题，确认请求已经成功到达App Runner服务，404是后端返回的。
• 查看App Runner的实时访问日志，直接看服务端收到的请求路径，会明确看到所有请求都带了/api前缀，和你后端定义的路由路径不一致。
• 直接在本地执行curl命令请求App Runner的带/api前缀的地址，比如curl -i -X POST https://<你的App Runner域名>/api/users/sign-in，会得到和前端完全一致的404报错，即可实锤是路径前缀问题。

• 核心缺失配置：/api*路径行为没有配置路径改写规则，CloudFront默认全量转发原始请求路径，导致后端收到的路径多了一层/api前缀，无法匹配路由。
• 路径匹配规则不严谨：你配置的/api*模式会匹配所有以/api开头的路径，包括/apixxx、/apireference.html这类不属于API的路径，容易出现误转发。
• 冗余配置待清理：当前后端保留的CORS配置在同域代理场景下完全不需要，后续如果不删除，反而可能因为origin匹配逻辑异常拦截正常请求。

1. 打开CloudFront控制台，找到你配置的优先级为0的/api*路径行为，编辑开启路径改写功能，配置规则为：将匹配到的路径前缀/api替换为空字符串。配置后用户请求/api/users/sign-in时，CloudFront转发给App Runner的路径会变成/users/sign-in，和你之前直接调用App Runner的路径完全一致。
2. （推荐优化）将路径匹配模式从/api*修改为/api/*，避免误匹配非API路径；如果需要兼容直接访问/api的场景，可以单独加一条优先级更高的/api路径行为，配置302重定向到/api/即可。
3. 现有配置里的HTTP方法权限、CachingDisabled缓存策略、AllViewer源请求策略都是正确的，不需要修改。
4. 等待CloudFront配置部署生效（通常需要3-10分钟），清空浏览器缓存后重新测试，404问题会直接消失。
5. 确认所有接口访问正常后，删除Express代码中所有CORS相关配置即可——当前架构下前端静态资源和API都挂在同一个CloudFront域名下，属于同源请求，完全不存在跨域问题。

如果你的CloudFront版本暂时找不到原生路径改写功能，可以在源请求阶段挂载一个最简Lambda@Edge函数，把请求uri里的/api前缀删掉再转发给源，逻辑和原生路径改写完全一致，不过目前AWS已经全地域支持CloudFront原生路径改写，不需要额外写函数。

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