504 Gateway Timeout: vad det betyder och hur du åtgärdar det

Vad felet betyder

Ett 504 är webbservern framför (nginx, Apache, en lastbalanserare, ett CDN) som ger upp inför applikationen bakom sig. Förfrågan skickades vidare, backend började arbeta, och framsidans timer gick ut innan ett svar kom tillbaka. Skillnaden mot ett 502 Bad Gateway är att backend går att nå; den är bara för långsam. Typiska timers är 60 sekunder i nginx (fastcgi_read_timeout, proxy_read_timeout), 60 sekunder i Apache (ProxyTimeout) och 100 sekunder hos Cloudflare, vilket du inte kan ändra i gratisplanen.

Att höja tidsgränsen är sällan lösningen. Något tar för lång tid, och det är det du behöver hitta.

Vanliga orsaker

1. En långsam databasfråga. Ett WordPress-plugin som räknar rader i en enorm tabell vid varje sidladdning, ett saknat index, en wp_options-tabell full av utgångna transienter. Varje förfrågan väntar, och under belastning läggs väntetiderna ihop.
2. Ett externt anrop som hänger sig. Applikationen kontaktar en betalleverantör, en e-posttjänst, ett väder-API eller en licensserver, och den tjänsten är långsam eller nere. Utan tidsgräns på det anropet väntar din sida på den.
3. För få arbetare. Alla PHP-FPM-arbetare är upptagna med långsamma förfrågningar; nya köar tills framsidan ger upp. Utifrån ser det ut som en timeout trots att varje enskild förfrågan skulle vara snabb.
4. Cron eller säkerhetskopiering som körs i förgrunden. Ett säkerhetskopieringsplugin, en import, en sitemap med 50 000 URL:er: genereras de inom en webbförfrågan överskrider de varje tidsgräns.
5. Disk-I/O eller swap. Servern får slut på minne och swappar; allt blir tio gånger långsammare. Syns som hög belastning med låg CPU-användning.
6. Nätverket mellan framsida och baksida. En lastbalanserare i ett datacenter, backend i ett annat, en brandvägg som tyst släpper paket. Sällsynt, men ett 504 på varje förfrågan med en overksam backend pekar hit.

Om du är besökare

Ladda om efter en minut. Om hemsidan är långsam snarare än nere, prova en annan sida; tidsgränsen kan vara knuten till en tung sida.

Om det är din hemsida: kontrollera först

Kör kontrollen av om hemsidan ligger nere: den rapporterar statuskoden och svarstiden utifrån. En hemsida som svarar på 30 sekunder i dag är en hemsida som visar 504 under belastning i morgon.

På din egen server, hitta vart tiden tar vägen:

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

# vad gör PHP just 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: vilka frågor körs, och hur länge?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# minne och swap
free -m
vmstat 1 5

En processlista full av samma fråga, eller kolumnerna si/so i vmstat som inte är noll, pekar ut orsaken.

Åtgärder på din egen server

1. Slå på loggen för långsamma frågor och rätta frågan

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

Efter några minuter listar sudo mysqldumpslow -s t /var/log/mysql/slow.log | head de värsta frågorna. Lägg till det saknade indexet, eller hitta pluginet som kör frågan och ersätt det. I WordPress är en uppsvälld 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;"

Allt i hundratals kilobyte som autoladdas vid varje förfrågan är en kandidat för borttagning.

2. Sätt en tidsgräns på externa anrop

Varje HTTP-anrop som din applikation gör behöver en egen tidsgräns, kortare än webbserverns. I PHP med cURL: CURLOPT_CONNECTTIMEOUT 5 och CURLOPT_TIMEOUT 10. I WordPress tar wp_remote_get() ett timeout-argument; många plugin lämnar det på standardvärdet och väntar för evigt. Om en tredjepartstjänst är nere bör sidan fortsätta fungera i begränsad form (visa formuläret utan den aktuella fraktkostnaden), inte dö.

3. Flytta långa jobb ut ur förfrågan

Säkerhetskopior, importer, exporter, stora sitemaps och e-postutskick hör hemma i ett cronjobb eller en kö, inte i en sidvisning. För WordPress: stäng av pseudo-cron och kör den riktiga:

// 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. Justera tidsgränserna, med försiktighet

Om en enskild sida legitimt behöver längre tid (en admin-export, en rapport), höj tidsgränsen bara för den platsen, inte 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 inom ett <Location>-block. PHP självt har max_execution_time; sätt det till samma värde, annars stoppar PHP först och du får ett 500 i stället. Kör sedan sudo nginx -t && sudo systemctl reload nginx.

5. Sluta swappa

ps aux --sort=-%mem | head

Om PHP-FPM-arbetare använder 150 MB var och du kör 30 av dem på en server med 4 GB går räkneexemplet inte ihop. Sänk pm.max_children, höj minnet eller åtgärda pluginet som använder minnet. En server som inte swappar är en server vars 504 för det mesta försvinner.

6. Cacha

En helsidescache (nginx FastCGI-cache, ett WordPress-cacheplugin, Varnish) betjänar återkommande besökare utan att röra PHP eller databasen. De flesta 504 under belastning försvinner när startsidan och de mest besökta sidorna kommer från cachen.

När det är ditt webbhotells problem

På delat webbhotell kan du åtgärda långsamma frågor och plugin men inte serverns tidsgränser eller grannarnas belastning. Skicka till ditt webbhotell:

Hej, min hemsida example.com returnerar ”504 Gateway Timeout” sedan ungefär 16:00 UTC. Sidor som tidigare laddades på under två sekunder får nu timeout. Jag har inte ändrat något. Kan ni kontrollera om databasservern eller PHP-poolen för mitt konto är överbelastad eller om ett annat konto på servern orsakar hög belastning, och berätta vad ni hittar?

Förhindra nästa

Ett 504 är en långsam hemsida som blev långsammare, och svarstiden går att mäta långt före timeouten. Hemsidekontroller registrerar svarstiden för varje kontroll; sätt ett larm på den, så ser du trenden veckor innan besökarna ser ett fel. Serveragenten lägger till belastning, minne och swap inifrån. På din egen server hittar en Deep Fix den långsamma frågan eller det hängande anropet och åtgärdar det, debiterad i block om 15 minuter, pris innan du beställer.