Next.js 16 replaced middleware.ts with proxy.ts

If you are upgrading to Next.js 16 and your middleware.ts has quietly stopped running, it is not broken — it is no longer the file Next looks for. The concept survives under a new name, a new export, and a different runtime.

#What actually changed

The rename is the visible part. The runtime move is the part that changes what you can write: on Node you are no longer confined to the Edge subset, so Node built-ins and libraries that depend on them work in a file where they previously could not.

#The shape of the new file

import { NextResponse, type NextRequest } from "next/server";

export function proxy(request: NextRequest) {
  const res = NextResponse.next();
  res.headers.set("X-Robots-Tag", "noindex, nofollow, noarchive");
  return res;
}

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

#The matcher is read statically

This is the one that cost me real time. config.matcher is not evaluated at runtime — Next reads it out of the source at build time, before any module graph exists. That means it cannot reference anything imported.

// ✗ Does not work. ADMIN_PATH is an import; the build-time reader
//   cannot resolve it, and the matcher ends up wrong or empty.
import { ADMIN_PATH } from "@/lib/admin-path";
export const config = { matcher: [`${ADMIN_PATH}/:path*`] };

// ✓ Works. The literal has to be present in this file.
export const config = { matcher: ["/desk-4f7a/:path*"] };

If you keep a path constant in a shared module — which you should, if several files need it — the matcher becomes a deliberate duplication of that value. Comment it as such at both ends, because it looks exactly like the kind of duplication a future reader will helpfully refactor away.

#Migrating in practice

1. Rename middleware.ts to proxy.ts, keeping it at the project root.
2. Rename the exported function to proxy and make sure it is a named export.
3. Inline any imported constants used inside config.matcher as string literals.
4. Re-check anything that assumed the Edge runtime — the file now runs on Node.
5. Verify against a production build, not next dev.

#Why the rename is the right call

"Middleware" was borrowed from Express, where it means a chain of handlers each calling the next. Next's version was never that. It was one function, running once, in front of routing — closer to a reverse proxy than to a middleware stack, and the name led people to expect composition that was never there.

proxy describes what the file actually is. Renames are annoying exactly once; a misleading name is annoying every time somebody new reads the code.