504 Gateway Timeout: wolne backendy, limity czasu i 502 vs 503 vs 504
504 Gateway Timeout oznacza, że proxy dotarło do Twojego backendu, czekało na odpowiedź i poddało się, zanim ta nadeszła. Nic się nie zawiesiło i nic nie odmówiło żądania: coś za proxy jest wolniejsze, niż proxy jest skłonne czekać.
Co raportuje 504
RFC 9110 definiuje 504 dla serwera działającego jako brama albo proxy, który nie otrzymał na czas odpowiedzi od serwera wyżej w łańcuchu, z którym musiał się połączyć. Słowo "na czas" jest zdefiniowane przez konfigurację, nie przez specyfikację, więc 504 to zawsze stwierdzenie o dwóch rzeczach naraz: jak wolny był backend i jaki limit ustawiono w proxy.
To ma ważną praktyczną konsekwencję. Gdy proxy zwraca 504, backend zwykle nadal pracuje nad żądaniem. Połączenie z klientem zniknęło, ale wolne zapytanie wciąż się wykonuje, raport wciąż jest generowany, a zasoby wciąż są zajęte. Dlatego fala 504 często pogarsza stan serwera: każde porzucone żądanie zostawia po sobie pracę, a kolejka rośnie szybciej, niż się opróżnia.
504 kontra 502 kontra 503
| 502 Bad Gateway | 503 Service Unavailable | 504 Gateway Timeout | |
|---|---|---|---|
| Co się stało | Backend dał nieprawidłową odpowiedź albo zamknął połączenie | Serwer celowo odmówił wykonania pracy | Backend przyjął pracę i nigdy nie odpowiedział na czas |
| Stan backendu | Niedziałający, ulegający awarii albo mówiący w złym protokole | Działa, ale przeciążony albo w konserwacji | Działa i jest zajęty, wciąż przetwarza |
| Szybkość odpowiedzi | Zwykle natychmiastowa | Zwykle natychmiastowa | Wolna, przychodzi przy limicie czasu |
| Typowa linia w logu | connect() failed albo upstream prematurely closed connection | Reguła konserwacji albo brak zdrowych serwerów wyżej w łańcuchu | upstream timed out (110: Connection timed out) |
Retry-After | Rzadkie | Częste i zalecane | Rzadkie |
| Pierwsze miejsce do sprawdzenia | Czy proces backendu działa? | Pojemność, flagi konserwacji, kontrole zdrowia | Wolne zapytania i wolne zależności |
W praktyce 502 zawodzi szybko, 503 odmawia grzecznie, a 504 najpierw każe czekać. Dedykowany przewodnik po 502 i przegląd 5xx w pełni omawiają pozostałe dwa.
Dlaczego backend jest zbyt wolny
- Wolne zapytania do bazy danych. Brakujący indeks, zapytanie, które urosło razem z danymi, wzorzec N+1 w pętli albo rywalizacja o blokady przy współbieżności. Najczęstsza pojedyncza przyczyna.
- Wolne wywołania zewnętrzne. Wychodzące żądanie API bez własnego limitu czasu dziedziczy najgorszy dzień zdalnej usługi i przekazuje go Twoim odwiedzającym.
- Zimne starty. Pierwsze żądanie po skalowaniu w górę, starcie kontenera albo okresie bezczynności płaci naraz za inicjalizację, nawiązanie połączenia i rozgrzanie cache'u.
- Naprawdę ciężka praca na żądaniu WWW. Generowanie raportów, eksporty, przetwarzanie obrazów albo masowe importy obsługiwane synchronicznie w końcu przekroczą każdy rozsądny limit czasu.
- Rywalizacja o zasoby. Wysycenie CPU, presja pamięci i swapowanie spowalniają każde żądanie, więc najwolniejsze przekraczają limit jako pierwsze.
- Zbyt ciasno ustawione limity czasu. Jeśli endpoint zasadnie potrzebuje więcej czasu, niż pozwala proxy, to konfiguracja jest błędem, nie kod.
- Problemy sieciowe między skokami. Utrata pakietów albo opóźnienia rozwiązywania DNS dla adresu wyżej w łańcuchu dodają opóźnienie, które nie pojawia się w pomiarach czasu aplikacji.
Jak zdiagnozować i naprawić 504
- Zmierz czas do błędu. Opóźnienie przed 504 zwykle odpowiada skonfigurowanemu limitowi czasu, co mówi, który skok je wyprodukował:
504 przy niemal dokładnie 60 sekundach wskazuje na domyślny limit czasu odczytu proxy. Takie przy 30 albo 100 sekundach wskazuje na komponent skonfigurowany z tą liczbą, często CDN, a nie Twoje własne proxy.curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/slow-page - Ustal, czy to jeden endpoint, czy wszystkie. Jeden wolny URL to problem aplikacji. Wszystko wolne naraz to wysycenie zasobów albo zawodząca zależność.
- Przeczytaj log błędów proxy. Przy nginx linia jest wyraźna:
Wskazuje serwer wyżej w łańcuchu i fazę, co odróżnia wolne połączenie od wolnej odpowiedzi.[error] upstream timed out (110: Connection timed out) while reading response header from upstream, upstream: "http://127.0.0.1:8080/" - Zmierz czas backendu bezpośrednio, bez proxy. Jeśli to samo żądanie do serwera źródłowego trwa 90 sekund, proxy mówi prawdę, a naprawa należy do aplikacji.
- Profiluj wolną ścieżkę. Sprawdź log wolnych zapytań, a potem ślady aplikacji. Większość 504 sprowadza się do jednego zapytania albo jednego wywołania zewnętrznego.
- Napraw przyczynę, zanim naprawisz limit czasu. Dodaj indeks, zbuforuj kosztowny wynik albo przenieś naprawdę długą pracę do zadania w tle, które zwraca odpowiedź od razu i raportuje postęp osobno.
- Podnoś limit czasu tylko wtedy, gdy praca jest zasadnie długa, i podnoś go spójnie na każdym skoku. Limit CDN wynoszący 30 sekund czyni 120-sekundowy limit czasu serwera źródłowego bezcelowym.
- Ustaw limity czasu na własnych wywołaniach wychodzących, żeby wolna zależność zawodziła szybko z jasnym błędem, zamiast zużywać workera, aż proxy się podda.
Czas odpowiedzi to wczesne ostrzeżenie
504 to stan końcowy spowolnienia, które narastało przez jakiś czas. Czasy odpowiedzi dryfują od pół sekundy do dwóch sekund do dziesięciu, a nikt tego nie zauważa, dopóki żądania nie zaczną przekraczać limitu. Zaplanowana kontrola HTTP zapisuje czas odpowiedzi każdej kontroli razem z kodem statusu, więc trend jest widoczny jako wykres na długo przed pierwszym przekroczeniem czasu, a alert przychodzi przy pierwszej prawdziwej awarii, a nie po zapełnieniu kolejki wsparcia. Sprawdzanie z kilku regionów też pomaga, bo trasa, która jest szybka z jednego kontynentu, a wolna z innego, wskazuje na ścieżkę sieciową albo konfigurację brzegową, a nie na Twoją bazę danych.