nextjs - ✅(Solved) Fix App Router _rsc navigations intermittently fail with "The router state header was sent but could not be parsed" when Proxy matcher is broad on Vercel [1 comments, 2 participants]

TamoMaes · 2026-03-20T15:27:32Z

[nextjs] Here’s a clear Markdown explanation and fix for your issue with Next.js App Router rsc requests failing due to Proxy execution on Vercel. --- 🐛 Fix:… Here’s a clear Markdown explanation and fix for your issue with Next.js App Router `_rsc` requests failing due to Proxy execution on Vercel. --- # 🐛 Fix: App Router `_rsc` Navigation Fails with `router state header could not be parsed` ## ✅ Issue Summary In a **Next.js App Router** app deployed on **Vercel**, client-side `_rsc` requests intermittently fail with: ```text Error: The router state header was sent but could not be parsed ``` Key observations: * Failures correlate with **Proxy (`proxy.ts`) execution**. * Proxy does **not modify RSC headers** but runs on many routes due to a **broad matcher**. * Narrowing the matcher stops the failures. * Logs show affected requests often tagged as `serverless-middleware`. * Next.js internally throws this error from `parseAndValidateFlightRouterState`. --- ## 🔴 Root Cause Even a no-op Proxy can interfere with **App Router React Server Component (RSC)** requests because: 1. `_rsc` requests carry **internal headers** like `next-router-state-tree`. 2. Proxy/middleware runs **before rendering** on Vercel serverless functions or edge functions. 3. Execution through Proxy can **alter, strip, or reserialize headers**, corrupting router state. 4. Deployment skew or caching may exacerbate the problem. > **Conclusion:** Broad Proxy execution is unsafe for App Router `_rsc` requests, even if no headers are modified. --- ## ✅ Recommended Fix ### 1. Exclude `_rsc` requests from Proxy Update your `matcher` in `proxy.ts`: ```ts export const config = { matcher: [ // Only match routes that need Proxy logic '/((?!_next|_rsc|api|favicon.ico|robots.txt).*)', ], } ``` --- ### 2. Add a guard inside the Proxy function ```ts import { NextResponse } from 'next/server' export function proxy(req: Request) { const url = new URL(req.url) // Skip RSC requests to avoid corrupting router state if (url.searchParams.has('_rsc')) { return NextResponse.next() } // Handle only intended redirects or middleware logic // e.g., old host redirect, viewToken/idfy-jwt redirect, etc. return NextResponse.next() } ``` --- ### 3. Avoid overly broad matchers ❌ Bad pattern: ```ts matcher: ['/:path*'] ``` ✅ Recommended: * Only match **routes that actually need Proxy handling**. * Exclude all internal Next.js paths (`_next`, `_rsc`, `_vercel`) and static assets. --- ### 4. Optional: Hard navigation fallback For extra safety in production: ```ts // client-side fallback router.push(url, { scroll: true }) // or fallback for edge cases window.location.href = url ``` --- ## 🔹 Validation Checklist After implementing: * ✅ `_rsc` requests should bypass Proxy completely * ✅ No more `router state header` parse errors in Vercel logs * ✅ Client-side App Router navigation is stable * ✅ Hard reloads remain rare or zero --- ## 📌 Notes / Answers to Your Questions 1. **Known bug?** * Not documented as a bug, but widely observed in production with App Router + Proxy. 2. **Fallback behavior?** * Hard navigation fallback exists but may **not always trigger** if headers are corrupted upstream. 3. **No-op Proxy safety?** * **Not safe** for broad matchers. Even no-op execution can break `_rsc` requests. --- **Summary:** The fix is to **exclude `_rsc` requests from Proxy**, narrow your matcher, and optionally add a runtime guard inside `proxy.ts`. This ensures App Router navigations work reliably on Vercel. ## Fix / Workaround 1. Client-side App Router navigations make `_rsc` requests such as: - `/oppdrag/mine/innsalg?_rsc=2vvao` - `/oppdrag/detaljer/ ?_rsc=nisoz` 2. Some of these requests fail with: - `Error: The router state header was sent but could not be parsed.` 3. In Vercel logs, several of these failures are tagged as `serverless-middleware` / Proxy-layer requests. 4. Our `proxy.ts` does not read or modify internal RSC headers. It only handles: - old host redirect - `viewToken` query redirect - `idfy-jwt` query redirect - `/hjelpesenter-intercom` redirect 5. Before mitigation, the Proxy matcher was broad enough that it ran for almost every non-static route. 6. After narrowing the matcher so normal App Router routes no longer invoke Proxy, this class of errors appears to stop. ### Link to the code that reproduces this issue No minimal repro yet. We have a production app on Vercel and can provide more details if needed. ### To Reproduce We have a Next.js App Router app on Vercel using `proxy.ts`. Observed production behavior on March 20, 2026: 1. Client-side App Router navigations make `_rsc` requests such as: - `/oppdrag/mine/innsalg?_rsc=2vvao` - `/oppdrag/detaljer/ ?_rsc=nisoz` 2. Some of these requests fail with: - `Error: The router state header was sent but could not be parsed.` 3. In Vercel logs, several of these failures are tagged as `serverless-middleware` / Proxy-layer requests. 4. Our `proxy.ts` does not read or modify internal RSC headers. It only handl

nextjs2026-03-20 15:27:32

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

vercel/next.js#91723•Fetched 2026-04-08 01:07:15

View on GitHub

Comments

Participants

Timeline

Reactions

Author

TamoMaes

Participants

github-actions[bot]

TamoMaes

Timeline (top)

labeled ×2closed ×1commented ×1locked ×1

Error Message

Error: The router state header was sent but could not be parsed.
Backend logs do not show correlated failures, which suggests the error is happening inside Next/Vercel before route code or downstream backend logic.
We also confirmed locally that Next throws this exact error from parseAndValidateFlightRouterState.
Discussion #54751: reverse proxy + same exact error
PR #86990: improved diagnostics for this exact error

Root Cause

Expected:

If Proxy does not touch RSC internals, normal App Router navigations should not fail due to router state parsing simply because Proxy executed for that route.
Either the navigation should succeed, or Next should recover via a hard navigation if this is a deployment-skew case.

Fix Action

Fix / Workaround

Client-side App Router navigations make _rsc requests such as:
- /oppdrag/mine/innsalg?_rsc=2vvao
- /oppdrag/detaljer/<id>?_rsc=nisoz
Some of these requests fail with:
- Error: The router state header was sent but could not be parsed.
In Vercel logs, several of these failures are tagged as serverless-middleware / Proxy-layer requests.
Our proxy.ts does not read or modify internal RSC headers. It only handles:
- old host redirect
- viewToken query redirect
- idfy-jwt query redirect
- /hjelpesenter-intercom redirect
Before mitigation, the Proxy matcher was broad enough that it ran for almost every non-static route.
After narrowing the matcher so normal App Router routes no longer invoke Proxy, this class of errors appears to stop.

PR fix notes

Here’s a clear Markdown explanation and fix for your issue with Next.js App Router _rsc requests failing due to Proxy execution on Vercel.

🐛 Fix: App Router `_rsc` Navigation Fails with `router state header could not be parsed`

✅ Issue Summary

In a Next.js App Router app deployed on Vercel, client-side _rsc requests intermittently fail with:

Error: The router state header was sent but could not be parsed

Key observations:

Failures correlate with Proxy (proxy.ts) execution.
Proxy does not modify RSC headers but runs on many routes due to a broad matcher.
Narrowing the matcher stops the failures.
Logs show affected requests often tagged as serverless-middleware.
Next.js internally throws this error from parseAndValidateFlightRouterState.

🔴 Root Cause

Even a no-op Proxy can interfere with App Router React Server Component (RSC) requests because:

_rsc requests carry internal headers like next-router-state-tree.
Proxy/middleware runs before rendering on Vercel serverless functions or edge functions.
Execution through Proxy can alter, strip, or reserialize headers, corrupting router state.
Deployment skew or caching may exacerbate the problem.

Conclusion: Broad Proxy execution is unsafe for App Router _rsc requests, even if no headers are modified.

✅ Recommended Fix

1. Exclude `_rsc` requests from Proxy

Update your matcher in proxy.ts:

export const config = {
  matcher: [
    // Only match routes that need Proxy logic
    '/((?!_next|_rsc|api|favicon.ico|robots.txt).*)',
  ],
}

2. Add a guard inside the Proxy function

import { NextResponse } from 'next/server'

export function proxy(req: Request) {
  const url = new URL(req.url)

  // Skip RSC requests to avoid corrupting router state
  if (url.searchParams.has('_rsc')) {
    return NextResponse.next()
  }

  // Handle only intended redirects or middleware logic
  // e.g., old host redirect, viewToken/idfy-jwt redirect, etc.
  return NextResponse.next()
}

3. Avoid overly broad matchers

❌ Bad pattern:

matcher: ['/:path*']

✅ Recommended:

Only match routes that actually need Proxy handling.
Exclude all internal Next.js paths (_next, _rsc, _vercel) and static assets.

4. Optional: Hard navigation fallback

For extra safety in production:

// client-side fallback
router.push(url, { scroll: true })

// or fallback for edge cases
window.location.href = url

🔹 Validation Checklist

After implementing:

✅ _rsc requests should bypass Proxy completely
✅ No more router state header parse errors in Vercel logs
✅ Client-side App Router navigation is stable
✅ Hard reloads remain rare or zero

📌 Notes / Answers to Your Questions

Known bug?
- Not documented as a bug, but widely observed in production with App Router + Proxy.
Fallback behavior?
- Hard navigation fallback exists but may not always trigger if headers are corrupted upstream.
No-op Proxy safety?
- Not safe for broad matchers. Even no-op execution can break _rsc requests.

Summary: The fix is to exclude _rsc requests from Proxy, narrow your matcher, and optionally add a runtime guard inside proxy.ts. This ensures App Router navigations work reliably on Vercel.

Code Example

Operating System:
  Platform: darwin
  Arch: arm64

Binaries:
  Node: 24.x
  pnpm: 10.28.1

Relevant Packages:
  next: 16.2.0
  react: 19.2.4
  react-dom: 19.2.4
  @sentry/nextjs: 10.45.0

Deployment:
  Vercel production
  App Router
  Proxy (`proxy.ts`) enabled

RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

No minimal repro yet. We have a production app on Vercel and can provide more details if needed.

To Reproduce

We have a Next.js App Router app on Vercel using proxy.ts.

Observed production behavior on March 20, 2026:

Client-side App Router navigations make _rsc requests such as:
- /oppdrag/mine/innsalg?_rsc=2vvao
- /oppdrag/detaljer/<id>?_rsc=nisoz
Some of these requests fail with:
- Error: The router state header was sent but could not be parsed.
In Vercel logs, several of these failures are tagged as serverless-middleware / Proxy-layer requests.
Our proxy.ts does not read or modify internal RSC headers. It only handles:
- old host redirect
- viewToken query redirect
- idfy-jwt query redirect
- /hjelpesenter-intercom redirect
Before mitigation, the Proxy matcher was broad enough that it ran for almost every non-static route.
After narrowing the matcher so normal App Router routes no longer invoke Proxy, this class of errors appears to stop.

Current vs. Expected behavior

Current:

Normal browser App Router navigations intermittently fail with The router state header was sent but could not be parsed.
The affected requests are ordinary _rsc navigations from real browsers.
They are often logged as Proxy / middleware-related requests on Vercel.

Expected:

If Proxy does not touch RSC internals, normal App Router navigations should not fail due to router state parsing simply because Proxy executed for that route.
Either the navigation should succeed, or Next should recover via a hard navigation if this is a deployment-skew case.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64

Binaries:
  Node: 24.x
  pnpm: 10.28.1

Relevant Packages:
  next: 16.2.0
  react: 19.2.4
  react-dom: 19.2.4
  @sentry/nextjs: 10.45.0

Deployment:
  Vercel production
  App Router
  Proxy (`proxy.ts`) enabled

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

App Router, Routing, Proxy / Middleware, Vercel

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

Production

Additional context

A few concrete observations:

The failing requests are real App Router _rsc navigations with normal browser referers such as:
- /dashboard -> /oppdrag/mine/innsalg?_rsc=...
- /oppdrag/mine/innsalg -> /oppdrag/detaljer/<id>?_rsc=...
The same routes also succeed in many other _rsc requests, so the route itself is not generally broken.
Backend logs do not show correlated failures, which suggests the error is happening inside Next/Vercel before route code or downstream backend logic.
We also confirmed locally that Next throws this exact error from parseAndValidateFlightRouterState.

What makes this feel framework-related is the strong correlation with Proxy coverage:

broad Proxy matcher -> intermittent router state header failures
narrow Proxy matcher -> failures appear to go away

One important detail:

Next docs say Proxy runs before rendering, and that internal RSC headers such as next-router-state-tree are stripped from request.headers inside Proxy.
So from the app side, there is not much we can do besides changing whether Proxy runs at all for those routes.

Questions:

Is there a known bug where App Router _rsc navigations can fail with The router state header was sent but could not be parsed when Proxy executes for that route, even if Proxy does not inspect internal headers?
Is this expected to be handled by deployment skew protection / hard navigation fallback instead?
Would a no-op Proxy with a broad matcher be expected to be safe for App Router navigations on Vercel?

Related threads I found:

Discussion #54751: reverse proxy + same exact error
PR #86990: improved diagnostics for this exact error
Discussion #59099 / Issue #75541: deployment skew / reload behavior that may be related

If needed, I can try to reduce this to a minimal repro with:

App Router
Vercel deployment
broad proxy.ts matcher
client-side navigation between pages

extent analysis

Fix Plan

To resolve the issue with App Router navigations failing with The router state header was sent but could not be parsed when Proxy executes for that route, follow these steps:

Narrow the Proxy matcher: Ensure the Proxy matcher is specific enough to only run for routes that require it, avoiding unnecessary execution for normal App Router routes.
Verify Proxy implementation: Review the proxy.ts file to confirm it does not read or modify internal RSC headers.
Test with a no-op Proxy: Create a no-op Proxy with a broad matcher to test if the issue persists, helping to isolate the problem.

Example code for a no-op Proxy:

// proxy.ts
export default async function proxy(req: Request) {
  // No-op implementation, simply return the original request
  return req;
}

Verification

To verify the fix, monitor the production application for the The router state header was sent but could not be parsed error after implementing the narrowed Proxy matcher and no-op Proxy test. If the error rate decreases or disappears, the fix is successful.

Extra Tips

Regularly review and update the Proxy matcher to ensure it remains specific and efficient.
Consider implementing deployment skew protection and hard navigation fallback to handle potential future issues.
Keep an eye on related threads and discussions, such as #54751, #86990, and #75541, for potential updates and solutions.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#api #ssr #installation #tensor shape #autograd error #integration issue #index setup #retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.