499 to kod specyficzny dla nginx, który pojawia się w logach dostępu, gdy klient zamknął połączenie, a nginx wciąż przetwarzał żądanie. Żadna odpowiedź nie jest wysyłana, bo nie ma już komu jej odebrać.
Zwykle oznacza to, że aplikacja w backendzie (upstream) działała wolno: użytkownik przeszedł na inną stronę, load balancer lub klient API przekroczył własny limit czasu albo health check przestał czekać. Gwałtowny wzrost liczby błędów 499 przy długich czasach żądań wskazuje na wolny backend, natomiast kilka błędów 499 od użytkowników, którzy przerywają wczytywanie strony, to normalna sytuacja.
Gdy jako pierwszy limit czasu przekroczy serwer proxy przed nginx, nginx zapisuje w logu 499, a proxy zgłasza własny błąd, np. 504 lub 524 w Cloudflare.
Przykładowa odpowiedź
# The client gave up before nginx had a response; nothing is sent.
# nginx access.log (last field: $request_time in seconds)
198.51.100.23 - - [06/Nov/2026:10:15:32 +0000] "GET /report?year=2026 HTTP/1.1" 499 0 "-" "Mozilla/5.0" 30.001SEO i sprawdzanie przekierowań
Roboty nigdy nie otrzymują kodu 499, ale jeśli Googlebot zrezygnuje z czekania na wolną stronę, w Twoich logach pojawi się 499 dla jego żądań. To oznaka długiego czasu odpowiedzi serwera, co zmniejsza intensywność indeksowania przez Google. Narzędzia do sprawdzania przekierowań także przerywają bardzo wolne przeskoki po przekroczeniu limitu czasu; narzędzie Pomiar opóźnień przekierowań pokazuje, który przeskok jest wolny.
Typowe przyczyny i zastosowania
- Backend aplikacji potrzebuje więcej czasu, niż klient, CDN lub load balancer jest gotów czekać.
- Użytkownicy przerywają wczytywanie wolnej strony lub opuszczają ją, zanim się wczyta.
- Narzędzia monitorujące i health checki używają krótkich limitów czasu.