504 Gateway Timeout: hvad det betyder, og hvordan du retter det

Hvad fejlen betyder

En 504 er webserveren foran (nginx, Apache, en load balancer, et CDN), der giver op over for applikationen bag sig. Forespørgslen blev sendt videre, backenden gik i gang med at arbejde, og forsidens timer løb ud, før der kom et svar tilbage. Forskellen til en 502 Bad Gateway er, at backenden kan nås; den er bare for langsom. Typiske timere er 60 sekunder i nginx (fastcgi_read_timeout, proxy_read_timeout), 60 sekunder i Apache (ProxyTimeout) og 100 sekunder hos Cloudflare, som du ikke kan ændre med det gratis abonnement.

At hæve timeouten er sjældent rettelsen. Noget tager for lang tid, og det noget er det, du skal finde.

Almindelige årsager

1. En langsom databaseforespørgsel. Et WordPress-plugin, der tæller rækker i en kæmpetabel ved hver sideindlæsning, et manglende indeks, en wp_options-tabel fuld af udløbne transients. Hver forespørgsel venter, og under belastning lægges ventetiderne sammen.
2. Et eksternt kald, der hænger. Applikationen kontakter en betalingsudbyder, en mailtjeneste, et vejr-API eller en licensserver, og den tjeneste er langsom eller nede. Uden en timeout på kaldet venter din side på den.
3. For få workers. Alle PHP-FPM-workers er optaget af langsomme forespørgsler; nye står i kø, indtil forsiden giver op. Udefra ligner det en timeout, selv om hver enkelt forespørgsel ville være hurtig.
4. Cron eller backup, der kører i forgrunden. Et backup-plugin, en import, et sitemap på 50.000 URL’er: genereret inde i en webforespørgsel overskrider de enhver timeout.
5. Disk-I/O eller swap. Serveren løber tør for hukommelse og swapper; alt bliver ti gange langsommere. Synligt som høj belastning med lavt CPU-forbrug.
6. Netværket mellem forside og bagside. En load balancer i ét datacenter, backenden i et andet, en firewall, der i det stille dropper pakker. Sjældent, men en 504 ved hver forespørgsel med en ledig backend peger herhen.

Hvis du er besøgende

Genindlæs efter et minut. Er hjemmesiden langsom frem for nede, så prøv en anden side; timeouten kan være knyttet til én tung side.

Hvis det er din hjemmeside: tjek først

Kør tjekket af, om hjemmesiden er nede: det melder statuskode og svartid udefra. En hjemmeside, der svarer på 30 sekunder i dag, er en hjemmeside, der viser 504 under belastning i morgen.

På din egen server skal du finde ud af, hvor tiden går:

# hober workers sig op?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# hvad laver PHP lige nu? (kræver pm.status_path i poolen)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E 'state|request URI|duration' | head -40

# MySQL/MariaDB: hvilke forespørgsler kører, og hvor længe?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# hukommelse og swap
free -m
vmstat 1 5

En processliste fuld af den samme forespørgsel eller si/so-kolonner i vmstat, der ikke er nul, nævner årsagen.

Rettelser på din egen server

1. Slå den langsomme forespørgselslog til, og ret forespørgslen

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

Efter nogle minutter viser sudo mysqldumpslow -s t /var/log/mysql/slow.log | head de værste forespørgsler. Tilføj det manglende indeks, eller find det plugin, der kører forespørgslen, og erstat det. I WordPress er en oppustet options-tabel en klassiker:

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

Alt i hundredvis af kilobyte, der autoloades ved hver forespørgsel, er en kandidat til fjernelse.

2. Sæt en timeout på eksterne kald

Hvert HTTP-kald, din applikation foretager, har brug for sin egen timeout, kortere end webserverens. I PHP med cURL: CURLOPT_CONNECTTIMEOUT 5 og CURLOPT_TIMEOUT 10. I WordPress tager wp_remote_get() et timeout-argument; mange plugins lader det stå på standardværdien og venter for evigt. Er en tredjepartstjeneste nede, skal siden degradere (vise formularen uden den aktuelle fragtpris), ikke dø.

3. Flyt langt arbejde ud af forespørgslen

Backups, importer, eksporter, store sitemaps og mailudsendelse hører hjemme i et cronjob eller en kø, ikke i en sidevisning. I WordPress slår du pseudo-cron fra og kører den rigtige:

// 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. Justér timeouts, med omtanke

Har en enkelt side med rette brug for længere tid (en eksport i admin, en rapport), så hæv timeouten kun for den placering, ikke globalt:

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

Apache med PHP-FPM: ProxyTimeout 300 inde i en <Location>-blok. PHP selv har max_execution_time; sæt den til den samme værdi, ellers stopper PHP først, og du får en 500 i stedet. Derefter sudo nginx -t && sudo systemctl reload nginx.

5. Stop swapningen

ps aux --sort=-%mem | head

Bruger PHP-FPM-workers hver 150 MB, og du kører 30 af dem på en server med 4 GB, går regnestykket ikke op. Sænk pm.max_children, øg hukommelsen, eller ret det plugin, der bruger hukommelsen. En server, der ikke swapper, er en server, hvis 504’er for det meste forsvinder.

6. Cache

En fuldside-cache (nginx FastCGI-cache, et WordPress-caching-plugin, Varnish) betjener tilbagevendende besøgende uden at røre PHP eller databasen. De fleste 504’er under belastning forsvinder, når forsiden og de mest besøgte sider kommer fra cachen.

Når det er din hostingudbyders problem

Hos delt hosting kan du rette langsomme forespørgsler og plugins, men ikke serverens timeouts eller naboernes belastning. Send din hostingudbyder:

Hej, min hjemmeside example.com returnerer “504 Gateway Timeout” siden ca. kl. 16:00 UTC. Sider, der før indlæstes på under to sekunder, løber nu ud i timeout. Jeg har ikke ændret noget. Kan I tjekke, om databaseserveren eller PHP-poolen på min konto er overbelastet, eller om en anden konto på serveren forårsager høj belastning, og fortælle mig, hvad I finder?

Forebyg den næste

En 504 er en langsom hjemmeside, der blev langsommere, og svartiden kan måles længe før timeouten. Hjemmesidetjek registrerer svartiden for hvert tjek; sæt en alarm på den, så ser du tendensen uger før besøgende ser en fejl. Serveragenten tilføjer belastning, hukommelse og swap indefra. På din egen server finder en Deep Fix den langsomme forespørgsel eller det hængende kald og retter det, afregnet i blokke af 15 minutter, pris før du bestiller.