Niewielki zestaw narzędzi do debugowania przekierowań i nagłówków HTTP w produkcji

Problem z debugowaniem HTTP w produkcji

Większość problemów HTTP jest niewidoczna w przeglądarce. Łańcuch przekierowań zawodzi po cichu, nagłówek pamięci podręcznej różni się o jeden znak, polityka CORS blokuje żądanie bez wyjaśnienia. Narzędzia deweloperskie przeglądarki pokazują wynik rozmowy, ale często ukrywają surową wymianę, która spowodowała problem.

Ma to największe znaczenie w produkcji, gdzie nie można po prostu dodać logowania ani zrestartować usług, aby sprawdzić, co się zmieniło. Potrzebujesz narzędzi, które pokazują rzeczywistą rozmowę HTTP: nagłówki żądania, nagłówki odpowiedzi, kody statusu, cele przekierowań, czasy. Oto pięć narzędzi, które niezawodnie wykonują to zadanie, oraz techniki przeglądarkowe, które je uzupełniają.

curl: podstawa

curl to pierwsze narzędzie, po które warto sięgnąć, ponieważ pokazuje dokładnie to, co wysłał serwer, bez interpretacji przeglądarki po drodze.

Aby zobaczyć nagłówki odpowiedzi bez treści:

curl -I https://example.com

Aby śledzić przekierowania i zobaczyć każdy krok:

curl -L -v https://example.com

Flaga -v (verbose) pokazuje pełne żądanie i odpowiedź, w tym wszystkie nagłówki. Flaga -L automatycznie podąża za przekierowaniami. Razem pokazują cały łańcuch przekierowań, czyli miejsce, w którym znajduje się większość problemów produkcyjnych.

Aby zobaczyć tylko lokalizacje przekierowań:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Jest to przydatne, gdy trzeba zweryfikować łańcuch przekierowań bez szumu pełnych nagłówków. Flaga -w formatuje wynik tak, aby pokazać tylko kod statusu i następny URL w łańcuchu.

curl pozwala też wysyłać niestandardowe nagłówki, co jest niezbędne przy testowaniu zachowania CDN, uwierzytelniania lub endpointów API:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl z lepszymi ustawieniami domyślnymi

httpie to narzędzie w Pythonie, które robi to, co curl, ale ma składnię łatwiejszą do zapamiętania i wynik łatwiejszy do czytania. Nie jest zamiennikiem — curl jest potężniejszy i częściej zainstalowany — ale do szybkich kontroli httpie bywa szybsze.

Aby zobaczyć nagłówki:

http HEAD https://example.com

Aby śledzić przekierowania:

http --follow --all https://example.com

Flaga --all pokazuje każdą odpowiedź w łańcuchu przekierowań, nie tylko końcową. To odpowiednik curl -L -v, ale wynik jest kolorowany i łatwiejszy do przejrzenia.

Aby wysłać JSON:

http POST https://api.example.com name=value

httpie domyślnie zakłada JSON, co oszczędza pisania podczas testowania API. Ładnie formatuje też odpowiedź, dzięki czemu łatwiej zauważyć nieprawidłowe nagłówki lub nieoczekiwane wartości.

Browser DevTools: karta Network

Karta Network w przeglądarce to miejsce, od którego warto zacząć, jeśli problem występuje tylko w przeglądarce. Pokazuje te same informacje co curl, ale pokazuje też interpretację przeglądarki: czy zablokowała żądanie, jak obsłużyła cache, czy wysłała cookies.

Aby zobaczyć pełne nagłówki żądania i odpowiedzi, kliknij dowolne żądanie na karcie Network, a następnie spójrz na sekcję Headers. Widok "Raw" pokazuje nagłówki dokładnie tak, jak zostały wysłane, bez formatowania.

Aby zobaczyć łańcuchy przekierowań, szukaj żądań z kodami statusu 3xx. Przeglądarka grupuje je pod końcowym żądaniem, ale można je rozwinąć, aby zobaczyć każdy krok. To tutaj znajdziesz pętle przekierowań, brakujące nagłówki Location lub przekierowania wskazujące niewłaściwą domenę.

Aby zobaczyć czasy, spójrz na kartę Timing dla dowolnego żądania. Pokazuje ona, ile czasu przeglądarka poświęciła na wyszukiwanie DNS, połączenie TCP, uzgadnianie TLS i oczekiwanie na serwer. Jeśli przekierowanie jest wolne, karta Timing mówi, czy problemem jest opóźnienie sieci, czy przetwarzanie po stronie serwera.

Jedno ograniczenie: przeglądarka ukrywa część nagłówków ze względów bezpieczeństwa. Nagłówki Set-Cookie są widoczne, ale rzeczywiste wartości cookies są redagowane. Nagłówki Authorization bywają całkowicie ukryte. Jeśli musisz je zobaczyć, użyj curl.

mitmproxy: proxy przechwytujące

mitmproxy to narzędzie w Pythonie, które działa między przeglądarką a serwerem, pokazując każde żądanie i każdą odpowiedź w czasie rzeczywistym. Jest bardziej złożone niż curl, ale to jedyne narzędzie, które pokazuje, co przeglądarka naprawdę wysyła, w tym nagłówki dodawane automatycznie przez przeglądarkę.

Aby je uruchomić:

mitmproxy

Następnie skonfiguruj przeglądarkę tak, aby używała localhost:8080 jako proxy HTTP. mitmproxy pokaże każde żądanie w interfejsie terminalowym. Możesz sprawdzać nagłówki, edytować żądania przed wysłaniem albo odtwarzać żądania z innymi parametrami.

Jest to przydatne przy debugowaniu problemów, które występują tylko w przeglądarce: żądań preflight CORS, obsługi cookies lub żądań, które zawodzą, gdy obecne są określone nagłówki. Przydaje się też do testowania, jak witryna zachowuje się za firmowym proxy lub VPN, ponieważ mitmproxy potrafi symulować takie środowiska.

Wadą jest złożoność konfiguracji. Trzeba zainstalować certyfikat główny, aby mitmproxy mogło przechwytywać ruch HTTPS, oraz skonfigurować przeglądarkę do korzystania z proxy. Do szybkich kontroli curl jest szybszy. Do głębokiego debugowania mitmproxy jest warte czasu poświęconego na konfigurację.

webpagetest: perspektywa produkcyjna

WebPageTest to bezpłatna usługa, która ładuje stronę w prawdziwych przeglądarkach z różnych lokalizacji i pokazuje pełną rozmowę HTTP. Jest wolniejsza niż curl, ale pokazuje to, czego doświadczają realni użytkownicy, w tym zachowanie CDN, rozwiązywanie DNS i negocjację TLS.

Widoki "Request Headers" i "Response Headers" pokazują dokładnie, co przeglądarka wysłała i odebrała. Widok "Waterfall" pokazuje czasy każdego żądania, w tym przekierowań. To tutaj znajdziesz problemy, które występują tylko w określonych regionach lub w określonych sieciach.

WebPageTest pokazuje też łańcuch przekierowań dla głównego dokumentu, czyli miejsce, w którym znajduje się większość problemów z przekierowaniami. Jeśli Twoja witryna przekierowuje z http:// na https://, potem z www. na wariant bez www., a następnie z / na /en/, WebPageTest pokaże wszystkie trzy kroki i czas trwania każdego z nich.

W przypadku narzędzi pomagających weryfikować i optymalizować te podstawy HTTP Wux Webtools oferuje kilka narzędzi, które działają w całości w przeglądarce, w tym analizatory nagłówków i kontrolery przekierowań, które szanują prywatność, przetwarzając wszystko po stronie klienta.

Gdy nagłówki kłamią

Najtrudniejsze problemy HTTP to te, w których serwer wysyła sprzeczne nagłówki. Nagłówek Cache-Control mówi no-cache, ale nagłówek Expires mówi, że zasób jest ważny przez rok. Nagłówek Location wskazuje względny URL, ale nagłówek Content-Location wskazuje coś innego. Przeglądarka musi zgadnąć, któremu zaufać, a różne przeglądarki zgadują inaczej.

Gdy tak się dzieje, trzeba zobaczyć surowe nagłówki w kolejności, w jakiej wysłał je serwer. curl -v to pokazuje. mitmproxy również. DevTools przeglądarki czasem zmieniają kolejność nagłówków dla czytelności, co ukrywa problem.

Inny częsty problem: nagłówki dodane przez CDN lub load balancer, a nie przez aplikację. Jeśli debugujesz problem z cache, musisz wiedzieć, czy nagłówek Cache-Control pochodzi z aplikacji, czy z CDN. curl pokazuje końcowy wynik, ale nie mówi, skąd pochodzi każdy nagłówek. Do tego trzeba ominąć CDN (uderzając bezpośrednio w serwer origin) i porównać nagłówki.

Problem pętli przekierowań

Pętle przekierowań to najczęstszy problem HTTP w produkcji. Powstają, gdy dwa serwery nie zgadzają się co do tego, dokąd powinien wskazywać URL: CDN przekierowuje do origin, origin przekierowuje z powrotem do CDN. Albo load balancer przekierowuje HTTP na HTTPS, ale aplikacja przekierowuje HTTPS z powrotem na HTTP, bo nie widzi nagłówka X-Forwarded-Proto.

Aby to zdebugować, trzeba zobaczyć pełny łańcuch przekierowań, w tym nagłówek Location na każdym kroku. curl -L -v to robi, ale zatrzymuje się po 50 przekierowaniach, aby zapobiec nieskończonym pętlom. Jeśli trafiasz na ten limit, masz pętlę przekierowań.

Rozwiązaniem jest zwykle zmiana konfiguracji: poinformowanie aplikacji, aby ufała nagłówkowi X-Forwarded-Proto, albo poinformowanie CDN, aby przestał przekierowywać żądania, które już są HTTPS. Nie da się jednak tego naprawić, dopóki nie zobaczysz pętli, a przeglądarka nie pokaże więcej niż kilku przekierowań, zanim się podda.

Co sprawdzić najpierw

Gdy coś psuje się w produkcji, sprawdzaj te elementy po kolei:

1. Kod statusu: Czy jest taki, jak oczekiwano? 301 jest trwały, 302 jest tymczasowy, 307 zachowuje metodę HTTP. Jeśli widzisz zły kod, problem leży w konfiguracji przekierowań.

1. Nagłówek Location: Czy wskazuje właściwe miejsce? Czy jest to bezwzględny URL, czy względny? Względne URL-e są rozwiązywane względem bieżącego URL-a, co może dać nieoczekiwane wyniki, jeśli bazowy URL nie jest taki, jak zakładasz.

1. Nagłówki cache: Czy przeglądarka cache'uje przekierowanie? Przekierowanie 301 jest domyślnie cache'owane, co oznacza, że błędnie skonfigurowane przekierowanie może psuć witrynę przez wiele godzin nawet po naprawie. Sprawdź nagłówki Cache-Control i Expires, aby zobaczyć, jak długo przeglądarka będzie pamiętać przekierowanie.

1. Nagłówki CORS: Jeśli żądanie jest cross-origin, czy serwer wysyła właściwy nagłówek Access-Control-Allow-Origin? Jeśli nie, przeglądarka zablokuje żądanie, a w konsoli zobaczysz błąd CORS. Nagłówki odpowiedzi serwera to jedyne miejsce, w którym można to naprawić — nie da się tego obejść w przeglądarce.

1. Czasy: Ile trwało żądanie? Jeśli jest wolne, czy przyczyną jest opóźnienie sieci, czy przetwarzanie po stronie serwera? DevTools przeglądarki i WebPageTest pokazują rozbicia czasów, które mówią, gdzie upłynął czas.

Aby głębiej spojrzeć na to, jak zachowanie przeglądarek zmieniło się wokół prywatności i nagłówków, zobacz co zmieniło się w cookies w 2026 roku i co z tym zrobić, gdzie omówiono konsekwencje ostatnich aktualizacji przeglądarek dla nagłówków i zgód.

Najważniejsze wnioski

• curl -L -v pokazuje pełny łańcuch przekierowań i wszystkie nagłówki, bez interpretacji przeglądarki
• Karta Network w przeglądarce pokazuje, co przeglądarka zrobiła z odpowiedzią, w tym decyzje dotyczące cache i CORS
• mitmproxy pokazuje, co przeglądarka wysłała, w tym nagłówki dodawane automatycznie przez przeglądarkę
• WebPageTest pokazuje, czego doświadczają realni użytkownicy, w tym zachowanie CDN i różnice regionalne
• Pętle przekierowań i sprzeczne nagłówki to najczęstsze problemy produkcyjne, a bez inspekcji surowego HTTP są niewidoczne

FAQ

Q: Dlaczego curl pokazuje inne nagłówki niż przeglądarka?

A: Ponieważ przeglądarka automatycznie dodaje nagłówki (User-Agent, Accept, Cookie) i stosuje własne reguły cache oraz CORS. curl wysyła tylko to, co każesz mu wysłać. Aby zobaczyć, co przeglądarka faktycznie wysyła, użyj mitmproxy albo DevTools przeglądarki.

Q: Jak debugować przekierowanie, które występuje tylko u niektórych użytkowników?

A: Sprawdź, czy przekierowanie zależy od nagłówków wysyłanych przez użytkownika: User-Agent, Accept-Language, Cookie lub adresu IP (przez X-Forwarded-For). Użyj curl, aby wysłać te same nagłówki, które wysłał użytkownik, albo użyj WebPageTest, aby załadować stronę z lokalizacji użytkownika.

Q: Jaka jest różnica między przekierowaniami 301 i 302?

A: 301 jest trwałe i mówi przeglądarce, aby cache'owała przekierowanie (czasem na zawsze). 302 jest tymczasowe i mówi przeglądarce, aby go nie cache'owała. Jeśli nie masz pewności, którego użyć, użyj 302 — zawsze możesz później zmienić je na 301.

Q: Dlaczego moje przekierowanie działa w curl, ale nie w przeglądarce?

A: Prawdopodobnie dlatego, że przeglądarka cache'uje stare przekierowanie albo blokuje przekierowanie z powodu CORS lub reguł mixed content. Sprawdź konsolę DevTools przeglądarki pod kątem błędów i sprawdź nagłówki Cache-Control, aby zobaczyć, czy przeglądarka używa odpowiedzi z cache.

Q: Jak zobaczyć nagłówki dodawane przez CDN?

A: Użyj curl, aby uderzyć w URL CDN, a następnie użyj curl ponownie, aby uderzyć bezpośrednio w serwer origin (omijając CDN). Porównaj nagłówki. Te, które pojawiają się tylko w pierwszej odpowiedzi, pochodzą z CDN.

<!-- tool-cta:start -->

💡 Wypróbuj to: Podczas tropienia problemów z przekierowaniami Redirect Checker śledzi cały łańcuch i pokazuje kody stanu oraz nagłówki na każdym etapie.

<!-- tool-cta:end -->

Źródła

• curl documentation — Oficjalne odniesienie do opcji wiersza poleceń i zachowania curl
• HTTPie documentation — Przewodnik po składni i funkcjach httpie
• MDN Web Docs: HTTP redirections — Kompleksowe wyjaśnienie kodów statusu przekierowań HTTP i ich zachowania
• WebPageTest documentation — Jak interpretować wyniki i nagłówki WebPageTest