Wdrożenie właśnie się skończyło, a aplikacja zwraca 500 Internal Server Error zamiast odpowiedzi. Najczęściej oznacza to nieoczekiwany problem po stronie serwera, choć sam kod nie mówi, czy zawinił kod aplikacji, konfiguracja czy jedna z usług po drodze.
Najpierw ustal, która warstwa zwraca 500
- 500 to objaw, a nie wskazanie konkretnej przyczyny.
- Zakres awarii pomaga zawęzić problem: jedna ścieżka, cała aplikacja czy tylko żądania po wdrożeniu.
- Logi z czasu błędu są zwykle użyteczniejsze niż treść strony błędu.
- 500, 502 i 503 opisują różne sytuacje, więc nie warto traktować ich zamiennie.
- Wycofanie ostatniej zmiany może przywrócić działanie usługi, ale nie zastępuje znalezienia przyczyny.
Kod 500 nie wskazuje winnej warstwy
Komunikat na ekranie jest często celowo lakoniczny. Zgodnie z RFC 9110 status 500 informuje, że serwer napotkał nieoczekiwany warunek i nie mógł obsłużyć żądania. To może być wyjątek w aplikacji, błędna konfiguracja albo problem z zasobami, ale sam status nie rozstrzyga, która z tych możliwości wystąpiła.
Uważam, że w diagnozie najłatwiej stracić czas, gdy traktuje się treść błędu jak raport techniczny. Zamiast zgadywać, ustal najpierw, które żądanie nie działa i czy awaria powtarza się dla innych ścieżek, metod HTTP lub użytkowników.
Zakres awarii podpowiada, gdzie zacząć
Jeśli pada tylko zapis formularza, a strona główna działa, podejrzenie pada raczej na konkretną ścieżkę kodu, walidację lub zależność używaną przez tę operację. Gdy 500 pojawia się na każdej trasie, sprawdź zmiany wspólne dla całej aplikacji, konfigurację runtime’u i dostępność usług zewnętrznych.
| Sytuacja | Możliwy kierunek diagnozy | Co zrobić |
|---|---|---|
| 500 pojawiło się zaraz po wdrożeniu | Regresja w kodzie, konfiguracji lub migracji | Porównaj zakres zmian i logi; jeśli usługa jest krytyczna, rozważ rollback według procedury wdrożeniowej. |
| Nie działa jedna ścieżka lub metoda żądania | Błąd konkretnego handlera, danych wejściowych albo zależności | Odtwórz żądanie i porównaj je z działającą ścieżką. |
| Wiele ścieżek przestało działać jednocześnie | Wspólny komponent, konfiguracja, baza danych lub wyczerpane zasoby | Sprawdź logi aplikacji i platformy z tego samego przedziału czasu. |
| Aplikacja zwraca 500, ale log aplikacji jest pusty | Błąd mógł powstać przed uruchomieniem kodu aplikacji albo w proxy | Sprawdź log serwera WWW, reverse proxy i środowiska uruchomieniowego. |
| Problem występuje tylko pod obciążeniem | Limit pamięci, CPU, połączeń lub czasu wykonania | Skoreluj błędy z metrykami zasobów i liczbą równoczesnych żądań. |
Tabela daje kierunek, nie wyrok. Szczególnie mylący bywa pusty log aplikacji: jeśli żądanie nie dotarło do procesu, jego ślad może znajdować się wyłącznie w warstwie pośredniczącej.
500, 502 i 503 prowadzą do różnych tropów
W architekturze z reverse proxy statusy mogą wyglądać podobnie dla użytkownika, ale opisują inne zdarzenia. 502 wskazuje na nieprawidłową odpowiedź serwera pośredniczącego od serwera zaplecza, a 503 na czasową niemożność obsłużenia żądania, na przykład z powodu przeciążenia lub prac serwisowych.
Gdy aplikacja sama zwraca 500, szukaj wyjątku lub błędu obsługi żądania. Przy 502 sprawdź komunikację proxy z upstreamem, czyli usługą, do której proxy przekazuje ruch. Przy 503 zacznij od dostępności instancji i limitów. To rozróżnienie ogranicza ryzyko naprawiania niewłaściwego komponentu.
Log z właściwej chwili jest lepszy niż zgadywanie
Zapisz dokładny czas błędu, ścieżkę, metodę HTTP oraz identyfikator żądania, jeśli system go udostępnia. Potem zestaw te informacje z logiem aplikacji, serwera WWW i proxy. Szukaj pierwszego błędu w łańcuchu zdarzeń, nie tylko ostatniego komunikatu, który pojawił się po awarii.
Przy wdrożeniu porównaj działające i niedziałające instancje: wersję artefaktu, zmienne środowiskowe, dostęp do sekretów oraz wynik migracji. Jeśli problem występuje wyłącznie w jednej instancji, globalna zmiana konfiguracji może tylko zamazać różnicę, która wskazuje źródło kłopotu.
Wycofanie zmiany jest rozsądnym ruchem, gdy awaria zaczęła się bezpośrednio po wdrożeniu i wpływa na usługę produkcyjną. Zabezpiecz jednak logi i dane diagnostyczne przed rollbackiem; w przeciwnym razie usuniesz trop razem z wadliwą wersją.
Długie 500 może ograniczyć crawlowanie strony
Awaria dotyczy też widoczności serwisu, jeśli jego strony są regularnie pobierane przez roboty. Dokumentacja Google Crawling Infrastructure wyjaśnia, że odpowiedzi 5xx powodują czasowe ograniczenie tempa crawlowania; przy utrzymujących się błędach adresy mogą zostać usunięte z indeksu.
Przy krótkim incydencie nie ma sensu nerwowo zmieniać adresów URL ani usuwać stron. Najpierw przywróć poprawną odpowiedź serwera, potem sprawdź najważniejsze adresy i historię awarii w narzędziach diagnostycznych. W przypadku wdrożeń krytycznych ustaw alert na odsetek odpowiedzi 5xx, a nie wyłącznie na dostępność strony głównej, bo pojedyncza niedziałająca ścieżka potrafi umknąć prostemu testowi.
