Cloudflare Pages po cichu porzuca _redirects powyżej 100KB

Dokumentacja Cloudflare Pages mówi, że limit to 2000 przekierowań. Nie kłamie, ale wskazuje na niewłaściwą liczbę. Limitem, który zdjął z tego serwisu krytyczne przekierowania na produkcji, był limit rozmiaru pliku 100KB, a tryb awarii jest tu najgorszy z możliwych: cichy. Żadnego błędu buildu. Żadnego ostrzeżenia przy wdrożeniu. Żadnej linii w logu. Plik _redirects wgrywa się, wdrożenie świeci na zielono, a część reguł po prostu nigdy się nie stosuje.

To polemika ze sposobem, w jaki uczy się o tym limicie. “Trzymaj się poniżej 2000 reguł” to rada, którą wszyscy powtarzają, i to ona pozwoliła naszemu plikowi urosnąć do około 157KB, podczas gdy do 2000 reguł było wciąż daleko. Liczba, która miała znaczenie, nigdy nie znalazła się w zdaniu, które obserwowaliśmy.

#Limit bajtów _redirects w Cloudflare: TL;DR w 4 punktach

• Cloudflare Pages ogranicza _redirects na trzy sposoby: 2000 reguł statycznych, 100 reguł dynamicznych i 100KB rozmiaru pliku. Pierwszy jest tym, który wszyscy cytują; trzeci jest tym, który psuje produkcję.
• Reguły poza progiem 100KB są porzucane podczas przetwarzania pliku przy wdrożeniu. Nie ma ostrzeżenia. Wdrożony plik po prostu przestaje stosować reguły od pewnej linii.
• Serwis w sześciu językach z długimi opisowymi slugami przekracza 100KB w okolicach 1200 do 1300 reguł, daleko poniżej limitu liczby reguł. Uderzasz więc w ścianę bajtów, podczas gdy panel wciąż twierdzi, że masz zapas.
• Naprawa to nie “usuń przekierowania”. To przeniesienie masowych reguł jeden-do-jednego do Pages Function, którą ogranicza skompresowany rozmiar skryptu do 1MB, a nie limit 100KB dla redirects.

#Słownik: _redirects, Pages Functions, splat, 301

Ten przypadek opiera się na kilku pojęciach platformy. Jeśli któreś jest nieznane, warto poświęcić trzydzieści sekund, bo awaria kryje się dokładnie w luce między nimi.

• _redirects - plik tekstowy w wyjściu buildu (tutaj public/_redirects), w którym każda linia to jedna reguła: ścieżka źródłowa, cel i opcjonalny kod statusu. Cloudflare Pages czyta go przy wdrożeniu i stosuje reguły na edge, zanim ruch trafi do serwisu.
• Przekierowanie statyczne - dosłowna reguła jeden-do-jednego, na przykład /old-page/ /new-page/ 301. Bez wildcardów.
• Przekierowanie dynamiczne - reguła z wildcardem * lub placeholderem :splat, na przykład /blog/* /articles/:splat 301. Korzysta z silnika szablonów ścieżek Cloudflare i jest ograniczona do 100 na plik.
• 301 - status HTTP dla przekierowania trwałego. Mówi Google, że stary URL przeniósł się na dobre i sygnał rankingowy powinien podążyć za nim do nowego URL.
• Pages Function - niewielki skrypt serverless (tutaj w functions/), który uruchamia się na edge przy każdym pasującym żądaniu. Może czytać tablicę odnośników i wystawiać przekierowania w kodzie, bez sufitu 100KB.
• _middleware.ts - Pages Function uruchamiana przy każdym żądaniu przed routingiem. Naturalne miejsce, by wykonać wyszukanie w mapie i wystawić 301, jeśli ścieżka pasuje.

Te rozróżnienia są niewidoczne, dopóki przekierowanie nie przestanie działać. Wtedy stają się całą historią.

#Jak plik _redirects o rozmiarze 157KB zepsuł produkcję

Plik nie urósł lekkomyślnie. Urósł w sposób, w jaki rośnie mapa przekierowań każdego długo żyjącego serwisu wielojęzycznego: za każdym razem, gdy oczyszczano slug, wycofywano przestarzały URL albo reorganizowano wariant językowy, dopisywano parę (stary, nowy). Sześć języków, opisowe slugi w rodzaju /pl/tworzenie-stron-internetowych-oraz-sklepow-wordpress/ i kilka lat porządków doprowadziły plik do mniej więcej 157KB i około 1890 reguł.

Nikt się nie martwił, bo 1890 to mniej niż 2000. To był błąd. Limit bajtów został przekroczony na długo przed tym, zanim limit reguł był choć blisko.

Objaw na początku nie wyglądał jak problem z przekierowaniami. Wyglądał jak trzy niepowiązane pożary:

• Google Merchant Center oznaczył dwa z dwunastu produktów jako niedostępne strony produktowe. Cele z ich feedu były przekierowaniami leżącymi blisko dołu pliku.
• Google Search Console raportował 388 adresów URL “Nie znaleziono (404)”. Spora ich część miała wpisy w _redirects, które na papierze powinny je przechwycić.
• Walidacja w GSC raz po raz kończyła się niepowodzeniem. Prosiliśmy o walidację, Google wracał do URL, trafiał na ten sam 404, bo przekierowanie nigdy nie było żywe, i odrzucał walidację. Pętla nie przerywała się sama z siebie.

Strony, szablony, build, liczba reguł, wszystko wyglądało zdrowo. Warstwa routingu została po cichu amputowana poniżej linii, na którą nikt nie patrzył.

#Jak potwierdzić, że ogon jest porzucany

Diagnostyka jest mechaniczna, gdy przestaniesz ufać plikowi, a zaczniesz ufać edge. Nie próbkuj reguł losowo; próbkuj je według pozycji.

1. Weź regułę z okolic góry _redirects, jedną ze środka i jedną z okolic dołu.
2. Wywołaj każdą ścieżkę źródłową na produkcji i odczytaj tylko kod statusu: curl -s -o /dev/null -w "%{http_code}" https://twoj-serwis/sciezka-zrodlowa/.
3. Porównaj. Na tym serwisie reguły w okolicach linii 9 do 130 zwracały czysto 301. Reguły poza mniej więcej linią 200 zwracały 404, z kilkoma fałszywymi przejściami, gdzie niepowiązana logika middleware (wykrywanie slugów międzyjęzykowych, wzorce legacy) przypadkiem łapała URL inną drogą.

Gdy góra pliku działa, a ogon zwraca 404, choć obie reguły są zatwierdzone i identyczne w kształcie, wniosek nie jest dwuznaczny: plik jest obcinany na limicie bajtów. Dokładna linia odcięcia zależy od tego, jak długa jest twoja przeciętna reguła, dlatego serwis w sześciu językach z długimi slugami uderza w nią wcześniej, niż sugeruje liczba reguł.

#Dlaczego limit bajtów jest wiążącym ograniczeniem, a nie liczba reguł

Arytmetyka to cały argument. Krótka reguła w rodzaju /a/ /b/ 301 to około 12 bajtów. Realistyczna reguła wielojęzyczna, /pl/tworzenie-stron-wordpress/ /pl/tworzenie-stron-internetowych-oraz-sklepow-wordpress/ 301, to bliżej 90 bajtów. Przy 80 do 90 bajtach na regułę 100KB wyczerpuje się w okolicach 1200 do 1300 reguł - setki poniżej 2000, które dokumentacja stawia na pierwszym planie. Limit, który obserwujesz, powinien być tym, w który uderzysz pierwszy, a dla serwisów z opisowymi slugami to bajty, nie linie.

#Co mówi dokumentacja Cloudflare, a co pomija

Dokumentacja przekierowań wymienia wszystkie trzy limity. Liczba 100KB jest tam zapisana. To, czego strona nie mówi nigdzie, to co się dzieje, gdy ją przekroczysz: reguły poza progiem są porzucane, a wdrożenie i tak kończy się sukcesem. Kontrast z limitem liczby reguł ma znaczenie. Przekrocz 2000 reguł, a build to ujawni; plik jest za duży w sposób, o którym platforma cię informuje. Przekrocz 100KB, a platforma obetnie i zachowa ciszę.

Ta asymetria to pułapka. Limit, który zgłasza błąd głośno, uczy cię go respektować. Limit, który zawodzi po cichu, uczy cię go ignorować, bo nic nigdy nie świeci na czerwono. Ta sama klasa problemów pojawia się w bliźniaczym pliku _headers, który ma własne ograniczenia rozmiaru, oraz w każdym artefakcie buildu, gdzie “wdrożyło się” myli się z “wszystko się zastosowało”. Kontrakt platformy, który powinieneś zinternalizować, to nie największa liczba na stronie limitów; to najmniejsza liczba, która zawodzi, nie mówiąc ci o tym. Ta sama luka zaufania leży u podstaw naszego wcześniejszego opracowania o tym, jak tłumaczenie AI psuje wielojęzyczne SEO na warstwie strukturalnej: w obu przypadkach widoczny wynik wygląda poprawnie, podczas gdy warstwa routingu pod spodem jest zepsuta.

#Naprawa: przenieś masowe przekierowania do Pages Function

_redirects to niewłaściwe miejsce na tysiące dosłownych reguł. Właściwym miejscem jest Pages Function czytająca mapę. Functions są ograniczone skompresowanym rozmiarem skryptu do 1MB, a nie limitem 100KB dla redirects, więc mapa przekierowań o rozmiarze 200KB mieści się z mniej więcej pięciokrotnym zapasem.

Migracja na tym serwisie, wdrożona w jednym commicie 2026-05-07, składała się z trzech części:

1. functions/redirect-map.ts eksportuje ReadonlyMap<string, string> par źródło-cel. Klucze są normalizowane raz - na małe litery, z dodanym końcowym slashem, ze zwiniętymi powtórzonymi slashami - więc każde żądanie to pojedyncze wyszukanie O(1), a nie skan. Zaczęło się od 1851 wpisów, a teraz trzyma 2233.
2. functions/_middleware.ts wykonuje wyszukanie między istniejącymi krokami normalizacji (zwijanie slashy, asciifikacja diakrytyków) a krokiem końcowego slasha. Buduje znormalizowany klucz, sprawdza mapę i wystawia bezpośredni 301 do celu, gdy trafia.
3. public/_redirects zostało przycięte z około 157KB do mniej więcej 3,3KB i 41 reguł: komentarz nagłówkowy, cztery reguły Merchant Center najwyższego priorytetu oraz reguły z wildcardem lub :splat, które naprawdę potrzebują silnika szablonów ścieżek Cloudflare.

Trzydzieści reguł próbkowanych losowo z nowej mapy wszystkie zwróciły czysto 301 na produkcji. Pętla 404 w Search Console zakończyła się, gdy przekierowania, których wciąż oczekiwał, naprawdę zaistniały na edge.

#Kolejność middleware jest częścią naprawy

Przeniesienie reguł do Function jest poprawne tylko wtedy, gdy wyszukanie uruchamia się w odpowiednim punkcie żądania. _middleware.ts wykonywał już realną pracę przed migracją: zamienia na małe litery i zwija powtórzone slashe, asciifikuje diakrytyki, by /pl/wdrozenia/ i wariant z diakrytykami rozwiązywały się do tej samej trasy, oraz dodaje końcowy slash. Wyszukanie w mapie musi siedzieć po normalizacji i przed przekierowaniem na końcowy slash, inaczej pojawiają się dwa błędy.

Umieść wyszukanie zbyt wcześnie, przed zwinięciem slashy, a klucz znormalizowany w czasie buildu (małe litery, pojedyncze slashe, końcowy slash) nigdy nie pasuje do surowej ścieżki przychodzącej z podwójnym slashem albo mieszaną wielkością liter. Mapa po cichu chybia, a URL spada do 404, co wygląda dokładnie jak błąd, który próbowałeś naprawić. Umieść je zbyt późno, gdy przekierowanie na końcowy slash już wystawiło 301, a płacisz dwoma przeskokami za każde przekierowane żądanie: jeden, by dodać slash, drugi, by dotrzeć do celu. Przekierowania dwuprzeskokowe wytracają moc linków i spowalniają crawl. Mapa musi konsumować już znormalizowany klucz i zwierać się pojedynczym 301. Logika routingu na edge jest sekwencyjna, a nie workiem niezależnych reguł, i kolejność jest tak samo nośna jak same reguły. Więcej opracowań o edge i platformach znajdziesz na blogu wppoland.

#Alternatywy, które odrzuciliśmy, i dlaczego

Statyczna mapa skompilowana do Function nie była jedyną opcją. Na stole były dwie inne.

• Workers KV. Przechowuj pary przekierowań w przestrzeni nazw klucz-wartość i wyszukuj je w czasie wykonania. To skaluje się do milionów wpisów i odsprzęga przekierowania od wdrożeń. Odrzuciliśmy to dla tego serwisu: odczyt KV dodaje opóźnienie sieciowe do każdego żądania, które może być przekierowaniem, limity odczytów w darmowym planie są realnym sufitem przy naszym ruchu, a 2200 reguł mieści się komfortowo w skompilowanej mapie, która jedzie z Function i nic nie kosztuje w czasie żądania. KV zarabia na siebie, gdy zbiór przekierowań jest na tyle duży albo zmienny, że ponowne wdrażanie w celu jego zmiany jest bolesne. Nasz nie jest ani jednym, ani drugim.
• Podział _redirects na wiele mniejszych plików. Cloudflare Pages czyta jeden plik _redirects; nie ma mechanizmu include, więc to nigdy nie było realne. Instynkt za tym pomysłem - korzystaj dalej z natywnej funkcji platformy - to ten sam instynkt, który najpierw pozwolił plikowi urosnąć poza limit.

Skompilowana mapa wygrała, bo usuwa limit z równania w całości, jednocześnie trzymając wyszukania w pamięci i zerując ich koszt na żądanie. Decyzja nie jest uniwersalna; jest słuszna dla zbioru przekierowań w niskich tysiącach, który zmienia się kilka razy w miesiącu.

#Jak utrzymać warstwę przekierowań w zdrowiu później

Migracja nie jest jednorazową ucieczką; bez dyscypliny plik znów się rozrasta. Reguły, które się utrzymały:

• Nowe statyczne przekierowania jeden-do-jednego idą do mapy Function, nigdy do _redirects. Dopisuj do functions/redirect-map.ts.
• Nowe przekierowania z wildcardem lub :splat idą do _redirects, który ma teraz mniej więcej trzydziestokrotnie większy zapas pod limitem.
• Pilnuj rozmiaru w bajtach, nie liczby reguł. Linia w CI, która wywala build, gdy public/_redirects przekroczy około 50KB, daje szeroki margines przed cichą ścianą 100KB. Liczba reguł jest tu metryką próżności; bajty są kontraktem.
• Sprawdzaj według pozycji po każdej dużej zmianie przekierowań. Góra, środek, ogon. To trzy wywołania curl i łapie obcinanie, zanim zrobi to Google.

Głębsza lekcja przeżyje samego Cloudflare. Limit platformy, który zawodzi po cichu, jest groźniejszy niż twardy limit, który zgłasza błąd, bo zielone wdrożenie uczy cię ufać plikowi, który nie jest już w pełni stosowany. Gdy limit jest udokumentowany jako jedna liczba, a egzekwowany jako inna, w tej luce psuje się produkcja. Przeczytaj stronę limitów co do każdej liczby na niej, potem zweryfikuj tę, która zawodzi po cichu, na żywym edge, a nie w zatwierdzonym pliku.