Werkende proxy.ts-voorbeelden voor Next.js 16, het bestand dat middleware.ts verving: auth-redirects, routering per land, A/B-cookies, taaldetectie, matchers en een simulator.
In Next.js 16 heet het middlewarebestand proxy.ts en exporteert het een functie met de naam proxy; middleware.ts is verouderd en een codemod hernoemt het. De functie krijgt een NextRequest en kan redirecten, rewriten, headers of cookies zetten of een respons teruggeven. Een config.matcher beperkt op welke paden hij draait. Standaard gebruikt hij nu de Node.js-runtime.
Wat er veranderde in Next.js 16
Veel antwoorden online beschrijven nog middleware.ts op de Edge-runtime. De voorbeelden hier gebruiken de huidige bestandsnaam, werken zoals ze er staan en blijven kort genoeg om aan te passen. Probeer de simulator om te zien welke tak van een gecombineerde proxy voor een bepaald verzoek afgaat voordat u hem deployt.
De naam wel. Versie 16 markeert de bestandsconventie middleware als verouderd en hernoemt die naar proxy, met dezelfde API's voor request en response. Oude middleware.ts-bestanden worden geacht over te stappen, en de officiële codemod hernoemt zowel het bestand als de geëxporteerde functie.
Het Next.js-team zegt dat het woord middleware verward werd met Express-middleware en tot overmatig gebruik aanzette. Proxy beschrijft een netwerkgrens vóór de app, en ze raden het aan als laatste redmiddel wanneer geen andere API past.
Nee. Proxy gebruikt standaard Node.js, en de runtime-segmentoptie instellen in een proxybestand geeft een fout. Dat betekent ook dat libraries die alleen op Node draaien daar nu werken, wat een veelgehoorde klacht was over de oude middleware die alleen op Edge draaide.
Alleen als eerste filter. De authenticatiegids van Next.js raadt aan het sessiecookie in proxy te lezen voor snelle redirects en de sessie daarna opnieuw te controleren in een data access layer, Server Actions en Route Handlers. Server Functions die de matcher uitsluit, slaan proxy helemaal over.
Nee. De platformtabel in de documentatie vermeldt static export als niet ondersteund, omdat er geen server is om het te draaien. Node-servers en Docker worden ondersteund, en bij andere hosts hangt het af van hun adapter.
Hoe paden in config.matcher zich gedragen
Een optimistische controle: hij kijkt alleen of het sessiecookie er is en onthoudt waar de bezoeker heen wilde.
De bezoeker houdt de URL /pricing maar ziet de EU-pagina. De landheader hier is die van Vercel; andere hosts gebruiken hun eigen headernaam.
Een bezoeker krijgt één keer een groep toegewezen, het cookie houdt hem daarin, en een rewrite serveert de variant op dezelfde URL.
Paden die al met een ondersteunde locale beginnen, gaan door. Al het andere wordt geredirect op basis van de eerste passende Accept-Language-waarde.
Headers binnen de request-optie zetten maakt ze leesbaar met headers() in de route, zonder ze aan de browser te tonen.
Auth-voorbeeld: beschermd pad en geen sessiecookie.
Landvoorbeeld: {country} staat in de EU-lijst, dus de EU-pagina wordt op dezelfde URL geserveerd.
A/B-voorbeeld: de bezoeker zit in groep {bucket}, en een cookie houdt hem daar.
Uitgesloten door de taalmatcher, dus het verzoek gaat ongewijzigd door.
Taalvoorbeeld: het pad heeft al een ondersteunde locale.
Taalvoorbeeld: de eerste ondersteunde taal in de header is {locale}.
Stel een pad, een sessiecookie, een land en een browsertaal in en zie of de voorbeelden hieronder het verzoek zouden doorlaten, redirecten of rewriten.
Pad van het verzoek
Landheader (x-vercel-ip-country)
Accept-Language-header
Groep in het A/B-cookie
Verzoek heeft een sessiecookie
Gratis beginnen · Geen creditcard nodig