Critical Next.js (#82117) breaking redirects for over a year — Need core team visibility

Help
1

Hi NextJS team,

I am writing to bring urgent attention to a confirmed Next.js routing bug that heavily impacts production builds but has stalled in triage.

:police_car_light: The Problem & Production Impact

When redirect or permanentRedirect, Next.js duplicates the Location and x-nextjs-stale-time headers.

Instead of a clean redirect to /redirect, browsers and CDNs receive a malformed header, attempting to route users to /redirect,/redirect. This completely breaks user experience, navigation flows, and SEO indexing for any statically optimized redirect routes.

:magnifying_glass_tilted_left: Root Cause Already Identified

The community has already done the heavy lifting and isolated the exact lines causing this in the core repository:

  1. app-render/action-handler.ts invokes res.setHeader('Location', redirectUrl).
  2. Later, templates/app-page.ts uses a native res.appendHeader() loop on cachedData.headers without checking for existing keys, directly duplicating the field.

This issue is already tracked internally under NEXT-4749, but it has not seen engineering activity. Because this breaks core framework routing behavior out of the box, could a member of the @nextjs team look into scheduling a fix or reviewing a community PR for this?

Thank you very much

2

Hi Xydotguy,

I can’t help with internal scheduling, but the repro you described does sound narrow enough to make this actionable.

For a production workaround, I’d try to avoid the exact combination that seems to trigger the duplicate headers: render-time redirect() / permanentRedirect() inside a statically cached or force-static route.

If the redirect is known from the URL alone, moving it to next.config.js should avoid the App Router render path entirely:

module.exports = {
  async redirects() {
    return [
      {
        source: "/old-path",
        destination: "/redirect",
        permanent: true,
      },
    ]
  },
}

If it has to be conditional, I’d test returning the redirect from Proxy/Middleware or a Route Handler instead of throwing redirect() during the page render. If neither is possible, the short-term mitigation may be to opt only the affected route out of the static path until the upstream fix lands.

For the GitHub issue, the most useful extra evidence would be a tiny reproduction repo plus a version matrix like:

15.4.0: OK
15.4.1: duplicate Location
latest stable: duplicate Location
next@canary: OK or still broken

and one raw header capture:

curl -sv https://your-repro-url.example/problem-route 2>&1 | grep -i "location\|x-nextjs-stale-time"

That gives maintainers a very direct way to confirm whether the fix needs to be in the cached header replay path rather than in normal redirect handling.