Łańcuchy przekierowań: jak je znaleźć i spłaszczyć w NGINX

Łańcuch przekierowań powstaje wtedy, gdy stary adres URL przechodzi przez kilka przekierowań, zanim dotrze do docelowej strony. Na przykład: najpierw http, potem www, potem ukośnik na końcu, a na koniec reguła dla starej ścieżki. Rozwiązanie polega na tym, żeby każdy stary URL kierować od razu na jego docelowy adres HTTPS jedną regułą return w NGINX. Skąd się biorą takie łańcuchy? Zwykle narastają przy kolejnych przenosinach serwisu, bo każda przeprowadzka dokładała własną regułę do tych, które zostały po poprzedniej.

Czym są łańcuchy przekierowań i dlaczego narastają po przenosinach serwisu?

Łańcuch przekierowań to seria przekierowań, w której każdy skok prowadzi do kolejnego przekierowania zamiast do docelowej strony. Po kilku migracjach typowy łańcuch wygląda tak:

http://example.com/old → https://example.com/old → https://www.example.com/old → https://www.example.com/old/ → https://www.example.com/new/

Cztery skoki. Dla jednej strony. Każda przeprowadzka zostawia swoje reguły w osobnym bloku server albo location, a one uruchamiają się jedna po drugiej. Łańcuch mimo wszystko kończy się na prawdziwej stronie i tym różni się od pętli, w której adres URL nigdy nie prowadzi do celu. Masz proxy przed serwerem źródłowym? Wtedy najpierw wyklucz schemat opisany w tekście o pętlach przekierowań WordPressa za proxy.

Jak Google radzi sobie z wieloma przekierowaniami?

Googlebot podąża za przekierowaniami, a stałe przekierowania po stronie serwera mówią Google, że adres docelowy ma traktować jako kanoniczny. Według wytycznych Google dotyczących przekierowań przekierowania po stronie serwera to metoda, którą Google najpewniej odczyta poprawnie. Reguły NGINX wygrywają więc z meta refresh i JavaScriptem. Strona Google nie podaje limitu skoków. Ale pomyśl: każdy dodatkowy skok to jedno żądanie więcej, zarówno dla odwiedzających, jak i dla robotów, a nic w zamian nie zyskujesz. Wybór kodu statusu to osobna kwestia (opisujemy ją w poradniku o przekierowaniach stałych i tymczasowych).

Jak sprawdzić przekierowania za pomocą curl

curl -I pokazuje kod statusu i nagłówek Location dla jednego skoku, bez pobierania strony. Dodaj -L, żeby prześledzić całą ścieżkę, a potem przefiltruj wynik tak, żeby zostały same skoki:

curl -sIL http://example.com/old | grep -Ei '^(HTTP|location)'

W praktyce przeprowadziłbym audyt tak:

1. Zbierz stare adresy URL z dawnych map witryny, raportów linków zwrotnych i wcześniejszych map przekierowań.
2. Sprawdź każdą ścieżkę we wszystkich czterech wariantach: http i https, z www i bez.
3. Zapisz liczbę skoków i końcowy URL dla każdego wariantu.

Krótka pętla wskaże każdy URL, który zwraca więcej niż jeden nagłówek Location:

while read -r url; do
  n=$(curl -sIL "$url" | grep -ci '^location:')
  [ "$n" -gt 1 ] && echo "$n hops: $url"
done < urls.txt

Pętle wyglądają inaczej. curl podąża za przekierowaniami, aż dojdzie do limitu --max-redirs, a potem przerywa z błędem. Żadnego końcowego 200.

Spłaszczanie łańcuchów przekierowań regułami return w NGINX

Pomysł jest prosty. Zbuduj pełny docelowy URL (właściwy protokół, właściwy host, właściwa ścieżka) w jednym return 301, tak żeby każde niekanoniczne żądanie trafiało do celu w jednym skoku. Jeden blok łapiący wszystko, który wysyła na https://www.example.com$request_uri, zastępuje osobne reguły z http na https i dla www. Stare ścieżki trafiają do map, sprawdzanej przed przekierowaniem hosta, więc stara ścieżka przeskakuje od razu na docelową stronę. I każdy adres docelowy zapisuj z ukośnikiem na końcu. Inaczej po drodze odpali się reguła dla ukośnika i znowu masz dwa skoki. Przy zwykłych przenosinach jeden do jednego return jest czytelniejszy i tańszy niż rewrite, bez dyskusji.

map $uri $legacy_target {
    default   "";
    /old      https://www.example.com/new/;
    /old/     https://www.example.com/new/;
}

server {
    listen 80;
    server_name example.com www.example.com;
    if ($legacy_target) { return 301 $legacy_target; }
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    if ($legacy_target) { return 301 $legacy_target; }
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    if ($legacy_target) { return 301 $legacy_target; }
    # konfiguracja serwisu
}

Większa migracja? To samo, tylko więcej linii. Podejście do map przekierowań przy przenosinach serwisu rozszerza dokładnie tę mapę do tysięcy wpisów.

Testowanie i utrzymanie spłaszczonych reguł

Uruchom nginx -t, przeładuj konfigurację, a potem przepuść tę samą listę przez curl jeszcze raz. Każdy stary URL powinien teraz zwracać jedno 301, a potem 200. I tyle. Następnie zaktualizuj linki wewnętrzne, tagi canonical i mapę witryny na adresy docelowe, żeby serwis sam nie tworzył nowych skoków. Trzymaj jeden plik z mapą przekierowań w systemie kontroli wersji. Gdy strona znowu się przeniesie, edytuj istniejące adresy docelowe zamiast dokładać nową regułę na wierzch (dokładnie tak powstał ten łańcuch). Przy reverse proxy przed serwerem przekierowania nadal siedzą w NGINX na serwerze źródłowym. Upewnij się tylko, że proxy przekazuje żądania tak, żeby serwer źródłowy widział właściwy protokół i host. Jeśli nie, reguły dopasują się do złego bloku.

Łańcuchy zostają naprawione tylko wtedy, gdy ktoś faktycznie za nie odpowiada. Sprawdź stare adresy przez curl, połącz reguły protokołu i www w jeden return, skieruj stare ścieżki prosto na docelowe adresy i powtarzaj testy po każdych kolejnych przenosinach. Nic efektownego, ale działa.

FAQ