Spis treści

Wysyłasz żądanie metodą POST z ciałem i nagłówkiem autoryzacji, a na serwer dociera pusty GET bez żadnego niestandardowego nagłówka. Brzmi znajomo? Jeśli pracujesz z proxy i zautomatyzowanymi żądaniami, prędzej czy później spotkasz się z takim zachowaniem. Nie jest to błąd twojego kodu ani usterka proxy Proxeon. To normalna, przewidziana w specyfikacji mechanika przekierowań HTTP, którą po prostu trzeba zrozumieć i nauczyć się nią sterować.

W tym przewodniku wyjaśnimy, dlaczego podczas przekierowania metoda żądania może się zmienić, a nagłówki zniknąć. Nauczysz się rozróżniać kody 301, 302, 307 i 308, dowiesz się, jak domyślnie zachowują się różne klienty HTTP i dostaniesz praktyczne przykłady wyłączania automatycznych przekierowań wraz z ręczną obsługą. Wszystko na prawdziwym kodzie, bez lania wody.

Wprowadzenie: żądanie wychodzi jako POST, a przychodzi GET – kto jest winien

Wyobraź sobie zadanie inżynierskie. Wysyłasz żądanie POST do punktu autoryzacji przez proxy. Serwer odpowiada kodem przekierowania i wskazuje nowy adres. Twój klient HTTP automatycznie podąża za tym adresem. Ale robi to już metodą GET, bez ciała żądania i bez nagłówka Authorization. W efekcie serwer docelowy otrzymuje nie to, co wysyłałeś, i logika się sypie.

Kto jest winien? Formalnie – nikt. Takie zachowanie wynika z historycznej implementacji kodów 301 i 302. Dawniej przeglądarki i biblioteki przy otrzymaniu tych kodów prawie zawsze zmieniały metodę na GET. Stało się to de facto standardem, który został utrwalony. Później, aby dać programistom możliwość zachowania metody i ciała żądania, wprowadzono kody 307 i 308. Omówimy je szczegółowo poniżej.

Co zyskasz po przeczytaniu

Po przeczytaniu tego poradnika będziesz pewnie zarządzać przekierowaniami w dowolnym popularnym kliencie HTTP. Będziesz w stanie przewidzieć, co stanie się z metodą i ciałem żądania. Nauczysz się zachowywać krytyczne nagłówki podczas przekierowań. I będziesz w stanie debugować skomplikowane łańcuchy przekierowań przechodzące przez proxy.

Dla kogo jest ten poradnik

  • Dla programistów, którzy piszą scrapery, integracje i automatyzację opartą na proxy.
  • Dla testerów QA, którzy testują API i scenariusze internetowe.
  • Dla DevOpsów, którzy konfigurują proxy dla ruchu sieciowego.
  • Dla wszystkich, którzy chociaż raz zastanawiali się, dlaczego POST stał się GET.

Co warto wiedzieć wcześniej

Podstawowa znajomość protokołu HTTP: czym jest metoda żądania, nagłówki, ciało i kod statusu odpowiedzi. Umiejętność uruchamiania poleceń w terminalu. Wskazana minimalna znajomość jednego z języków: Python lub JavaScript. Jeśli czegoś z tego nie wiesz, nie martw się – najważniejsze terminy wyjaśnimy prostym językiem w osobnym rozdziale.

Ile czasu to zajmie

Na uważne przeczytanie i powtórzenie wszystkich przykładów wystarczy około 60 minut. Jeśli potrzebujesz tylko rozwiązać konkretny problem, skorzystaj ze spisu treści i przejdź od razu do odpowiedniego rozdziału.

Przygotowanie wstępne: narzędzia i dostęp

Zanim zaczniesz pracować z przykładami, przygotuj środowisko. Zajmie to chwilę, ale potem wszystko pójdzie gładko.

Wymagane narzędzia

  1. Zainstaluj curl w wersji 7.88 lub nowszej. Sprawdź poleceniem curl --version w terminalu.
  2. Zainstaluj Pythona w wersji 3.10 lub nowszej. Sprawdź poleceniem python --version.
  3. Zainstaluj biblioteki Pythona: uruchom pip install requests httpx.
  4. Zainstaluj Node.js w wersji 20 lub nowszej, jeśli planujesz testować axios i fetch. Sprawdź poleceniem node --version.
  5. Zainstaluj axios przez npm install axios w testowym folderze projektu.

Dostęp do proxy

Do ćwiczeń będziesz potrzebować działającego proxy Proxeon. Przygotuj dane do połączenia: adres serwera, port, login i hasło. Trzymaj je pod ręką w bezpiecznym miejscu. Będziemy je podstawiać w przykładach kodu.

Wskazówka: Nigdy nie przechowuj loginu i hasła do proxy bezpośrednio w kodzie. Użyj zmiennych środowiskowych. Na przykład w terminalu ustaw export PROXY_URL=http://user:pass@host:port, a w kodzie czytaj tę wartość ze środowiska. Dzięki temu nie wyślesz przypadkiem sekretów do repozytorium.

Wymagania systemowe

Wystarczy dowolny nowoczesny komputer z Windows 10 i nowszym, macOS 12 i nowszym lub aktualną dystrybucją Linuksa. Nie ma specjalnych wymagań sprzętowych: praca z żądaniami HTTP nie obciąża systemu.

⚠️ Uwaga: Jeśli testujesz na serwerze produkcyjnym, najpierw stwórz osobną testową gałąź kodu lub osobny testowy skrypt. Nie eksperymentuj z logiką przekierowań bezpośrednio na produkcji – zmiana zachowania przekierowań może zepsuć autoryzację i sprawić, że żądania zaczną trafiać w niewłaściwe miejsca.

✅ Sprawdzenie: Na tym etapie polecenia sprawdzające wersje curl, Pythona i Node.js powinny działać poprawnie, a dane proxy Proxeon powinny być zapisane w zmiennej środowiskowej.

Podstawowe pojęcia prostym językiem

Aby dalsza część była zrozumiała, omówimy kluczowe terminy. Nawet jeśli je znasz, nie zaszkodzi odświeżyć.

Czym jest przekierowanie

Przekierowanie, czyli redirect, to odpowiedź serwera, która mówi klientowi: zasobu, którego szukasz, tu nie ma, idź pod inny adres. Serwer zwraca kod statusu z rodziny 3xx oraz nagłówek Location z nowym adresem. Klient czyta ten nagłówek i wysyła nowe żądanie właśnie tam.

Czym jest metoda żądania i ciało

Metoda to rodzaj akcji. GET prosi o dane, POST wysyła dane na serwer, PUT aktualizuje, DELETE usuwa. Ciało żądania to ładunek, który wysyłasz razem z POST lub PUT. Na przykład JSON z loginem i hasłem podczas autoryzacji.

Czym są nagłówki

Nagłówki to metadane żądania. Przekazują dodatkowe informacje: format danych (Content-Type), autoryzację (Authorization), agent użytkownika (User-Agent), twoje własne pola serwisowe. Podczas przekierowania część nagłówków może zostać zachowana, a część – zgubiona. To właśnie często psuje logikę.

Czym jest automatyczne przekierowanie

Automatyczne przekierowanie to sytuacja, gdy twój klient HTTP sam, bez twojego udziału, podąża za adresem z nagłówka Location. Większość klientów robi to domyślnie. Wygodne, ale niebezpieczne: tracisz kontrolę nad tym, co dzieje się z metodą, ciałem i nagłówkami między krokami.

Jak w to wszystko wpisuje się proxy

Proxy Proxeon znajduje się między twoim klientem a serwerem docelowym. Przekazuje twoje żądanie dalej i zwraca odpowiedź. Podczas przekierowania proxy po prostu przesyła kod statusu i nagłówek Location. Decyzję o przejściu podejmuje twój klient. Ważny niuans: jeśli używasz puli proxy z rotacją, różne kroki łańcucha przekierowań mogą przejść przez różne IP. Wrócimy do tego osobno.

Wskazówka: Zapamiętaj prostą zasadę. Proxy nie zmienia metody żądania podczas przekierowania. Metodę zmienia twój klient HTTP zgodnie z regułami obsługi kodu statusu. Dlatego przyczyny należy szukać w ustawieniach klienta, a nie w proxy.

Krok 1: Poznaj cztery kody – 301 i 302 kontra 307 i 308

Cel etapu: nauczyć się bezbłędnie określać, co stanie się z metodą i ciałem żądania przy otrzymaniu każdego z czterech kodów przekierowania.

To fundament całego poradnika. Jeśli przyswoisz sobie różnicę między tymi kodami, połowa problemów z przekierowaniami zniknie sama.

Kod 301 – przekierowanie stałe

Oznacza, że zasób przeniósł się na stałe. Historycznie przy otrzymaniu 301 klienci zmieniają metodę POST na GET i odrzucają ciało żądania. Formalnie specyfikacja tego nie wymaga, ale tak się przyjęło w praktyce i prawie wszyscy klienci tak robią ze względu na kompatybilność wsteczną.

Kod 302 – przekierowanie tymczasowe

Oznacza, że zasób jest tymczasowo dostępny pod innym adresem. Zachowanie jest analogiczne do 301: w praktyce POST staje się GET, ciało jest tracone. To właśnie kod 302 najczęściej jest winny sytuacji opisanej we wprowadzeniu.

Kod 307 – przekierowanie tymczasowe z zachowaniem metody

Ten kod został wprowadzony specjalnie, aby rozwiązać problem zmiany metody. Przy 307 klient ma obowiązek zachować oryginalną metodę i ciało. Wysłałeś POST – pójdzie POST. Wysłałeś ciało – zostanie przekazane dalej. To tymczasowy odpowiednik 302, ale bez niespodzianek z metodą.

Kod 308 – przekierowanie stałe z zachowaniem metody

Stały odpowiednik 301, ale z zachowaniem metody i ciała. Wysłałeś POST – dotrze POST. To najbardziej przewidywalny z kodów do przekierowania żądań POST.

Tabela zbiorcza zachowania

Poniżej – słowny opis tabeli, abyś miał pełny obraz w głowie.

  • 301: stałe. Metoda POST w praktyce zmienia się na GET. Ciało jest odrzucane. GET pozostaje GET.
  • 302: tymczasowe. Metoda POST w praktyce zmienia się na GET. Ciało jest odrzucane. GET pozostaje GET.
  • 307: tymczasowe. Metoda jest w pełni zachowana. Ciało jest zachowane. POST pozostaje POST.
  • 308: stałe. Metoda jest w pełni zachowana. Ciało jest zachowane. POST pozostaje POST.

⚠️ Uwaga: Nie polegaj na tym, że wszystkie serwery ściśle przestrzegają specyfikacji. Niektóre stare systemy zwracają 302 tam, gdzie logicznie powinien być 307, oczekując przy tym zachowania metody. Zawsze sprawdzaj faktyczne zachowanie, a nie tylko kod. Testuj na prawdziwym punkcie końcowym.

Wskazówka: Jeśli tworzysz własny serwer i chcesz, aby żądania POST po przekierowaniu pozostały POST, używaj kodów 307 lub 308. To uchroni twoich klientów przed nieprzyjemnymi niespodziankami i zbędnym debugowaniem.

✅ Sprawdzenie: Patrząc na kod odpowiedzi, potrafisz od razu powiedzieć, czy metoda i ciało zostaną zachowane. Dla 307 i 308 – tak. Dla 301 i 302 – w praktyce nie.

Krok 2: Co ginie podczas przekierowania – Authorization, niestandardowe nagłówki, ciasteczka

Cel etapu: zrozumieć, jakie dane znikają podczas przekierowania i dlaczego, aby z wyprzedzeniem zapewnić ich zachowanie.

Zmiana metody to nie jedyny problem. Nawet przy kodach 307 i 308, gdy metoda jest zachowana, część nagłówków może zniknąć. Omówimy trzy główne straty.

Utrata nagłówka Authorization przy zmianie domeny

To najczęstszy i najbardziej podstępny problem. Ze względów bezpieczeństwa większość klientów HTTP usuwa nagłówek Authorization podczas przekierowania na inną domenę. Logika jest prosta: jeśli logujesz się na stronie A, twój sekretny token nie powinien automatycznie trafiać na stronę B, na którą zostałeś przekierowany. W przeciwnym razie atakujący mógłby ustawić przekierowanie i wyłudzić twoje dane uwierzytelniające.

W efekcie wysyłasz żądanie z poprawnym tokenem, klient podąża za przekierowaniem do innej domeny, ale już bez Authorization. Serwer docelowy odpowiada, że nie jesteś zalogowany. Wszystko logiczne, ale nieoczywiste.

Wskazówka: Jeśli naprawdę musisz przekazać autoryzację do innej domeny, rób to świadomie i ręcznie. Wyłącz automatyczne przekierowanie, sprawdź, dokąd dokładnie prowadzi Location, upewnij się, że to zaufany adres, i dopiero wtedy dodaj nagłówek Authorization do nowego żądania własnoręcznie.

Utrata niestandardowych nagłówków

Twoje własne nagłówki – na przykład pola serwisowe typu X-Request-Id lub X-Client-Version – przy automatycznym przekierowaniu zachowują się różnie w zależności od klienta. Niektóre biblioteki przenoszą je dalej, inne resetują. Nie można na tym polegać. Jeśli nagłówek jest krytyczny dla logiki, kontroluj jego przekazywanie ręcznie.

Utrata ciasteczek z flagami

Ciasteczka mają flagi, które ograniczają ich wysyłanie. Flaga Secure zezwala na wysyłanie tylko przez bezpieczne połączenie. Flaga Domain ogranicza zestaw domen, do których ciasteczko jest wysyłane. Flaga SameSite reguluje wysyłanie przy przejściach między stronami. Jeśli przekierowanie prowadzi cię do domeny lub protokołu, który nie pasuje do flag ciasteczka, to ciasteczko po prostu nie zostanie wysłane.

Na przykład ciasteczko z flagą Secure nie zostanie wysłane, jeśli przekierowanie nagle prowadzi na niezabezpieczony adres. Ciasteczko z ograniczeniem domeny nie zostanie wysłane do obcej domeny. To prawidłowe zachowanie z punktu widzenia bezpieczeństwa, ale trzeba je uwzględnić.

⚠️ Uwaga: Nigdy nie próbuj na siłę zdejmować flag ochronnych z cudzych ciasteczek ani przekazywać Authorization na niezaufane domeny dla wygody. Te mechanizmy chronią twoje dane uwierzytelniające. Omijaj je tylko w infrastrukturze, którą w pełni kontrolujesz, i z pełnym zrozumieniem konsekwencji.

✅ Sprawdzenie: Rozumiesz trzy klasy strat podczas przekierowania: nagłówek Authorization w innej domenie, niestandardowe nagłówki, ciasteczka z ograniczającymi flagami. Wiesz, że każdą z nich można odtworzyć tylko przez świadomą ręczną obsługę.

Krok 3: Domyślne zachowanie w różnych klientach

Cel etapu: dowiedzieć się, jak dokładnie zachowuje się każdy popularny klient HTTP, aby nie dziwić się rozbieżnościom.

Główna pułapka polega na tym, że domyślne zachowanie wszystkich klientów jest różne. Omówimy pięć najpopularniejszych.

curl

Domyślnie curl w ogóle nie podąża za przekierowaniami. Po prostu pokaże ci odpowiedź z kodem 3xx i nagłówkiem Location. Aby włączyć automatyczne przekierowanie, musisz jawnie dodać flagę -L. To czyni curl bardzo przewidywalnym: zawsze wiesz, że bez flagi nie będzie żadnych ukrytych przekierowań.

Przykład żądania bez przekierowania:

curl -i -x $PROXY_URL https://example.com/redirect

Flaga -i pokaże nagłówki odpowiedzi, flaga -x ustawia proxy. Zobaczysz kod i Location, ale nie nastąpi przekierowanie.

requests (Python)

Biblioteka requests domyślnie automatycznie podąża za przekierowaniami. Przy tym dla kodów 301, 302 i 303 zmienia metodę POST na GET. Dla 307 i 308 zachowuje metodę. Automatyczne przekierowanie można wyłączyć parametrem allow_redirects=False.

httpx (Python)

Ciekawy fakt: httpx domyślnie NIE podąża za przekierowaniami, w przeciwieństwie do requests. Zrobiono to celowo, aby programista jawnie podejmował decyzję. Aby włączyć przekierowania, przekaż follow_redirects=True. Takie zachowanie jest bliższe filozofii curl.

axios (JavaScript, Node.js)

W środowisku Node.js axios domyślnie automatycznie podąża za przekierowaniami. Ograniczyć lub wyłączyć to można parametrem maxRedirects. Jeśli ustawisz maxRedirects: 0, automatyczne przekierowanie zostanie wyłączone, a axios zwróci błąd lub odpowiedź z kodem przekierowania, w zależności od ustawień.

fetch (przeglądarka i Node.js)

Standardowy fetch domyślnie automatycznie podąża za przekierowaniami. Sterować tym można parametrem redirect, który przyjmuje trzy wartości: follow – podążaj, manual – nie podążaj i zwróć nieprzezroczystą odpowiedź, error – traktuj przekierowanie jako błąd.

Wskazówka: Zapamiętaj dwie grupy. curl i httpx domyślnie NIE podążają – sam decydujesz. requests, axios i fetch domyślnie podążają. Jeśli przenosisz kod między tymi narzędziami, koniecznie sprawdź ustawienia przekierowań, w przeciwnym razie logika po cichu się zepsuje.

⚠️ Uwaga: Różne domyślne zachowanie to główna przyczyna tajemniczych błędów przy przepisywaniu skryptów z jednego klienta na inny. Skrypt na requests działał, przenosisz na httpx i nagle zamiast finalnej odpowiedzi dostajesz kod 302. Przyczyna – httpx nie podąża sam. Zawsze jawnie określaj ustawienia przekierowań.

✅ Sprawdzenie: Potrafisz z pamięci podać domyślne zachowanie dla curl, requests, httpx, axios i fetch oraz znasz parametr do sterowania przekierowaniami w każdym z nich.

Krok 4: Ręczne zarządzanie przekierowaniami – kiedy to jedyna słuszna droga

Cel etapu: nauczyć się wyłączać automatyczne przekierowanie i samodzielnie obsługiwać każdy krok przekierowania, w pełni kontrolując metodę, ciało i nagłówki.

Automatyczne przekierowanie jest wygodne, ale w trzech sytuacjach szkodzi i potrzebna jest ręczna kontrola:

  1. Gdy musisz zachować Authorization przy przejściu do innej domeny.
  2. Gdy ważne jest dokładne poznanie, przez które proxy i IP przeszedł każdy krok łańcucha.
  3. Gdy serwer odpowiada 302 tam, gdzie logicznie powinien być 307, a ty chcesz ręcznie zachować metodę POST.

Wyłączanie automatycznego przekierowania: curl

W curl wszystko jest proste: nie dodawaj flagi -L. Klient pokaże ci pierwszą odpowiedź. Potem sam bierzesz Location i wykonujesz nowe żądanie:

curl -i -x $PROXY_URL "https://example.com/login"

Czytasz nagłówek Location z wyniku, następnie wykonujesz kolejne żądanie ręcznie, dodając potrzebne nagłówki:

curl -i -x $PROXY_URL -H "Authorization: Bearer TOKEN" "https://example.com/next"

Wyłączanie automatycznego przekierowania: requests

Tu używamy parametru allow_redirects=False i obsługujemy łańcuch w pętli:

import os, requests; proxies = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}; url = "https://example.com/login"; method = "POST"; body = {"user": "a", "pass": "b"}; headers = {"Authorization": "Bearer TOKEN"}; 
for _ in range(5): 
r = requests.request(method, url, json=body, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301, 302, 303, 307, 308): break; 
loc = r.headers["Location"]; 
if r.status_code in (301, 302, 303): method = "GET"; body = None; 
url = loc

Zwróć uwagę: w tej pętli sam decydujesz, czy zmienić metodę, czy nie, i sam decydujesz, czy pozostawić nagłówek Authorization. W tym tkwi siła ręcznej obsługi.

Wyłączanie automatycznego przekierowania: httpx

Ponieważ httpx domyślnie nie podąża, wystarczy nie włączać follow_redirects. Logika pętli jest analogiczna jak w requests: sprawdzasz kod, czytasz Location, podejmujesz decyzje o metodzie i nagłówkach, wykonujesz następne żądanie.

Wyłączanie automatycznego przekierowania: axios

W axios ustaw maxRedirects: 0. Przy otrzymaniu kodu przekierowania axios w Node.js rzuci błąd, w którego obiekcie response będą dostępne status i nagłówki. Z nagłówka Location bierzesz nowy adres i samodzielnie formujesz kolejne żądanie.

Wyłączanie automatycznego przekierowania: fetch

W fetch przekaż redirect: "manual". Wtedy fetch nie będzie podążał i zwróci odpowiedź, z której odczytasz niezbędne dane do następnego kroku.

Wskazówka: Przy ręcznej obsłudze zawsze loguj na każdym kroku cztery rzeczy: oryginalny URL, otrzymany kod, wartość Location i metodę następnego żądania. To zamieni niezrozumiały łańcuch w przejrzystą sekwencję, którą łatwo czytać i debugować.

⚠️ Uwaga: Przy ręcznej obsłudze sam odpowiadasz za bezpieczeństwo. Zanim przeniesiesz Authorization na nowy adres z Location, sprawdź, czy domena należy do zaufanej infrastruktury. Ślepe kopiowanie sekretów na dowolny adres z Location to poważna luka.

✅ Sprawdzenie: Masz działającą pętlę ręcznej obsługi przynajmniej w jednym kliencie, która poprawnie przechodzi łańcuch przekierowań i zachowuje potrzebne nagłówki tylko dla zaufanych domen.

Krok 5: Ograniczenie głębokości i ochrona przed pętlami

Cel etapu: zabezpieczyć swój kod przed nieskończonymi przekierowaniami i nie dopuścić, aby pętla przekierowań zawiesiła aplikację.

Czasami serwery są źle skonfigurowane i adres A prowadzi do adresu B, a B z powrotem do A. Jeśli twój klient podąża bez ograniczeń, zapętli się. Przy ręcznej obsłudze jest to samo niebezpieczeństwo: pętla bez licznika będzie kręcić się w nieskończoność.

Ograniczenie liczby przekierowań

Zawsze ustawiaj maksymalną głębokość. Rozsądna wartość to od pięciu do dziesięciu przekierowań. Więcej w normalnych scenariuszach prawie się nie zdarza.

  • W curl: flaga --max-redirs 10 razem z -L.
  • W requests: biblioteka sama ogranicza głębokość, ale przy ręcznej pętli użyj range(10).
  • W httpx: parametr max_redirects przy włączonych przekierowaniach.
  • W axios: parametr maxRedirects z odpowiednią liczbą.
  • W fetch: przy ręcznej obsłudze licz przekierowania sam w pętli.

Ochrona przed pętlami przez śledzenie odwiedzonych adresów

Niezawodna technika: przechowuj zbiór już odwiedzonych URL-i. Przed każdym przekierowaniem sprawdzaj, czy nie byłeś już na tym adresie. Jeśli byłeś – przerywaj łańcuch z błędem. To łapie nawet złożone pętle z kilku adresów.

seen = set(); 
while url and url not in seen: 
seen.add(url); 
r = requests.request(method, url, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301,302,303,307,308): break; 
url = r.headers["Location"]

Wskazówka: Łącz obie techniki: i sztywny limit liczby, i zbiór odwiedzonych adresów. Limit chroni przed długimi łańcuchami, zbiór – przed pętlami. Razem dają pełną ochronę.

✅ Sprawdzenie: Twój kod gwarantowanie kończy działanie na dowolnym łańcuchu przekierowań, nawet jeśli serwer tworzy nieskończoną pętlę. Albo dociera do finalnej odpowiedzi, albo przerywa działanie z jasnym błędem o przekroczeniu głębokości lub wykryciu pętli.

Krok 6: Przekierowania i zmiana IP – dlaczego łańcuch trafia na inne proxy

Cel etapu: zrozumieć, jak rotacja proxy współdziała z przekierowaniami, i nie dopuścić, aby kroki łańcucha przechodziły przez różne IP.

To subtelny i często niedoceniany aspekt. Jeśli używasz puli proxy Proxeon z rotacją IP, ważne jest, aby zrozumieć, na jakim poziomie następuje zmiana adresu.

Dlaczego kroki mogą przechodzić przez różne IP

Wyobraź sobie, że twoja rotacja jest ustawiona na zmianę IP przy każdym nowym połączeniu. Przy automatycznym przekierowaniu klient może otworzyć nowe połączenie dla następnego kroku przekierowania. Jeśli między krokami rotacja wyda nowy IP, to pierwsze żądanie pójdzie z jednego adresu, a przekierowanie wg Location – już z innego. Dla wielu serwerów wygląda to podejrzanie: autoryzację zaczął jeden klient, a kontynuował jakby inny.

Co się przy tym psuje

  • Sesje przypisane do IP są zrywane. Serwer widzi, że kontynuacja przyszła z innego adresu, i resetuje sesję.
  • Ciasteczka wydane dla konkretnej sesji przestają być przyjmowane.
  • Logika oczekująca pojedynczego źródła w obrębie łańcucha zaczyna działać niestabilnie.

Jak utrzymać jedną sesję na jednym IP

Kluczem jest przypięcie IP na czas całego łańcucha. Proxeon obsługuje tryb sesji lepkiej (sticky session), kiedy ten sam IP trzyma się przez zadany okres. Użyj go w scenariuszach, gdzie ważna jest integralność łańcucha przekierowań.

  1. Wybierz w ustawieniach połączenia tryb sesji lepkiej zamiast rotacji na każde żądanie.
  2. Ustaw czas trzymania IP z zapasem na cały łańcuch przekierowań.
  3. W kodzie używaj jednej sesji klienta dla wszystkich kroków: w requests to obiekt requests.Session(), w httpx – httpx.Client().
  4. Upewnij się, że ponownie używasz połączenia, a nie tworzysz nowego na każdym kroku.

Wskazówka: Dla integralności łańcucha przekierowań zawsze twórz jeden obiekt sesji klienta i przepuszczaj przez niego wszystkie kroki. To i ponownie wykorzystuje połączenie, i zachowuje ciasteczka między żądaniami, i zmniejsza szansę przejścia na inne IP w środku łańcucha.

⚠️ Uwaga: Nie myl sesji lepkiej z nieskończonym trzymaniem IP. Ustaw rozsądny czas trzymania – dokładnie na czas trwania operacji. Pamiętaj, że cała praca z proxy musi odbywać się zgodnie z prawem i zasadami zasobów, z którymi wchodzisz w interakcję.

✅ Sprawdzenie: Cały łańcuch przekierowań przechodzi przez ten sam IP, sesja nie jest zrywana, ciasteczka są przyjmowane na każdym kroku. Możesz to sprawdzić, żądając na każdym kroku usługi pokazującej twój bieżący IP i upewniając się, że się nie zmienia.

Krok 7: Debugowanie – jak zobaczyć cały łańcuch i kody krok po kroku

Cel etapu: uzyskać pełny obraz łańcucha przekierowań, aby dokładnie wiedzieć, gdzie traci się metodę lub nagłówek.

Debugowanie na ślepo to najgorsze, co można robić z przekierowaniami. Poniżej – narzędzia, które czynią łańcuch widocznym.

Pełny log w curl

Flaga -v włącza tryb szczegółowy. Zobaczysz każde żądanie, każdą odpowiedź, wszystkie nagłówki i wszystkie przekierowania. Z flagą -L curl pokaże cały łańcuch w całości.

curl -v -L --max-redirs 10 -x $PROXY_URL "https://example.com/login"

Czytaj wynik od góry do dołu. Linie zaczynające się od znaku większości – to to, co idzie na serwer. Linie ze znakiem mniejszości – to, co przychodzi w odpowiedzi. W ten sposób zobaczysz, na którym kroku zniknął nagłówek.

Historia przekierowań w requests

Jeśli pozostawisz automatyczne przekierowanie włączone, finalna odpowiedź będzie miała atrybut history – listę wszystkich pośrednich odpowiedzi. Przejdź przez nią i wypisz kod i URL każdego kroku:

r = requests.post(url, json=body, proxies=proxies); 
for h in r.history: print(h.status_code, h.url); 
print("final", r.status_code, r.url)

Historia przekierowań w httpx

Przy włączonym follow_redirects odpowiedź httpx również ma właściwość history. Logika jest ta sama: iterujesz i wypisujesz kod i URL każdej pośredniej odpowiedzi.

Debugowanie axios i fetch

W axios przy ręcznej obsłudze loguj każdą odpowiedź w pętli sam. W fetch z trybem manual wypisuj status i nagłówek Location na każdym kroku. Nie ma tu wspólnej wbudowanej listy historii, więc ręczne logowanie to twoje główne narzędzie.

Wskazówka: Ustal jednolity format linii logu dla jednego kroku: numer kroku, metoda, URL, kod odpowiedzi, Location, obecność Authorization. Taki tabelaryczny zapis natychmiast pokazuje, gdzie dokładnie metoda zmieniła się na GET lub zniknął token. To oszczędza godziny debugowania.

Czego szukać w logach

  • Moment, gdzie metoda w wychodzącym żądaniu stała się GET zamiast POST. To oznaka kodu 301, 302 lub 303.
  • Krok, gdzie zniknął nagłówek Authorization. Zwykle to przejście na inną domenę.
  • Zmianę domeny lub protokołu w wartości Location – właśnie tam giną ciasteczka z flagami.
  • Powtarzające się adresy – oznaka pętli.

✅ Sprawdzenie: Potrafisz wypisać pełny łańcuch przekierowań z kodami i URL-ami dla dowolnego klienta i dokładnie wskazać krok, na którym zmieniła się metoda lub zniknął nagłówek.

Sprawdzenie wyniku: lista kontrolna

Przejdź przez tę listę. Jeśli wszystkie punkty są spełnione, w pełni zarządzasz przekierowaniami.

  1. Znasz zachowanie metody i ciała dla kodów 301, 302, 307 i 308.
  2. Rozumiesz, dlaczego Authorization znika przy zmianie domeny.
  3. Znasz domyślne zachowanie dla curl, requests, httpx, axios i fetch.
  4. Masz działający przykład wyłączenia automatycznego przekierowania.
  5. Masz działającą pętlę ręcznej obsługi łańcucha.
  6. Twój kod jest chroniony przed nieskończonymi pętlami limitem i zbiorem odwiedzonych adresów.
  7. Używasz sesji lepkiej Proxeon dla integralności łańcucha tam, gdzie to potrzebne.
  8. Potrafisz wypisać pełny łańcuch przekierowań w logach.

Jak przetestować

Weź testowy punkt końcowy, który odpowiada kodem 302 na żądanie POST. Przepuść go przez automatyczne przekierowanie i upewnij się, że metoda stała się GET. Następnie przepuść go przez ręczną obsługę z zachowaniem metody i upewnij się, że POST dotarł do finalnego adresu. Różnica w zachowaniu będzie dowodem, że wszystko kontrolujesz.

✅ Sprawdzenie: Oba scenariusze – automatyczne przekierowanie i ręczna obsługa – dają przewidywalny, wytłumaczalny wynik, a nie przypadkowy.

Typowe błędy i rozwiązania

Omówimy najczęstsze pułapki i sposoby ich omijania.

Błąd 1: POST stał się GET

Przyczyna: serwer zwrócił kod 301 lub 302, a klient według historycznej zasady zmienił metodę. Rozwiązanie: jeśli kontrolujesz serwer, zwracaj 307 lub 308. Jeśli nie – wyłącz automatyczne przekierowanie i powtórz żądanie właściwą metodą ręcznie.

Błąd 2: zniknął nagłówek Authorization

Przyczyna: przekierowanie prowadzi do innej domeny, klient usunął sekret ze względów bezpieczeństwa. Rozwiązanie: sprawdź domenę z Location, a jeśli jest zaufana, dodaj Authorization do następnego żądania ręcznie.

Błąd 3: skrypt działał na requests, ale zepsuł się na httpx

Przyczyna: httpx domyślnie nie podąża za przekierowaniami, a requests podąża. Rozwiązanie: jawnie ustaw follow_redirects=True w httpx lub odwrotnie – wszędzie przejdź na ręczną obsługę dla jednolitości.

Błąd 4: aplikacja zawiesiła się na łańcuchu

Przyczyna: nieskończona pętla przekierowań bez ograniczenia głębokości. Rozwiązanie: dodaj limit przekierowań i zbiór odwiedzonych adresów, jak pokazano w kroku 5.

Błąd 5: sesja jest zrywana w środku łańcucha

Przyczyna: kroki łańcucha przeszły przez różne IP z powodu rotacji proxy. Rozwiązanie: włącz sesję lepką Proxeon i używaj jednego obiektu sesji klienta dla wszystkich kroków.

Błąd 6: ciasteczko nie jest wysyłane po przekierowaniu

Przyczyna: flaga Secure, Domain lub SameSite nie pasuje do nowego adresu. Rozwiązanie: sprawdź protokół i domenę w Location i upewnij się, że odpowiadają flagom ciasteczka. Nie zdejmuj flag ochronnych dla wygody.

Błąd 7: curl nie podąża za przekierowaniem

Przyczyna: zapomniałeś flagi -L. Rozwiązanie: dodaj -L dla automatycznego przekierowania lub zostaw bez niej dla ręcznej kontroli – w zależności od zadania.

Dodatkowe możliwości i optymalizacja

Gdy opanujesz podstawy, warto zaprowadzić porządek i zwiększyć niezawodność.

Jednolity moduł obsługi przekierowań

Nie rozrzucaj logiki po kodzie. Zbierz obsługę łańcucha w jedną funkcję z parametrami: listą zaufanych domen, maksymalną głębokością, zestawem kodów do zachowania metody. Dzięki temu zachowanie będzie jednolite w całym projekcie.

Biała lista domen dla Authorization

Stwórz jawną listę domen, na które wolno przekazywać Authorization przy przekierowaniu. Wszystko poza listą – nigdy nie otrzymuje sekretu. To czyni bezpieczeństwo zarządzalnym, a nie przypadkowym.

Metryki łańcuchów

Zbieraj statystyki: średnia długość łańcucha, odsetek żądań z przekierowaniami, kody, które występują najczęściej. Anomalny wzrost długości łańcuchów to wczesny sygnał problemów po stronie serwera docelowego.

Wskazówka: Skonfiguruj ostrzeżenie, jeśli łańcuch przekroczy trzy przekierowania. W większości poprawnych scenariuszy wystarcza jeden-dwa. Nagły wzrost to powód, aby sprawdzić, co zmieniło się na zasobie docelowym.

FAQ: najczęstsze pytania o obsługę przekierowań

Dlaczego POST staje się GET, skoro nic nie zmieniałem?

Ponieważ serwer zwrócił kod 301 lub 302, a twój klient według historycznej zasady zmienił metodę na GET. Aby tego uniknąć, potrzebny jest kod 307 lub 308 albo ręczna obsługa.

Czy proxy zmienia metodę żądania podczas przekierowania?

Nie. Proxeon i każde poprawne proxy po prostu przesyła status i Location. Decyzję o zmianie metody podejmuje twój klient HTTP. Przyczyny należy szukać w ustawieniach klienta.

Jak zachować Authorization przy przejściu na inną domenę?

Tylko ręcznie. Wyłącz automatyczne przekierowanie, sprawdź domenę z Location, upewnij się, że jest zaufana, i dodaj nagłówek Authorization do następnego żądania sam.

Jaki kod najlepiej użyć do przekierowania POST?

Kod 307 dla tymczasowego i 308 dla stałego przekierowania. Oba zachowują metodę i ciało żądania, chroniąc klientów przed niespodziankami.

Dlaczego ten sam skrypt zachowuje się inaczej w requests i httpx?

Ponieważ requests domyślnie podąża za przekierowaniami, a httpx – nie. Jawnie ustawiaj konfigurację przekierowań, aby zachowanie było spójne.

Jak zabezpieczyć się przed nieskończoną pętlą przekierowań?

Ustaw sztywny limit przekierowań i prowadź zbiór już odwiedzonych adresów. Jeśli adres się powtarza lub limit zostanie przekroczony – przerywaj łańcuch z błędem.

Dlaczego sesja rwie się w środku łańcucha przekierowań?

Najprawdopodobniej kroki przeszły przez różne IP z powodu rotacji. Włącz sesję lepką Proxeon i używaj jednego obiektu sesji klienta dla wszystkich kroków.

Dlaczego ciasteczko nie jest wysyłane po przekierowaniu?

Z powodu niezgodności flag Secure, Domain lub SameSite z nowym adresem. Sprawdź protokół i domenę w Location. Flag ochronnych nie wolno zdejmować.

Jak zobaczyć cały łańcuch przekierowań?

W curl użyj -v -L. W requests i httpx sprawdź atrybut history finalnej odpowiedzi. W axios i fetch loguj każdy krok ręcznie.

Czy można całkowicie zakazać przekierowań?

Tak. W curl nie dodawaj -L, w requests ustaw allow_redirects=False, w httpx nie włączaj follow_redirects, w axios ustaw maxRedirects: 0, w fetch podaj redirect: "manual".

Zakończenie

Masz teraz pełny i praktyczny obraz pracy z przekierowaniami przez proxy. Rozumiesz, dlaczego POST staje się GET, i wiesz, że winne temu nie jest proxy, lecz historyczne zasady obsługi kodów 301 i 302. Znasz różnicę między 301, 302, 307 i 308 i potrafisz wybrać właściwy kod. Wiesz, jakie dane giną podczas przekierowania: Authorization w innej domenie, niestandardowe nagłówki, ciasteczka z flagami ochronnymi.

Poznałeś domyślne zachowanie curl, requests, httpx, axios i fetch i nie zaskoczą cię już rozbieżności przy przenoszeniu kodu. Masz działające przykłady wyłączania automatycznego przekierowania i ręcznej obsługi łańcucha z pełną kontrolą metody i nagłówków. Umiesz chronić się przed pętlami i utrzymywać jedną sesję na jednym IP przez sesję lepką Proxeon. Wreszcie – umiesz debugować łańcuchy i widzieć każdy krok.

Co zrobić dalej? Zbuduj jednolity moduł obsługi przekierowań z białą listą domen dla Authorization i konfigurowalną głębokością. Dodaj metryki długości łańcuchów. Przepuść swoje rzeczywiste scenariusze przez ręczną obsługę i porównaj z automatycznym przekierowaniem – w ten sposób znajdziesz ukryte miejsca, gdzie ginęły dane.

Idź dalej w zgłębianiu stosu sieciowego: poznaj dokładniej cykl życia ciasteczek, subtelności połączeń TLS i ponowne wykorzystywanie połączeń. Każda z tych umiejętności sprawi, że twoja praca z proxy Proxeon będzie jeszcze bardziej niezawodna i przewidywalna. Życzymy udanej pracy inżynierskiej oraz czystych, przejrzystych łańcuchów żądań.