Next.js生产环境根路由被[...slug].tsx异常捕获的路由问题

1. 检查Cloudflare配置冲突 #

• 查看Cloudflare的页面规则/缓存规则，确认根路由example.com/没有被设置错误的缓存策略或路由转发，比如误将根路由指向动态路由的缓存版本。
• 临时关闭「始终使用HTTPS」规则测试，排查是否是HTTPS重定向和Next.js路由逻辑冲突；同时检查「SSL/TLS」设置，若用「灵活SSL」建议改为「完全/严格SSL」（确保服务器有有效证书），避免请求头异常影响路由判断。

2. 验证Docker容器内的路由行为 #

• 确认next.config.js没有错误的重写/重定向规则干扰默认路由优先级：

  module.exports = {
    async rewrites() {
      return []; // 确保根路由未被重写到[...slug]
    },
    trailingSlash: false, // 避免尾斜杠设置导致匹配异常
  };
  

• 进入容器内部用curl测试根路由：

  docker exec -it <容器ID> sh
  curl http://localhost:3000/
  

  如果容器内请求正常，问题出在Cloudflare到容器的转发环节；若容器内也异常，说明构建或容器配置有问题。

3. 修正动态路由的空slug处理逻辑 #

Next.js路由优先级是精确路由 > 动态路由 > 捕获所有路由，但生产环境可能因缓存或渲染逻辑导致根路由被[...slug].tsx错误捕获：

• 检查pages/[...slug].tsx的服务端渲染逻辑，避免空slug时直接返回404，改为重定向到根路由：

  export async function getServerSideProps(context) {
    const { slug } = context.params;
    // 捕获空slug（对应根路由请求）时重定向到index
    if (!slug || slug.length === 0) {
      return {
        redirect: {
          destination: '/',
          permanent: true,
        },
      };
    }
    // 其他业务逻辑...
  }
  

4. 检查反向代理的请求头转发 #

如果容器前用了Nginx等反向代理，确保正确转发Host等关键请求头：

location / {
  proxy_pass http://localhost:3000;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
}

错误的请求头会导致Next.js无法正确解析路由。

5. 清除缓存并重建镜像 #

• 清除Docker镜像缓存，避免旧构建产物残留：

  docker build --no-cache -t your-app-image .
  docker run -d -p 3000:3000 your-app-image
  

• 检查T3栈依赖版本，尝试升级Next.js到稳定版，排查依赖兼容问题。

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