Jak sprawdzić, czy strona nie działa — u wszystkich czy tylko u Ciebie
Strona się nie otwiera. Nie działa u wszystkich, czy problem jest po Twojej stronie — w Wi-Fi, DNS, przeglądarce? A jeśli to Twoja własna witryna, od czego zacząć? Poniżej sprawdzenia w kolejności, która oszczędza najwięcej czasu: od „czy to tylko u mnie?” po sam serwer.
Krok 1: nie działa u wszystkich czy tylko u Ciebie?
Najszybciej odpowiesz, patrząc na stronę z innego miejsca:
- Otwórz ją na telefonie z wyłączonym Wi-Fi: internet mobilny to inna sieć i zwykle inny DNS.
- Spróbuj innej przeglądarki lub okna prywatnego — rozszerzenia i pamięć podręczna potrafią psuć strony.
- Uruchom sprawdzenie statusu strony. Pobiera stronę z naszego serwera — z innej sieci i innego miejsca niż Ty — i pokazuje kod HTTP, czas odpowiedzi, SSL i przekierowania.
Jeśli z naszego serwera i przez internet mobilny strona działa, a z sieci domowej nie, problem jest lokalny: router, pamięć DNS, VPN, antywirus lub firmowa zapora. Zrestartuj router, wyczyść pamięć DNS, wyłącz VPN i spróbuj ponownie. Jeśli strona nie działa nigdzie — czytaj dalej.
Krok 2: przeczytaj komunikat błędu
Komunikat przeglądarki już zawęża listę przyczyn:
- „Nie można uzyskać dostępu do tej witryny” / DNS_PROBE_FINISHED_NXDOMAIN — nazwa domeny nie zamienia się na adres. Przejdź do kroku o DNS.
- Przekroczono limit czasu / odmowa połączenia — DNS działa, ale serwer nie odpowiada: jest wyłączony, przeciążony albo zapora odrzuca połączenie.
- Ostrzeżenie o certyfikacie (NET::ERR_CERT_DATE_INVALID i podobne) — serwer odpowiada, ale certyfikat SSL wygasł, jest nieważny lub wystawiony na inną nazwę.
- Strona z kodem błędu (500, 502, 503, 404…) — serwer jest osiągalny i odpowiada; problem leży w aplikacji, konfiguracji lub adresie.
Cała strona czy jedna podstrona?
Zanim zajrzysz do serwera, oceń skalę problemu. Otwórz stronę główną i dwie-trzy inne podstrony, w tym plik statyczny — obrazek albo robots.txt. Jeśli pliki statyczne się ładują, a podstrony nie, serwer WWW działa, a pada aplikacja (CMS, baza danych, PHP). Jeśli zepsuta jest tylko jedna sekcja, sprawdź, co ją wyróżnia: wtyczka, zewnętrzne API, ciężkie zapytanie do bazy. Jeśli strona główna działa, a konkretny link zwraca 404, podstronę prawdopodobnie przeniesiono bez przekierowania. A jeśli wszystko pada tylko w panelu administracyjnym, przyczyną jest częściej sesja, cookies lub reguła bezpieczeństwa niż awaria.
Krok 3: kody odpowiedzi — 5xx kontra 4xx
Odpowiadając, serwer zwraca kod stanu. Sprawdzenie kodu odpowiedzi HTTP pokaże dokładny kod dowolnego adresu URL, łącznie ze wszystkimi przekierowaniami po drodze.
| Kod | Co zwykle oznacza | Typowa przyczyna |
|---|---|---|
| 500 | Wewnętrzny błąd serwera | Błąd w kodzie, wadliwa wtyczka lub aktualizacja, złe uprawnienia plików |
| 502 | Bad Gateway | Serwer WWW lub CDN nie dostaje poprawnej odpowiedzi od aplikacji za nim (PHP-FPM, Node, upstream) |
| 503 | Usługa niedostępna | Przeciążenie, tryb konserwacji, wyczerpany limit procesów |
| 504 | Gateway Timeout | Aplikacja odpowiada za wolno: ciężkie zapytania, zawieszone procesy |
| 403 | Brak dostępu | Uprawnienia, blokada IP, reguła WAF lub wtyczki bezpieczeństwa |
| 404 | Nie znaleziono | Zły adres, usunięta strona, zepsute reguły przepisywania — sam serwer działa |
| 429 | Zbyt wiele żądań | Ograniczenie liczby żądań na serwerze lub w CDN |
Zasada ogólna: 5xx to problem po stronie serwera; 4xx — serwer działa, ale odmawia lub nie znajduje tego konkretnego żądania. Strona główna zwracająca 404 nie „leży” w zwykłym sensie — coś jest nie tak z adresem lub routingiem.
Krok 4: problemy z DNS
Jeśli domena się nie rozwiązuje, sprawdź jej rekordy w DNS Lookup: czy istnieje rekord A (lub AAAA) i czy wskazuje właściwy serwer? Czy rekordy NS są takie, jakie podał Twój dostawca DNS?
Częste przyczyny:
- Domena wygasła. Rejestratorzy często przełączają DNS na stronę parkingową lub usuwają go całkiem. Datę wygaśnięcia pokaże WHOIS.
- Rekordy niedawno zmieniono. Po przeprowadzce hostingu lub dostawcy DNS część resolverów wciąż zwraca stary adres, dopóki nie minie TTL w pamięci podręcznej. Sprawdzenie propagacji DNS porównuje odpowiedzi wielu publicznych resolverów z serwerami autorytatywnymi i pokazuje, kto widzi już nową wartość.
- U rejestratora zmieniono serwery NS, a strefa u nowego dostawcy jest pusta lub niekompletna.
Szczegółowo o każdym typie rekordu — w artykule o sprawdzaniu rekordów DNS domeny.
Krok 5: wygasły certyfikat SSL
Stronę z wygasłym certyfikatem przeglądarka zasłania pełnoekranowym ostrzeżeniem, które odwiedzający odbierają jako „strona nie działa”. Automatyczne odnawianie zwykle temu zapobiega, ale po cichu przestaje działać przy zmianie DNS, dodaniu CDN albo gdy zadanie odnawiania przestaje się uruchamiać. Sprawdzenie SSL pokaże datę wygaśnięcia, łańcuch i nazwy w certyfikacie. Więcej: sprawdzanie certyfikatu SSL.
Krok 6: awarie hostingu, CDN i usług zewnętrznych
Czasem problem w ogóle nie dotyczy Twojej strony. Duzi dostawcy hostingu, platformy chmurowe i CDN publikują strony statusu (zwykle status.dostawca.com) z bieżącymi incydentami. Jeśli korzystasz z CDN, np. Cloudflare, jego własne strony błędów podpowiadają, po której stronie jest awaria: błąd, w którym pojawia się Twój serwer źródłowy, oznacza, że CDN działa, ale nie może połączyć się z hostingiem.
Sprawdzaj też „wolno”, nie tylko „martwo”: czas odpowiedzi strony rozkłada żądanie na DNS, połączenie, TLS i czas do pierwszego bajtu. TTFB rzędu kilku sekund wskazuje na przeciążony serwer lub wolną aplikację, co często poprzedza błędy 502 i 504.
Krok 7: blokada przez zaporę lub WAF
Strona może „nie działać” tylko dla części odwiedzających. Zapory aplikacji webowych, wtyczki bezpieczeństwa, ochrona DDoS hostingu i blokady krajów odcinają pojedynczy adres IP, całego operatora albo kraj. Objawy: u jednych 403 lub strona weryfikacji, u innych wszystko działa; strona otwiera się przez internet mobilny, ale nie z biura. Jeśli na publiczną czarną listę trafił adres IP Twojego serwera lub poczty, zobacz dlaczego IP jest na czarnej liście.
Dla właściciela strony: co zrobić teraz i następnym razem
- Potwierdź awarię z zewnątrz (sprawdzenie statusu, internet mobilny).
- Sprawdź oczywiste rzeczy: daty ważności domeny i certyfikatu, zawieszenie hostingu za nieopłaconą fakturę, zapełniony dysk.
- Zajrzyj do logów: dziennik błędów serwera WWW i aplikacji dokładnie z chwili awarii. Większość błędów 500 jest tam wyjaśniona.
- Cofnij ostatnią zmianę: aktualizację wtyczki, wdrożenie, edycję konfiguracji. Najpierw wycofanie, potem dochodzenie.
- Zrestartuj usługi (serwer WWW, PHP-FPM, bazę danych), jeśli się zawiesiły — a potem ustal, dlaczego.
- Napisz do hostingu konkretnie: godzina, adres, kod odpowiedzi, treść błędu.
Aby dowiadywać się o problemie przed odwiedzającymi, skonfiguruj monitoring dostępności: zewnętrzne sprawdzenie co kilka minut z powiadomieniem e-mailem lub w komunikatorze. Osobno ustaw przypomnienia o wygaśnięciu certyfikatu i domeny — to awarie, którym najłatwiej zapobiec.