Stavový kód 499: co v nginx znamená client closed request

Co znamená stavový kód 499

499 Client Closed Request je specifický pro nginx a nikdy nebyl definovaný v žádném RFC. Kódy nad 99 a pod 600 jsou obecně vyhrazené pro řádky stavu HTTP, ale 499 je vlastní konvence nginx, zaznamenávaná, když nginx zjistí, že spojení klienta spadlo, zatímco pořád čekal na odpověď upstreamové aplikace, nebo zatímco pořád posílal tělo odpovědi zpátky klientovi. Nejběžnější skutečná podoba je pomalý upstream v kombinaci s klientem, kartou prohlížeče, nebo load balancerem, jehož vlastní timeout je kratší, než jak dlouho by to serveru trvalo, takže klient zavěsí jako první.

Jak se to projevuje v logách

499 jako stavový kód vrácený jakémukoli klientovi, prohlížeči, curl, nebo čemukoli jinému, nikdy neuvidíte, protože podle definice je klient v okamžiku, kdy by ho nginx poslal, už pryč. Existuje jen ve vlastním přístupovém logu nginx:

10.0.0.12 - - [19/Sep/2026:14:02:11 +0000] "GET /api/report HTTP/1.1" 499 0 "-" "python-requests/2.31"

Velikost odpovědi 0 bajtů a načasování vzhledem ke známé době odezvy vašeho upstreamu jsou dva nejužitečnější detaily: 499, která konzistentně dopadá přesně kolem timeoutu vašeho upstreamu, bez ničeho poslaného zpátky, jasně ukazuje na "backend byl příliš pomalý a něco přestalo čekat".

Co způsobuje 499

• Pomalá upstreamová aplikace. Backendu trvá odpovědět déle, než je nějaký klient nebo mezičlánek ochotný čekat, ať už jde o pomalý databázový dotaz, volání externího API, nebo skutečně náročný výpočet.
• Timeout na straně klienta kratší, než server potřebuje. Zavřená karta prohlížeče, mobilní aplikace, která to vzdá u nestabilního spojení, nebo vlastní timeout knihovny HTTP klienta, který zafunguje dřív, než odpověď dorazí.
• Load balancer nebo upstreamová proxy s kratším timeoutem. Pokud mezi skutečným koncovým uživatelem a nginx něco sedí, jeho vlastní timeout může spustit odpojení, které nginx zaznamená jako 499, i když skutečný koncový uživatel výslovně nic nezrušil.
• Uživatel opouštějící stránku nebo obnovující ji. Někdo, kdo odklikne z pomalu se načítající stránky, nebo netrpělivě obnoví stránku, uzavře probíhající spojení dřív, než ho nginx dokončil.
• Hodnoty timeoutu nekonzistentní napříč řetězcem. Klient, CDN, load balancer, a samotný nginx mohou mít každý jiný timeout, a odpojení nastane podle toho, který je nejkratší, bez ohledu na to, jak jsou nastavené ostatní.

Proč se to nikdy neobjeví v prohlížeči

499 není odpověď, je to poznámka, kterou si nginx dělá sám pro sebe o odpovědi, kterou nikdy nedokončil odesílat. Uživatel, jehož karta vyprodukovala ve vašich logách 499, nevidí vůbec nic: žádnou chybovou stránku, žádný stavový kód, jen stránku, která se přestala načítat, nebo kolečko, které nikdy nezmizelo, protože neexistovala žádná odpověď, kterou by prohlížeč mohl vykreslit. Přesně proto spoléhání na hlášení chyb od uživatelů tohle úplně přehlédne; jediné místo, kde je 499 vidět, je vlastní přístupový log serveru.

Jak opravit a omezit 499

Neexistuje jediné nastavení, které 499 odstraní, protože základní příčinou je závod mezi tím, že to klient vzdá, a tím, že server dokončí, a oprava závisí na tom, která strana toho závodu je vlastně rozbitá. Začněte tím, že zjistíte, jestli je upstream u postižené trasy konzistentně pomalý, nebo jestli se odpojení soustředí kolem jednoho klienta, sítě, nebo mezičlánku, protože to ukazuje na jiné opravy.

1. Nejdřív prozkoumejte dobu odezvy upstreamu, protože pomalý backend je nejčastější základní příčina. Podívejte se, jak dlouho postižené požadavky na upstreamu skutečně trvaly, ne jen na to, že nginx zaznamenal 499.
2. Sesouhlaste hodnoty timeoutu napříč celým řetězcem, záměrně, místo abyste nechali výchozí hodnotu v každé vrstvě: klient, CDN, load balancer, a vlastní proxy_read_timeout a proxy_connect_timeout nginx by se měly nastavit s jasným pochopením, který z nich má zafungovat první.
3. Zvažte proxy_ignore_client_abort, pokud na tom, aby upstream dokončil svou práci i po odpojení klienta, ve vaší aplikaci záleží, například kvůli dokončení zápisu, který by neměl zůstat napůl hotový:

   proxy_ignore_client_abort on;

   Tohle nezabrání záznamu 499 pro původní odpojení; mění to, jestli nginx dál nechá upstreamový požadavek běžet bez ohledu na to.
4. Zrychlete samotnou upstreamovou práci tam, kde je základní příčinou skutečně pomalý endpoint, protože žádné ladění timeoutu neopraví backend, který sám o sobě trvá příliš dlouho; profilujte konkrétní pomalé dotazy nebo volání za postiženou trasou.
5. Berte rostoucí míru 499 jako skutečný signál, ne šum v logu k odfiltrování, protože obvykle to znamená buď, že vaše aplikace zpomalila, nebo že je vaše konfigurace timeoutu někde v řetězci nesouladná.

Jak předejít tomu, aby se to stalo výpadkem

Protože se 499 ke klientovi nikdy nedostane jako viditelná chyba, skutečně pomalý endpoint může snadno zůstat bez povšimnutí, dokud si někdo nepřečte přístupové logy, i když skuteční uživatelé mezitím potichu opouštějí požadavky. Naplánovaná HTTP kontrola měří skutečnou dobu odezvy přímo proti endpointu a upozorní, když se zhorší, čímž zachytí zpomalení, které 499 produkuje, dřív, než přeroste v přímá selhání požadavků. Monitoring z více míst taky pomůže oddělit skutečně pomalý backend od timeoutu, který zafunguje jen u klientů na určité síťové cestě.

Související chyby

Viz 504 Gateway Timeout pro standardní, klientovi viditelný ekvivalent, když to vzdá sám nginx při čekání na upstream místo toho, aby to nejdřív vzdal klient, přehled 4xx pro standardní rodinu chyb klienta, a 429 Too Many Requests pro jiný druh odmítnutí vázaný na četnost, ne na načasování.

Často kladené otázky

Je 499 skutečný stavový kód HTTP?

Ne. Je to vlastní konvence záznamu nginx pro klienta, který se odpojil dřív, než se dokončila odpověď, a nikdy se neposílá po drátě žádnému klientovi, protože klient je v okamžiku, kdy by byla poslaná, už pryč.

Proč můj monitorovací nástroj nikdy neuvidí 499?

Monitorovací kontrola je sama klient, a pokud je to zrovna ona, kdo to u pomalé odpovědi vzdá, nahlásí vlastní chybu timeoutu, ne 499, protože nikdy nedostane HTTP odpověď, ze které by přečetla stavový kód. 499 se objeví jen ve vlastním záznamu přístupového logu serveru pro daný požadavek.

Znamená 499, že mi spadl server?

Ne. Konkrétně to znamená, že server pořád pracoval, nebo se chystal začít pracovat, když se klient odpojil. Pád by typicky místo toho vyprodukoval 502 nebo 500, jakmile by něco odpovědělo.

Můžu zastavit zpracování na upstreamu, když se klient odpojí?

Ve výchozím stavu nginx obecně přestane na upstream čekat, jakmile klient zmizí, ale přesné chování závisí na vašem nastavení proxy; proxy_ignore_client_abort on řekne nginx, aby nechal upstreamový požadavek pokračovat, místo aby ho opustil.

Jaká je nejčastější oprava pro časté 499?

Sesouhlasení hodnot timeoutu napříč klientem, jakoukoli mezilehlou proxy nebo load balancerem, a samotným nginx, v kombinaci s řešením toho, co upstream vůbec dělá pomalým. Ani jedno samo obvykle přetrvávající vzor nevyřeší.