504 Gateway Timeout: hva det betyr og hvordan du fikser det

Hva feilen betyr

En 504 er webserveren foran (nginx, Apache, en lastbalanserer, et CDN) som gir opp applikasjonen bak seg. Forespørselen ble sendt videre, backend begynte å jobbe, og fronten hadde ikke fått svar før tidtakeren gikk ut. Forskjellen fra en 502 Bad Gateway er at backend kan nås; den er bare for treg. Typiske tidtakere 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 endre på gratisplanen.

Å øke tidsavbruddet er sjelden løsningen. Noe tar for lang tid, og det noe er det du må finne.

Vanlige årsaker

1. En treg databasespørring. En WordPress-plugin som teller rader i en enorm tabell ved hver sidelasting, en manglende indeks, en wp_options-tabell full av utløpte transients. Hver forespørsel venter, og under belastning legger ventetidene seg oppå hverandre.
2. Et eksternt kall som henger. Applikasjonen kontakter en betalingsleverandør, en e-posttjeneste, et vær-API eller en lisensserver, og den tjenesten er treg eller nede. Uten tidsavbrudd på det kallet venter siden din på den.
3. For få arbeidere. Alle PHP-FPM-arbeiderne er opptatt med trege forespørsler; nye står i kø til fronten gir opp. Utenfra ser dette ut som et tidsavbrudd selv om hver enkelt forespørsel ville vært rask.
4. Cron eller sikkerhetskopi som kjører i forgrunnen. En backup-plugin, en import, et nettstedskart med 50 000 URL-er: genereres de inne i en webforespørsel, overskrider de ethvert tidsavbrudd.
5. Disk-I/O eller swap. Serveren går tom for minne og swapper; alt går ti ganger tregere. Synlig som høy belastning med lav CPU-bruk.
6. Nettverket mellom front og bak. En lastbalanserer i ett datasenter, backend i et annet, en brannmur som stille forkaster pakker. Sjeldent, men en 504 på hver forespørsel med en ledig backend peker hit.

Hvis du er besøkende

Last på nytt etter et minutt. Er nettsiden treg i stedet for nede, prøv en annen side; tidsavbruddet kan være knyttet til én tung side.

Hvis det er din nettside: sjekk først

Kjør nettside-nede-sjekken: den rapporterer statuskoden og svartiden utenfra. En nettside som svarer på 30 sekunder i dag, er en nettside som viser 504 under belastning i morgen.

På din egen server finner du hvor tiden går:

# hoper arbeiderne seg opp?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# hva gjør PHP akkurat nå? (krever 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 spørringer kjører, og hvor lenge?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# minne og swap
free -m
vmstat 1 5

En prosessliste full av samme spørring, eller si/so-kolonner i vmstat som ikke er null, peker ut årsaken.

Løsninger på din egen server

1. Slå på loggen for trege spørringer og fiks spørringen

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

Etter noen minutter lister sudo mysqldumpslow -s t /var/log/mysql/slow.log | head de verste spørringene. Legg til den manglende indeksen, eller finn pluginen som kjører spørringen og erstatt den. I WordPress er en oppblåst options-tabell 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 på flere hundre kilobyte som autoloader ved hver forespørsel, er en kandidat for fjerning.

2. Sett et tidsavbrudd på eksterne kall

Hvert HTTP-kall applikasjonen din gjør, trenger sitt eget tidsavbrudd, kortere enn webserverens. I PHP med cURL: CURLOPT_CONNECTTIMEOUT 5 og CURLOPT_TIMEOUT 10. I WordPress tar wp_remote_get() et timeout-argument; mange plugins lar det stå på standardverdien og venter i evighet. Er en tredjepartstjeneste nede, bør siden degraderes (vise skjemaet uten live fraktpris), ikke dø.

3. Flytt langvarig arbeid ut av forespørselen

Sikkerhetskopier, importer, eksporter, store nettstedskart og e-postutsending hører hjemme i en cron-jobb eller en kø, ikke i en sidevisning. For WordPress slår du av pseudo-cron og kjører den ekte:

// 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. Juster tidsavbruddene, med omhu

Trenger en enkelt side legitimt lengre tid (en admin-eksport, en rapport), øk tidsavbruddet bare for den plasseringen, 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 inne i en <Location>-blokk. PHP selv har max_execution_time; sett den til samme verdi, ellers stopper PHP først og du får en 500 i stedet. Deretter sudo nginx -t && sudo systemctl reload nginx.

5. Slutt å swappe

ps aux --sort=-%mem | head

Bruker PHP-FPM-arbeiderne 150 MB hver og du kjører 30 av dem på en server med 4 GB, går ikke regnestykket opp. Senk pm.max_children, øk minnet, eller fiks pluginen som bruker minnet. En server som ikke swapper, er en server der 504-feilene for det meste forsvinner.

6. Cache

En fullsidecache (nginx FastCGI cache, en WordPress cache-plugin, Varnish) betjener gjentatte besøkende uten å røre PHP eller databasen. De fleste 504-feil under belastning forsvinner når forsiden og de mest besøkte sidene kommer fra cachen.

Når det er hosting-leverandørens problem

På delt hosting kan du fikse trege spørringer og plugins, men ikke serverens tidsavbrudd eller naboenes belastning. Send hosting-leverandøren din:

Hei, nettsiden min example.com returnerer «504 Gateway Timeout» siden omtrent 16:00 UTC. Sider som pleide å laste på under to sekunder, får nå tidsavbrudd. Jeg har ikke endret noe. Kan dere sjekke om databaseserveren eller PHP-poolen til kontoen min er overbelastet eller om en annen konto på serveren forårsaker høy belastning, og si hva dere finner?

Forhindre neste gang

En 504 er en treg nettside som ble tregere, og svartid kan måles lenge før tidsavbruddet. Nettsidesjekker registrerer svartiden for hver sjekk; sett et varsel på den, så ser du trenden uker før besøkende ser en feil. Serveragenten legger til belastning, minne og swap fra innsiden. På din egen server finner en Deep Fix den trege spørringen eller det hengende kallet og fikser det, fakturert i blokker på 15 minutter, pris før du bestiller.