Link to the code that reproduces this issue

https://github.com/vercel/next.js/blob/canary/packages/next/src/lib/load-custom-routes.ts#L722-L731

To Reproduce

1. Configure next.config.js with deploymentId and experimental.useSkewCookie: true
2. Deploy two versions simultaneously behind a load balancer with weighted traffic routing (e.g., 50/50 split)
3. Load a page — the initial HTML response sets Set-Cookie: __vdpl={stable-sha}
4. Observe that _next/static chunk requests also receive Set-Cookie: __vdpl={responding-pod-sha}
5. When a chunk request is routed to the other deployment (which returns 404 — it doesn't have that build's chunks), the 404 response still sets Set-Cookie: __vdpl={other-sha}, overwriting the original cookie
6. The client is now pinned to a deployment it wasn't assigned to

Current vs. Expected behavior

Current: useSkewCookie injects Set-Cookie: __vdpl={deploymentId} on all responses via source: '/:path*', including _next/static asset responses. In multi-deployment environments with per-request routing, this causes static asset 404s from the wrong deployment to overwrite the client's version affinity cookie — silently switching users between versions.

At 50% rollout weight with ~15 chunk requests per page load, the probability of at least one chunk hitting the wrong deployment is 1 - 0.5^15 ≈ 99.997%. Effectively all users drift to one version, making weighted rollouts meaningless.

Expected: The __vdpl cookie should only be set on responses that go through application routing (page navigations, API routes, RSC payloads) — not on _next/static responses. Static asset responses should not establish or change version affinity because:

• They may be served by a deployment that doesn't own that asset (404 during weighted routing)
• A 404 response carries no meaningful "version assignment"
• Only page-level responses where the server renders content should pin version affinity

Provide environment information

Next.js: 16.1.6
Deployment: Self-hosted on Kubernetes with weighted rollout strategy
Config: deploymentId: process.env.BUILD_ID, experimental.useSkewCookie: true
Output: standalone

Which area(s) are affected? (Select all that apply)

Headers, Cookies

Which stage(s) are affected? (Select all that apply)

Other (Deployed)

Additional context

The feature was introduced in https://github.com/vercel/next.js/pull/78841. The PR description notes the trade-off of "better caching" by using a cookie instead of ?dpl= query params, but the source: '/:path*' pattern was not scoped to exclude static assets.

This affects any self-hosted deployment where multiple versions serve traffic simultaneously with per-request routing — which includes any load balancer doing weighted distribution (ALB, nginx, HAProxy, Traefik, Kubernetes ingress controllers, etc.).

On Vercel this doesn't manifest because the routing layer reads the __vdpl cookie and pins requests to the correct deployment before they reach the server, preventing the 404 in the first place.

Proposed fix

Exclude _next/static from the cookie header source pattern:

  headers.unshift({
-   source: '/:path*',
+   source: '/((?!_next/static).*)',
    headers: [
      {
        key: 'Set-Cookie',
        value: `__vdpl=${config.deploymentId}; Path=/; HttpOnly`,
      },
    ],
  });

This mirrors the default Next.js middleware matcher convention, which already excludes this path.