Straightforward gatekeeper logic: check the path, check the session, redirect if there's no user. But nothing was happening — unauthenticated requests sailed right into the dashboard.
The debugging process
Re-read the logic first, not the plumbing. Before touching imports or config, I re-checked the actual conditions, was isDashboardPage matching correctly, was session?.user the right check. Logic held up. So the bug wasn't in what the code did, it was in whether the code ran at all. That reframed the problem. If the logic is sound but has zero effect, the function likely isn't being invoked. That points away from application logic and toward file location/convention.
Checked where the file actually lived. proxy.ts was sitting inside lib/, not at the project root. Found the actual constraint. In Next.js 16, middleware.ts was renamed to proxy.ts, and it has to live at the project root (or inside src/, next to app) to be picked up as the framework's request-interception layer. Nested inside lib/, Next.js never registers it, it's just an unused file that happens to export a function.
Fix: moved proxy.ts to the root. Immediately started intercepting requests as expected.
Why this matters, not just as a bug fix
This isn't a cosmetic rename. proxy.ts runs before any route or page renders, before your dashboard, your API routes, even static assets get served. It's the one place in a Next.js app where you can stop a request before it costs you anything downstream: no wasted render, no wasted DB call, no exposure of protected content.
For a real product, that's the difference between:
A page that looks protected (e.g. a client-side check that flashes the dashboard for a frame before redirecting), and
A boundary that's actually enforced at the network edge, where an unauthenticated request never reaches protected logic at all.
That's the business case in one line: gatekeeping at the proxy layer isn't just about UX polish, it's what keeps unauthorized users from ever touching paid features, private data, or admin routes, regardless of what a client bypasses.
Takeaway for the post: when a function "does nothing" despite correct logic, don't just review the code, review whether the framework is even calling it. File location and naming conventions are invisible failure points that produce no error message, just silence.
Top comments (0)