Analizator nagłówków HTTP
Darmowy analizator HTTP: statusy, redirect chain, cache, kompresja i raport nagłówków bezpieczeństwa z czytelnym Security Score. Profesjonalne narzędzie online, które działa w Twojej przeglądarce. Szybko, bezpiecznie i bez instalowania zbędnego oprogramowania.
-
1Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku. -
2Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce. -
3Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.
return "Wynik gotowy w 0.1s";
}
Analizator Nagłówków HTTP
Profesjonalny audyt odpowiedzi serwera i parametrów bezpieczeństwa Twojej witryny.
Powiązane narzędzia
Inne narzędzia, które mogą Ci się przydaćAnalizator nagłówków HTTP: sprawdź serwer, bezpieczeństwo i przekierowania w 30 sekund
Czasem strona „działa”, ale coś jest nie tak: SEO siada po migracji, cache robi bałagan, a przeglądarka krzyczy o braku HSTS. I wtedy wchodzą nagłówki HTTP — małe linijki, które mówią o Twojej witrynie więcej, niż niejedna wtyczka. Ten analizator zbiera nagłówki, liczy Security Score, pokazuje przekierowania i daje Ci czytelny raport: co jest okej, co jest podejrzane, a co warto poprawić.
darmowe online bez rejestracji raport bezpieczeństwa przekierowania 301/302 cache i kompresja
Co dokładnie sprawdzisz w nagłówkach?
Nagłówki HTTP to odpowiedź serwera na Twoje zapytanie. W praktyce zawierają informacje o tym, jak serwer dostarcza treść (status, cache, kompresja, typ danych) oraz jak zabezpiecza użytkownika (nagłówki bezpieczeństwa, polityki, ciasteczka). To dzięki nim wiesz, czy strona korzysta z HTTPS, czy ma sensowny cache, czy chroni przed clickjackingiem, czy przypadkiem nie zdradza technologii serwera.
W analizatorze dostajesz podsumowanie (status, czas odpowiedzi, rozmiar zasobu), raport bezpieczeństwa, pełną listę nagłówków oraz surową odpowiedź — idealne, gdy chcesz wkleić wynik do ticketa albo porównać konfigurację przed i po zmianach.
Kiedy to narzędzie ratuje dzień?
Najczęściej wtedy, gdy „coś” nie gra, ale trudno wskazać palcem winowajcę. Błędy cache potrafią udawać błędy aplikacji. Przekierowania potrafią zjadać budżet crawl i psuć wydajność. A brak nagłówków bezpieczeństwa bywa niewidoczny do pierwszego incydentu albo audytu.
Jeśli robisz migrację na HTTPS, wdrażasz CDN, zmieniasz serwer (np. Nginx/Apache), podmieniasz aplikację albo dopinasz WAF — test nagłówków jest jednym z najszybszych sposobów, żeby sprawdzić, czy konfiguracja poszła w dobrą stronę.
Jak używać analizatora nagłówków HTTP krok po kroku
To jest proste, ale warto trzymać się jednej zasady: testuj konkretny adres, który ma znaczenie biznesowe (np. strona główna, landing kampanii, ważny artykuł, endpoint API). Różne ścieżki mogą mieć różne nagłówki.
- Wklej pełny adres URL, najlepiej z protokołem (https://…)
- Jeśli testujesz zabezpieczenia, zostaw domyślny User-Agent. Jeśli serwer blokuje boty, wpisz własny.
- Ustaw timeout, gdy serwer bywa wolny albo stoi za „kapryśnym” proxy.
- Zdecyduj, czy chcesz podążać za przekierowaniami. Do diagnostyki SEO zwykle tak — do testów „dlaczego przekierowuje” czasem nie.
- Kliknij analizę i porównaj podsumowanie ze szczegółami w raporcie.
Jak czytać wynik: status, czas, rozmiar i „Security Score”
Kod odpowiedzi HTTP mówi, co serwer zrobił z Twoim żądaniem. 200 jest nudne (dobrze). 3xx to przekierowania (czasem okej, czasem problem). 4xx to błędy po stronie żądania albo dostępu (np. 403/404). 5xx zwykle oznacza problem serwera lub aplikacji. Analizator pokazuje też czas odpowiedzi — to nie jest pełny test wydajności, ale świetny sygnał „czy jest wolno już na starcie”.
Rozmiar zasobu (Content-Length) potrafi zdradzić rzeczy zaskakujące: nagle rośnie po wdrożeniu, bo zniknęła kompresja; spada do kilkunastu bajtów, bo serwer zwraca błąd lub placeholder; zmienia się zależnie od cache. To szybka wskazówka, gdzie szukać dalej.
Security Score to procentowy wskaźnik obecności kluczowych nagłówków bezpieczeństwa. Traktuj go jak „lampkę kontrolną”: wysoki wynik zwykle oznacza dobrą bazę, ale liczy się też jakość ustawień. Niski wynik jest jasnym sygnałem, że w konfiguracji brakuje ważnych warstw ochrony.
Nagłówki bezpieczeństwa: co jest ważne i dlaczego
W raporcie zobaczysz listę nagłówków bezpieczeństwa z informacją, czy są obecne oraz jaka jest ich wartość (albo rekomendacja, jeśli brakuje). Oto jak je rozumieć „po ludzku”, bez wchodzenia w akademickie definicje.
HSTS
Wymusza korzystanie z HTTPS przez określony czas. Chroni przed przypadkami „wróciłem na http”, a także przed częścią ataków typu downgrade.
CSP
Polityka treści, która ogranicza skąd mogą ładować się skrypty, style i zasoby. To jedno z najsilniejszych narzędzi przeciw XSS, jeśli jest ustawione z głową.
X-Frame-Options
Chroni przed osadzaniem strony w ramkach (clickjacking). Jeśli masz panel logowania albo wrażliwe akcje — to często „must have”.
Referrer-Policy
Kontroluje, ile informacji o źródle odwiedzin wychodzi do innych serwisów. Zmniejsza wycieki danych w linkach i nagłówkach.
X-Content-Type-Options
Powstrzymuje przeglądarkę przed „zgadywaniem” typu pliku. Małe, ale ważne, bo ogranicza niektóre klasy nadużyć.
Permissions-Policy
Kontroluje uprawnienia typu kamera, mikrofon, geolokalizacja. Dobre ustawienie zmniejsza powierzchnię ataku i ryzyko „niespodzianek” w przeglądarce.
Nie każdy serwis potrzebuje wszystkiego od razu. Strona-wizytówka ma inny profil ryzyka niż aplikacja z logowaniem. Ale brak podstawowych nagłówków bezpieczeństwa w 2026 roku to trochę jak jazda bez pasów — dopóki nic się nie wydarzy, jest „okej”, a potem robi się bardzo drogo.
Przekierowania: szybka diagnostyka SEO i „dlaczego jest wolno”
Jeśli włączysz podążanie za przekierowaniami, zobaczysz pełną ścieżkę: kolejne statusy i docelowe lokalizacje. To świetne do polowania na błędy typu: http → https → www → bez slash → z parametrami → i jeszcze raz. Każdy dodatkowy skok to opóźnienie, ryzyko złej kanonikalizacji i większe pole do pomyłek.
Najczęstszy zdrowy scenariusz to jedno przekierowanie (albo brak). Wszystko powyżej dwóch warto obejrzeć krytycznie. Zdarza się, że przekierowania wynikają z mieszanki: ustawień serwera, reguł aplikacji, CDN i wtyczek. Właśnie dlatego widok „łańcucha” jest tak pomocny — pokazuje fakty, a nie intencje.
Cache, kompresja i typ treści: trzy nagłówki, które robią różnicę
W podsumowaniu technicznym zwróć uwagę na Cache-Control, Content-Encoding i Content-Type. Te trzy pola potrafią wyjaśnić większość zagadek z wydajnością i „dlaczego użytkownik widzi starą wersję”.
- Cache-Control mówi, czy zasób można buforować i na jak długo. Przy dobrym ustawieniu strony wczytują się szybciej, a serwer oddycha.
- Content-Encoding pokazuje, czy działa kompresja (np. gzip/br). Brak kompresji często oznacza większe transfery i gorsze wyniki Core Web Vitals.
- Content-Type potwierdza, co serwer naprawdę wysyła. Przy problemach z CSS/JS i błędach MIME to pierwsze miejsce, gdzie warto spojrzeć.
| Nagłówek | Co mówi w praktyce | „Czerwone flagi” |
|---|---|---|
| Cache-Control | Jak długo i gdzie można buforować | Brak, sprzeczne dyrektywy, cache na treściach dynamicznych |
| Content-Encoding | Czy zasób jest skompresowany | Brak kompresji na HTML/CSS/JS, nietypowe wartości |
| Content-Type | Typ i kodowanie treści | Zły MIME dla JS/CSS, brak charset przy HTML |
| Set-Cookie | Jakie cookies ustawia serwer | Dużo cookies „znikąd”, brak flag Secure/HttpOnly/SameSite |
| Server / X-Powered-By | Co serwer zdradza o technologii | Za dużo szczegółów (wersje), brak spójności między warstwami |
| Strict-Transport-Security | Wymuszenie HTTPS w przeglądarce | Brak na serwisach produkcyjnych, zbyt krótki max-age |
Ciasteczka: ile ich jest i czy wyglądają bezpiecznie
Analizator zlicza nagłówki Set-Cookie, więc widzisz, ile cookies serwer ustawia na wejściu. Sama liczba nie jest jeszcze wyrokiem, ale bywa świetnym tropem: nagle robi się ich więcej po wdrożeniu tagów; ciasteczka mają dziwne domeny; albo nie mają podstawowych flag bezpieczeństwa.
Jeśli masz logowanie, sesje, koszyk, strefę klienta — cookies są krytyczne. Nawet jeśli nie zmieniasz aplikacji, zmiana reverse proxy czy CDN potrafi wpłynąć na to, jak cookies są ustawiane i przesyłane. Z tym narzędziem sprawdzisz to bez grzebania w DevTools.
Najczęstsze problemy i jak je szybko namierzyć
W praktyce diagnostyka nagłówków to gra w skojarzenia: widzisz symptom, szukasz nagłówka, który to potwierdzi. Poniżej kilka typowych scenariuszy.
„Strona raz działa, raz nie”
Sprawdź kody odpowiedzi i przekierowania. Jeśli w łańcuchu pojawiają się zmienne statusy (np. 302 na przemian z 200), to często oznacza reguły zależne od warunków (cookies, geolokalizacja, A/B testy) albo niestabilną warstwę pośrednią.
Warto też spojrzeć na czas odpowiedzi — duże skoki mogą wskazywać na problemy po stronie origin, a nie frontu.
„Po wdrożeniu jest wolniej”
Najpierw zobacz, czy działa kompresja (Content-Encoding). Potem cache: czy zasoby statyczne mają sensowne Cache-Control. Na koniec łańcuch przekierowań — czasem dodatkowe 301/302 to ukryty koszt, który boli szczególnie na mobile.
Jeśli rozmiar zasobu wzrósł, a kompresja zniknęła, masz odpowiedź szybciej, niż po godzinie w Lighthouse.
„Audyt bezpieczeństwa wytknął braki”
Raport bezpieczeństwa pokaże, które nagłówki są nieobecne. Zacznij od tych, które są najczęściej rekomendowane: HSTS, X-Content-Type-Options, Referrer-Policy, X-Frame-Options i sensownie ustawione cookies. CSP bywa bardziej wymagające, ale często daje największy zwrot w ochronie.
Traktuj to jako listę priorytetów: najpierw „quick wins”, potem trudniejsze polityki.
„Serwer ujawnia za dużo”
Jeśli nagłówki Server i X-Powered-By zdradzają wersje i technologie, to zwiększa ekspozycję na automatyczne skanery. W wielu przypadkach da się to ograniczyć na poziomie konfiguracji serwera lub proxy.
To nie zastępuje poprawek bezpieczeństwa, ale utrudnia życie atakującym i redukuje „szum” w raportach.
Dla kogo jest ten analizator?
Jeśli masz styczność z wdrożeniami, SEO albo bezpieczeństwem, to jest narzędzie, które przydaje się częściej, niż myślisz. Nie musisz znać na pamięć wszystkich nagłówków — wystarczy, że umiesz zadać dobre pytanie i porównać wynik „przed vs po”.
Specjaliści i właściciele stron
Weryfikujesz przekierowania, kanonikalne wejście na domenę, cache i statusy po migracji.
Programiści i admini
Sprawdzasz, czy reverse proxy/CDN nie zmienił zachowania aplikacji, cookies i kompresji.
Bezpieczeństwo i audyt
Szybko oceniasz warstwy ochrony nagłówkami i wykrywasz braki w politykach przeglądarki.
FAQ
Czy analizator działa na każdej stronie?
W większości przypadków tak, ale są wyjątki. Niektóre serwery blokują automatyczne zapytania, wymagają specyficznego User-Agenta albo dopuszczają ruch tylko z wybranych lokalizacji. Zdarza się też, że aplikacja zwraca inną odpowiedź dla przeglądarki i inną dla „bota”. Wtedy warto spróbować innego User-Agenta lub sprawdzić, czy nie działa ochrona typu WAF.
Co oznacza, że nagłówki bezpieczeństwa są „brak”?
To znaczy, że serwer ich nie zwrócił w odpowiedzi. Czasem to świadoma decyzja (np. brak CSP na bardzo prostej stronie), ale często jest to po prostu zaniedbanie albo brak spójnej konfiguracji po zmianach na serwerze. Jeśli wynik jest niski, potraktuj raport jak listę elementów do wdrożenia lub przeglądu w kolejności priorytetu.
Dlaczego widzę kilka przekierowań zamiast jednego?
Najczęściej to efekt „nakładających się” reguł: jedna warstwa wymusza HTTPS, druga dopina www, trzecia normalizuje slash na końcu, a czwarta przenosi na nową ścieżkę. Każdy krok osobno ma sens, ale razem tworzą łańcuch. W SEO i performance zwykle dążysz do minimalnej liczby skoków — im krócej, tym lepiej.
Czy wysoki Security Score oznacza, że strona jest bezpieczna?
To dobry znak, ale nie „gwarancja bezpieczeństwa”. Score informuje o obecności nagłówków, nie o tym, czy cała aplikacja jest odporna na błędy логiki, podatności w zależnościach czy wycieki danych. Nagłówki są ważną warstwą ochrony, ale warto je traktować jako część większej układanki: konfiguracji serwera, aplikacji, uprawnień i monitoringu.
Co zrobić, jeśli narzędzie nie może pobrać nagłówków?
Najpierw upewnij się, że URL jest poprawny i ma protokół (http/https). Potem zwiększ timeout, bo niektóre serwery odpowiadają wolniej albo wymagają handshake po drodze. Jeśli to nie pomoże, spróbuj ustawić inny User-Agent. Jeżeli serwis jest za ochroną anty-bot, może być konieczne testowanie z innego środowiska lub po stronie serwera (np. whitelisting).
Czy mogę używać tego do sprawdzania API i endpointów?
Tak — i to często ma jeszcze większy sens niż na zwykłej stronie HTML. API bywa wrażliwe na cache, CORS, typ treści i kompresję. Dzięki pełnej liście nagłówków zobaczysz, czy odpowiedź ma poprawny Content-Type, czy pojawiają się właściwe polityki, a także jak zachowuje się serwer w przypadku przekierowań lub błędów.