Next.js 13第三方Cookie登录态丢失排查与解决方案

上个月接了个对接需求，我们作为SaaS服务商，要把一个付费查询组件嵌入客户的营销网站。组件本身是Next.js 13做的独立应用，嵌入方式和iframe类似。联调阶段出现了一个特别诡异的bug：用户在客户网站点击“立即查询”，跳到我们应用里正常登录、使用，只要用户回到客户网站再点第二次，登录态就没了，又得重新登录。一开始怀疑是数据库session表有问题，查了半天才发现，根本不是服务端问题，是浏览器把我们的Cookie当成第三方Cookie拦了。这个问题在Next.js 13项目里特别典型，因为App Router模式下，很多东西从客户端挪到了服务端，Cookie的读写链路变了，很多人按照旧经验排查根本找不到方向。这篇就把我完整的排查过程和落地方案写出来，给遇到类似问题的朋友一个参考。

1. 第三方Cookie问题为什么会砸在Next.js 13项目头上

1.1 什么是“第三方上下文”：不是技术文档里说的那么抽象

先把这个概念掰碎了说。每次HTTP请求里携带的Cookie，到底是“第一方”还是“第三方”，不是看Cookie本身，而是看当前浏览器地址栏的域名和发起请求的URL域名之间的关系。

如果你访问的是 www.a.com，页面里的JavaScript向 www.a.com/api 发请求，这个请求带的Cookie就是第一方Cookie。但如果页面里嵌入了 b.com 的iframe，iframe内部向 b.com/api 发请求，浏览器请求栏顶部是 a.com，请求的却是 b.com 的资源，这个上下文就是第三方。简单说：地址栏是谁，谁发起的跨站请求都算第三方。

Next.js 13项目容易踩中这个坑，和它自身的架构有直接关系。App Router模式下，默认组件都是Server Component，很多数据请求直接发生在服务端，服务端直接发fetch不会受浏览器Cookie策略影响。但只要你涉及客户端交互，包括但不限于：iframe嵌入、OAuth跳转登录、跨域API调用、CDN域名下的静态资源请求，Cookie的携带逻辑就又回到浏览器手里，这时候第三方Cookie的限制就会冒出来。

1.2 浏览器厂商为什么集体围剿第三方Cookie

Chrome从80版本开始把未声明SameSite的Cookie默认视作Lax，这个改动直接改变了几亿用户的默认行为。Safari更激进，ITP（Intelligent Tracking Prevention）直接把第三方Cookie的默认存活时间按“7天/24小时”这种策略动态收紧，甚至干脆不收。Firefox的Enhanced Tracking Protection也会拦截没有经过用户显式授权的跨站Cookie。

这些策略的本意是防止广告追踪，但误伤的是所有合法业务。你的Next.js应用如果和一个独立的后端API域（比如 api.example.com）分开部署，用户访问 www.example.com 时，前端请求 api.example.com 会自动携带 www.example.com 域下的Cookie吗？不会。反过来也一样，服务端给 api.example.com 设置的Cookie，默认也不会在 www.example.com 的页面请求里带上。

我在排查那个嵌入组件时就发现了更麻烦的事情：Safari对第三方的iframe里的Cookie限制比常规跨域请求严得多，即使正确设置了 SameSite=None; Secure，在Safari中也保持不了多久，24小时左右就会被清掉。所以那时候我就明白，这个问题不是配一个属性就能一劳永逸的。

2. 一条Cookie从诞生到丢失的完整链路追踪

2.1 登录请求前后的完整Cookie生命周期

要修复这个问题，必须先能完整追踪一条Cookie的生命周期。以最常见的OAuth登录流程为例，用户访问第三方站点 customer-site.com，页面嵌入Next.js应用 app.customer-site.com 的iframe，用户点击“登录”。

1. iframe内部的Next.js应用发起 /api/auth/login 请求，重定向到OAuth授权服务器。
2. 用户完成授权后，浏览器按 redirect_uri 跳回 app.customer-site.com/api/auth/callback?code=xxx。
3. Next.js Route Handler里的代码用这个code向OAuth服务器换token，拿到token后调用 NextResponse.json() 或 NextResponse.redirect()，同时通过 response.cookies.set() 写一个登录态Cookie。
4. 浏览器收到响应，根据 Set-Cookie 里的属性决定是否存储和后续是否携带。

第二步到第三步之间，浏览器地址栏的域名是 customer-site.com 还是 app.customer-site.com，直接决定这个Cookie的“身份”。如果 redirect_uri 指向 app.customer-site.com，那地址栏会跳转到 app.customer-site.com，此时设置的Cookie其实是第一方的，问题不大。

但因为我们的嵌入场景是iframe，用户停留在 customer-site.com 页面里完成授权后，授权服务器跳转的目标是iframe内部，浏览器地址栏不会变，仍然是 customer-site.com。这时候 app.customer-site.com 设置的Cookie，就变成了名副其实的第三方Cookie。

2.2 决定Cookie命运的三个属性：SameSite、Domain、Secure

打开DevTools的Application面板，看任意一条Cookie，你会发现它的命运从写入那一刻就由几个属性决定了。

SameSite 是第一个分水岭。它有三个值：Strict、Lax、None。

• Strict：任何跨站请求都不带，只允许第一方上下文。
• Lax：跨站时只在顶级导航（用户直接输入URL或点击链接进入）时携带，iframe、fetch、XHR跨站全不带。
• None：跨站时携带，但必须配合 Secure，也就是只允许HTTPS。

Chrome默认未设置时按 Lax 处理，这是大量旧项目“莫名其妙掉登录”的根源。原先后端代码只写了 res.cookie('token', value)，没指定SameSite，Chrome 80之前默认放行，升级后全线拦截。

Domain 决定Cookie归属于哪个域。不设置的情况下，Cookie归属当前响应的host，并且不包含子域名。比如 app.customer-site.com 设置的Cookie，默认不会发送给 api.customer-site.com。如果你要跨子域共享，必须显式设置 Domain=.customer-site.com。

Secure 决定Cookie是否只在HTTPS连接中传输。SameSite=None 的Cookie如果少了 Secure，浏览器直接拒绝存储，这是第二个坑。

这三个属性在Next.js里通过Route Handler或者Server Action写入Cookie时，都有对应的配置项，后面方案部分我会给出代码。

2.3 用DevTools快速定位是哪个环节断了

排查时不要瞎猜，在Chrome DevTools的Network面板里看请求的Cookie状态最快。

• 打开Network面板，勾选“Preserve log”，找到登录回调那个请求。
• 点击请求，在Headers里看 Request Headers 里有没有 Cookie: xxx。如果整个请求头里没有Cookie字段，基本可以断定是浏览器没带上。
• 接着看 Response Headers 里的 Set-Cookie。如果响应里确实返回了 Set-Cookie，但Application面板的Cookies列表里没有新增条目，说明被浏览器拦截了。
• Chrome还会在Console里直接给出原因，常见的有：
  • This cookie is a third-party cookie and has been blocked
  • This cookie is missing the "SameSite" attribute
  • This cookie is labeled "Secure" but is not set over a secure connection

看到其中任何一条，方向就清楚了。Chrome的这个提示比任何日志都好使，我在现场排查时基本靠它确定问题归属。

3. 在Next.js 13项目里的四种落地修复方案

3.1 方案一：用next.config.js的rewrites把第三方请求变成第一方请求

要让浏览器不把请求当第三方，最直接的办法是把请求路径改成“同源”。Next.js的rewrites配置天然支持这个。

javascript复制// next.config.js
const nextConfig = {
  async rewrites() {
    return [
      {
        source: '/api/:path*',
        destination: 'https://api.example.com/:path*',
      },
      {
        source: '/auth/:path*',
        destination: 'https://auth.example.com/:path*',
      },
    ];
  },
};

module.exports = nextConfig;

配置完之后，Next.js应用里原来发往 https://api.example.com 的请求，全部改成发往 /api/xxx，nginx或者Next.js内部会把请求代理到真实后端。这样浏览器看到的请求是同源的，Cookie自然按第一方处理。

这个方案在部署层面最简单，但有一个隐藏的坑：rewrites默认在服务端代理，Cookie会透传给目标后端，但目标后端需要能接受来自Next.js服务端的请求，并且区分“直接访问”和“代理访问”。如果后端逻辑里有基于来源IP或者反向代理的校验，要提前适配。我们在Next.js应用部署在Vercel时，rewrites的代理转发由Vercel边缘网络完成，还曾遇到过目标后端对UA做过校验导致代理失败的情况，这个后面坑的部分详说。

3.2 方案二：用Route Handler做认证中转，手工搬运Set-Cookie

rewrites适合API请求代理，但如果是OAuth流程，需要动态处理跳转和Cookie写入，就得用Route Handler做一个认证中转站。

核心逻辑是这样的：Next.js的Route Handler作为OAuth回调的接收端，拿到授权码后由服务端去拿token，并把后端返回的 Set-Cookie 原样搬运到浏览器的响应里。因为最终响应是从Next.js域发出的，浏览器存储Cookie时会把Next.js应用域作为归属，这就把第三方上下文改写成了第一方上下文。

typescript复制// app/api/auth/callback/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function GET(request: NextRequest) {
  const code = request.nextUrl.searchParams.get('code');

  // 服务端向OAuth服务器换取token
  const tokenRes = await fetch('https://auth.example.com/oauth/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      code,
      client_id: process.env.CLIENT_ID,
      client_secret: process.env.CLIENT_SECRET,
      redirect_uri: process.env.REDIRECT_URI,
    }),
  });

  if (!tokenRes.ok) {
    return NextResponse.redirect(new URL('/login?error=oauth', request.url));
  }

  const setCookieHeader = tokenRes.headers.get('set-cookie');

  const response = NextResponse.redirect(new URL('/dashboard', request.url));

  if (setCookieHeader) {
    response.headers.append('set-cookie', setCookieHeader);
  }

  return response;
}

注意这里的 response.headers.append('set-cookie', setCookieHeader)，如果后端返回了多个 Set-Cookie（比如一个access_token、一个refresh_token），很多语言的HTTP库默认会合并处理，取值时要用 getAll('set-cookie') 而不是 get('set-cookie')。我在Node 18以下的运行环境上就踩过，get 只能拿到第一个，导致refresh_token丢失。

3.3 方案三：利用服务端fetch的Cookie透传机制（App Router专属）

App Router模式下的Server Component和Route Handler有一个共同特点：它们可以访问 cookies() 和 headers()，也能在服务端直接读写Cookie。

如果你在服务端做数据获取，完全绕开了浏览器侧请求，就不会有第三方Cookie的问题。比如有个页面需要根据用户登录态展示数据，不要在前端组件里用 useEffect 发请求，而是直接在Server Component里请求：

typescript复制// app/dashboard/page.tsx
import { cookies } from 'next/headers';

export default async function DashboardPage() {
  const cookieStore = cookies();
  const token = cookieStore.get('session_token');

  if (!token) {
    return <p>未登录</p>;
  }

  const res = await fetch('https://api.example.com/dashboard-data', {
    headers: {
      Authorization: `Bearer ${token.value}`,
    },
    cache: 'no-store',
  });

  if (!res.ok) {
    throw new Error('请求失败');
  }

  const data = await res.json();
  // 渲染页面
}

在这个写法里，fetch 发生在Next.js服务端，传给后端API的是从浏览器侧Cookie里取出来的 token，再以 Authorization header的方式传给上游服务，让上游服务不依赖Cookie认证，这是最干净的方案。不过它有前提：上游API必须支持Bearer token或自定义header鉴权，如果上游只认Cookie，那依然绕不开。

3.4 方案四：在代码里显式声明SameSite和Secure属性

如果确实需要用Cookie方式跨域传递登录态，可以在写入Cookie时按第三方场景显式设置：

typescript复制import { cookies } from 'next/headers';

export async function POST(request: Request) {
  const body = await request.json();

  const cookieStore = cookies();
  cookieStore.set('session_token', body.token, {
    httpOnly: true,
    secure: true,
    sameSite: 'none',
    maxAge: 60 * 60 * 24 * 7,
    path: '/',
  });

  return new Response('ok', { status: 200 });
}

sameSite: 'none' 是让Cookie在第三方上下文携带的前提，但要注意，这个设置生效有一个硬性条件：secure: true，也就是必须全程HTTPS。如果开发环境用http://localhost访问，浏览器会拒绝存储这类Cookie。本地调试时可以把 secure 配成动态的，判断请求里 x-forwarded-proto 等于 https 才强制开启。

这个方案适合对Cookie机制比较熟悉、且业务确实必须在第三方上下文中共享登录态的团队。但我要强调，它解决的是Chrome下的问题，Safari的ITP对第三方Cookie的清理策略是动态的，即使设置了SameSite=None也会被定期清掉。所以，指望靠这一个方案搞定所有浏览器是不现实的，只能作为过渡。

4. 安全属性组合：Cookie能跨域但不能裸奔

4.1 Cookie属性矩阵：哪些能跨、哪些必须配

理顺Cookie属性之后，很多问题其实是属性组合错了。我把常见组合和对应的“允许携带场景”做了个表，方便对照：

在生产环境我会遵循两条基本原则：

第一，能不放Cookie就不放Cookie。Next.js 13的服务端组件可以把状态封装在服务端，客户端只需要一个不透明的sessionId，数据全部通过服务端fetch获取，这样Cookie的暴露面最小。

第二，必须放Cookie时，access_token要httpOnly。因为第三方上下文里，iframe的JS是可以被嵌入方控制的，如果 document.cookie 能读取到你的token，对方站点的XSS就等于直接偷走了你的会话。httpOnly 让JS读不到，只有浏览器自动带上。但要注意，httpOnly的Cookie也没法用 document.cookie 清除，登出时要走后端接口。

4.2 真实生产环境里的CSRF与Cookie泄漏风险

第三方Cookie场景下，CSRF的威胁比第一方大很多。因为你的Cookie会被自动携带，如果第三方站点里有个恶意表单，向你的API提交请求，浏览器会带着Cookie一起发，后端没法区分这个请求是不是用户真实发起的。

常见的缓解手段：

• SameSite=Lax兜底：对非跨站请求保持默认Lax，只在真正需要跨站的接口上用None。不要一股脑给所有接口都配None。
• 双重提交Cookie：后端生成一个随机CSRF token写入Cookie，同时要求请求header里也带同样的token，服务端比对两者是否一致。因为恶意站点读取不到你域下的header，这个方案在跨站场景下有效。
• 校验Origin/Referer：在Next.js Route Handler里针对敏感请求校验 Origin 头，不是白名单域名就拒绝。

typescript复制// app/api/transfer/route.ts
import { NextRequest, NextResponse } from 'next/server';

const ALLOWED_ORIGINS = new Set([
  'https://customer-site.com',
  'https://app.example.com',
]);

export async function POST(request: NextRequest) {
  const origin = request.headers.get('origin');

  if (!origin || !ALLOWED_ORIGINS.has(origin)) {
    return NextResponse.json({ error: 'invalid origin' }, { status: 403 });
  }

  // 处理业务逻辑
}

这套组合下来，即便Cookie能被携带，攻击者也无法伪造合法的Origin和CSRF token，风险可控。

5. 彻底绕开第三方Cookie：纯Token方案的改造思路

5.1 Token方案为什么能绕开第三方Cookie限制

如果从产品层面能选择，我建议新项目直接考虑纯Token方案，不要在第三方Cookie上死磕。核心思路：登录后，后端返回一个access_token，前端（Next.js客户端）把它存在内存或 localStorage/sessionStorage 里，后续每个请求通过 Authorization: Bearer <token> 头带过去。这样Cookie策略就完全无关了。

localStorage 的一个潜在问题是XSS读取。但结合Next.js 13的架构，可以把token初始化放在服务端。比如用户通过OAuth登录后，Route Handler拿到token，把token作为页面初始props的一部分传给客户端组件。这样比前端从URL参数里取token更安全，URL不会进日志，XSS面也会小一些。

还有一个非常适合Next.js 13的模式：用Server Component管会话，客户端只发无状态请求。也就是客户端拿到一个临时请求ID或一次性票据，真正的业务请求统一走服务端，由服务端维护token。这本质上把token收口到服务端了，浏览器侧只需要一个会话ID，第三方Cookie的问题基本消失。

5.2 在Next.js中间件中完成Token刷新

纯Token方案里，最需要处理的是token过期。每次用户操作都因为token过期被打回登录页，体验很差。好在Next.js 13的中间件（middleware.ts）在Edge Runtime运行，可以在请求到达页面之前拦截并处理刷新逻辑。

typescript复制// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export async function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname;

  // 登录、静态资源、图片等不需要拦截
  if (
    pathname.startsWith('/_next') ||
    pathname.startsWith('/api/auth') ||
    pathname === '/login'
  ) {
    return NextResponse.next();
  }

  const accessToken = request.cookies.get('access_token')?.value;
  const refreshToken = request.cookies.get('refresh_token')?.value;

  if (!accessToken && refreshToken) {
    // 尝试刷新token
    const refreshRes = await fetch('https://auth.example.com/refresh', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ refresh_token: refreshToken }),
    });

    if (refreshRes.ok) {
      const { access_token } = await refreshRes.json();
      const response = NextResponse.next();
      response.cookies.set('access_token', access_token, {
        httpOnly: true,
        secure: true,
        maxAge: 60 * 30,
        path: '/',
      });
      return response;
    }

    // 刷新失败，跳转登录
    const loginUrl = new URL('/login', request.url);
    loginUrl.searchParams.set('redirect', pathname);
    return NextResponse.redirect(loginUrl);
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!_next/static|favicon.ico).*)'],
};

这个中间件的好处是刷新逻辑在请求抵达页面之前就完成了，用户无感知。我第一次在Vercel上部署这个方案时，发现Edge Runtime环境里的 fetch 不支持读取 Set-Cookie 响应头。后来查文档，Edge Runtime默认不暴露 set-cookie，这是Vercel边缘网络的安全机制。所以中间件里要做token刷新的话，刷新接口得返回 { access_token } 的JSON体，而不是依赖 Set-Cookie 头。

5.3 嵌入式场景的PostMessage鉴权方案

回到我最开始说的iframe嵌入组件场景，纯Token方案也有兼容性问题，因为iframe内部的页面是Next.js应用，token存在iframe的localStorage里，外部主站是无法直接访问的。

跨iframe通信需要靠 window.postMessage。流程大致是：

1. 主站iframe里加载Next.js应用，嵌入时带上一个 site_id 参数。
2. 用户在主站点击“查询”，主站向自己的后端换取一次性ticket，然后通过 iframe.contentWindow.postMessage({ type: 'AUTH_TICKET', ticket }, 'https://app.example.com') 发给Next.js应用。
3. Next.js应用用这个ticket调用自己的服务端API换取会话，之后所有请求都带自己的token。

这个方案的好处是主站不需要关心Next.js应用内部的会话机制，Next.js应用也不需要读取或写入第三方Cookie。ticket是一次性的，即使被窃取，过期时间极短，风险可控。我在组件里就是用了这个思路，主站传一个ticket，组件内部通过服务端API换成短期session，彻底绕开了第三方Cookie。

6. 我在生产环境踩过的坑与最终选型建议

6.1 坑一：localhost和127.0.0.1的Cookie表现完全不一样

本地联调经常遇到一个怪事：用 http://localhost:3000 访问Next.js应用，OAuth登录后Cookie写得正常；把首页请求改成 http://127.0.0.1:3000，同一个应用、同一个登录流程，Cookie直接丢了。

原因在于浏览器的Cookie作用域是区分host的，localhost和127.0.0.1是两个不同的host，SameSite策略在这个场景下表现得非常微妙。而且有些OAuth服务商在配置 redirect_uri 时只允许注册一个回调地址，你注册了localhost，用127.0.0.1访问就会因为回调地址不匹配而报错。

建议是本地开发统一使用localhost，并且建议把所有跨域场景都挂到一个本地代理域名下，比如在 /etc/hosts 里配置 app.localhost.com 指向127.0.0.1，用 http://app.localhost.com:3000 访问开发环境，让它和线上环境保持一致的域名层级。

还有一处坑，Chrome 94之后把 localhost 视为“可信Secure上下文”，即使本地是HTTP，Secure 属性的Cookie也能写入。但如果你不是localhost，而是局域网IP或者自定义域名，HTTP下 Secure Cookie照样被拒。所以本地调试第三方Cookie功能时，建议直接用 npx next dev 配合浏览器监听HTTPS的代理，或者在next.config.js里把 secure 设为动态的。

6.2 坑二：Vercel边缘网络上的Cookie读取机制

Vercel部署的Next.js 13应用，middleware默认跑在Edge Runtime。Edge Runtime里 request.cookies.get() 可以读到请求头里的Cookie，但 response.cookies.set() 设置的Cookie，在中间件里不会像Node.js环境那样自动合并 Set-Cookie 响应头。

换句话说，你在middleware里给response set了Cookie，页面本身可能没收到。因为这个Cookie通过 NextResponse 对象返回后，Vercel的边缘网络会把它加到响应头里。最开始我以为是框架bug，后来发现是Edge Runtime对 Set-Cookie 的处理机制和Node.js里 res.setHeader 不同，需要开发者手动处理或者依赖框架封装。

如果你在Vercel上遇到中间件里设置的Cookie不生效，先检查两件事：

• 是否在响应返回前调用了 response.cookies.set()，并且确认没有其他地方覆盖了响应头。
• 是否因为 matcher 配置，导致某个页面请求没有经过中间件。

我的建议是，中间件里尽量只做跳转和鉴权判断，Cookie的写入尽量放在Route Handler或者API层。中间件里做token刷新太容易在边缘网络上踩到莫名其妙的坑。

6.3 坑三：Safari对iframe中第三方Cookie的严格限制

Safari的ITP是第三方Cookie的终极杀手。我实测过，Safari 17下，iframe里设置的第三方Cookie，在完全没有用户交互的情况下，可能几分钟到几小时就被清掉。即使设置了 SameSite=None; Secure，Safari会记录这个域名有跨站追踪行为，然后动态缩短Cookie的存活时间。

这个没法彻底绕开，只能靠产品设计规避。比如：

• 在iframe外先引导用户在主域完成一次登录，让主站和iframe应用共享一个上层域名Cookie。如果主站和iframe应用是同一父域下的不同子域，可以通过 Domain=.共同的父域 共享Cookie，这属于第一方Cookie，Safari不拦。
• 如果无法共享父域，就用前面说的PostMessage一次性ticket方案。
• 实在不行，在用户点击进入iframe时，主动弹出新窗口，把授权流程放到顶层页面完成，而不是iframe内部。顶层导航下的Cookie是第一方上下文，Safari会放行。

这是最折腾人的一个坑，因为它和代码无关，和浏览器策略强绑定。我最后的方案就是把iframe组件里的登录流程改成主窗口跳转，用 window.open 打开授权页，完成授权后传ticket回iframe，才彻底稳定。

6.4 不同场景的最终选型建议

回过头来看，第三方Cookie问题在不同场景下的最优解是不同的：

我个人最推荐的组合是：App Router服务端组件负责所有敏感数据交互，客户端只维护一个短期会话标识，跨站嵌入场景用一次性ticket换取服务端会话。这套思路在Next.js 13下实现起来并不复杂，而且能避开所有浏览器厂商对第三方Cookie的围剿。如果你的项目已经被第三方Cookie问题折磨，按这个方向重构，大概率能一劳永逸。