504 Gateway Timeout: pomalé backendy, timeouty a 502 vs 503 vs 504
504 Gateway Timeout znamená, že se proxy dostala k vašemu backendu, čekala na odpověď a vzdala se dřív, než nějaká dorazila. Nic nespadlo a nic požadavek neodmítlo: něco za proxy je pomalejší, než je proxy ochotná čekat.
Co 504 hlásí
RFC 9110 definuje 504 pro server fungující jako brána nebo proxy, který od upstream serveru, na který se potřeboval obrátit, nedostal odpověď včas. Slovo "včas" definuje konfigurace, ne specifikace, takže 504 je vždy výpověď o dvou věcech najednou: jak pomalý byl backend, a na jaký limit byla proxy nastavená.
Z toho plyne důležitý praktický důsledek. Když proxy vrátí 504, backend obvykle na požadavku dál pracuje. Spojení s klientem je pryč, ale pomalý dotaz pořád běží, report se pořád generuje a prostředky jsou pořád obsazené. Proto vlna 504 často server ještě zhorší: každý opuštěný požadavek za sebou nechá rozdělanou práci a fronta roste rychleji, než se vyprazdňuje.
504 versus 502 versus 503
| 502 Bad Gateway | 503 Service Unavailable | 504 Gateway Timeout | |
|---|---|---|---|
| Co se stalo | Backend dal neplatnou odpověď nebo zavřel spojení | Server práci záměrně odmítl | Backend práci přijal a nikdy neodpověděl včas |
| Stav backendu | Nedostupný, padá, nebo mluví špatným protokolem | Dostupný, ale přetížený nebo v údržbě | Dostupný a zaneprázdněný, pořád zpracovává |
| Rychlost odpovědi | Obvykle okamžitá | Obvykle okamžitá | Pomalá, dorazí na hranici timeoutu |
| Typický řádek logu | connect() failed nebo upstream prematurely closed connection | Pravidlo údržby, nebo žádné zdravé upstreamy | upstream timed out (110: Connection timed out) |
Retry-After | Neobvyklé | Běžné a doporučené | Neobvyklé |
| Kam se podívat nejdřív | Běží proces backendu? | Kapacita, příznaky údržby, health checky | Pomalé dotazy a pomalé závislosti |
V praxi 502 selže rychle, 503 zdvořile odmítne, a 504 vás nejdřív nechá čekat. Zbylé dvě v plné míře pokrývá samostatný návod na 502 a přehled 5xx.
Proč je backend příliš pomalý
- Pomalé databázové dotazy. Chybějící index, dotaz, který rostl spolu s daty, vzor N+1 ve smyčce, nebo soupeření o zámky při souběžnosti. Zdaleka nejčastější příčina.
- Pomalá volání třetích stran. Odchozí API požadavek bez vlastního timeoutu zdědí nejhorší den vzdálené služby a předá ho vašim návštěvníkům.
- Studené starty. První požadavek po navýšení kapacity, startu kontejneru nebo období nečinnosti zaplatí za inicializaci, navázání spojení a zahřátí cache najednou.
- Skutečně náročná práce na webovém požadavku. Generování reportů, exporty, zpracování obrázků nebo hromadné importy zpracované synchronně nakonec překročí jakýkoli rozumný timeout.
- Soupeření o zdroje. Vytížení CPU, tlak na paměť a swapování zpomalí každý požadavek, takže nejpomalejší z nich překročí limit jako první.
- Timeouty nastavené příliš nízko. Pokud endpoint oprávněně potřebuje víc času, než proxy dovoluje, chyba je v konfiguraci, ne v kódu.
- Síťové problémy mezi jednotlivými skoky. Ztráta paketů nebo zpoždění při překladu DNS pro adresu upstreamu přidají latenci, která se v časování aplikace vůbec neobjeví.
Jak 504 diagnostikovat a opravit
- Změřte čas do chyby. Zpoždění před 504 obvykle odpovídá nastavenému timeoutu, což prozradí, který skok ji vyprodukoval:
504 téměř přesně na 60 sekundách ukazuje na výchozí read timeout proxy. Ta na 30 nebo 100 sekundách ukazuje na komponentu nastavenou na dané číslo, často CDN, ne vaši vlastní proxy.curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/slow-page - Zjistěte, jestli jde o jeden endpoint, nebo o všechny. Jedna pomalá URL je problém aplikace. Všechno pomalé najednou je vyčerpání zdrojů nebo selhávající závislost.
- Přečtěte si chybový log proxy. U nginx je řádek jednoznačný:
Pojmenovává upstream i fázi, což odliší pomalé navazování spojení od pomalé odpovědi.[error] upstream timed out (110: Connection timed out) while reading response header from upstream, upstream: "http://127.0.0.1:8080/" - Změřte čas přímo na backendu, bez proxy. Pokud stejný požadavek na originu trvá 90 sekund, proxy hlásí pravdu a oprava patří do aplikace.
- Profilujte pomalou cestu. Zkontrolujte log pomalých dotazů, pak trasování aplikace. Většina 504 se scvrkne na jeden dotaz nebo jedno odchozí volání.
- Opravte příčinu, ne timeout. Přidejte index, cachujte nákladný výsledek, nebo přesuňte skutečně dlouhou práci na úlohu na pozadí, která odpoví okamžitě a průběh hlásí zvlášť.
- Timeout zvyšujte, jen když je práce oprávněně dlouhá, a zvyšte ho konzistentně na každém skoku. Limit CDN na 30 sekund udělá timeout originu na 120 sekund zbytečným.
- Nastavte timeouty na vlastních odchozích voláních, aby pomalá závislost selhala rychle s jasnou chybou, místo aby zabírala workera, dokud se proxy nevzdá.
Doba odezvy je včasné varování
504 je koncový stav zpomalení, které se nabalovalo už nějakou dobu. Doba odezvy se posune z půl sekundy na dvě sekundy, pak na deset, a nikdo si toho nevšimne, dokud požadavky nezačnou překračovat limit. Naplánovaná HTTP kontrola zaznamenává dobu odezvy každé kontroly spolu se stavovým kódem, takže je trend vidět jako graf dávno před prvním timeoutem, a upozornění přijde při prvním skutečném selhání, ne až se zaplní fronta podpory. Pomůže i kontrola z více regionů, protože trasa, která je rychlá z jednoho kontinentu a pomalá z jiného, ukazuje na síťovou trasu nebo konfiguraci edge, ne na vaši databázi.