500 Internal Server Error: przyczyny, logi i różnica wobec 502

Dlaczego 500 mówi Ci tak mało

RFC 9110 definiuje 500 jako nieoczekiwaną sytuację, która uniemożliwiła serwerowi zrealizowanie żądania. To celowo szerokie. Wszystko, czego aplikacja nie przewidziała, od odwołania do wartości null, przez nieudane połączenie z bazą danych, po plik konfiguracyjny, którego nie potrafi sparsować, kończy pod tym samym numerem.

Ta ogólnikowość to też funkcja bezpieczeństwa. Strona 500 nigdy nie powinna ujawniać publicznie śladów stosu, ścieżek plików, fragmentów SQL ani wersji bibliotek, bo to dokładnie te szczegóły, których chce atakujący. Więc kod pozostaje ogólny w odpowiedzi, a szczegóły trafiają do logu, który możesz przeczytać tylko Ty. Ten kompromis jest słuszny i sprawia, że jedna informacja jest cenniejsza od każdej innej: gdzie żyją Twoje logi.

500 kontra 502, 503 i 504

Wszystkie cztery to błędy serwera, ale są produkowane przez różne komponenty i wskazują na różne problemy. Właściwe ich rozróżnienie oszczędza większość czasu debugowania.

• 500 pochodzi z samej aplikacji. Coś się uruchomiło i rzuciło wyjątkiem. Log aplikacji ma ślad stosu.
• 502 pochodzi z proxy przed aplikacją, które dostało nieprawidłową odpowiedź albo zamknięte połączenie od backendu. Backend często niczego nie loguje, bo nigdy nie skończył żądania. Zobacz poradnik o 502.
• 503 to odmowa, nie awaria. Serwer jest przeciążony albo w trybie konserwacji i celowo odrzuca pracę, zwykle z Retry-After.
• 504 to przekroczenie czasu. Backend był osiągalny, ale nie odpowiedział w limicie proxy. Żądanie często wciąż działa w tle.

Prosty skrót myślowy: 500 oznacza, że Twój kod się zepsuł, 502 oznacza, że Twój backend nie żyje albo się źle zachowuje, 503 oznacza, że Twój serwer celowo mówi nie, 504 oznacza, że Twój backend jest zbyt wolny. Cała rodzina jest porównana w przeglądzie 5xx.

Co powoduje 500

• Nieobsłużone wyjątki w kodzie aplikacji. Największa pojedyncza kategoria. Wartość null, nieudana konwersja typu, indeks tablicy poza zakresem, dzielenie przez zero na ścieżce, której nikt nie testował.
• Awarie bazy danych. Wyczerpana pula połączeń, zrotowane poświadczenia, restart bazy danych, zapytanie powodujące zakleszczenie albo przekroczenie czasu.
• Brakujące albo zepsute zależności po wdrożeniu. Pakiet, który się nie zainstalował, plik, którego build nie skopiował, zmienna środowiskowa istniejąca na stagingu, a nie na produkcji.
• Błędy składni konfiguracji. Na Apache, jedna nieprawidłowa dyrektywa w pliku .htaccess daje 500 dla każdego żądania w tym katalogu.
• Uprawnienia i właściciel plików. Aplikacja nie może odczytać pliku konfiguracyjnego albo zapisać do katalogu pamięci podręcznej, sesji albo przesyłanych plików.
• Limity zasobów. Limit pamięci, limit czasu wykonania albo pełny dysk. Zwykle dają przerywane 500, skorelowane z ruchem.
• Awarie zewnętrznego API, które kod wywołuje bez planu awaryjnego, więc zdalna awaria staje się Twoją stroną błędu.

Jak zdiagnozować 500

1. Potwierdź kod i kto go wyprodukował. Firmowa strona błędu może ukrywać prawdziwy status:

   curl -sS -o /dev/null -D - https://example.com/failing-page

   Sprawdź linię statusu i dowolny nagłówek Server albo CDN. Jeśli błąd jest podpisany przez sieć brzegową, a origin odpowiada 200, wcale nie patrzysz na 500 z Twojej aplikacji.
2. Najpierw otwórz log aplikacji. Tu jest ślad stosu. Logi frameworku, strumień logów platformy albo stdout kontenera, cokolwiek używa Twój stos, dopasuj po znaczniku czasu i ścieżce żądania.
3. Potem log błędów serwera WWW. Apache error_log, nginx error.log, albo Dziennik zdarzeń Windows dla IIS. Jeśli aplikacja niczego nie zalogowała, awaria nastąpiła, zanim Twój kod się uruchomił, co wskazuje na konfigurację albo środowisko uruchomieniowe.
4. Odtwórz to celowo. Ustal, czy 500 dotyczy jednego adresu URL, jednej metody HTTP, jednego użytkownika czy wszystkiego. 500 tylko na POST zwykle oznacza obsługę formularza albo ścieżkę zapisu. 500 dla jednego użytkownika zwykle oznacza jego dane.
5. Włącz szczegółowe błędy w środowisku niepublicznym. Nigdy na produkcji. Odtwórz na stagingu z pełnym wyjściem błędów, co zamienia ogólne 500 w konkretny numer linii.
6. Sprawdź, co się zmieniło. Ostatnie wdrożenie, push konfiguracji, odnowienie certyfikatu, aktualizacja zależności albo migracja bazy danych. Jeśli strona działała godzinę temu bez zarzutu, odpowiedź niemal zawsze leży w ostatniej zmianie.
7. Sprawdź zasoby hosta. Miejsce na dysku, pamięć i liczbę połączeń. Dysk zapełniony logami daje 500, które wygląda na zupełnie niepowiązane z kodem.

500, które zwraca tylko jedna strona

Większość 500 nie wyłącza całej strony. Jedna trasa, jeden formularz albo jeden region się psuje, podczas gdy strona główna wciąż się ładuje, więc od zewnątrz nic nie wygląda na zepsute, a błędy ujawniają się dopiero po kilku dniach jako utracone rejestracje. Zaplanowana kontrola HTTP na stronach, które mają znaczenie, nie tylko na stronie głównej, porównuje zwrócony kod z oczekiwanym i alarmuje w chwili, gdy trasa zaczyna odpowiadać 500. Alerty mogą docierać e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i inne kanały, więc nocna awaria dociera do tego, kto jest na dyżurze, zamiast czekać do rana. HostTracker monitoruje strony internetowe od 2004 roku.