504 Gateway Timeout: co znamená a jak to opravit

Co chyba znamená

504 je webový server vpředu (nginx, Apache, load balancer, CDN), který se vzdal čekání na aplikaci za sebou. Požadavek byl předán, backend začal pracovat a časovač přední části vypršel dřív, než přišla odpověď. Rozdíl oproti 502 Bad Gateway je v tom, že backend je dosažitelný; je jen příliš pomalý. Typické časovače jsou 60 sekund v nginx (fastcgi_read_timeout, proxy_read_timeout), 60 sekund v Apache (ProxyTimeout) a 100 sekund u Cloudflare, které v bezplatném plánu změnit nemůžete.

Zvýšení časového limitu je opravou jen zřídka. Něco trvá příliš dlouho a to něco musíte najít.

Časté příčiny

1. Pomalý dotaz do databáze. Plugin WordPressu, který při každém načtení stránky počítá řádky v obrovské tabulce, chybějící index, tabulka wp_options plná prošlých transientů. Každý požadavek čeká a pod zátěží se čekání sčítá.
2. Externí volání, které visí. Aplikace kontaktuje poskytovatele plateb, poštovní službu, API počasí nebo licenční server a ta služba je pomalá nebo nejede. Bez časového limitu na to volání na ni vaše stránka čeká.
3. Příliš málo pracovníků. Všichni pracovníci PHP-FPM jsou zaneprázdnění pomalými požadavky; nové čekají ve frontě, dokud se přední část nevzdá. Zvenčí to vypadá jako časový limit, i když by každý jednotlivý požadavek byl rychlý.
4. Cron nebo záloha běžící v popředí. Plugin pro zálohy, import, mapa webu o 50 000 URL: generované uvnitř webového požadavku překročí jakýkoli časový limit.
5. Disk I/O nebo swap. Serveru dojde paměť a swapuje; všechno se zpomalí desetinásobně. Viditelné jako vysoká zátěž s nízkým využitím CPU.
6. Síť mezi přední a zadní částí. Load balancer v jednom datovém centru, backend v jiném, firewall tiše zahazující pakety. Vzácné, ale 504 při každém požadavku s nečinným backendem ukazuje sem.

Pokud jste návštěvník

Po minutě stránku načtěte znovu. Pokud je web spíš pomalý než nefunkční, zkuste jinou stránku; časový limit může souviset s jednou těžkou stránkou.

Pokud jde o váš web: nejdřív zkontrolujte

Spusťte kontrolu dostupnosti webu: hlásí stavový kód a dobu odezvy zvenčí. Web, který dnes odpovídá za 30 sekund, je web, který zítra pod zátěží ukáže 504.

Na vlastním serveru zjistěte, kam se čas ztrácí:

# are workers piling up?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# what is PHP doing right now? (needs pm.status_path in the pool)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E 'state|request URI|duration' | head -40

# MySQL/MariaDB: which queries are running, and for how long?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# memory and swap
free -m
vmstat 1 5

Seznam procesů plný stejného dotazu nebo sloupce si/so ve vmstat, které nejsou nulové, pojmenují příčinu.

Opravy na vlastním serveru

1. Zapněte log pomalých dotazů a opravte dotaz

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Po několika minutách vypíše sudo mysqldumpslow -s t /var/log/mysql/slow.log | head nejhorší dotazy. Přidejte chybějící index, nebo najděte plugin, který dotaz spouští, a nahraďte ho. Ve WordPressu je klasikou přerostlá tabulka voleb:

wp transient delete --all
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

Cokoli ve stovkách kilobajtů, co se načítá automaticky při každém požadavku, je kandidátem na odstranění.

2. Dejte externím voláním časový limit

Každé volání HTTP, které vaše aplikace dělá, potřebuje vlastní časový limit, kratší než ten webového serveru. V PHP s cURL: CURLOPT_CONNECTTIMEOUT 5 a CURLOPT_TIMEOUT 10. Ve WordPressu přijímá wp_remote_get() argument timeout; mnoho pluginů ho nechává na výchozí hodnotě a čeká donekonečna. Pokud služba třetí strany nejede, měla by stránka degradovat (zobrazit formulář bez živé ceny dopravy), ne umřít.

3. Přesuňte dlouhou práci mimo požadavek

Zálohy, importy, exporty, velké mapy webu a odesílání pošty patří do úlohy cron nebo fronty, ne do zobrazení stránky. U WordPressu vypněte pseudo-cron a spouštějte skutečný:

// wp-config.php
define('DISABLE_WP_CRON', true);

# crontab -e
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

4. Časové limity upravujte opatrně

Pokud jedna stránka legitimně potřebuje víc času (export v administraci, report), zvyšte časový limit jen pro tuto lokaci, ne globálně:

location = /wp-admin/export.php {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
}

Apache s PHP-FPM: ProxyTimeout 300 uvnitř bloku <Location>. Samotné PHP má max_execution_time; nastavte ho na stejnou hodnotu, jinak PHP skončí první a dostanete místo toho 500. Pak sudo nginx -t && sudo systemctl reload nginx.

5. Přestaňte swapovat

ps aux --sort=-%mem | head

Pokud každý pracovník PHP-FPM používá 150 MB a vy jich na serveru se 4 GB provozujete 30, výpočet nevychází. Snižte pm.max_children, zvyšte paměť nebo opravte plugin, který paměť spotřebovává. Server, který nesvapuje, je server, jehož 504 většinou zmizí.

6. Cache

Cache celých stránek (FastCGI cache v nginx, plugin pro cache ve WordPressu, Varnish) obsluhuje opakované návštěvníky bez zásahu do PHP nebo databáze. Většina 504 pod zátěží zmizí, jakmile úvodní stránka a nejnavštěvovanější stránky pocházejí z cache.

Když je to problém poskytovatele hostingu

Na sdíleném hostingu můžete opravit pomalé dotazy a pluginy, ale ne časové limity serveru ani zátěž sousedů. Pošlete poskytovateli:

Dobrý den, můj web example.com vrací „504 Gateway Timeout“ přibližně od 16:00 UTC. Stránky, které se dřív načítaly za méně než dvě sekundy, teď končí vypršením časového limitu. Nic jsem neměnil. Mohli byste zkontrolovat, zda není přetížený databázový server nebo pool PHP mého účtu, nebo zda vysokou zátěž nezpůsobuje jiný účet na serveru, a sdělit mi, co zjistíte?

Jak předejít dalšímu

504 je pomalý web, který zpomalil ještě víc, a dobu odezvy lze měřit dlouho před časovým limitem. Kontroly webu zaznamenávají dobu odezvy každé kontroly; nastavte na ni upozornění a uvidíte trend týdny předtím, než návštěvníci uvidí chybu. Serverový agent přidává zátěž, paměť a swap zevnitř. Na vlastním serveru Deep Fix najde pomalý dotaz nebo visící volání a opraví je, účtováno po 15minutových blocích, cena před objednáním.