Adiós middleware, hola proxy.ts

En Next.js 16, middleware.ts pasa a llamarse proxy.ts. No es solo un cambio de nombre: es una corrección de expectativas. "Middleware" sugería un pipeline tipo Express que intercepta cada request con acceso total al servidor; en realidad siempre fue una capa ligera que corre en el Edge Runtime antes de que Next.js decida qué ruta renderizar. El nuevo nombre, proxy, describe justo eso.

Qué cambia en la práctica

La API es la misma. Sigue siendo una función que recibe un NextRequest y devuelve un NextResponse, sigue corriendo en Edge Runtime (sin acceso a APIs de Node.js como fs o crypto completo), y sigue usando matcher para decidir en qué rutas se ejecuta.

// ❌ Next.js 15: middleware.ts
import { NextRequest, NextResponse } from 'next/server';

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

export const config = {
  matcher: ['/dashboard/:path*'],
};

// ✅ Next.js 16: proxy.ts
import { NextRequest, NextResponse } from 'next/server';

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

export const config = {
  matcher: ['/dashboard/:path*'],
};

Cambia el nombre del archivo (proxy.ts en la raíz del proyecto o en src/) y el nombre de la función exportada (proxy en vez de middleware). El resto —cookies, headers, redirects, rewrites, NextResponse.next()— es idéntico.

Migración sin sustos

Next.js 16 sigue soportando middleware.ts durante un periodo de transición: tu proyecto compila igual, pero verás un aviso de deprecación en build y en dev. El codemod oficial hace el cambio por ti:

npx @next/codemod@latest middleware-to-proxy .

Renombra el archivo y la función exportada. Si tienes lógica compartida importada desde middleware.ts en otros archivos, actualiza esos imports a mano después de correr el codemod.

Por qué el cambio importa

El nombre antiguo generaba una duda recurrente: "¿puedo hacer una query a la base de datos en el middleware?". La respuesta siempre fue no —Edge Runtime no lo permite bien, y no es el lugar—, pero "middleware" invitaba a pensarlo. "Proxy" deja claro el rol: redirigir, reescribir, leer/escribir cookies y headers, y devolver rápido. Cualquier cosa más pesada (auth completa, fetch a APIs internas, lógica de negocio) sigue perteneciendo al Server Component o Route Handler correspondiente.

Diferencias clave

---

Si tu middleware.ts de hoy ya es delgado —auth checks, redirects, geolocalización, feature flags por cookie— el cambio a proxy.ts es mecánico. Si es grueso, el mensaje de Next.js 16 es una señal para mover esa lógica a donde realmente pertenece: un Server Component o un Route Handler con Node.js runtime completo.