Gdy strona nie działa, najpierw potwierdź, że nie działa dla wszystkich, a nie tylko dla Ciebie. Potem idź od zewnątrz do środka: DNS, połączenie, certyfikat TLS, CDN lub proxy, serwer WWW, a na końcu aplikacja i jej zależności. Komunikat o błędzie zwykle podpowiada, od której warstwy zacząć, a każdy z poniższych kroków ma szybki test, który ją potwierdza albo wyklucza.
Rób notatki na bieżąco: co sprawdziłeś, o której i co zobaczyłeś. Dzięki nim łatwiej przekazać naprawę dalej i napisać postmortem.
Krok 1: Nie działa dla wszystkich czy tylko dla Ciebie?
Wklej adres do narzędzia Is it down?. Pobiera ono stronę ze Sztokholmu w Szwecji, podąża za maksymalnie pięcioma przekierowaniami i uznaje za działające wszystko poniżej HTTP 500. Potem otwórz stronę na telefonie z wyłączonym Wi-Fi.
Jeśli z zewnątrz działa, a u Ciebie nie, problem leży blisko Ciebie: VPN, wpis w pliku hosts, pamięć podręczna DNS routera, rozszerzenie przeglądarki albo firewall, który zablokował Twój adres IP po zbyt wielu nieudanych logowaniach. Zanim dotkniesz serwera, spróbuj okna prywatnego i innej sieci.
Przeczytaj komunikat o błędzie
Dokładny błąd wskazuje warstwę, która zawiodła. Zapisz go, zanim zaczniesz cokolwiek zmieniać.
Co widziszPrawdopodobna warstwaZacznij odDNS_PROBE_FINISHED_NXDOMAIN, „Nie można znaleźć adresu IP serwera”DNS lub domenaKroku 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTSieć lub serwerKroku 3„Połączenie nie jest prywatne”, NET::ERR_CERT_DATE_INVALIDCertyfikat TLSKroku 4Cloudflare 521, 522, 525 lub 526 albo strona błędu CDNMiędzy CDN a serwerem źródłowymKroku 5500, 502, 503 lub 504Serwer WWW lub aplikacjaKroku 6Strona, która się ładuje, ale jest pusta lub pokazuje błądAplikacja lub zależnośćKroku 7
Krok 2: Sprawdź DNS i domenę
Jeśli nazwa się nie rozwiązuje, reszta nie ma znaczenia. Zapytaj DNS, co zwraca dla Twojej domeny, i porównaj to z adresem serwera:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Brak jakiejkolwiek odpowiedzi: sprawdź narzędziem do sprawdzania wygaśnięcia domeny, czy rejestracja domeny nie wygasła. Wygasła domena często traci serwery nazw albo wskazuje na stronę parkingową rejestratora.
Zły adres: ktoś zmienił rekord albo serwery nazw przeniesiono do dostawcy, który nie ma Twoich rekordów. Porównaj odpowiedź z oczekiwaną za pomocą narzędzia DNS lookup.
U jednych dobrze, u innych źle: niedawna zmiana wciąż się rozchodzi. Resolwery trzymają starą odpowiedź, dopóki nie minie jej TTL – to propagacja DNS.
Nasz poradnik o błędzie DNS_PROBE_FINISHED_NXDOMAIN omawia przyczyny po stronie DNS jedna po drugiej.
Krok 3: Czy możesz połączyć się z serwerem?
Mając właściwy adres, sprawdź, czy serwer przyjmuje połączenia na portach WWW:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Połączenie odrzucone (connection refused): maszyna odpowiada, ale nic nie nasłuchuje na porcie. Serwer WWW się zatrzymał albo uległ awarii. Uruchom go i przeczytaj jego log, aby ustalić przyczynę.
Przekroczony czas (timed out): pakiety giną po drodze. Serwer jest wyłączony, firewall lub grupa zabezpieczeń odrzuca ruch albo sieć po drodze ma usterkę. Zajrzyj na stronę statusu i do konsoli dostawcy hostingu.
Nie polegaj wyłącznie na ping. Wiele hostów blokuje ICMP, więc serwer może nie odpowiadać na ping, a stronę serwować bez problemu – albo odpowiadać na ping, gdy serwer WWW leży.
Krok 4: Sprawdź certyfikat TLS
Problem z certyfikatem wyłącza stronę wszystkim naraz – przeglądarka pokazuje ostrzeżenie na całą stronę, choć sam serwer działa. Sprawdź host narzędziem SSL checker albo z wiersza poleceń:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
Najczęstsze przyczyny to certyfikat, który wygasł po nieudanym automatycznym odnowieniu, certyfikat dla innej nazwy albo brakujący certyfikat pośredni. Artykuł Błędy certyfikatów SSL – wyjaśnienie przypisuje każdemu ostrzeżeniu przeglądarki jego rozwiązanie.
Krok 5: Wyklucz CDN lub proxy
Jeśli przed stroną stoi CDN lub reverse proxy, strona błędu może pochodzić z proxy, a nie z Twojego serwera. Kody 52x Cloudflare mówią dokładnie, gdzie coś się zepsuło:
521: serwer źródłowy odrzucił połączenie.
522: przekroczono czas połączenia z serwerem źródłowym.
525: handshake TLS z serwerem źródłowym się nie powiódł.
526: certyfikat serwera źródłowego jest nieważny.
Aby przetestować serwer źródłowy z pominięciem CDN, wyślij żądanie bezpośrednio na jego adres IP, zachowując nazwę hosta. Zastąp 203.0.113.10 adresem swojego serwera źródłowego:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Jeśli serwer źródłowy odpowiada poprawnie, przyjrzyj się CDN: jego stronie statusu, ostatnio zmienianym regułom firewalla i temu, czy nadal ma właściwy adres serwera źródłowego. Jeśli serwer źródłowy też zawodzi, przejdź do serwera.
Krok 6: Sprawdź serwer WWW i aplikację
Kod statusu 5xx oznacza, że żądanie dotarło do Twojej infrastruktury i coś w niej zawiodło. Kod zawęża poszukiwania:
500: aplikacja zgłosiła błąd. Zobacz 500 Internal Server Error.
502: serwer WWW nie dostał poprawnej odpowiedzi od procesu aplikacji, który stoi za nim – często dlatego, że proces uległ awarii. Zobacz 502 Bad Gateway.
503: usługa jest przeciążona albo w trybie konserwacji. Zobacz 503 Service Unavailable.
504: aplikacja odpowiadała zbyt długo. Zobacz 504 Gateway Timeout.
Każdy kod ma własną stronę w przewodniku po kodach statusu HTTP. Na serwerze trzy sprawdzenia wykrywają większość przyczyn:
df -h # pełny dysk zatrzymuje bazy danych, logi i uploady
free -m # brak pamięci zabija procesy
tail -n 50 /var/log/nginx/error.log # albo logi Twojego serwera WWW i aplikacji
Potem zapytaj, co się zmieniło. Najbardziej prawdopodobna przyczyna to wdrożenie, aktualizacja wtyczki, zmiana konfiguracji albo wygasły klucz API w ostatniej godzinie, a wycofanie zmiany jest często szybsze niż debugowanie na żywo.
Krok 7: Sprawdź zależności
Twoja strona może być w dobrej kondycji, gdy coś, czego potrzebuje, już nie jest. Baza danych bez wolnych połączeń, zatrzymany serwer cache albo awaria dostawcy płatności, poczty czy logowania psują strony, które poza tym się ładują. Sprawdź strony statusu swoich dostawców, a tych największych poszukaj w Is it down?, które śledzi popularne usługi i ich ostatnie awarie.
Gdy strona działa, ale jest zepsuta
Niektóre awarie zwracają 200: pusta lista produktów, przycisk zamówienia, który nic nie robi, komunikat o błędzie w zwykłej stronie. Kod statusu ich nie wyłapie. Sprawdź, czy strona zawiera to, co powinna, i przejdź kluczową ścieżkę – np. logowanie lub płatność – tak, jak zrobiłby to klient.
W trakcie naprawy: informuj ludzi
Opublikuj krótką aktualizację, gdy tylko wiesz o problemie – nawet jeśli możesz napisać tylko, że go badasz – i podaj, kiedy pojawi się kolejna. Generator aktualizacji statusu przygotuje treść na każdy etap, a plan komunikacji podczas incydentu określa, kto mówi co i gdzie.
Skróć następną awarię
Najwolniejszą częścią większości awarii jest dowiedzenie się o nich. Dzięki zewnętrznemu monitorowaniu o problemie informuje Cię alert, a nie klient, i zaczynasz od dowodów zamiast od zgadywania. Oto, co daje Ci Uptimecheck:
Sprawdzenia co minutę ze Sztokholmu, Londynu i Nowego Jorku, a każda awaria jest potwierdzana z drugiej lokalizacji, zanim dostaniesz alert. Zobacz monitorowanie dostępności.
Dowody w incydencie: adres, na który rozwiązał się DNS, przekierowania, certyfikat, nagłówki i początek odpowiedzi, a do tego zrzut ekranu, gdy serwer odpowiedział, lub traceroute, gdy nie odpowiedział. Zobacz, jak działają incydenty i dowody.
Czasy odpowiedzi rozbite na fazy: DNS, połączenie, TLS, serwer i pobieranie, dzięki czemu wolna warstwa wyróżnia się, zanim zawiedzie.
Przypomnienia przed wygaśnięciem certyfikatów i domen oraz alerty, gdy zmieniają się rekordy DNS.
Sprawdzanie słów kluczowych i scenariusze (flows), które wyłapują stronę zwracającą 200, ale zepsutą. Zobacz monitorowanie scenariuszy.
Jeśli monitor pokazuje awarię, a u Ciebie strona działa, artykuł dlaczego monitor pokazuje awarię, gdy strona działa wyjaśnia, jak odczytać tę różnicę.
Dowiedz się przed swoimi klientami. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.