Kody statusu 5xx wyjaśnione: kiedy problemem jest Twój serwer
Kod statusu 5xx oznacza, że zawiodła Twoja infrastruktura, a nie żądanie odwiedzającego. Serwer przyjął żądanie, zrozumiał je, a potem nie potrafił wygenerować poprawnej odpowiedzi, więc każde 5xx na Twojej witrynie to incydent, za który odpowiadasz.
Co odróżnia 5xx od 4xx
RFC 9110 definiuje 5xx jako "Server Error": serwer jest świadomy, że popełnił błąd albo nie jest w stanie wykonać żądanej metody. To cała różnica. 404 mówi "nic tu nie ma". 500 mówi "coś tu jest i zepsułem się, próbując to wyprodukować".
Z tego wynikają dwie konsekwencje. Po pierwsze, 5xx zwykle nadaje się do ponowienia, bo to samo żądanie całkiem możliwe, że powiedzie się sekundę później, gdy zawodzący komponent odzyska sprawność. Po drugie, wyszukiwarki traktują 5xx jako sygnał tymczasowy i wycofują się z przeszukiwania, zamiast od razu deindeksować, podczas gdy utrzymujące się przez dni 5xx ostatecznie kosztuje Cię zaindeksowane strony.
Który etap zawiódł
Czytaj kod 5xx jako mapę tego, gdzie żądanie zginęło. Niemal każda nowoczesna witryna stawia przed aplikacją co najmniej jedno proxy, więc kod mówi Ci, po której stronie tej granicy nastąpiła awaria.
| Kod | Kto go wyprodukował | Co się stało |
|---|---|---|
| 500 Internal Server Error | Sama aplikacja | Nieobsłużony wyjątek albo nieoczekiwany warunek wewnątrz aplikacji |
| 501 Not Implemented | Serwer | Metoda żądania w ogóle nie jest obsługiwana |
| 502 Bad Gateway | Proxy, CDN albo load balancer | Backend odpowiedział, ale czymś nieprawidłowym, albo zamknął połączenie |
| 503 Service Unavailable | Serwer albo proxy, celowo | Przeciążony albo w konserwacji, celowo odmawia pracy |
| 504 Gateway Timeout | Proxy, CDN albo load balancer | Backend nigdy nie odpowiedział na czas |
| 505 HTTP Version Not Supported | Serwer | Wersja protokołu w żądaniu nie jest obsługiwana |
502, 503 i 504 niosą najwięcej wartości diagnostycznej, bo każdy nazywa inną awarię tego samego backendu: nieprawidłowa odpowiedź, odmówiona odpowiedź, brak odpowiedzi. Poradnik o 502 Bad Gateway opisuje pierwszy z nich dogłębnie, w tym linie logu proxy, które identyfikują dokładną usterkę.
Typowe przyczyny odpowiedzi 5xx
- Awarie aplikacji. Nieobsłużony wyjątek, nieudane połączenie z bazą danych albo wartość null w nieoczekiwanym miejscu produkuje 500 na każdej trasie dotykającej zepsutej ścieżki kodu.
- Proces backendu nie działa. Zatrzymany serwer aplikacji, martwa pula PHP-FPM albo kontener, który nie przeszedł kontroli zdrowia, nie daje proxy z czym rozmawiać, co objawia się jako 502.
- Wyczerpanie zasobów. Brak pamięci, brak deskryptorów plików, brak wątków roboczych albo brak połączeń do bazy danych. Zwykle zaczyna się jako przerywane błędy pod obciążeniem, zanim stanie się stałe.
- Wolne zależności. Wolne zapytanie, wolne API firmy trzeciej albo zimny start przesuwa czas odpowiedzi poza limit czasu proxy i zamienia się w 504.
- Wdrożenia i restarty. Każde okno, w którym stary proces się zatrzymał, a nowy jeszcze nie zaczął obsługiwać ruchu, produkuje wybuch 502 albo 503.
- Błędy konfiguracji. Zły adres upstream, zła konfiguracja TLS między proxy a backendem, albo niedopasowanie protokołu, na przykład mówienie HTTP do portu HTTPS.
- Pełny dysk. Niedoceniana przyczyna. Logi albo pliki tymczasowe zapełniają wolumin, sesje albo pamięci podręczne przestają zapisywać, a aplikacja zaczyna zawodzić w sposób, który wygląda na losowy.
Jak przejść przez 5xx krok po kroku
- Potwierdź kod i jego pochodzenie. Pobierz nagłówki bezpośrednio i spójrz, który komponent podpisał odpowiedź:
Nagłówekcurl -sS -o /dev/null -D - https://example.com/Server:albo nagłówek CDN przy błędzie mówi Ci, czy wygenerował go brzeg sieci, czy serwer źródłowy. - Przetestuj serwer źródłowy bezpośrednio, omijając proxy. Jeśli backend odpowiada 200 na swoim własnym porcie, podczas gdy publiczny URL odpowiada 502, usterka leży w warstwie proxy albo w łączu między nimi.
- Następnie przeczytaj log błędów proxy, a nie log aplikacji. Odwrotne proxy nazywają awarię precyzyjnie, na przykład
connect() failed (111: Connection refused)alboupstream timed out, co od razu odróżnia "backend nie działa" od "backend jest wolny". - Potem przeczytaj log aplikacji. Dla 500 zrzut stosu jest odpowiedzią. Dla 502 i 504 aplikacja często nie loguje nic, a ten brak sam w sobie jest informacją.
- Sprawdź zasoby na hoście. Pamięć, dysk, liczbę połączeń i nasycenie procesów roboczych. Przerywane 5xx pod ruchem to niemal zawsze osiągnięty limit.
- Spójrz, co się zmieniło. Wdrożenia, wypchnięte konfiguracje, odnowienia certyfikatów i aktualizacje zależności odpowiadają za dużą część nagłych początków 5xx.
Wyłapywanie przerywanych błędów 5xx
Błędy 5xx są często przerywane, co czyni je trudnymi do wyłapania ręcznie: strona, którą przeładowujesz, działa, a ta, którą wczytał Twój klient, nie zadziałała. Zaplanowane sprawdzenie HTTP działa nieprzerwanie i próbkuje witrynę dużo częściej, niż mógłbyś to robić ręcznie, więc seria błędów staje się widoczna jako wzorzec, a nie jako rozproszone skargi. Sprawdzanie z wielu lokalizacji odróżnia też prawdziwą awarię serwera od problemu trasowania albo brzegu sieci, który dotyka tylko części świata, dlatego monitoring dostępności z wielu lokalizacji używa punktów kontrolnych rozproszonych po regionach, a nie jednego punktu obserwacji. Jeśli zawodzący kod okaże się zamiast tego 403, 404 albo 429, żądanie nigdy nie dotarło do zepsutego backendu, a właściwym punktem startowym jest poradnik o rodzinie 4xx.