Proxy nie otrzymało odpowiedzi na czas.
Kiedy go używać
Aplikacja docelowa jest zbyt wolna lub się zawiesiła.
Typowe przyczyny i rozwiązania
Proxy przestało czekać na upstream. Typowe przyczyny: wolne zapytanie do bazy danych lub wywołanie zewnętrznego API, zakleszczony worker, za mało workerów na dany ruch albo firewall po cichu odrzucający pakiety. Limity czasu są warstwowe i wygrywa najkrótszy: proxy_read_timeout w nginx domyślnie wynosi 60 sekund, AWS ALB zrywa bezczynne połączenie po 60, API Gateway po 29, a Cloudflare pokazuje własny błąd 524 po 100 sekundach.
Sprawdź, gdzie ucieka czas: przejrzyj logi aplikacji pod kątem czasu trwania żądań, poszukaj wolnych zapytań i zmierz to samo żądanie wysłane bezpośrednio do serwera źródłowego, z pominięciem proxy. Zwiększanie limitów czasu tylko ukrywa problem; przenieś długie zadania do workera w tle i zwracaj 202 z URL-em statusu. Praca może się jeszcze zakończyć po 504, więc ponawianie nieidempotentnych żądań może ją zdublować.
Błąd serwera (5xx)
Kody 5xx to błędy serwera: żądanie może być poprawne, ale zawiódł serwer lub coś za nim. Warto ustawić na nie alerty.
Jak to wygląda
HTTP/1.1 504 Gateway TimeoutJak go wysłać
| Node.js / Express | res.status(504).end() |
|---|---|
| Python / Flask | return '', 504 |
| nginx | return 504; |
Jak go sprawdzić
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/