Amazon CloudFront部署NextJS应用时dynamic routing路由失效问题求助

你遇到的现象本质是客户端路由和CloudFront源站静态资源匹配规则不匹配：

• 应用内跳转走的是NextJS客户端侧路由逻辑，浏览器不会发起新的HTML资源请求，仅靠前端JS就能解析动态参数渲染页面
• 直接输入URL访问时，请求会直接打到CloudFront，此时源站的静态导出产物里只有[id].html模板文件，没有和动态参数123对应的123.html文件，所以会返回404错误

方案1：修改Lambda@Edge规则适配动态路由（最适配现有架构，无需改动其他配置） #

你已经用了Lambda@Edge处理静态路径的后缀补全，只需要在原有 rewrite 逻辑里加动态路由的 fallback 规则即可：

• 识别到访问路径属于动态路由的层级（比如匹配/path/subpath/*规则）时，不直接返回404，而是把请求 rewrite 到对应的动态路由模板路径/path/subpath/[id].html
• 客户端拿到[id].html的内容后，NextJS的前端路由会自动从URL里提取123作为动态参数完成渲染，和客户端跳转的逻辑完全一致
• 配置示例逻辑：

// 在你现有的lambdaRewrite.js里加入以下匹配逻辑
const dynamicRoutes = [
  // 按你的实际路由结构配置正则匹配规则
  /^\/path\/subpath\/[^/]+$/
]
if (dynamicRoutes.some(route => route.test(request.uri))) {
  request.uri = '/path/subpath/[id].html'
}

• 注意Lambda@Edge需要部署到美东1区域，修改后要重新触发CloudFront缓存失效才会生效

方案2：配置CloudFront自定义错误页面 fallback #

如果不想改Lambda@Edge的代码，可以用CloudFront原生的错误页配置实现：

• 进入CloudFront分配的错误页面配置 tab
• 新增自定义错误响应：
  • HTTP错误码选择404
  • 自定义错误响应选择「是」
  • 响应页面路径填你的动态路由模板路径/path/subpath/[id].html
  • HTTP响应码修改为200
• 这个方案的弊端是所有404请求都会 fallback 到这个页面，如果有多个动态路由需要配置更精细的规则，不如Lambda@Edge灵活

方案3：开启NextJS的SSG/ISR按需生成功能 #

如果你的NextJS应用不是纯静态导出，而是部署在支持NextJS运行时的环境（比如搭配ECS、Lambda作为源站），可以不用全量预生成所有动态参数对应的静态页面，开启fallback: true或者fallback: 'blocking'配置，源站会自动根据访问的动态参数生成对应页面再返回给CloudFront缓存，这种方案更适合动态参数量级极大的场景。

配置完成后先清理CloudFront缓存，再用无痕模式直接访问dns.com/path/subpath/123，就能正常加载页面，NextJS的useRouter钩子也能正常拿到query.id = 123的参数值。

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