Turbopack and single-locale middleware bypass in Next.js
A single entry in i18n.locales can change how request handling flows through a Next.js App Router build. In the Turbopack path, that can leave middleware or proxy checks out of the request path before authentication runs. The result is awkward in the worst way: a route still looks protected, but the control point never sees the request.
Why a single i18n locale changes the middleware path
Locale handling is usually harmless until it becomes a routing shortcut. With one configured locale, Turbopack can take a different path through App Router request handling, and that path can skip the middleware stage that a guard depends on. If auth sits behind that hook, the request reaches the page without passing the check.
Where Turbopack handles locale routing differently
The issue is not the locale itself. It is the interaction between one-locale configuration, build-time routing, and the point at which middleware is attached to the request flow. Once that path changes, a proxy or auth layer that expects every request to pass through middleware no longer has the same coverage.
That leaves a narrow but serious failure mode. The page still loads. The check still exists. It just does not run for that request path.
Why App Router checks can be skipped before auth runs
App Router auth logic often assumes middleware is the first gate. When the request bypasses that gate, any later check only helps if the page or action repeats the control. Many setups do not. They treat middleware as the boundary, then rely on it to block unauthorised access before the route handler or page code does anything useful.
That is a bad assumption once the build changes the route path.
What this bypass means for protected routes
Protected routes are only protected if the request actually crosses the control point. A bypass means a page can be reached without the middleware that was meant to stop it. That is a route guard problem, not a cosmetic bug.
Requests that reach pages without passing middleware
When a request arrives by a path that skips middleware, the usual auth checks never fire. That can expose pages, actions, or internal logic that were only meant to run after a proxy decision. It also makes testing misleading, because the route may look locked down in one build and exposed in another.
The practical risk is simple. If the middleware is the only thing standing between a request and a protected page, the page is not protected once that middleware is bypassed.
The difference between a route guard and an actual control point
A route guard can be useful, but it is not a control point unless every relevant request passes through it. Middleware, proxy logic, and auth checks need to sit in the same path, not as separate assumptions stitched together after the fact. If one build route can miss the guard, the guard has failed as a boundary.
That is why the fix is not just “add auth”. The real job is to make sure the auth check runs on the path the app actually uses after build and deployment.
Close the gap in the deployment and test it
Treat the locale setup as part of the security boundary, not just a content setting. A single locale in i18n.locales can change request handling enough to matter, so the build needs to be checked with that in mind. If Turbopack is in play, do not assume the middleware path matches a non-Turbopack build.
Re-check auth and proxy behaviour after each build change
Re-test protected routes after any build, routing, or locale change. Check that middleware still runs before the page or action path. Check that proxy behaviour still blocks the same requests in the same place. If the app depends on App Router middleware for authentication checks, that dependency needs to be verified again when the build system changes.
The boundary is only real when the request path matches the one being tested.
