Exemplos funcionais de proxy.ts para o Next.js 16, o arquivo que substituiu o middleware.ts: redirecionamentos de autenticação, roteamento por país, cookies de A/B, detecção de idioma, matchers e um simulador.
No Next.js 16, o arquivo de middleware se chama proxy.ts e exporta uma função chamada proxy; o middleware.ts está obsoleto e um codemod faz a renomeação. A função recebe um NextRequest e pode redirecionar, reescrever, definir headers ou cookies, ou retornar uma resposta. Um config.matcher limita em quais caminhos ela roda. Agora ela usa o runtime do Node.js por padrão.
O que mudou no Next.js 16
Muitas respostas na internet ainda descrevem o middleware.ts no runtime Edge. Os exemplos aqui usam o nome de arquivo atual, rodam como estão escritos e são curtos o bastante para adaptar. Use o simulador para ver qual ramo de um proxy combinado é acionado para uma requisição antes de publicar.
O nome está. A versão 16 torna obsoleta a convenção de arquivo middleware e a renomeia para proxy, com as mesmas APIs de requisição e resposta. Espera-se que os arquivos middleware.ts antigos sejam migrados, e o codemod oficial renomeia tanto o arquivo quanto a função exportada.
A equipe do Next.js diz que a palavra middleware era confundida com middleware do Express e incentivava o uso excessivo. Proxy descreve uma fronteira de rede na frente do app, e eles o recomendam como último recurso quando nenhuma outra API serve.
Não. O proxy usa Node.js por padrão, e definir a opção de segmento runtime em um arquivo de proxy gera um erro. Isso também significa que bibliotecas exclusivas do Node agora funcionam ali, o que era uma reclamação comum sobre o antigo middleware só para Edge.
Só como primeiro filtro. O guia de autenticação do Next.js recomenda ler o cookie de sessão no proxy para redirecionamentos rápidos e depois verificar a sessão de novo em uma camada de acesso a dados, nas Server Actions e nos Route Handlers. Server Functions excluídas pelo matcher pulam o proxy por completo.
Não. A tabela de plataformas da documentação lista static export como não suportado, porque não há servidor para rodá-lo. Servidores Node e Docker são suportados, e as outras hospedagens dependem do adaptador delas.
Como os caminhos de config.matcher se comportam
Uma verificação otimista: ela só procura o cookie de sessão e lembra para onde o visitante estava indo.
O visitante mantém a URL /pricing, mas vê a página da UE. O header de país mostrado aqui é o que a Vercel adiciona; outras hospedagens usam um nome de header próprio.
O visitante é atribuído a um grupo uma vez, o cookie o mantém nele e uma reescrita serve a variante na mesma URL.
Caminhos que já começam com um locale suportado seguem adiante. Todo o resto é redirecionado usando a primeira entrada correspondente do Accept-Language.
Definir headers dentro da opção request permite lê-los com headers() na rota, sem expô-los ao navegador.
Exemplo de autenticação: caminho protegido e nenhum cookie de sessão.
Exemplo de país: {country} está na lista da UE, então a página da UE é servida na mesma URL.
Exemplo de A/B: o visitante está no grupo {bucket}, e um cookie o mantém lá.
Excluído pelo matcher de idioma, então a requisição continua intacta.
Exemplo de idioma: o caminho já tem um locale suportado.
Exemplo de idioma: o primeiro idioma suportado no header é {locale}.
Defina um caminho, um cookie de sessão, um país e um idioma do navegador e veja se os exemplos abaixo deixariam a requisição seguir, a redirecionariam ou a reescreveriam.
Caminho da requisição
Header de país (x-vercel-ip-country)
Header Accept-Language
Grupo do cookie de A/B
A requisição tem cookie de sessão
Comece grátis · Sem cartão de crédito