Cloudflare Pages/Workers部署下Set-Cookie响应失效问题求助

针对你遇到的同一应用在Vercel正常、Cloudflare环境下登录失败（__Secure-authjs.session-token Cookie不生效）的问题，可从以下几个方向排查解决：

1. 调整Auth.js的Cookie配置 #

Cloudflare对响应头的Set-Cookie处理逻辑与Vercel不同，手动明确Cookie属性可避免浏览器拒绝存储：

export const { handlers, signIn, signOut, auth } = NextAuth({
  basePath: "/auth",
  experimental: { enableWebAuthn: true },
  session: {
    strategy: "jwt",
  },
  adapter: DrizzleAdapter(db, {
    usersTable: schema.users,
    sessionsTable: schema.sessions,
    verificationTokensTable: schema.verificationTokens,
    accountsTable: schema.accounts,
    authenticatorsTable: schema.authenticators,
  }),
  providers: [Passkey],
  // 新增Cookie配置
  cookies: {
    sessionToken: {
      name: "__Secure-authjs.session-token",
      options: {
        httpOnly: true,
        secure: process.env.NODE_ENV === "production",
        sameSite: "lax",
        path: "/",
        maxAge: 60 * 60 * 24 * 7,
      },
    },
  },
  trustHost: true, // 自动适配部署环境的主机名
});

2. 配置Cloudflare的HSTS与SSL设置 #

__Secure-前缀的Cookie要求必须在HTTPS环境下传输，需确保Cloudflare侧的安全配置正确：

• 登录Cloudflare控制台，进入域名的「SSL/TLS」设置，将模式改为「Full」或「Full (strict)」
• 在「规则」→「HTTP响应头」中添加Strict-Transport-Security头，值设置为max-age=63072000; includeSubDomains; preload

3. 排查Cloudflare的响应头过滤/修改 #

Cloudflare Pages的Serverless函数可能会自动修改或过滤响应头：

• 检查Cloudflare控制台的「Speed」→「优化」选项，暂时禁用「自动压缩」「Rocket Loader」等功能，测试是否影响Cookie传输
• 查看Cloudflare「日志」页面的Serverless函数执行日志，确认是否有响应头被拦截的错误信息

4. 升级依赖版本 #

Auth.js的WebAuthn功能处于实验阶段，新版本可能修复了Cloudflare环境的兼容性问题：

• 升级next-auth到最新稳定版
• 同步升级@auth/drizzle-adapter和next依赖

调试建议 #

• 打开浏览器开发者工具的「网络」标签，查看POST /auth/callback/passkey请求的响应头，确认Set-Cookie的具体内容，检查是否存在属性冲突（如Cookie过大、domain设置错误）
• 对比本地/Vercel/Cloudflare环境下的Set-Cookie头格式，确认Cloudflare是否未正确拆分多Cookie头

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