Przejdź do treści głównej

Poradniki / Kody statusu HTTP wyjaśnione

Kody statusu przekierowań 3xx

Kod statusu 3xx to przekierowanie: zasób, o który prosiłeś, jest gdzie indziej, a nagłówek Location w odpowiedzi mówi gdzie. Konkretny kod mówi klientowi, i każdej wyszukiwarce, czy przeniesienie jest trwałe czy tymczasowe oraz czy oryginalna metoda żądania musi zostać zachowana.

Jak działa przekierowanie

Przekierowanie to dwa żądania, nie jedno. Klient prosi o URL A, serwer odpowiada statusem 3xx i nagłówkiem Location wskazującym URL B, a klient wysyła wtedy nowe żądanie do B. Przeglądarki robią to automatycznie, więc odwiedzający widzi tylko ostateczną stronę i ostateczny URL w pasku adresu. Odpowiedź pośrednia wciąż kosztuje pełny przelot w obie strony, dlatego długie łańcuchy przekierowań są wolne.

Dwie właściwości odróżniają od siebie kody 3xx. Pierwsza to trwałość: trwałe przekierowanie mówi klientom i robotom indeksującym, że stary URL jest wycofany, a nowy powinien go zastąpić w zakładkach, linkach i indeksach, podczas gdy tymczasowe przekierowanie mówi, że stary URL wciąż jest tym prawdziwym i wróci. Druga to zachowanie metody. Starsze kody pozwalają klientowi zamienić POST na GET, gdy podąża za przekierowaniem, a nowsze tego zabraniają, więc POST pozostaje POST-em. To różnica między wysłanym formularzem, który dociera do nowego URL-a nienaruszony, a takim, który dociera jako pusty GET.

Każdy kod 3xx i jego znaczenie

  • 300 Multiple Choices. Zasób istnieje w kilku reprezentacjach, a serwer pozwala klientowi wybrać. Nie ma standardowego, czytelnego dla maszyn formatu tej listy, więc niemal nic tego nie implementuje. W praktyce nie zobaczysz 300 w naturze. Zobacz przewodnik 300 Multiple Choices, żeby dowiedzieć się, dlaczego przetrwał głównie jako termin wyszukiwania.
  • 301 Moved Permanently. Zasób ma nowy, trwały dom. Wyszukiwarki przenoszą sygnały rankingowe na cel, a klienci mają prawo buforować przekierowanie, czasem agresywnie. To kod dla zmiany domeny, migracji z HTTP na HTTPS albo trwałej przebudowy struktury URL.
  • 302 Found. Przekierowanie tymczasowe. Oryginalny URL zachowuje swoją tożsamość, więc wyszukiwarki zwykle nadal indeksują oryginał, a nie cel. Historycznie wielu klientów zmieniało metodę na GET, podążając za 302, dlatego standard ostrzega przed poleganiem tu na zachowaniu metody.
  • 303 See Other. "Twoje żądanie zostało przetworzone; teraz idź i zrób GET na tym innym zasobie." Klient dostaje wyraźne polecenie, żeby użyć GET dla kolejnego kroku, niezależnie od oryginalnej metody. To właściwa odpowiedź na POST formularza, który powinien wylądować na stronie wyniku.
  • 304 Not Modified. Wcale nie przekierowanie. Odpowiada na żądanie warunkowe i oznacza "Twoja zbuforowana kopia wciąż jest aktualna, użyj jej ponownie". Nie ma ciała ani Location. Zobacz 304 Not Modified.
  • 305 Use Proxy oraz 306 są przestarzałe. 305 zostało wycofane ze względów bezpieczeństwa, a 306 jest nieużywane. Zignoruj oba.
  • 307 Temporary Redirect. To samo znaczenie co 302, ale metoda i ciało muszą zostać zachowane. POST, który podąża za 307, dociera do nowego URL-a jako POST.
  • 308 Permanent Redirect. To samo znaczenie co 301, ale metoda i ciało muszą zostać zachowane.

Co psuje się w przekierowaniach

  • Tymczasowy kod przy trwałym przeniesieniu. Najczęstszy i najkosztowniejszy błąd. Wyszukiwarki trzymają stary URL w indeksie, a nowy nie dziedziczy pozycji starego.
  • Trwały kod przy tymczasowym przeniesieniu. Trudniejszy do cofnięcia, bo zbuforowane 301 może dalej kierować powracających odwiedzających w złe miejsce długo po usunięciu reguły.
  • Łańcuchy przekierowań. http do https, potem non-www do www, potem stara ścieżka do nowej, to trzy przeloty w obie strony, zanim dotrze jakakolwiek treść. Każdy skok dodaje opóźnienie i każdy skok to miejsce, w którym łańcuch może się zerwać.
  • Pętle przekierowań. A wysyła do B, a B odsyła z powrotem do A, zwykle dlatego, że reguła na poziomie aplikacji i reguła na poziomie serwera albo CDN nie zgadzają się co do kanonicznej formy. Przeglądarki poddają się po ustalonej liczbie skoków i pokazują błąd.
  • Wszystko wskazane na stronę główną. Gdy wszystkie wycofane strony przekierowują na root zamiast na swój najbliższy odpowiednik, przekierowanie bywa traktowane jako miękkie 404, a odwiedzający zostaje z niczym.
  • Utracone ciała POST. API albo endpoint formularza przeniesiony za 301 albo 302 może stracić swoją metodę i ładunek u niektórych klientów. Używaj 307 albo 308 dla wszystkiego, co nie jest zwykłym GET.

Jak zaudytować i naprawić swoje przekierowania

  1. Zobacz, co zwraca URL, bez podążania za nim:
    curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location)"
    To wypisuje linię statusu i cel jednym poleceniem.
  2. Teraz przejdź cały łańcuch i policz skoki:
    curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page
  3. Skróć łańcuchy do jednego skoku. Skieruj oryginalny URL bezpośrednio na cel końcowy zamiast pozwalać mu przechodzić przez reguły pośrednie.
  4. Dopasuj kod do intencji. Trwałe przeniesienie: 301, albo 308, jeśli endpoint przyjmuje żądania inne niż GET. Tymczasowe przeniesienie, strona konserwacji albo podział A/B: 302, albo 307, gdy metoda musi przetrwać. Przepływ post-then-redirect: 303.
  5. Napraw pętle, decydując raz o kanonicznej formie (protokół, host i końcowy ukośnik) i wymuszając ją dokładnie w jednej warstwie. Pętle niemal zawsze oznaczają, że dwie warstwy próbują być jednocześnie autorytatywne.
  6. Przetestuj ponownie na zimnym cache'u. Przeglądarka, która zbuforowała 301, będzie go dalej słuchać, więc zweryfikuj przez curl albo okno prywatne, zanim uznasz, że naprawa nie zadziałała.

Wyłapanie zepsutego przekierowania, zanim spadnie ruch

Przekierowania psują się bez żadnego widocznego objawu. Reguła, która zaczyna się zapętlać, albo certyfikat, który zawodzi na celu przekierowania, wciąż zostawiają stary URL odpowiadający, więc nic nie wygląda na zepsute, dopóki nie spadną ruch i pozycje. Zewnętrzna kontrola, która podąża za łańcuchem i asertuje status końcowy, wyłapuje zepsute przekierowanie w chwili, gdy się pojawi, a sprawdzanie z wielu sieci odróżnia globalną zmianę reguły od regionalnego problemu CDN. HostTracker wykonuje kontrole z ponad 300 punktów kontrolnych w 158 miastach i alertuje e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i więcej. Przetestuj URL i jego łańcuch przekierowań za pomocą narzędzia do kontroli HTTP, a przed wyborem kodu przeczytaj 301 vs 302.

Sprawdź teraz

Uruchom darmowe sprawdzenie na swojej stronie - bez zakładania konta.

HTTP check

Monitoruj to na stałe

Otrzymasz powiadomienie w chwili awarii: HostTracker sprawdza z ponad 300 lokalizacji i powiadamia e-mailem, SMS-em, przez Slack, Telegram i nie tylko.

Funkcje HostTracker

Więcej w tej sekcji: Kody statusu HTTP wyjaśnione