My Next.js 16.2.1 app with Clerk authentication was working fine on @netlify/build 35.10.1 (Next.js Runtime v5.15.9) but broke after an automatic upgrade to @netlify/build
35.11.2.
It works fine locally and all ENVs are confirmed in Netlify prod.
The error:
Error: Clerk: Unable to verify request, this usually means the Clerk middleware did not run.
(code=auth_signature_invalid)
Every server component that calls auth() from @clerk/nextjs/server returns a 500.
What’s happening:
Clerk’s clerkMiddleware runs in proxy.ts and successfully authenticates requests — I confirmed this with logging showing auth.protect() succeeding for every route.
However, when server components or API routes call auth(), they get auth_signature_invalid. Likely the auth signature headers that clerkMiddleware sets in the proxy are
no longer being forwarded to the server component/API route rendering context.
Key details:
- Working build: @netlify/build 35.10.1, Next.js Runtime v5.15.9
- Broken build: @netlify/build 35.11.2
- Stack: Next.js 16.2.1, @clerk/nextjs 7.0.1, proxy.ts with clerkMiddleware
- Works locally, only broken on Netlify
- Tried both proxy.ts and middleware.ts — same error with both
What I’ve verified via logging:
- The proxy runs and auth.protect() succeeds (session cookies are present)
- All env vars (CLERK_SECRET_KEY, NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY) are set correctly
- The failure happens in server components when they call auth() — the middleware auth signature is missing
Build log from working deploy:
@netlify/build 35.10.1
Using Next.js Runtime - v5.15.9
Next.js 16.1.6
ƒ Proxy (Middleware)
It appears that something changed in the build/runtime between 35.10.1 and 35.11.2 that broke how proxy/middleware headers propagate to server-side rendering. Is there a way
to pin @netlify/build to 35.10.1, or is this a known regression?