CloudFront+ELB能否修改请求查询字符串？AWS移除API路径前缀咨询

很多开发者刚接触CloudFront时都会误以为它只能做路径匹配转发，实际上它原生支持在请求转发到源站时完成路径改写，完全可以实现「请求mysite.com/api/v1/users映射为fj935hf02.elasticbeanstalk.com/v1/users」的效果，社区里常用的实现方式有三类：

1. CloudFront Functions 轻量重写（推荐首选） #

这是目前成本最低、无额外网络延迟的官方实现方案，完全不需要改动任何源站配置：

• 新建一个触发时机为查看器请求的CloudFront Function，核心逻辑就是对匹配固定前缀的请求做字符串裁剪
• 可直接复用的极简函数示例：

  function handler(event) {
      const request = event.request;
      // 匹配所有带/api前缀的请求
      if (request.uri.startsWith('/api/')) {
          // 移除/api前缀后再转发给EB源站
          request.uri = request.uri.replace('/api/', '/');
      }
      return request;
  }
  

• 将函数绑定到对应缓存行为的查看器请求触发位即可即时生效
• 适配tileserver-gl时完全不用打破现有统一域名的架构，只要在函数逻辑里加分支判断：比如识别到/tiles/*的请求时，裁掉/tiles前缀后把请求路由到tileserver-gl对应的源站就行，根本不需要tileserver-gl本身做路径适配

注意：这种边缘层的路径改写只在CloudFront到源站的内部转发链路生效，用户浏览器侧看到的URL始终保持mysite.com/xxx的格式，不会发生跳转或者后端源站路径暴露的问题。

2. Lambda@Edge 复杂逻辑适配 #

如果后续重写规则更复杂，比如需要根据请求头、查询参数动态选择源站、做多段路径的嵌套匹配，可以用同触发位置的Lambda@Edge替代CloudFront Functions，逻辑框架和上面的函数完全一致，只是支持更灵活的编程能力，代价是会引入非常轻微的冷启动延迟。

3. 源站层路由适配 #

如果不想在边缘层做路径改写，也可以从源站侧做兼容：

• 自主开发的自有API，可以在应用入口加全局中间件，把所有带/api前缀的请求映射到对应业务路由，这个是大部分项目一开始就会覆盖的适配逻辑
• 对不支持自定义根路径的tileserver-gl，不要硬塞进现有EB的API路由组，可以单独部署独立的EB环境承接这个服务，在CloudFront上给它配置独立的缓存行为，再用上面提到的边缘层函数剥离前缀即可。

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