Feil 504 i WordPress: webhotellet eller nettstedet

#Hva betyr feil 504 i WordPress

MDN, med henvisning til RFC 9110, definerer 504 som en situasjon der en server som fungerer som gateway eller proxy “ikke fikk svar i tide fra upstream-serveren” (egen oversettelse). Det er noe annet enn 502 Bad Gateway: der kom det et svar, men det var ugyldig. Ved 504 kom det ingenting.

På et typisk WordPress-webhotell ser kjeden slik ut: nettleser, eventuelt et CDN, nginx, PHP-FPM, databasen og eventuelt en objektcache. Koden 504 genereres av leddet som ventet. Det alene forteller hvor du skal lete. Hvis nginx venter på PHP, ligger problemet i PHP, databasen eller køen til PHP. Hvis CDN-et venter, ligger problemet på opprinnelsesserveren.

MDN-dokumentasjonen påpeker også at det finnes mange mulige årsaker, og at utbedringen vanligvis krever analyse fra serveradministratorens side. Derfor finnes det her ingen magisk rettelse, bare en rekkefølge på kontrollene.

#Er 504 webhotellets skyld eller nettstedets

Spørsmålet avgjøres av hvor omfattende feilen er. Tabellen under er en beslutningssnarvei, ikke en dom.

Webhotellets ansvar begynner der grensene (antall workere, minne, CPU) er for små for nettstedets normale trafikk. Nettstedets ansvar begynner der én enkelt forespørsel gjør så mye arbeid at den blokkerer en worker i flere titalls sekunder. I praksis er det ofte begge deler samtidig: trege forespørsler opptar workerne, og en liten pool har ingen reserve.

#Hvorfor går WordPress-nettstedet ned med noen ukers mellomrom

I november 2025 spurte eieren av to WordPress-nettsteder, som begge ble driftet av samme utvikler, rett ut på forumet r/webdev om dette var normalt:

Med noen ukers mellomrom går nettstedene plutselig ned eller slutter å fungere som de skal: enten lastes ikke siden, eller noe går i stykker. Utvikleren sier alltid noe sånt som at det er et problem med webhotellet, eller at noe må fornyes, sikkerhetskopieres eller oppdateres, og så tilbyr han en årlig avtale om vedlikehold eller sikkerhetskopiering mot ekstra betaling.

(egen oversettelse, r/webdev, tråd fra 2. november 2025)

Tråden fikk flere titalls svar. Her er spørsmålene den reiser, og det du kan sjekke selv.

#Er det webhotellets eller utviklerens skyld

Svarene i tråden delte seg i to leirer. En utvikler som overvåker nettstedene til alle kundene sine, skriver at nettsteder hos billigere webhoteller “er nede minst én gang i uken”, fordi de ikke tåler trafikken fra roboter (egen oversettelse, tomhermans, r/webdev). En annen svarer at et riktig konfigurert nettsted på et godt webhotell “nesten ALDRI skal gå ned” (egen oversettelse, redlotusaustin, r/webdev).

Begge deler kan stemme samtidig, og tabellen over hjelper deg å skille dem. Viser hvert utfall 502 eller 504 på hele nettstedet, er det som regel ressursene som svikter: en for liten PHP-FPM-pool eller en overbelastet delt server. Går nettstedet i stykker ett sted mens resten virker, ligger årsaken i koden, en plugin eller temaet.

#Kan roboter ta ned et WordPress-nettsted på billig webhotell

Ja. En robot som går gjennom adresser uten cache, starter PHP ved hver forespørsel. På delt webhotell med bare noen få PHP-arbeidere fylles køen raskt, og nye forespørsler ender med feil 504, som beskrives i avsnittene under. Det som hjelper, er sidecache foran PHP (på serveren eller i et CDN) og en grense for antall forespørsler fra én klient. Når du blokkerer roboter i Cloudflare, må du passe deg for innstillingen som også stenger ute Googlebot. Det har vi skrevet om i blokkerer Cloudflare Googlebot.

#Ødelegger plugin-oppdateringer WordPress-nettstedet

En av deltakerne i tråden peker på plugin-oppdateringer som en vanlig årsak til utfall når de legges rett inn på det levende nettstedet uten test på et staging-miljø (egen oversettelse, technomalist, r/webdev). Hvis utfallene faller sammen med oppdateringer, sammenlign datoene for utfallene med oppdateringshistorikken. Hvordan du jobber med en testkopi, står i guiden vår til staging i WordPress.

#Kan gjentatte utfall bety at nettstedet er hacket

Ja. Tråden beskriver et typisk forløp: Et nettsted som er infisert gjennom en sårbar plugin, gjenopprettes fra sikkerhetskopi, men hullet står fortsatt åpent, så etter noen dager skjer alt på nytt (egen oversettelse, 30thnight, r/webdev). Å gjenopprette en sikkerhetskopi uten å fjerne årsaken løser ikke problemet. Fremgangsmåten for opprydding finner du i guiden til fjerning av skadevare fra WordPress.

#Hvordan finner jeg ut hvorfor WordPress-nettstedet gikk ned

Det korteste svaret i tråden lyder: “Hva sier loggene?” (egen oversettelse, chmod777, r/webdev). Som eier kan du gjøre dette uten utvikler:

1. Slå på ekstern overvåking av oppetid som registrerer tidspunkt og varighet for hvert utfall.
2. Sørg for at du har egen tilgang til kontrollpanelet hos webhotellet, ikke bare til WordPress-panelet.
3. Etter et utfall åpner du PHP-feilloggen og feilloggen til webserveren for samme tidspunkt. Kritiske PHP-feil peker mot koden eller en plugin, overskredne prosessgrenser og tidsavbrudd mot ressursene hos webhotellet.
4. Sammenlign tidspunktene for utfallene med datoene for oppdateringer av plugins, tema og WordPress.

#Lønner det seg med en betalt vedlikeholdsavtale for WordPress

En vedlikeholdsavtale betaler for fast arbeid: oppdateringer som testes før de tas i bruk, overvåking, sikkerhetskopier og respons når noe går ned. Den bør likevel ikke være svaret på utfall som ingen har funnet årsaken til. Et utfall med noen ukers mellomrom er ikke normalt, verken med eller uten avtale. Etter hvert utfall bør du få skriftlig hva årsaken var og hva som ble endret for at det ikke skal skje igjen. Slik jobber vi med vedlikehold av WordPress-nettsider.

#Hvordan finner du ut hvor forespørselen satt fast

Start med tre steder, i denne rekkefølgen.

1. Feilloggen til webserveren fra tidspunktet for feilen. I nginx bekrefter oppføringen upstream timed out at serveren ventet på PHP.
2. PHP-FPM-loggen. Meldingen om at pm.max_children er nådd betyr at poolen var full og at de neste forespørslene sto i kø. Alternativet pm.max_children setter, slik PHP-dokumentasjonen beskriver det, grensen for samtidige forespørsler som poolen behandler.
3. WordPress-loggen. Sett WP_DEBUG til true, WP_DEBUG_LOG til true og WP_DEBUG_DISPLAY til false i wp-config.php. Feilene havner da i wp-content/debug.log i stedet for på skjermen. Slik beskriver WordPress-dokumentasjonen det. Slå av debug etter diagnosen.

Hvis webhotellet gir tilgang til PHP-FPM-slowloggen, sett request_slowlog_timeout, så skriver PHP en backtrace for forespørsler som varer lenger enn grensen. Alternativet er som standard slått av (verdien 0). Backtracen viser i hvilken funksjon i en plugin eller et tema PHP ventet.

På delt webhotell har du ofte ikke tilgang til disse loggene. Da er tilgang til dem og til målingene for PHP-poolen det første du må be supporten om, sammen med tidspunktet for feilen og adressen som returnerte 504.

#Hvorfor gir en for liten PHP-FPM-pool 504

Hver dynamiske forespørsel opptar én PHP-FPM-worker til svaret er ferdig. Når alle workerne er opptatt, må nye forespørsler vente. Hvis de venter lenger enn proxyens grense, ser den besøkende 504.

Standard fastcgi_read_timeout i nginx er 60 sekunder, og nginx-dokumentasjonen påpeker at grensen måles mellom to påfølgende lesinger fra FastCGI-serveren, ikke for hele svaret. På administrerte webhotell kan verdien være en annen, så ikke anta at den hos deg er akkurat 60 sekunder.

Å øke pm.max_children hjelper bare hvis serveren har minne til det. Hver WordPress-worker med noen få plugins tar en merkbar del av det, så en for høy verdi ender i tomt for RAM og drepte prosesser, altså en verre tilstand enn en kø. Konfigurasjon av poolen er en jobb for administratoren, som kan se minnebruken.

#Hvordan gir trege spørringer og autoloadede alternativer 504

Når 504 gjelder hele nettstedet og poolen ikke er full på grunn av trafikk, sjekk databasen. WordPress-dokumentasjonen peker på at WordPress gjentar mange spørringer i hver forespørsel, og at alternativer markert som autoload lastes ved hvert besøk. Den anbefaler å holde dem under 800 KB, og de fullstendige anbefalingene står i optimaliseringsveiledningen. En plugin som lagrer store datamengder i wp_options med autoload, presser dem inn i hver forespørsel. Størrelsen på autoloaden kan du sjekke med en SQL-spørring på kolonnen autoload i alternativtabellen.

For å finne trege spørringer finnes konstanten SAVEQUERIES. Den lagrer hver spørring, kjøretiden og funksjonen som kalte den, i $wpdb->queries. Den koster ytelse, så slå den på kort tid og helst på staging.

#Når gir objektcache og Redis 504

En vedvarende objektcache reduserer antall spørringer mot databasen og gjør vanligvis nettstedet raskere. Den krever likevel en fungerende cacheserver og drop-in-filen wp-content/object-cache.php.

Feilen slår motsatt vei når filen finnes og Redis-serveren ikke svarer. Hver forespørsel prøver da å koble seg til cachen, venter på tilkoblings-timeouten og går først deretter videre eller gir opp. Symptomet er 504 rett etter en omstart eller et sammenbrudd i cachetjenesten hos webhotellet, selv om koden i nettstedet ikke er endret.

Testen er enkel: gi object-cache.php et annet navn. Hvis 504 forsvinner, er det cachen som er synderen, ikke WordPress. Sett filen tilbake først etter at tjenesten er reparert.

#Hvordan gir WP-Cron, admin-ajax og eksterne API-er 504

Tre kilder til enkeltstående, trege forespørsler bør sjekkes hver for seg.

• WP-Cron. WordPress-dokumentasjonen forklarer at WP-Cron kjøres når noen besøker nettstedet, ikke som en fast prosess. Forsinkede, tunge oppgaver (sikkerhetskopier, import, utsendelse) kan derfor belaste en vanlig besøkendes forespørsel. Å flytte kallene til webhotellets system-cron avlaster fronten.
• admin-ajax.php. Plugins sender forespørsler hit fra administrasjonspanelet og fra fronten. Hvis 504 vises akkurat her, let etter en plugin som gjør en tung operasjon i bakgrunnen.
• Eksterne API-er. En plugin som venter på et tregt eksternt system (betaling, ERP, utsendelse) holder en worker så lenge systemet bruker på å svare. Uten en egen, kort timeout i den pluginen blir andres driftsstans til ditt 504.

#Hva er forskjellen på 504, 502 og 524

• 502 Bad Gateway: serveren bak proxyen svarte, men svaret var ugyldig. Ofte en krasjet PHP-FPM-prosess.
• 504 Gateway Timeout: ikke noe svar i tide. Oftest overbelastning eller en treg forespørsel.
• 524: en Cloudflare-kode. Cloudflare-dokumentasjonen oppgir at den vises når opprinnelsesserveren ikke svarer innen standardgrensen på 125 sekunder. Cloudflare anbefaler å be webhotellet sjekke lange prosesser og overbelastning, og å flytte store operasjoner over på en kanal uten proxy.

Bak et CDN kan du derfor se to ulike koder for samme årsak, avhengig av hvilket ledd som mistet tålmodigheten først.

#Når bør du øke timeouten, og når ikke

Å øke fastcgi_read_timeout eller PHP-tidsgrensen er begrunnet for én bevisst lang operasjon, for eksempel en manuell import. For et nettsted som viser 504 til besøkende er det en tilsløring: den trege forespørselen opptar fortsatt en worker, bare lenger, og poolen fylles raskere.

PHP-FPM har en egen sikring, request_terminate_timeout. Dokumentasjonen beskriver den som en grense der prosessen som behandler forespørselen blir drept, og oppgir standardverdien 0, altså avslått. Når den er satt fornuftig, beskytter den poolen mot ett enkelt hengende skript.

Oppdatering 27. oktober 2026. Lange jobber i wp-admin, som en sikkerhetskopi eller en databaseeksport, er en klassisk årsak til 504 på delt webhotell. Der kan du som regel ikke endre grensen i proxyen, og proxyen avbryter forespørselen før PHP er ferdig, uansett hva max_execution_time sier. Løsningen er å dele jobben opp i korte forespørsler som kan fortsette der de slapp. Vår plugin Migrator viser mønsteret. Fra versjon 1.6.0 eksporterer en sikkerhetskopi startet fra wp-admin databasen i trinn, en porsjon rader per forespørsel, slik at også en stor database blir eksportert uten 504 Gateway Timeout på delt webhotell. Et avbrutt trinn fortsetter der det forrige stoppet, og filteret migrator_step_seconds bestemmer hvor lenge ett trinn får jobbe, for webhoteller der proxyen kutter forespørsler tidlig. Hvis eksport eller import i en plugin stopper med 504 på omtrent samme sted hver gang, se etter en modus som jobber i porsjoner og kan gjenopptas, eller etter WP-CLI-kommandoer (Migrator har wp migrator-kommandoer fra versjon 1.5.0). Høyere PHP-grenser hjelper ikke, fordi proxyen ikke bryr seg om dem.

#Hvilke nginx-timeouter ender i 504

FastCGI-modulen i nginx har tre separate tidsgrenser, og ifølge dokumentasjonen for ngx_http_fastcgi_module er hver av dem 60 sekunder som standard.

De to siste tidsgrensene nullstilles for hver bit med data. Et skript som sender noe innimellom, kan derfor kjøre lenger enn ett minutt uten feil. Et skript som er stille fordi det venter på databasen eller et eksternt API, får 504 etter 60 sekunder. fastcgi_send_timeout betyr mest ved store POST-forespørsler, for eksempel filopplasting eller import.

Når nginx står foran Apache og ikke rett foran PHP-FPM, er det proxy_read_timeout fra modulen ngx_http_proxy_module som gjelder. Den er også 60 sekunder og måler også pausen mellom lesinger, ikke hele svaret.

Alle disse direktivene gjelder i kontekstene http, server og location. Du kan altså heve grensen bare for den ene stien som trenger det, i stedet for hele serveren:

location = /wp-admin/admin-ajax.php {
    # høyere grense bare her, resten av serveren blir på 60 s
    fastcgi_read_timeout 120s;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Stien til PHP-FPM-socketen varierer mellom distribusjoner og webhotell, så kopier den fra den eksisterende konfigurasjonen din og ikke fra eksempelet.

#Timeout i Apache med PHP-FPM og mod_proxy_fcgi

Apache sender PHP videre til PHP-FPM via mod_proxy_fcgi, som regel med SetHandler "proxy:unix:/sti/til/socket.sock|fcgi://localhost/". Ventetiden styres her av tre innstillinger som arver standardverdien fra hverandre:

• Timeout fra Apache-kjernen, 60 sekunder som standard. Apache-dokumentasjonen oppgir at dette er standardverdien i mod_proxy når ProxyTimeout ikke er satt.
• ProxyTimeout fra mod_proxy, som standard lik Timeout. Dokumentasjonen beskriver den som en måte å returnere en timeout på når en applikasjonsserver henger, i stedet for å vente så lenge det tar.
• parameteren timeout på ProxyPass eller i en worker-definisjon, som standard lik ProxyTimeout. Den angir hvor mange sekunder Apache venter på data til eller fra backend.

Alle tre har konteksten server config og virtual host, så de virker ikke i .htaccess. På delt webhotell kan bare serveradministratoren endre dem.

#Hvorfor max_execution_time ikke beskytter mot 504

max_execution_time i PHP er 30 sekunder som standard, altså mindre enn de 60 sekundene i nginx. Det ser ut som om PHP alltid stopper et skript før proxyen gir 504. Slik er det ikke. PHP-dokumentasjonen sier at systemkall og strømoperasjoner ikke påvirker grensen på andre systemer enn Windows, og siden om set_time_limit() legger til at tid brukt på databasespørringer heller ikke telles.

I praksis når en WordPress-forespørsel som venter 70 sekunder på en låst MySQL-tabell eller på en betalingsløsning, aldri PHP-grensen. Workeren er opptatt, og nginx gir 504 etter 60 sekunder uten data. Unntaket er PHP bygget med --enable-zend-max-execution-timers (standard for ZTS-bygg fra PHP 8.3.0), der grensen måler medgått tid, inkludert venting på inn- og utdata.

Derfor er det tidsgrensen på selve tilkoblingen som teller ved eksterne API-er. HTTP-funksjonene i WordPress (WP_Http::request) har en standard timeout på 5 sekunder, som kan endres med filteret http_request_timeout. En plugin som hever verdien til ett minutt, fjerner sikringen, og det er den pluginen som gjør et tregt API om til 504.

Tallene gir en rekkefølge som gjør diagnosen enklere: hver indre grense kortere enn den ytre. HTTP-timeouten i pluginen (5 s) under PHP-grensen (30 s), den under fastcgi_read_timeout (60 s), og den under de 125 sekundene hos Cloudflare. Slår den indre grensen til først, havner feilen i debug.log med navnet på funksjonen som ventet. Slår den ytre til først, får du bare en generell 504-side uten spor i WordPress-loggene.

#Hvordan lese statussiden til PHP-FPM

Det raskeste beviset på om en 504 kommer fra en kø eller fra én treg forespørsel, er statussiden til PHP-FPM. Den slås på med pm.status_path i poolkonfigurasjonen, som ikke er satt som standard. PHP-dokumentasjonen advarer om at siden viser adressene til forespørsler og informasjon om ressursene, så den bør begrenses til interne forespørsler eller kjente IP-adresser. Parameteren ?json gir JSON, og ?full legger til detaljer for hver prosess.

Under en feil er avlesningen enkel. En kø over null og ingen ledige prosesser betyr full pool: for få workere eller trege forespørsler som holder dem. Tom kø og ledige prosesser samtidig med 504 betyr at tiden går tapt i selve forespørselen, altså i databasen, cachen eller et eksternt API. Øvre grense for køen settes av listen.backlog, som er 511 på Linux som standard ifølge FPM-konfigurasjonsreferansen.

#Hvordan utbedrer du 504 trinn for trinn

1. Avgrens feilen: hele nettstedet, én adresse eller bare wp-admin.
2. Les server- og PHP-FPM-loggene fra tidspunktet for feilen.
3. Slå på debug.log og gjenskap feilen.
4. Slå av pluginene (via WP-CLI eller ved å gi katalogen nytt navn), og slå dem på igjen én og én mens du måler responstiden.
5. Hvis object-cache.php finnes, slå den av som test.
6. Sjekk de autoloadede alternativene og forsinkede WP-Cron-oppgaver.
7. Vurder først til slutt å øke poolen eller timeoutene, sammen med webhotellets administrator.

Hvis 504 dukket opp rett etter en oppdatering, ta også en titt på veiledningen om gjenoppretting av WordPress etter en mislykket oppdatering.

#Når er dette en jobb for en spesialist

Når loggene peker mot PHP-FPM-poolen, men webhotellet ikke gir tilgang til konfigurasjonen. Når 504 kommer tilbake etter hver utbedring. Når nettbutikken mister bestillinger mens feilen varer. Ved en gjennomgang som skal skille kostnaden for webhotellet fra kostnaden for koden, hjelper optimalisering av ytelsen på WordPress-nettstedet. Når nettstedet ligger nede nå og årsaken er ukjent, er WordPress-reparasjon og teknisk support redningen.