Jak sprawdzić w CMD, czy strona działa poprawnie? Test bez przeglądarki

Odpowiedź strony w CMD można sprawdzić poleceniem curl, bez otwierania witryny w przeglądarce. Wynik pokaże kod HTTP albo błąd połączenia. Pozwala to ustalić, czy udało się dotrzeć do usługi WWW i jak odpowiedziała na żądanie. Sam kod 200 nie potwierdza jednak działania wszystkich funkcji strony.

Taki test przydaje się, gdy witryna nie chce się otworzyć, wyświetla pusty ekran albo działa tylko w jednej sieci. Pomaga też porównać wynik z własnego komputera z testem dostępności strony wykonywanym z serwera bynet.pl. Oba pomiary dotyczą odpowiedzi HTTP, ale odbywają się z różnych miejsc w sieci.

Jak sprawdzić w CMD, czy strona odpowiada?

W Windows najprościej użyć programu curl.exe. Jest dostępny standardowo w Windows 11 i nowszych wydaniach Windows 10. Do zwykłego testu strony nie potrzeba uprawnień administratora.

1. Naciśnij Windows + R.
2. Wpisz cmd i zatwierdź Enterem.
3. Wklej poniższe polecenie, zastępując adres adresem sprawdzanej strony.

curl.exe -I --max-time 20 "https://example.com"

Parametr -I wysyła żądanie HEAD, które pobiera nagłówki bez treści strony. --max-time 20 ogranicza cały test do 20 sekund. Adres powinien zawierać https:// albo http://, zgodnie ze sprawdzaną wersją witryny. Cudzysłowy chronią przed interpretowaniem znaków w adresie przez wiersz poleceń.

Przykładowy, uproszczony wynik może wyglądać tak:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Pierwszy wiersz zawiera kod odpowiedzi HTTP. Tutaj jest to 200, czyli pomyślna obsługa żądania. Oznaczenie wersji protokołu może być inne, zależnie od programu i serwera.

Nie każdy serwer poprawnie obsługuje HEAD. Jeśli pojawi się kod 405 albo wynik wyraźnie różni się od działania strony w przeglądarce, trzeba porównać go z testem GET opisanym dalej.

Co oznacza kod odpowiedzi HTTP?

Otrzymanie kodu HTTP oznacza, że jakaś warstwa obsługująca adres odpowiedziała na żądanie. Może to być właściwy serwer, serwer pośredniczący albo system ochrony witryny. Kod mówi, jak obsłużono konkretną próbę dostępu.

Wynik	Co oznacza?	Co sprawdzić dalej?
200 OK	Żądanie obsłużono pomyślnie.	Czy pobrano oczekiwaną treść i czy działają potrzebne funkcje?
301, 302, 307, 308	Adres przekierowuje do innego miejsca.	Docelowy adres i jego odpowiedź po przekierowaniu.
401 Unauthorized	Dostęp wymaga uwierzytelnienia.	Czy adres jest przeznaczony dla zalogowanych użytkowników?
403 Forbidden	Serwer odmawia realizacji żądania.	Uprawnienia, blokadę IP lub ochronę przed automatycznymi zapytaniami.
404 Not Found	Nie znaleziono zasobu albo serwer nie ujawnia jego istnienia.	Dokładny adres podstrony i odpowiedź strony głównej.
405 Method Not Allowed	Wybrana metoda nie jest dozwolona dla tego zasobu.	Wynik GET zamiast HEAD.
429 Too Many Requests	Przekroczono dopuszczalną liczbę żądań.	Przerwę przed następnym testem i ewentualny nagłówek Retry-After.
500, 502, 503, 504	Wystąpił błąd serwera lub warstwy pośredniej.	Znaczenie konkretnego kodu i zasięg problemu.

Błąd 404 jednej podstrony nie oznacza niedostępności całej witryny. Podobnie 403 może dotyczyć wyłącznie żądań programu curl, podczas gdy zwykła przeglądarka otrzymuje dostęp.

Przy odpowiedziach z rodziny 5xx dalsze rozpoznanie zależy od numeru. Inaczej interpretuje się wewnętrzny błąd aplikacji, a inaczej przekroczenie czasu oczekiwania między serwerami. Te różnice opisujemy w poradniku o błędach serwera 5xx.

Jak sprawdzić stronę po przekierowaniu?

Pierwsza odpowiedź często przenosi z HTTP na HTTPS albo z domeny bez www na wersję z tym przedrostkiem. Samo przekierowanie nie jest awarią, ale trzeba jeszcze sprawdzić, dokąd prowadzi.

curl.exe -I -L --max-redirs 10 --max-time 20 "https://example.com"

Parametr -L pozwala podążać za przekierowaniami HTTP. --max-redirs 10 ogranicza ich liczbę, dzięki czemu zapętlone przekierowania nie będą kontynuowane bez końca. Nadal obowiązuje limit 20 sekund dla całej operacji.

Wynik może zawierać kilka bloków nagłówków. Przykładowo najpierw pojawi się 301 z nagłówkiem Location, a następnie 200 z adresu docelowego. Odczytać trzeba cały przebieg i ostatnią odpowiedź, zamiast zatrzymywać się na pierwszym numerze.

Jeśli test kończy się błędem przekroczenia liczby przekierowań, przyczyną może być pętla, na przykład wzajemne odsyłanie dwóch wersji adresu. To inna sytuacja niż brak możliwości połączenia z serwerem.

Test GET: gdy HEAD nie wystarcza

GET pobiera treść wskazanego zasobu. To metoda używana także przy typowym otwieraniu dokumentu w przeglądarce, choć samo żądanie curl nadal różni się od pełnego działania przeglądarki.

Do porównania służy polecenie:

curl.exe -sS -L --max-redirs 10 --max-time 20 -D - -o NUL "https://example.com"

Poszczególne parametry odpowiadają za sposób pokazania wyniku:

• -sS ukrywa pasek postępu, ale pozostawia komunikaty błędów.
• -D - wyświetla nagłówki odpowiedzi w oknie CMD.
• -o NUL odrzuca pobraną treść, żeby kod HTML nie zasłonił wyniku.
• -L obsługuje przekierowania, a pozostałe ograniczenia zatrzymują zbyt długi test.

Bez -I i bez opcji zmieniających metodę curl wykonuje tutaj GET. Treść jest pobierana, lecz nie jest wyświetlana ani renderowana.

Jeżeli HEAD zwraca 405, a GET otrzymuje 200, różnica dotyczy obsługi metod. Nie ma wtedy podstaw, by na podstawie samego HEAD uznać stronę za niedostępną. Wynik GET pomaga rozpoznać tę sytuację, ale nadal nie sprawdza logowania, formularzy ani działania skryptów.

Jak sprawdzić kod HTTP i czas odpowiedzi w jednym wyniku?

Gdy nie są potrzebne wszystkie nagłówki, curl może wypisać krótki raport. Poniższe polecenie jest przeznaczone do wklejenia bezpośrednio w CMD:

curl.exe -sS -L --max-redirs 10 --max-time 20 -o NUL -w "HTTP: %{http_code}\nCzas: %{time_total} s\nAdres: %{url_effective}\n" "https://example.com"

Przykładowy wynik, podany wyłącznie jako ilustracja:

HTTP: 200
Czas: 0.438 s
Adres: https://example.com/

http_code pokazuje ostatni otrzymany kod HTTP, a url_effective końcowy adres. time_total podaje łączny czas operacji, obejmujący także pobieranie odpowiedzi oraz obsługiwane przekierowania.

To nie jest czas pełnego załadowania strony w przeglądarce. Polecenie nie pobiera automatycznie wszystkich obrazów, arkuszy CSS i skryptów powiązanych z dokumentem. Nie mierzy też momentu, w którym witryna staje się gotowa do używania. Duży dokument może wydłużyć ten pomiar mimo szybkiego rozpoczęcia odpowiedzi.

W pliku .bat lub .cmd znaki % w formacie -w trzeba podwoić, na przykład do %%{http_code}. Zapis powyżej dotyczy ręcznego wykonania w oknie CMD.

Co oznaczają błędy curl i wynik HTTP 000?

Jeśli nie uda się uzyskać odpowiedzi HTTP, zamiast nagłówków pojawi się komunikat programu. Numer w zapisie curl: (28) jest kodem błędu curl, a nie kodem HTTP.

Komunikat lub wynik	Znaczenie	Następny krok
curl: (6)	Nie udało się rozpoznać nazwy hosta.	Sprawdzenie pisowni domeny i DNS.
curl: (7)	Nie udało się nawiązać połączenia.	Weryfikacja adresu, portu i dostępu z innej sieci.
curl: (28)	Przekroczono limit czasu.	Odczyt pełnego komunikatu i porównanie z innym punktem pomiaru.
curl: (35)	Wystąpił problem podczas uzgadniania połączenia TLS.	Sprawdzenie szczegółów błędu i konfiguracji HTTPS.
curl: (60)	Nie powiodła się weryfikacja certyfikatu serwera.	Sprawdzenie komunikatu, zegara systemowego i zaufania do certyfikatu.
HTTP: 000	Curl nie ma kodu odpowiedzi HTTP do pokazania.	Odczyt towarzyszącego błędu programu.

000 nie jest kodem HTTP wysłanym przez witrynę. Zwykle pojawia się, gdy próba zakończyła się przed uzyskaniem odpowiedzi, na przykład na etapie DNS, połączenia lub TLS.

Timeout też nie wskazuje jednej przyczyny. Limit może upłynąć podczas łączenia, oczekiwania na odpowiedź albo pobierania danych. Sam numer 28 nie dowodzi przeciążenia serwera.

Przy błędach HTTPS znaczenie ma pełny komunikat. Przyczyny obejmują między innymi niewłaściwą nazwę w certyfikacie, problem z łańcuchem zaufania lub błędny czas na komputerze. Sposób ich rozróżnienia opisuje poradnik o błędzie certyfikatu SSL. Dodanie -k wyłącza weryfikację certyfikatu, więc nie potwierdza poprawnego działania HTTPS.

Czy ping wystarczy do sprawdzenia strony internetowej?

Ping sprawdza odpowiedzi ICMP, a nie działanie HTTP lub HTTPS. Można go wykonać jako dodatkowy test łączności:

ping example.com

W tym poleceniu podaje się samą nazwę hosta, bez https:// i bez ścieżki podstrony. Poprawny wynik oznacza, że cel odpowiedział na pakiety testowe. Nie potwierdza, że usługa WWW przyjmuje połączenia ani że aplikacja działa.

Możliwa jest też sytuacja odwrotna: strona działa, ale ping nie otrzymuje odpowiedzi, ponieważ ruch ICMP jest filtrowany. Dlatego dostępność witryny należy sprawdzać żądaniem HTTP, a ping traktować pomocniczo.

Jeżeli curl nie potrafi rozpoznać domeny, przydaje się sprawdzenie DNS:

nslookup example.com

nslookup odpytuje DNS i pozwala zobaczyć między innymi zwrócone adresy. Poprawna odpowiedź DNS nie potwierdza jeszcze, że pod tym adresem działa serwer WWW. Również ustawienia DNS przeglądarki mogą różnić się od używanych w tym teście. Dalszą diagnostykę opisujemy przy awarii DNS.

Dlaczego strona odpowiada w CMD, ale nie działa poprawnie?

Curl sprawdza odpowiedź na konkretne żądanie, a przeglądarka buduje z wielu zasobów działającą stronę. Pobranie dokumentu HTML to dopiero część tego procesu.

Witryna może zwracać 200, a mimo to mieć uszkodzony skrypt, niedostępne API, problem z logowaniem lub niedziałający formularz. Odpowiedź 200 może też zawierać komunikat o pracach technicznych zamiast oczekiwanej treści.

Standardowe polecenia curl nie uruchamiają JavaScriptu, nie korzystają automatycznie z sesji zalogowanej w przeglądarce i nie wykonują działań użytkownika. Sukces testu strony głównej nie potwierdza więc, że można zapłacić za zamówienie, wysłać wiadomość albo odtworzyć film.

Przy problemie z konkretną usługą wynik HTTP trzeba zestawić z jej objawami. Jeśli nie działa publikowanie lub logowanie, pomocne jest na przykład sprawdzenie informacji o awarii Facebooka. Odpowiedź strony głównej nie rozstrzyga o sprawności tych funkcji.

Dlaczego wynik bynet.pl różni się od testu na komputerze?

Test w CMD wychodzi z komputera użytkownika, a test bynet.pl z naszego serwera. Różnią się adresy IP, trasy połączeń, a czasem również odpowiedzi DNS i serwery obsługujące żądanie.

Witryna może dodatkowo inaczej traktować ruch z centrum danych, VPN lub konkretnego kraju. Znaczenie mają też metoda żądania, nagłówki i reguły ochrony przed botami. Dwa testy HTTP nie muszą więc otrzymać identycznej odpowiedzi.

Poniżej chodzi o porównanie dostępu do tego samego adresu i oczekiwanej odpowiedzi, a nie o samo pojawienie się dowolnego kodu:

Wynik porównania	Co z niego wynika?	Co dalej?
Lokalny test i bynet.pl otrzymują oczekiwaną odpowiedź.	Adres jest dostępny z obu punktów w chwili pomiaru.	Sprawdzenie problematycznej funkcji w przeglądarce.
Lokalny test zawodzi, bynet.pl otrzymuje oczekiwaną odpowiedź.	Problem nie występuje jednakowo na obu trasach.	Porównanie z internetem mobilnym oraz kontrola lokalnego DNS, VPN i komunikatu curl.
Lokalny test działa, a bynet.pl zawodzi.	Wynik z serwera bynet.pl nie opisuje dostępu wszystkich użytkowników.	Porównanie kodów, czasu i możliwych blokad ruchu serwerowego.
Oba testy zawodzą.	Problem wystąpił z dwóch punktów pomiaru.	Sprawdzenie innej sieci, konkretnego błędu i informacji o usłudze.

Dwa nieudane testy nie dowodzą jeszcze awarii u wszystkich. Trzeba także uwzględnić czas pomiaru, ponieważ krótki przestój może zakończyć się pomiędzy próbami.

Gdy problem dotyczy wielu adresów tylko w jednej sieci, dalsze działania powinny obejmować diagnostykę połączenia internetowego. Jeśli celem jest wykrywanie kolejnych przestojów własnej witryny, potrzebny jest monitoring strony internetowej, który wykonuje pomiary cyklicznie. Pojedynczy test CMD pokazuje stan w danym momencie.

Najczęściej zadawane pytania o sprawdzanie strony w CMD

Poniższe odpowiedzi dotyczą uruchamiania poleceń w Windows i sprawdzania konkretnych adresów.