Esempi funzionanti di proxy.ts per Next.js 16, il file che ha sostituito middleware.ts: redirect di autenticazione, routing per paese, cookie A/B, rilevamento della lingua, matcher e un simulatore.
In Next.js 16 il file middleware si chiama proxy.ts ed esporta una funzione chiamata proxy; middleware.ts è deprecato e un codemod lo rinomina. La funzione riceve una NextRequest e può fare redirect, rewrite, impostare header o cookie, oppure restituire una risposta. Un config.matcher limita i percorsi su cui viene eseguita. Ora usa per impostazione predefinita il runtime Node.js.
Cosa è cambiato in Next.js 16
Molte risposte online descrivono ancora middleware.ts sul runtime Edge. Gli esempi qui usano il nome di file attuale, funzionano così come sono scritti e restano abbastanza brevi da adattare. Prova il simulatore per vedere quale ramo di un proxy combinato scatta per una data richiesta prima di pubblicarlo.
Il nome sì. La versione 16 depreca la convenzione del file middleware e la rinomina in proxy, con le stesse API di richiesta e risposta. I vecchi file middleware.ts dovrebbero essere migrati, e il codemod ufficiale rinomina sia il file sia la funzione esportata.
Il team di Next.js spiega che la parola middleware veniva confusa con il middleware di Express e ne incoraggiava un uso eccessivo. Proxy descrive un confine di rete davanti all'app, e lo consigliano come ultima risorsa quando nessun'altra API è adatta.
No. Proxy usa Node.js per impostazione predefinita, e impostare l'opzione di segmento runtime in un file proxy genera un errore. Questo significa anche che ora lì funzionano le librerie solo Node, una lamentela comune sul vecchio middleware solo Edge.
Solo come primo filtro. La guida all'autenticazione di Next.js consiglia di leggere il cookie di sessione nel proxy per redirect rapidi, poi di verificare di nuovo la sessione in un livello di accesso ai dati, nelle Server Actions e nei Route Handlers. Le Server Functions escluse dal matcher saltano del tutto il proxy.
No. La tabella delle piattaforme nella documentazione indica l'export statico come non supportato, perché non c'è un server che lo esegua. Server Node e Docker sono supportati, e gli altri hosting dipendono dal loro adapter.
Come si comportano i percorsi di config.matcher
Un controllo ottimistico: cerca solo il cookie di sessione e ricorda dove stava andando il visitatore.
Il visitatore mantiene l'URL /pricing ma vede la pagina UE. L'header del paese mostrato qui è quello aggiunto da Vercel; altri hosting usano un nome di header proprio.
Al visitatore viene assegnato un gruppo una sola volta, il cookie lo mantiene lì e un rewrite serve la variante allo stesso URL.
I percorsi che iniziano già con una lingua supportata passano. Tutto il resto viene reindirizzato usando la prima voce corrispondente di Accept-Language.
Impostare gli header dentro l'opzione request li rende leggibili con headers() nella route, senza esporli al browser.
Esempio di auth: percorso protetto e nessun cookie di sessione.
Esempio per paese: {country} è nell'elenco UE, quindi la pagina UE viene servita allo stesso URL.
Esempio A/B: il visitatore è nel gruppo {bucket}, e un cookie lo mantiene lì.
Escluso dal matcher della lingua, quindi la richiesta prosegue invariata.
Esempio di lingua: il percorso ha già una lingua supportata.
Esempio di lingua: la prima lingua supportata nell'header è {locale}.
Imposta un percorso, un cookie di sessione, un paese e una lingua del browser, e scopri se gli esempi qui sotto lascerebbero passare la richiesta, la reindirizzerebbero o farebbero un rewrite.
Percorso della richiesta
Header del paese (x-vercel-ip-country)
Header Accept-Language
Gruppo del cookie A/B
La richiesta ha un cookie di sessione
Inizia gratis · Nessuna carta di credito richiesta