504 Gateway Timeout: ce înseamnă și cum se repară

Ce înseamnă eroarea

Un 504 este serverul web din față (nginx, Apache, un load balancer, un CDN) care renunță la aplicația din spatele lui. Cererea a fost trimisă mai departe, backendul a început să lucreze, iar cronometrul părții din față a expirat înainte să vină un răspuns. Diferența față de un 502 Bad Gateway este că backendul este accesibil; doar că este prea lent. Cronometrele tipice sunt de 60 de secunde în nginx (fastcgi_read_timeout, proxy_read_timeout), 60 de secunde în Apache (ProxyTimeout) și 100 de secunde la Cloudflare, pe care nu le poți schimba în planul gratuit.

Mărirea timeout-ului este rareori remedierea. Ceva durează prea mult, iar acel ceva trebuie găsit.

Cauze frecvente

1. O interogare lentă a bazei de date. Un plugin WordPress care numără rânduri într-un tabel uriaș la fiecare încărcare de pagină, un index lipsă, un tabel wp_options plin de transient-uri expirate. Fiecare cerere așteaptă, iar sub încărcare așteptările se adună.
2. Un apel extern care se blochează. Aplicația contactează un furnizor de plăți, un serviciu de e-mail, un API meteo sau un server de licențe, iar acel serviciu este lent sau căzut. Fără un timeout pe acel apel, pagina ta îl așteaptă.
3. Prea puțini workeri. Toți workerii PHP-FPM sunt ocupați cu cereri lente; cele noi stau la coadă până când partea din față renunță. Din exterior arată ca un timeout, deși fiecare cerere în parte ar fi rapidă.
4. Cron sau backup rulând în prim-plan. Un plugin de backup, un import, o sitemap de 50.000 de URL-uri: generate în interiorul unei cereri web, depășesc orice timeout.
5. I/O de disc sau swap. Serverul rămâne fără memorie și face swap; totul încetinește de zece ori. Vizibil ca încărcare mare cu utilizare mică a CPU.
6. Rețeaua dintre partea din față și cea din spate. Un load balancer într-un centru de date, backendul în altul, un firewall care pierde pachete pe tăcute. Rar, dar un 504 la fiecare cerere cu un backend inactiv indică aici.

Dacă ești vizitator

Reîncarcă după un minut. Dacă site-ul este lent, nu căzut, încearcă o altă pagină; timeout-ul poate fi legat de o singură pagină grea.

Dacă e site-ul tău: verifică mai întâi

Rulează website down checker: raportează codul de status și timpul de răspuns din exterior. Un site care răspunde în 30 de secunde astăzi este un site care va arăta 504 sub încărcare mâine.

Pe propriul server, află unde se duce timpul:

# se adună workerii?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# ce face PHP chiar acum? (necesită pm.status_path în pool)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E 'state|request URI|duration' | head -40

# MySQL/MariaDB: ce interogări rulează și de cât timp?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# memorie și swap
free -m
vmstat 1 5

O listă de procese plină cu aceeași interogare sau coloanele si/so din vmstat care nu sunt zero numesc cauza.

Remedieri pe propriul server

1. Activează logul de interogări lente și repară interogarea

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

După câteva minute, sudo mysqldumpslow -s t /var/log/mysql/slow.log | head listează cele mai rele interogări. Adaugă indexul lipsă sau găsește pluginul care rulează interogarea și înlocuiește-l. În WordPress, un tabel de opțiuni umflat este un clasic:

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;"

Orice se încarcă automat la fiecare cerere și are sute de kiloocteți este candidat la eliminare.

2. Pune un timeout pe apelurile externe

Fiecare apel HTTP pe care îl face aplicația ta are nevoie de propriul timeout, mai scurt decât al serverului web. În PHP cu cURL: CURLOPT_CONNECTTIMEOUT 5 și CURLOPT_TIMEOUT 10. În WordPress, wp_remote_get() primește un argument timeout; multe plugin-uri îl lasă la valoarea implicită și așteaptă la nesfârșit. Dacă un serviciu terț este căzut, pagina ar trebui să degradeze (să arate formularul fără tariful de livrare în timp real), nu să moară.

3. Mută munca lungă în afara cererii

Backup-urile, importurile, exporturile, sitemap-urile mari și trimiterea de e-mailuri își au locul într-un cron job sau o coadă, nu într-o vizualizare de pagină. Pentru WordPress, dezactivează pseudo-cron-ul și rulează-l pe cel real:

// 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. Ajustează timeout-urile, cu grijă

Dacă o singură pagină are nevoie legitim de mai mult timp (un export din administrare, un raport), mărește timeout-ul doar pentru acea locație, nu global:

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

Apache cu PHP-FPM: ProxyTimeout 300 într-un bloc <Location>. PHP însuși are max_execution_time; setează-l la aceeași valoare, altfel PHP se oprește primul și primești un 500 în loc. Apoi sudo nginx -t && sudo systemctl reload nginx.

5. Oprește swap-ul

ps aux --sort=-%mem | head

Dacă workerii PHP-FPM folosesc fiecare 150 MB și rulezi 30 dintre ei pe un server de 4 GB, calculul nu iese. Micșorează pm.max_children, mărește memoria sau repară pluginul care folosește memoria. Un server care nu face swap este un server ale cărui 504 dispar în mare parte.

6. Cache

Un cache de pagină întreagă (nginx FastCGI cache, un plugin de cache WordPress, Varnish) servește vizitatorii care revin fără să atingă PHP sau baza de date. Majoritatea 504 sub încărcare dispar odată ce pagina principală și paginile de top vin din cache.

Când e problema furnizorului tău de hosting

Pe hosting partajat poți repara interogări lente și plugin-uri, dar nu timeout-urile serverului sau încărcarea vecinilor. Trimite-i furnizorului tău:

Bună ziua, site-ul meu example.com returnează „504 Gateway Timeout” începând cu aproximativ 16:00 UTC. Paginile care se încărcau înainte în sub două secunde expiră acum. Nu am schimbat nimic. Ați putea verifica dacă serverul de baze de date sau pool-ul PHP al contului meu este suprasolicitat sau dacă un alt cont de pe server cauzează o încărcare mare și să-mi spuneți ce găsiți?

Prevenirea următorului

Un 504 este un site lent care a devenit mai lent, iar timpul de răspuns este măsurabil cu mult înainte de timeout. Verificările de site înregistrează timpul de răspuns al fiecărei verificări; setează o alertă pe el și vei vedea tendința cu săptămâni înainte ca vizitatorii să vadă o eroare. Agentul de server adaugă încărcarea, memoria și swap-ul din interior. Pe propriul server, un Deep Fix găsește interogarea lentă sau apelul blocat și le repară, facturat în blocuri de 15 minute, cu prețul înainte să comanzi.