Next.js Middleware/Proxy redirect loop at /login in Production, but works perfectly on npm start locally

[anshul3212]

Summary

Hi everyone,
I am facing a strange routing issue where my application works flawlessly in local development (next dev) and during local production simulation (npm run build && npm run start). However, once deployed to my production environment(amplify), it breaks with a redirect loop error specifically when handling the /login route.
The Setup:

• Framework: Next.js (App Router)
• Structure: Root page (app/page.tsx) handles a simple fallback redirect('/login').
• Routing Interception: I have configured my file to intercept auth cookies. If a session token exists, users should go to /dashboard. If no token exists, they go to /login.

The Bug:
When i am logged in i go to dashboard and i have make the public pages like /login,/verify-otp etc but when i am logged in and try to go to the login page my middleware is not working and it is going to the login page even if i have to cookies for login the catch is that the middle ware is working on other public routes but not for login only.

Has anyone encountered this specific environment mismatch between local npm start and live hosting environments? Could this be related to Edge runtime deployment restrictions, or how Next.js handles production cookie headers differently than localhost? Any help or pointers would be greatly appreciated!

Additional information

No response

Example

No response

[kuldeeprajput-dev]

This looks more like a matcher or Amplify configuration issue than a cookie issue. Make sure /login is included in your matcher and avoid redirecting to the current route:

export function proxy(request: NextRequest) {
  const path = request.nextUrl.pathname
  const token = request.cookies.get("session")?.value

  if (token && path === "/login") {
    return NextResponse.redirect(new URL("/dashboard", request.url))
  }

  if (!token && path.startsWith("/dashboard")) {
    return NextResponse.redirect(new URL("/login", request.url))
  }

  return NextResponse.next()
}

export const config = {
  matcher: ["/login", "/verify-otp", "/dashboard/:path*"],
}

The [Next.js Proxy docs](https://nextjs.org/docs/app/api-reference/file-conventions/proxy) say: “The matcher option allows you to target specific paths for the Proxy to run on.”

Also ensure the session cookie has path: "/". Then check Amplify’s Rewrites and redirects section for a /login or SPA catch-all rule.

One more important point: [Amplify currently documents support only through Next.js 15](https://docs.aws.amazon.com/amplify/latest/userguide/ssr-amplify-support.html). If you use Next.js 16 with proxy.ts, the production environment may not fully support it yet.

[anshul3212]

export const config = {
matcher: [
"/",
"/login", // Explicitly monitor the login route
"/((?!_next/static|_next/image|favicon.ico|..(?:svg|png|jpg|jpeg|gif|webp)$).)",
],
};

this is the matcher and also the problem is coming sometime for login only sometime it is working and sometime not and yes i am using next js 16 and also the same problem is not occurring on other public routes and it is only not working on production amplify but working on local(npm run and start)

[kuldeeprajput-dev]

Thanks, the matcher looks fine. Does this happen when using a <Link>, router.push(), or the browser Back button? Next.js [automatically prefetches routes in production](https://nextjs.org/docs/app/guides/prefetching), so /login may be restored from the router/browser cache without a new Proxy request.

Try disabling prefetch for auth links:

<Link href="/login" prefetch={false}>Login</Link>

After successful login, use router.replace("/dashboard") instead of push, then call router.refresh().

Also test /login with a hard refresh. If that redirects correctly, the issue is client-side caching, not the matcher. If it still fails, log request.cookies.has("your-cookie-name") in Proxy without logging the token to verify whether Amplify receives the cookie.

[anshul3212]

import { redirect } from "next/navigation";

export default function Page() {
redirect("/login");
}

this is my login that i have added on root page app/page.tsx
and after successfull login i am doing this router.push("/dashboard");

[amrishkhan05]

https://www.amrishkhan.dev/blog/fix-nextjs-middleware-redirect-loop-why-your-login-page-keeps-redirecting-3m8d

i have written an article on this issue. Hope it helps

[icyJoseph]

Do you have any logs or headers you see during the navigation? Often when next build + start diverges from the deployment, we have to look at the layers in between.

Are you able to curl this endpoint while pretending to be logged in as well? Like login, and then in the Chrome Dev tools you can copy a request as curl — https://developer.chrome.com/blog/replay-a-network-request-in-curl — careful with LLM advice too, it often doesn't ask for more context, and over fixates in framework details and such. Let's try to debug this first.

[anshul3212]

sorry for the late reply .I want to confirm that we are doing this to know my proxy issue ?

[icyJoseph]

Yes, we want to understand what's happening. We need to see what headers arrive to the login endpoint, you can preserve network logs in the chrome dev tools to see the request/response headers in the redirects.

[anshul3212]

so i need to give you the generated cUrl?

[tpriyankaa]

This is a classic issue that occurs because of how production Edge CDNs (like AWS Amplify or CloudFront) handle cookies and caching differently than your local Node.js server.

When you test locally (npm start), your server evaluates cookies on every single request. In production, AWS Amplify caches redirects (307/308) at the edge CDN level. If it caches a redirect response without verifying the user's Cookie header, it creates an infinite redirect loop.

Here are the two steps to fix this loop:

1. Fix the Middleware Caching Loop

Update your middleware.ts to ensure that you are explicitly setting the x-middleware-cache: no-cache header on redirects. This forces the edge server to evaluate the auth state dynamically instead of serving a cached loop.

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('session_token')?.value;
  const { pathname } = request.nextUrl;

  // 1. User is logged in, but tries to access public auth pages (/login, /verify-otp)
  if (token && (pathname === '/login' || pathname === '/verify-otp' || pathname === '/')) {
    const response = NextResponse.redirect(new URL('/dashboard', request.url));
    // CRITICAL: Prevent Edge CDN caching of this redirect response
    response.headers.set('x-middleware-cache', 'no-cache');
    return response;
  }

  // 2. User is NOT logged in, but tries to access protected dashboard pages
  if (!token && pathname.startsWith('/dashboard')) {
    const response = NextResponse.redirect(new URL('/login', request.url));
    response.headers.set('x-middleware-cache', 'no-cache');
    return response;
  }

  return NextResponse.next();
}

export const config = {
  // Ensure middleware excludes internal assets but targets your routes perfectly
  matcher: ['/((?!_next/static|_next/image|favicon.ico|api).*)'],
};

2. Configure AWS Amplify to Forward Cookies

By default, AWS Amplify might strip or ignore incoming headers/cookies before sending the request downstream to your Next.js serverless architecture.

1. Go to your AWS Amplify Console.
2. Navigate to Hosting > Rewrites and redirects or App Settings > Cache Settings.
3. Ensure your Cache Policy is configured to Forward all cookies (specifically your session cookie) to the origin runtime. If cookies aren't forwarded, request.cookies.get() will return undefined on the Edge layer, triggering your fallback redirect endlessly.

[tpriyankaa]

No need to share your full cURL command here!

Instead, you just need to ensure your AWS Amplify or Edge CDN configuration is explicitly forwarding your authentication cookies downstream. If the Edge layer strips the cookies, the middleware will always read them as undefined and throw you into that endless redirect loop.

Try updating your middleware.ts with the x-middleware-cache: no-cache header block provided above, push the update to production, and let me know if that instantly breaks the redirect loop for you!

[anshul3212]

ok

[anshul3212]

i have added this but again the same issue is happening when i login and goes to dashboard then when i hit /login goes to login

[DevelopmentEsmarkFinch]

Two things nobody's flagged yet.

First — you mentioned you're on Next.js 16. In 16, middleware.ts was renamed to proxy.ts with an exported proxy() function. If you've been editing middleware.ts, that file isn't running, which would explain why the fix above changed nothing. Worth confirming which filename you actually have.

Second — x-middleware-cache: no-cache won't help here. That was an internal for the client router cache, not a CDN header, and CloudFront ignores it.

To confirm what's happening, following on from @icyJoseph's request: hit /login while logged in with devtools open, preserve log, and check the response headers on the /login document request. If you see x-cache: Hit from cloudfront, the edge is serving cached static HTML and your proxy never ran. /login has no dynamic markers so Next prerenders it, and Amplify caches it with cookies stripped from the cache key.

If that's the case, two fixes:

Force /login dynamic so it's never edge-cached — add export const dynamic = 'force-dynamic' to app/login/page.tsx.
Or in Amplify, add a cache policy for /login that includes your session cookie in the cache key (or set Cache-Control: no-store on it).

Also worth noting Amplify's docs currently list support through Next.js 15, so Next 16 + proxy.ts may have rough edges there regardless.

[anshul3212]

Thanks now it is working i added the force dynamic in my login and it is working now

[icyJoseph]

you mentioned you're on Next.js 16. In 16, middleware.ts was renamed to proxy.ts with an exported proxy() function. If you've been editing middleware.ts, that file isn't running, which would explain why the fix above changed nothing. Worth confirming which filename you actually have.

The middleware file is deprecated, not removed.

[iam-manish]

I think there is one important variable here that is worth isolating before
changing the Proxy logic further: you're running Next.js 16 on AWS Amplify.

AWS currently documents Amplify Hosting compute support for Next.js versions
12 through 15. So even though the Next.js 16 application builds and most routes
work, the deployment is outside Amplify's currently documented supported range.

That would also explain why:

• next build && next start works locally
• your matcher works for the other routes
• /login behaves inconsistently only after Amplify deployment
• changing middleware/Proxy cache headers did not solve the issue

I would test this before making additional authentication changes:

1. Deploy the same branch using Next.js 15.
2. Keep the exact same Proxy/matcher and cookie logic.
3. Test /login while authenticated.
4. Compare the request/response headers with the Next.js 16 deployment.

You can also verify the Proxy independently with a request containing the real
session cookie:

curl -I
-H "Cookie: session_token="
https://your-domain.com/login

The expected response should be a redirect to /dashboard.

If Next.js 15 redirects correctly while the identical Next.js 16 deployment
does not, you've isolated this to the hosting/runtime compatibility layer rather
than your matcher.

I'd also avoid relying on x-middleware-cache: no-cache as the main fix here,
especially since you already tested it and the issue remained.

Your matcher itself appears broad enough to cover /login.

So my debugging order would be:

Next.js 15 on Amplify
↓
same auth cookie
↓
same /login request
↓
compare response headers
↓
then investigate Proxy logic only if behavior is identical

Given that AWS currently only documents support through Next.js 15, I would
rule that out first.