Działające przykłady proxy.ts dla Next.js 16, pliku, który zastąpił middleware.ts: przekierowania auth, routing według kraju, ciasteczka A/B, wykrywanie języka, matchery i symulator.
W Next.js 16 plik middleware nazywa się proxy.ts i eksportuje funkcję o nazwie proxy; middleware.ts jest przestarzały, a codemod zmienia jego nazwę. Funkcja otrzymuje NextRequest i może przekierować, przepisać trasę, ustawić nagłówki lub ciasteczka albo zwrócić odpowiedź. config.matcher ogranicza ścieżki, dla których się uruchamia. Domyślnie działa teraz w runtime Node.js.
Co zmieniło się w Next.js 16
Wiele odpowiedzi w sieci wciąż opisuje middleware.ts w runtime Edge. Przykłady tutaj używają aktualnej nazwy pliku, działają w obecnej postaci i są na tyle krótkie, że łatwo je dostosować. Wypróbuj symulator, aby przed wdrożeniem zobaczyć, która gałąź połączonego proxy zadziała dla danego żądania.
Przestarzała jest nazwa. Wersja 16 oznacza konwencję pliku middleware jako przestarzałą i zmienia jej nazwę na proxy, z tymi samymi API żądań i odpowiedzi. Stare pliki middleware.ts powinny zostać przeniesione, a oficjalny codemod zmienia nazwę zarówno pliku, jak i eksportowanej funkcji.
Zespół Next.js mówi, że słowo middleware myliło się z middleware z Express i zachęcało do nadużywania. Proxy opisuje granicę sieciową przed aplikacją, a zespół poleca je jako ostateczność, gdy żadne inne API nie pasuje.
Nie. Proxy domyślnie używa Node.js, a ustawienie opcji segmentu runtime w pliku proxy rzuca błąd. Oznacza to też, że działają tam teraz biblioteki tylko dla Node, na co często narzekano przy starym middleware działającym wyłącznie w Edge.
Tylko jako pierwszy filtr. Przewodnik po uwierzytelnianiu w Next.js zaleca odczyt ciasteczka sesji w proxy dla szybkich przekierowań, a potem ponowną weryfikację sesji w warstwie dostępu do danych, Server Actions i Route Handlers. Server Functions wykluczone przez matcher całkowicie omijają proxy.
Nie. Tabela platform w dokumentacji wymienia eksport statyczny jako nieobsługiwany, bo nie ma serwera, który mógłby je uruchomić. Serwery Node i Docker są obsługiwane, a inne hostingi zależą od swojego adaptera.
Jak zachowują się ścieżki config.matcher
Optymistyczne sprawdzenie: szuka tylko ciasteczka sesji i zapamiętuje, dokąd odwiedzający zmierzał.
Odwiedzający zachowuje URL /pricing, ale widzi stronę dla UE. Pokazany tu nagłówek kraju dodaje Vercel; inne hostingi używają własnej nazwy nagłówka.
Odwiedzający jest raz przypisywany do grupy, ciasteczko go w niej utrzymuje, a przepisanie serwuje wariant pod tym samym URL.
Ścieżki, które już zaczynają się od obsługiwanego locale, przechodzą dalej. Wszystko inne jest przekierowywane według pierwszego pasującego wpisu Accept-Language.
Nagłówki ustawione w opcji request są czytelne przez headers() w trasie i nie trafiają do przeglądarki.
Przykład auth: chroniona ścieżka i brak ciasteczka sesji.
Przykład kraju: {country} jest na liście UE, więc strona dla UE jest serwowana pod tym samym URL.
Przykład A/B: odwiedzający jest w grupie {bucket}, a ciasteczko go w niej utrzymuje.
Wykluczone przez matcher języka, więc żądanie idzie dalej bez zmian.
Przykład języka: ścieżka ma już obsługiwane locale.
Przykład języka: pierwszy obsługiwany język w nagłówku to {locale}.
Ustaw ścieżkę, ciasteczko sesji, kraj i język przeglądarki, i zobacz, czy przykłady poniżej przepuściłyby żądanie, przekierowały je czy przepisały.
Ścieżka żądania
Nagłówek kraju (x-vercel-ip-country)
Nagłówek Accept-Language
Grupa w ciasteczku A/B
Żądanie ma ciasteczko sesji
Zacznij za darmo · Bez karty kredytowej