Strona internetowa nie działa u wszystkich czy tylko u Ciebie?
Gdy strona się nie otwiera, pierwsze pytanie brzmi zawsze tak samo. Problem siedzi w serwisie czy w moim połączeniu? Żądanie wychodzi tutaj z naszego serwera, a nie z Twojego komputera, więc wynik rozstrzyga tę wątpliwość. Strona internetowa, która odpowiada nam poprawnie i pozostaje niedostępna u Ciebie, wskazuje na przyczynę lokalną. Najczęściej odpowiada za to rozwiązywacz DNS operatora z nieaktualnym wpisem, filtr w sieci firmowej, rozszerzenie blokujące treści albo pamięć podręczna przeglądarki.
Samo sprawdzenie jest celowo lekkie i szybkie, bo pobieramy tylko nagłówki odpowiedzi, a gdy serwer nie obsługuje takiego żądania, pierwsze dwa kilobajty treści. Nie ściągamy obrazków, arkuszy stylów ani skryptów, więc nie obciążamy cudzego serwera i nie zaburzamy jego statystyk. Wynik opisuje stan w czasie rzeczywistym, ponieważ niczego nie trzymamy w pamięci podręcznej. Zanim zgłosisz awarię do hostingu, sprawdź, jaki kod zwraca serwer, bo to on wskazuje, po czyjej stronie leży problem.
Cztery różne rodzaje „nie działa”
Problemy z dostępnością dzielą się na cztery rodzaje, które w przeglądarce wyglądają podobnie, a prowadzą do zupełnie innych działań. Brak odpowiedzi oznacza, że nie udało się nawiązać połączenia. Serwer milczy, odrzuca połączenie albo domena nie prowadzi do żadnego adresu. To sytuacja najpoważniejsza i najczęściej sprawa dla hostingu.
Inaczej wygląda błąd serwera, czyli kod z zakresu 500. Domena działa, serwer odpowiada, ale aplikacja na nim nie potrafi zbudować strony. Przyczyną bywa błąd w kodzie, przepełniona baza danych albo wyczerpana pamięć, a przy stronie na WordPressie zwykle nieudana aktualizacja wtyczki lub motywu. Rozróżnij 500 (błąd samej aplikacji) od 502 i 504 (serwer pośredniczący nie doczekał się odpowiedzi od aplikacji) i od 503 (usługa celowo wyłączona, na przykład na czas aktualizacji).
Pętla przekierowań to sytuacja, w której serwer odsyła w kółko pod te same adresy. Klasyczne przyczyny to sprzeczne reguły „z www na bez www” i „z bez www na www” albo wymuszanie HTTPS na serwerze stojącym już za bramą, która to szyfrowanie zdejmuje. Przeglądarka pokazuje wtedy błąd „zbyt wiele przekierowań”.
Wadliwy certyfikat SSL jest przypadkiem szczególnym, bo strona odpowiada poprawnie, a mimo to przeglądarka pokazuje ostrzeżenie przed wejściem. Dla odwiedzającego wygląda to jak awaria, choć technicznie serwis działa i nadal zwraca kod 200, a ostrzeżenie zniknie dopiero po odnowieniu certyfikatu. Oznaczamy tę sytuację osobno, bo ważne jest, żeby odróżnić ją od awarii aplikacji, a datę ważności i łańcuch zaufania obejrzysz w sprawdzaniu certyfikatu SSL.
Łańcuch przekierowań i to, jak szybko odpowiada serwer
Wpisanie adresu bez protokołu i bez „www” zwykle uruchamia kilka przekierowań pod rząd, z HTTP na HTTPS, z wersji bez „www” na wersję z „www”, ze starego adresu na nowy. Każdy krok to osobne żądanie i osobne opóźnienie, a przeglądarka wykonuje je po kolei.
Widok krok po kroku ma dwa praktyczne zastosowania. Pierwsze dotyczy szybkości, bo łańcuch trzech przekierowań przed wyświetleniem strony to zwykle kilkaset dodatkowych milisekund, które da się usunąć, kierując od razu do adresu docelowego. Drugie dotyczy SEO. Łańcuchy przekierowań rozmywają sygnały przekazywane między adresami, a mieszanie przekierowań stałych (301) z tymczasowymi (302) potrafi zablokować przekazanie tych sygnałów w ogóle. Zdrowa konfiguracja to jedno przekierowanie stałe prowadzące wprost do adresu docelowego.
Co można wyczytać z nagłówków odpowiedzi
Nagłówki to metadane odpowiedzi, informacje o niej samej, nie o jej treści. Kilka z nich przydaje się w codziennej diagnostyce. Server i X-Powered-By zdradzają oprogramowanie serwera, choć często są celowo ukrywane. Cache-Control mówi, jak długo przeglądarki i serwery pośredniczące mogą trzymać odpowiedź; zbyt agresywne ustawienie to najczęstsza przyczyna „zmieniłem stronę, a nadal widać starą”. Content-Type określa rodzaj treści i kodowanie znaków, a błąd w tym miejscu daje krzaczki zamiast polskich liter.
Osobną grupą są nagłówki bezpieczeństwa. Strict-Transport-Security wymusza na przeglądarce łączenie się wyłącznie po HTTPS, Content-Security-Policy ogranicza źródła skryptów i stylów, X-Content-Type-Options blokuje zgadywanie typu treści. Ich obecność mówi sporo o tym, czy ktoś zajmował się konfiguracją serwera, czy zostawił ustawienia domyślne.
Pojedyncze sprawdzenie a automatyczny monitoring stron internetowych
Pojedyncze sprawdzenie opisuje działanie strony w tej chwili. Klikasz, dostajesz kod odpowiedzi i czas reakcji, a na tym historia się kończy, bo niczego nie zapisujemy. Monitoring stron działa inaczej, bo zewnętrzna usługa odpytuje Twoją stronę co kilka minut przez całą dobę, prowadzi historię niedostępności i wysyła powiadomienie SMS albo e-mail, gdy serwis przestaje odpowiadać.
Wybór między jednym a drugim zależy od tego, ile kosztuje minuta przerwy. Przy blogu albo stronie wizytówce wystarczy sprawdzić dostępność strony internetowej wtedy, gdy ktoś zgłosi problem. Sklep internetowy jest w innej sytuacji, bo każda minuta niedostępności to porzucone koszyki i telefony od klientów. Sami takiej usługi nie prowadzimy, ponieważ wymagałaby kont użytkowników i przechowywania danych kontaktowych.