自建Next.js+Clerk Dev Auth生产环境无法识别会话问题排查求助

背景说明 #

我在EC2实例的Docker容器中部署了自建Next.js应用，架构如下：

CloudFlare -> Caddy reverse proxy (in docker) -> next.js app (in docker)

已配置Clerk Dev Auth，本地运行正常，但生产环境下用户会话/认证数据无法传递至后端。已开启debug: true，在afterAuth中间件中确认密钥配置正确，存在cookieToken，请求头中也有与cookieToken一致的__session字段，但用户登录后请求中的auth参数为空：

auth {
  sessionClaims: null,
  sessionId: null,
  session: null,
  userId: null,
  user: null,
  actor: null,
  orgId: null,
  orgRole: null,
  orgSlug: null,
  organization: null,
  getToken: [Function: getToken],
  debug: [Function],
  isPublicRoute: true,
  isApiRoute: false
}

在Clerk社区及GitHub Issues中未找到解决方案，怀疑问题可能出自Next.js而非Clerk，求新的调试方向。

可尝试的调试思路 #

• 检查Next.js中间件的路由匹配规则：确认auth参数为空的路由是否被误标记为公开路由。从当前auth输出看isPublicRoute为true，这会导致Clerk跳过认证校验直接返回空对象，需核对middleware.ts中的matcher配置，以及afterAuth逻辑中是否错误设置了该标记。
• 验证代理层的Cookie传递配置：
  • 检查Caddy配置，确保已添加header_up Host {host}、header_up X-Forwarded-Proto {scheme}等规则，保证请求头和Cookie能完整传递到Next.js容器。
  • 检查CloudFlare的SSL/TLS模式，若开启“灵活SSL”，CloudFlare到Caddy的请求为HTTP，会导致Cookie的Secure属性失效，后端无法读取，建议切换为“完全SSL”模式。
• 排查Docker环境变量配置：确认生产环境中NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY、CLERK_SECRET_KEY是否正确注入，且CLERK_COOKIE_DOMAIN设置为生产环境的顶级域名，避免Cookie域名不匹配。
• 测试绕过代理直接访问Next.js容器：在EC2实例内部用curl直接请求Next.js容器端口（如curl http://localhost:3000/api/auth/me -H "Cookie: __session=xxx"），若auth参数恢复正常，说明问题出在代理层；若仍为空，再聚焦Next.js与Clerk的配置冲突。
• 配置Next.js的信任主机参数：在next.config.js中添加trustHost: true，确保Next.js信任反向代理传递的主机头，避免因域名验证失败导致Cookie失效。
• 输出Clerk完整认证日志：在afterAuth中间件中调用auth.debug()，查看完整的认证流程日志，确认是Cookie验证失败、会话过期还是其他环节出现异常。
• 解码Session Token验证有效性：提取__session中的Token值，用Clerk的Secret Key进行JWT解码，确认Token包含有效用户信息且未过期，排除Token本身的问题。

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