Funktionierende proxy.ts-Beispiele für Next.js 16, die Datei, die middleware.ts ersetzt hat: Auth-Redirects, Länder-Routing, A/B-Cookies, Spracherkennung, Matcher und ein Simulator.
In Next.js 16 heißt die Middleware-Datei proxy.ts und exportiert eine Funktion namens proxy; middleware.ts ist veraltet, und ein Codemod benennt sie um. Die Funktion erhält einen NextRequest und kann umleiten, umschreiben, Header oder Cookies setzen oder eine Antwort zurückgeben. Ein config.matcher legt fest, für welche Pfade sie läuft. Standardmäßig nutzt sie jetzt die Node.js-Runtime.
Was sich in Next.js 16 geändert hat
Viele Antworten im Netz beschreiben noch middleware.ts auf der Edge-Runtime. Die Beispiele hier verwenden den aktuellen Dateinamen, laufen so, wie sie geschrieben sind, und bleiben kurz genug zum Anpassen. Probiere den Simulator aus, um vor dem Deployment zu sehen, welcher Zweig eines kombinierten Proxys bei einer bestimmten Anfrage greift.
Der Name schon. Version 16 erklärt die Dateikonvention middleware für veraltet und benennt sie in proxy um, mit denselben Request- und Response-APIs. Alte middleware.ts-Dateien sollen umziehen, und der offizielle Codemod benennt sowohl die Datei als auch die exportierte Funktion um.
Laut dem Next.js-Team wurde der Begriff Middleware mit Express-Middleware verwechselt und hat zu übermäßigem Einsatz verleitet. Proxy beschreibt eine Netzwerkgrenze vor der App, und das Team empfiehlt sie als letztes Mittel, wenn keine andere API passt.
Nein. Proxy nutzt standardmäßig Node.js, und das Setzen der Segment-Option runtime in einer Proxy-Datei löst einen Fehler aus. Dafür funktionieren dort jetzt auch reine Node-Bibliotheken, was an der alten, nur auf Edge laufenden Middleware oft bemängelt wurde.
Nur als erster Filter. Der Authentifizierungs-Leitfaden von Next.js empfiehlt, das Session-Cookie im Proxy für schnelle Umleitungen zu lesen und die Session dann in einer Datenzugriffsschicht, in Server Actions und Route Handlers erneut zu prüfen. Server Functions, die der Matcher ausschließt, umgehen den Proxy vollständig.
Nein. Die Plattformtabelle in der Dokumentation führt den statischen Export als nicht unterstützt, weil es keinen Server gibt, der ihn ausführt. Node-Server und Docker werden unterstützt, bei anderen Hosts hängt es vom jeweiligen Adapter ab.
Wie sich config.matcher-Pfade verhalten
Eine optimistische Prüfung: Sie sucht nur nach dem Session-Cookie und merkt sich, wohin der Besucher wollte.
Der Besucher behält die URL /pricing, sieht aber die EU-Seite. Der hier gezeigte Länder-Header ist der, den Vercel hinzufügt; andere Hosts verwenden einen eigenen Header-Namen.
Ein Besucher wird einmal einer Gruppe zugeteilt, das Cookie hält ihn dort, und ein Rewrite liefert die Variante unter derselben URL aus.
Pfade, die bereits mit einer unterstützten Sprache beginnen, werden durchgelassen. Alles andere wird anhand des ersten passenden Accept-Language-Eintrags umgeleitet.
Header, die innerhalb der Option request gesetzt werden, sind in der Route mit headers() lesbar, ohne dass der Browser sie sieht.
Auth-Beispiel: geschützter Pfad und kein Session-Cookie.
Länder-Beispiel: {country} steht auf der EU-Liste, daher wird die EU-Seite unter derselben URL ausgeliefert.
A/B-Beispiel: Der Besucher ist in Gruppe {bucket}, und ein Cookie hält ihn dort.
Vom Sprach-Matcher ausgeschlossen, daher läuft die Anfrage unverändert weiter.
Sprach-Beispiel: Der Pfad enthält bereits eine unterstützte Sprache.
Sprach-Beispiel: Die erste unterstützte Sprache im Header ist {locale}.
Lege einen Pfad, ein Session-Cookie, ein Land und eine Browsersprache fest und sieh, ob die Beispiele unten die Anfrage durchlassen, umleiten oder umschreiben würden.
Anfragepfad
Länder-Header (x-vercel-ip-country)
Accept-Language-Header
Gruppe im A/B-Cookie
Anfrage hat ein Session-Cookie
Kostenlos starten · Keine Kreditkarte nötig