Så här åtgärdar du 504 Gateway Timeout-felet på din webbplats

504 Gateway Timeout-felet är ett av de vanligaste HTTP 5xx-felen som webbplatsägare och webbplatsbesökare möter. För många bloggar och e-handelsplattformar är det viktigt att veta hur man fixar ett serverfel som detta. Annars finns det en risk för att ens hårt förvärvade besökare lockas till konkurrentwebbplatser.

504 Gateway Timeout-felet berättar inte varför det har inträffat, och det är därför svårt att fastställa vad som orsakar serverns timeout. Den här artikeln hjälper dig att förstå detta fel i detalj, lära dig hur du diagnostiserar dess orsak och slutligen hur du fixar det.

Efter att du har provat alla olika lösningar som nämns i inlägget bör din webbplats vara igång på nolltid.

Låter det intressant? Vi kör igång!

Kolla in vår videoguide om hur du åtgärdar 504 Gateway Timeout-felet på din webbplats

Enklare uttryckt uppstår det här felet när två servrar är involverade i bearbetningen av en begäran. Den första servern (vanligtvis huvudservern) tar timeout i väntan på ett svar från den andra servern (uppströmsservern).

Felkod	504 Gateway Timeout Fel
Typ av fel	Server-sidan
Felvariationer	504 Gateway Time-out 504 Gateway Timeout NGINX NGINX 504 Gateway Timeout Gateway Timeout-fel Fel 504 HTTP-fel 504 HTTP-fel 504 — Gateway Timeout HTTP 504 504 fel Gateway Timeout (504)
Orsaker till fel	Serveranslutningsproblem Problem med nätverksanslutning DNS-problem Brandväggs-problem

Så här fungerar processen: varje gång som du besöker en webbplats i din webbläsare så skickar webbläsaren en begäran till webbservern där webbplatsen hostas. Servern bearbetar din begäran och svarar med de begärda resurserna.

Serversvaret inkluderar en av många HTTP-statuskoder för att ange svarets status för webbläsaren. Men alla dessa HTTP-statuskoder är inte felmeddelanden. En 200 OK-statuskod innebär exempelvis att servern har bearbetat din begäran framgångsrikt och att ”Allt är OK”.

5xx-klassen av HTTP-statuskoder anger att något är fel med servern, att servern är medveten om detta och inte kan utföra klientbegärandet. Som ett resultat kallas de även serverfel 5xx-statuskoder.

Officiellt anges fem statuskoder under klassen 5xx (500,  501,  502,  503 och 504). Du kan även stöta på många inofficiella koder (506, 507, 509,  520, osv.).

504 Gateway Timeout-felet manifesterar sig i olika former. Här är några sätt som det vanligtvis dyker upp på:

504 Gateway Timeout-felet liknar 502 Bad Gateway-felet, vilket indikerar att den första servern fick ett ogiltigt svar från den andra servern (uppströmsservern).

Varianter av 504 Gateway Timeout-felet

Webbläsaren visar alla 504 Gateway Timeout-fel som finns inuti den, precis som alla andra fel. Eftersom det finns olika operativsystem, webbservrar, webbläsare och användaragenter kan det dyka upp på flera sätt.

Nedan finns några vanliga 504-felmeddelandevariationer som du kan stöta på:

• 504 Gateway Timeout
• 504 Gateway Timeout NGINX
• NGINX 504 Gateway Timeout
• Gateway Timeout Fel
• Fel 504
• HTTP Fel 504
• HTTP Fel 504 — Gateway Timeout
• HTTP 504
• 504 Fel
• Gateway Timeout (504)
• This page isn’t working — Domain took to long to respond
• 504 Gateway Time-out — The server didn’t respond in time
• The page request was canceled because it took too long to complete
• Site visitors: There was an issue serving your request, please try again in a few minutes.
• Site Owners: There was a gateway timeout. You should visit your error log for more information.
• En tom vit skärm

Alla ovanstående felsvar, även om de är formulerade annorlunda, uppstår av samma 504 Gateway Timeout-serverfel.

Webbservrar och webbplatser kan anpassa hur de visar 504 Gateway Timeout-felet för användare. Några av sätten är ganska coola! Det är en utmärkt taktik för att dämpa sina besökares besvikelse.

Vad är orsakerna till 504 Gateway Timeout-felet?

Eftersom 504-felet beror på en timeout mellan servrar har problemet förmodligen inte att göra med klientens enhet eller internetanslutning. Detsamma gäller även för din enhet och anslutning.

Ett 504 Gateway Timeout-fel är en indikation på att webbservern väntar för länge med att svara på en annan server och ”tar timeout”. Det kan finnas många orsaker till den här timeouten: den andra servern kanske inte fungerar korrekt, är överbelastad eller ligger nere.

Den andra servern behöver inte alltid vara extern (t.ex. CDN, API-gateway). Det kan även vara en serverliknande entitet inom huvudwebbservern (exempelvis omvänd proxy-server, databasserver).

SEO-effekten av 504 Gateway Timeout-felet

Alla 5xx-fel hindrar en webbsida från att laddas, vilket gör dem skadliga för användarupplevelsen. Därför tar sökmotorer som Google dessa fel på allvar. Om felet kvarstår under en längre tid kan det till och med leda till att webbsidan avindexeras från sökmotorresultaten.

När Google’s spindlar exempelvis snubblar över felet 503 Tjänst Otillgänglig, kommer de att förstå att det är ett tillfälligt problem eftersom det oftast används för att aktivera webbplatsunderhållsläge. De kommer således att försöka genomsöka sidan igen senare.

Ett 504 Gateway Timeout-fel är inte nödvändigtvis tillfälligt eftersom det kan bero på flera saker. Om din webbplats ligger nere i endast några minuter, och om spindlarna försöker genomsöka den flera gånger varje minut, försöker de betjäna sidan från cachen.  De skulle med andra ord inte ens märka det.

Men om din webbplats ligger nere i 6+ timmar eller mer, kommer Google att betrakta 504-felet som ett allvarligt problem som du behöver åtgärda så snart som möjligt. Detta kan påverka din SEO negativt.

Google Search Console är ett av de bästa SEO-verktygen för att övervaka webbplatsens HTTP 5xx-fel.

Så här åtgärdar du 504 Gateway Timeout-felet?

Utan att veta exakta detaljer om webbplatsen, exempelvis dess serverkonfiguration, hosting-plan, plugins från tredje part och trafiken den lockar, kan det vara frustrerande och överväldigande att försöka fixa ett 504 Gateway Timeout-fel.

Eftersom många variabler är inblandade rekommenderar jag att du börjar med att lösa problem på klientsidan, som är ganska sällsynta. Efter detta kan du fixa problem på serversidan. Det är vanligtvis där den skyldige finns i form av något 504-fel.

1. Prova att läsa in webbsidan igen

En av de första sakerna som du kan prova när du stöter på ett 504 Gateway Timeout-fel är att vänta några minuter och försöka ladda om sidan.

Du kan trycka på kortkommandot F5 för att uppdatera/ladda om webbsidan i de flesta webbläsare. Om du vill ta bort sidans webbläsarcache innan du laddar om kan du istället trycka genvägskombinationen ctrl+F5.

När du håller på kan du även försöka ladda webbplatsen i en annan webbläsare för att utesluta att detta är problemet. Eftersom de flesta 504-fel beror på tillfälligt överbelastade servrar bör den här lösningen få din webbplats att komma tillbaka.

Om det inte fungerar att vänta och ladda om webbplatsen kan du kontrollera om en webbplats ligger nere för alla eller bara för dig. Två användbara onlineverktyg för att testa en webbplats för stilleståndstid är Down for Everyone or Just Me och Is It Down Right Now?

2. Starta om nätverksenheterna

Ibland kan problem med nätverksenheter som modem eller routrar leda till ett 504 Gateway Timeout-fel. Om du startar om dessa enheter kan problemet lösa sig.

Även om du kan stänga av alla dessa nätverksenheter i valfri ordning, är det viktigt att du slår på dem i rätt ordning. Aktivera vanligtvis dessa enheter utifrån och in, och följ anslutningsordningen från Internet-leverantören till din huvudklientenhet.

3. Kontrollera proxyinställningarna

En proxyserver sitter mellan enheten och internet. Den används främst för att förbättra integriteten online genom att dölja privat information (t.ex. enhetsplats) från webbplatser och webbservrar (t.ex. med hjälp av ett VPN).

Även om det är sällsynt att proxyservrar orsakar ett 504-fel, kan felaktiga proxyserverinställningar ibland vara orsaken. Du kan inaktivera proxyservern och försöka läsa in webbsidan igen för att se om detta åtgärdar felet.

De flesta klienter använder inte en proxytjänst, så du kan hoppa över det här steget om du är säker på att du inte använder någon proxyserver. Men du kanske har ställt in detta utan att du ens vet om det. Jag föreslår att du kontrollerar enhetens och webbläsarens proxyinställningar för att utesluta detta.

4. Kontrollera om det finns DNS-problem

Ett 504 Gateway Timeout-fel kan även orsakas av DNS-problem på serversidan eller klientsidan (eller båda).

Den mest sannolika orsaken till ett DNS-problem på serversidan är att FQDN (fullständigt kvalificerat domännamn) inte kan besluta sig för rätt IP-adress eller att DNS-servern inte svarar. Vanligtvis inträffar detta när du just har migrerat din webbplats till en ny server eller host. Det är därför viktigt att vänta på att domänens DNS-poster ska spridas fullt ut, vilket kan ta upp till 24 timmar.

Du kan använda kostnadsfria verktyg som whatsmydns.net DNS Checker eller DNSMap för att se om ditt DNS har spridit sig över hela världen.

Om du vill åtgärda DNS-problem på klientsidan kan du försöka rensa den lokala DNS-cachen. Det är som att rensa webbläsarens cacheminne, med den skillnaden att du istället rensar DNS-cachen från operativsystemet.

Om du använder Windows kan du rensa DNS-cacheminnet genom att öppna Kommandotolken och ange följande direktiv:

ipconfig /flushdns

Du bör se meddelandet “Successfully flushed the DNS resolver Cache.” om detta fungerade.

För de senaste macOS-versionerna kan du öppna Terminal och köra följande kommando:

sudo killall -HUP mDNSResponder

Du kommer inte att se någon avisering i macOS när processen är klar, men du kan ändra detta genom att bifoga ditt anpassade meddelande till kommandot.

sudo killall -HUP mDNSResponder; DNS Cache was cleared successfully

Om du använder äldre macOS-versioner varierar det kommando som du behöver ange beroende på vilken version av macOS du kör. För mer information kan du läsa macOS-avsnittet i Kinstas djupgående handledning om att rensa DNS.

Om du använder Linux-operativsystemet är processen ganska lik macOS eftersom även Linux använder Terminal som kommandoradsgränssnitt. Eftersom det finns många Linux-distributioner kan det exakta kommandot som du behöver ange variera. Du kan kolla in Kinstas guide för mer information.

Slutligen kan du tillfälligt ändra DNS-servrar på klientsidan. Som standard blir du automatiskt tilldelad DNS-servrar av internet-leverantören. Men du kan tillfälligt ändra dessa till offentliga DNS-IPs.

Några pålitliga DNS-servrar som du kan prova är Google Public DNS, Cloudflare 1.1.1.1, Quad9 DNS och Cisco OpenDNS.

5. Inaktivera tillfälligt webbplatsens CDN

Ibland kan problemet även ligga hos ditt innehållsleveransnätverk (CDN). Om en webbplats ursprungsserver inte kan nås kommer de flesta CDN att försöka visa hela webbsidan från cacheminnet.

Men de flesta CDN aktiverar inte den här funktionen som standard eftersom det är komplext att cachelagra dynamiska tillgångar på de flesta webbplatser (exempelvis WordPress-administratörens instrumentpanel).

Ett enkelt sätt att felsöka detta är att tillfälligt inaktivera CDNet. Om du exempelvis använder det kostnadsfria WordPress-pluginet CDN Enabler för att länka dina webbplatstillgångar till CDN-webbadresserna kan du inaktivera plugin-programmet och testa att ladda om din webbplats.

Detsamma gäller för andra plugins som du kan använda för att ansluta till ditt CDN (t.ex. WP Rocket, Breeze, W3 Total Cache).

Om du inte kan komma åt webbplatsens administratörspanel kan du inaktivera pluginet via SFTP genom att byta namn på pluginets mappnamn.

CDNs som Cloudflare eller Sucuri, som tillhandahåller fullständiga proxytjänster, har extra brandväggar mellan sina edge-servrar och din ursprungsserver. Du kan därför stöta på HTTP 5xx-fel oftare när du använder dem. De flesta av dem cachelagrar 5xx-fel som returneras av din ursprungsserver, så det är enkelt att felsöka dem.

På Cloudflares kostnadsfria plan är risken stor att man möter ett 5xx-fel. Eftersom det är en fullständig proxytjänst, finns det inget snabbt sätt att inaktivera detta. Men innan du blir arg på cloudflare, bör du känna till att Cloudflare visar två varianter av 504 Gateway Timeout-felet.

504 Gateway Timeout-felet hos Cloudflare (variation 1)

Cloudflare visar dig en anpassad 504 Gateway Timeout-felskärm när webbplatsens ursprungsserver ger ett standard HTTP 504-svar.

Här ligger problemet hos din webbserver och inte hos Cloudflare. Du kan försöka fixa det med de andra lösningarna som nämns nedan eller kontakta din hosting-leverantörs support för teknisk hjälp.

504 Gateway Timeout hos Cloudflare (variation 2)

Om Cloudflare orsakar 504 Gateway Timeout-felet skriver felskärmen ut ”cloudflare”, som för närvarande är standardservernamnet för alla Cloudflare-tillgångar. Felskärmen visas vanligtvis så här:

Eftersom Cloudflare inte svarar ser du ingen Cloudflare-märkt felskärm här.

Tekniker på Cloudflare är troligtvis medvetna om problemet och arbetar redan på en lösning. Du kan bekräfta detta genom att kontrollera webbsidan Cloudflare System Status. Alternativt, kan du även höra av dig till Cloudflare’s support för en snabbare lösning.

504 Gateway Timeout hos Cloudflare på grund av stora uppladdningar

Även Storleken på dina uppladdningar till din webbplats kan vara en anledning till serverns timeout. Cloudflare begränsar uppladdningsfilens storlek (per HTTP POST-begäran) till endast 100 MB på både kostnadsfria- och Pro-planer.

Problemet kan ligga hos din host eller hos Cloudflare. Du kan ta reda på den exakta orsaken genom att kringgå Cloudflare med din DNS hosts-fil och prova din uppladdning igen.

Om du använder Cloudflare med WordPress rekommenderar jag att du använder deras kostnadsfria plugin och utesluter kritiska webbadresser från cachelagring (exempelvis WordPress-administratörens instrumentpanel). Du kan hänvisa till Kinsta’s detaljerade inlägg om hur du konfigurerar Cloudflare-inställningar för WordPress.

Föreslagen läsning: Hur man ställer in Cloudflare APO för WordPress.

6. Kontrollera serverproblem med din host

Serverproblem är en av de vanligaste orsakerna till att du ställs inför ett 504 Gateway Timeout-fel. Eftersom de flesta WordPress-webbplatser ligger på Nginx– eller Apache-webbservrar väntar Nginx eller Apache på ett svar från något och tar timeout.

Många kunder kommer till Kinsta för att de möter det här problemet hos andra hostar. Konversationen går ungefär så här:

Vi får cirka 100 000 besökare per månad med mer än 200 000 visningar. För närvarande hostas vi hos ____ och vi upplever ständigt 504-fel på grund av serveröverbelastning. Jag gillar inte hur ____ har hanterat problemet, och vi fick även veta att vi snart måste gå vidare till deras dedikerade planer, vilket jag inte tror är nödvändigt.

Webbplatser med hög trafik och e-handel är mer benägna att få 504-fel på grund av serveröverbelastning eftersom de genererar många icke-cachelagringsbara begäranden. Det här problemet kan dock drabba alla webbplatser, inklusive enkla bloggar. Många hostar kommer att be dig att uppgradera till en plan på hög nivå för att lösa problemet, något som i de flesta fall är onödigt.

Kinsta använder LXD-hanterade hostar och arrangerade LXC-programvarucontainers för varje webbplats. Varje webbplats är med andra ord inrymd i sin egen isolerade container med tillgång till all programvara som krävs för att köra den (Linux, Nginx, PHP,  MySQL). Resurserna är 100% privata och delas inte med någon annan webbplats, inte ens dina egna.

De flesta hostar som tillhandahåller delade hosting-planer har inte den här funktionen. Av den anledningen kan en webbplats med hög trafik som finns på samma server som din göra att även din webbplats möter ett 504-fel.

Förutom att vi isolerar varje webbplats i sin container har Kinsta även utformat sin infrastruktur för att enkelt hantera tusentals samtidiga anslutningar. Kinsta hostar till och med MySQL-databaserna på localhost, inte en fjärrserver. Detta innebär att man slipper latens mellan datorer, vilket resulterar i snabbare sökfrågor och mindre risk för timeout.

Många kunder som migrerar till Kinsta ser enorma minskningar av totala laddningstider.

En överbelastad server är inte den enda orsaken till en servers timeout. Det kan finnas många andra orsaker till 504-felet:

Långsam serverinfrastruktur

Servern som du använder för att hosta din webbplats kanske inte har tillräckligt med resurser för att hantera belastningen. Det är som att spela ett modernt, grafikintensivt videospel på en tio år gammal dator.

Servern lägger helt enkelt på när den försöker betjäna webbplatsen. Den enda lösningen på det här problemet är att uppgradera till en server med bättre infrastruktur. Av denna anledning kommer även Kinstas mest grundläggande hosting-plan att kunna hantera en statisk webbplats med medeltrafik.

Det behövs fler PHP-bearbetare

PHP-bearbetare används för att köra koden för din webbplats. En e-handelswebbplats som får 50 000 besökare per månad behöver mycket mer resurser än en enkel blogg med samma mängd trafik. Om alla PHP-bearbetare på servern är upptagna skapas en kö.

När kön blir för lång ignorerar servern gamla begäranden, vilket kan leda till att servern kastar upp ett 504-gatewayfel. Du kan be din host om att öka antalet PHP-bearbetare. Detta gör att webbplatsen kan köra flera begäranden samtidigt.

Problem med brandväggen

Serverns brandvägg kan ha en del fel eller en felaktig konfiguration. Några av dess regler hindrar kanske servern från att upprätta en ordentlig anslutning. Om du vill veta om brandväggen är den skyldige kan du kontrollera serverns felloggar.

Problem med nätverksanslutningen

Anslutningsproblem mellan proxyservern och webbservern kan orsaka förseningar för svar på HTTP-begäranden. Det kan även uppstå problem med nätverksanslutningen om du använder en belastningsutjämnare.

HTTP-timeout

HTTP-timeout kan uppstå när en anslutning mellan webbservern och klienten hålls öppen för länge. Detta sker vanligtvis för WordPress-webbplatser när du kör WordPress-importer. Ett sätt att lösa problemet är att byta till en snabbare internetanslutning.

Du kan även använda ett verktyg med stöd för WP-CLI  för att köra skripten direkt på servern och helt kringgå HTTP-anslutningen. Du kan exempelvis använda wp-import WP-CLI-kommandot för att köra WordPress Importer-pluginet direkt via kommandoradsgränssnittet.

Viktigt: 504 Gateway Timeout-felet liknar 503 Service Unavailable-felet eller 502 Bad Gateway-felet. De är dock väldigt olika. Om du möter ett 504-fel på Kinsta ska du höra av dig till supporten för att omedelbart åtgärda problemet.

För att övervaka webbplatsens stilleståndstid på egen hand kan du använda ett verktyg som exempelvis updown.io. Det kontrollerar regelbundet webbplatsens status (eller varje webbadress) genom att skicka en HTTP-begäran till den. Du kan ställa in kontrollfrekvensen på allt ifrån 15 sekunder till 1 timme. Om din webbplats inte svarar korrekt kommer verktyget att meddela dig med ett e-postmeddelande eller ett SMS.

Du får en generös mängd kostnadsfria krediter för varje konto på updown.io, men om du letar efter billigare alternativ kan du kolla in WebGazer eller UptimeRobot. Båda dessa verktyg hjälper dig att övervaka webbplatsens upptid var 5: e minut kostnadsfritt. Det duger fint för de flesta webbplatsägarna.

Övervakning av din webbplats ger dig en uppfattning om hur ofta den ligger nere. Detta är särskilt användbart om du använder en delad hosting-leverantör. De flesta hostar för applikationer, databaser och hanterad WordPress-hosting (som Kinsta) tar hand om detta åt dig automatiskt. Det rekommenderas därför alltid att du väljer en sådan host.

För en detaljerad förklaring, kan du kolla in Kinsta’s inlägg om vikten av hanterad WordPress-hosting.

7. Sök efter spam, bottar eller DDoS-attacker

Illvilliga angripare kan sakta ner webbservern genom att skicka för många och/eller för resurskrävande begäranden. Om din webbplats blir spammad av robotar eller drabbas av en DDoS-attack kan detta överväldiga din server och resultera i 504 Gateway Timeout-fel för många hederliga användare.

Du kan titta på servertrafiken och analyserna för att se om du kan upptäcka några oregelbundna mönster i webbplatstrafiken. Om du använder Kinsta som host för din webbplats kan du enkelt se dessa data genom att gå till din MyKinsta Analytics-instrumentpanel.

Starta din undersökning genom att titta på de klient-IPs som ligger i toppen. Detta ger dig en uppfattning om vem som genererar det maximala antalet begäranden och varifrån de kommer. Om din server plötsligt använder enormt mycket bandbredd eller lockar mycket trafik, kommer den här rapporten att vara väldigt praktisk.

När du har gjort detta kan du kolla in Cacheanalys-rapporten. Här kan du se hur många begäranden som kringgår eller missar cacheminnet eller som betjänas från cachen. Av prestanda- och stabilitetsskäl bör du cachelagra så många begäranden som möjligt, men det är inte alltid möjligt att göra detta.

WooCommerce-webbplatser genererar exempelvis många oanvändbara begäranden för funktioner som kundvagnen och kassaprocessen.

Slutligen kan du använda ett säkerhetsplugin för att förbättra din webbplats säkerhet. Med ett sådant kan du upptäcka och blockera oroande trafik / IPs. Du kan även be din host om att blockera vissa IP-adresser.

Beroende på attackens längd och omfattning kan blockering av IP-adresser bli en oändlig process, eftersom många angripare ändrar sina IP-adresser och proxyadresser efter att ha blockerats.

Obs: Kinsta tillåter inte att kunder installerar säkerhetsplugin. De kan nämligen ha en väldigt dålig effekt på webbplatsens prestanda, särskilt dess skanningsfunktioner. Eftersom Kinsta använder belastningsutjämnare med Google Cloud Platform, skulle blockering av IP-adresser inte alltid fungera så effektivt.

Du kan använda dedikerade säkerhetslösningar som Cloudflare eller Sucuri för att skydda dina webbplatser från DDoS-attacker och spambots. För mer info kan du kolla in Kinsta’s artiklar om hur du installerar Cloudflare på din webbplats och hur Sucuri hjälpte till att stoppa en DDoS-attack.

8. Reparera din skadade WordPress-databas

Ibland kan ett 504 Gateway Timeout-fel bero på en skadad databas, särskilt på WordPress-webbplatser. Detta beror vanligtvis på skadade databastabeller eller filer. Detta kan även orsakas av ett allvarligt säkerhetsproblem som att din webbplats eller databas hackas.

Hur man reparerar en skadad WordPress-databas beror på problemet. Plugins som WP-DBManager gör det enkelt att diagnostisera databasproblem och reparera dem. Jag rekommenderar att du läser Kinsta’s detaljerade genomgång om reparation av WordPress-databasproblem för att komma igång.

9. Kontrollera webbplatsens plugins och teman

I de flesta fall orsakar plugins och teman från tredje part inte 504-fel. Men det finns en liten risk att de kan orsaka server-timeout, vanligtvis genom att de köar många icke-cachelagrade begäranden som genereras av pluginet / temat. Eftersom detta binder upp många av serverns PHP-bearbetare kan det uppstå ett 504-fel.

Ett bra exempel på detta problem är WooCommerce, ett plugin som installeras för att lägga till e-handelsfunktionalitet på WordPress-webbplatser.

Det enklaste sättet att felsöka det här problemet är genom att inaktivera alla dina plugins. Kom ihåg att du inte kommer att förlora några data om du endast inaktiverar ett plugin.

Om du kan komma åt din administratörspanel kan du gå till plugin-skärmen, välja Inaktivera från massåtgärdsmenyn, markera alla plugins och sedan trycka på knappen Tillämpa. Detta kommer att inaktivera alla dina plugins.

Om du inte kan komma åt ditt administratörsområde kan du inaktivera plugins via SFTP med den metod som beskrivits tidigare. Byt bara namn på huvudpluginmappens namn för att massinaktivera alla plugins.

När du har inaktiverat alla plugins ska du kontrollera om din webbplats laddas korrekt. Om den fungerar måste du aktivera varje plugin och successivt testa webbplatsen igen efter varje aktivering.

Slutligen ska du se till att dina plugins, teman och WordPress-kärnan är uppdaterade. Se även till att servern kör den rekommenderade versionen av PHP.

Om du tycker att detta känns överväldigande kan du alltid kontakta din host för hjälp. Kinsta använder Kinsta APM och andra felsökningstekniker för att hjälpa klienter att begränsa vilket plugin, vilken sökfråga eller vilket skript som kan orsaka felet.

Om felet är en ineffektiv sökfråga eller dålig kod i ett plugin / tema, kan du hyra en WordPress-utvecklare för att lösa problemet.

10. Kontrollera felloggar

Att visa felloggar kan vara till stor hjälp vid felsökning av 504-fel på din webbplats. Detta kan hjälpa dig att snabbt hitta problemen på din webbplats, särskilt om problemet är ett krävande plugin på din webbplats.

Om du är Kinsta-kund så kan du enkelt se loggade fel i MyKinsta-instrumentpanelen. Börja med att välja WordPress-webbplatser i sidofältsmenyn. Välj sedan den webbplats som du vill undersöka och välj Loggar för att öppna sidan Loggvisning.

Om din host inte har ett loggningsverktyg kan du aktivera WordPress felsökningsläge genom att lägga till följande kod i din wp-config.php-fil:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG-konstanten aktiverar eller inaktiverar WordPress felsökningsläge. Den inkluderar två andra valfria konstanter som kan utöka dess funktioner. WP_DEBUG_LOG-konstanten dirigerar alla fel som ska sparas i en debug.log-fil i /wp-content/-katalogen. Om du inte hittar den här filen kan du alltid skapa en sådan.

WP_DEBUG_DISPLAY-konstanten kontrollerar om felsökningsloggar visas på HTML-sidan. Om du ställer in detta på false döljs alla fel. Du kan dock granska felen senare, eftersom du även har definierat WP_DEBUG_LOG som true.

Viktigt: Om WP_DEBUG har aktiverats i Kinsta-miljön dirigeras alla fel till debug.log-filen och inte till error.log i MyKinsta-instrumentpanelen.

Du kan även ladda ner de råa WordPress-felloggfilerna via SFTP. Du kan vanligtvis hitta felloggar i serverns rotkatalog i en mapp med namnet ”logs”.

Kinsta-användare kan även aktivera WordPress felsökningsläge från sin MyKinsta-instrumentpanel. För att göra detta, ska du navigera till Webbplatser > Verktyg > WordPress Felsökning och klicka på knappen Aktivera. Detta gör att du kan se PHP-fel och meddelanden utan att aktivera felsökningsläget via SSH eller SFTP.

Du kan slutligen även kontrollera serverloggfilerna. Beroende på vilken server du använder som host för din WordPress-webbplats finns de ofta på dessa platser:

• Apache: /var/log/apache2/error.log/
• Nginx: /var/log/nginx/error.log/

Du kan läsa loggningsrelaterad dokumentation av Apache eller Nginx för mer information.

11. Konfigurera Apache- eller Nginx-inställningarna korrekt

Du kan redigera serverns konfigurationsfiler för att öka resursgränserna för specifika direktiv. Detta kan hjälpa dig att lösa 504 Gateway Timeout-felet.

För Apache-webbservrar

Lägg först till följande kod i httpd.conf:

TimeOut 600

Den här inställningen definierar hur länge servern väntar på vissa begäranden innan den markerar dem som ett problem med nätverkstimeout. Standardvärdet är 60 sekunder (Apache 2.4-versionen).

Du kan bara lägga till det här direktivet i filen httpd.conf, inte i .htaccess-filen. Eftersom de flesta delade hosting-leverantörerna inte tillåter dig att ändra httpd.conf-filen kan du istället försöka öka värdet på LimitRequestBody-direktivet i .htaccess-filen.

Lägg sedan till följande rad i din php.ini-fil:

max_execution_time 300

Standardvärdet för PHP’s max_execution_time-direktiv är 30 sekunder. Om du ökar detta kan webbplatsens PHP-skript köras längre.

För Nginx-webbservrar

Om du kör dina WordPress-webbplatser på Nginx + FastCGI Process Manager (PHP-FPM) eller använder Nginx som omvänd proxy för Apache kan du justera serverinställningarna för att förhindra 504 Gateway Timeout-fel.

504 Gateway Timeout-fel på Nginx + FastCGI (PHP-FPM)

Du måste först redigera PHP-FPM pool config-filen. Du hittar den på /etc/php7.4/fpm/pool.d/www.conf i din Nginx-server (den exakta sökvägen kan variera beroende på PHP-versionen). Du kan alternativt köra följande kommando i terminalen för att redigera PHP-FPM pool config-filen:

sudo nano /etc/php/7.2/fpm/pool.d/www.conf

Ange sedan följande direktiv:

request_terminate_timeout = 300

Efter detta måste du redigera din php.ini-fil. Du kan hitta den på /etc/php.ini. Öppna filen och lägg till/ändra värdet för max_execution_time till 300 sekunder.

max_execution_time = 300

Lägg slutligen till följande kod i nginx.conf-filens platsblock:

location ~ .php$ {
...
fastcgi_read_timeout 300;
}

Ladda om Nginx och PHP-FPM för att ändringarna ska träda i kraft.

sudo service nginx reload
sudo service php7.4-fpm reload

Den exakta koden för att ladda om PHP-FPM varierar beroende på vilken PHP-version som är installerad på servern. Testa din webbplats för att se om detta har åtgärdat problemet.

504 Gateway Timeout-fel på Nginx Proxy

Om du använder Nginx som omvänd proxyserver för Apache kan du göra den mer tålig mot server-timeout genom att lägga till följande direktiv i nginx.conf-filen:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

Glöm inte att ladda om Nginx efter att du har gjort dina ändringar.

sudo service nginx reload

Andra HTTP-fel som liknar 504 Gateway Timeout-felet

Som jag nämnde tidigare i artikeln liknar många andra HTTP 5xx-fel 504 Gateway Timeout-felet. Detta beror på att samtliga uppstår på serversidan. Dessa fel inkluderar:

• 500 Internal Server Error
• 501 Not Implemented Error
• 502 Bad Gateway Error
• 503 Service Unavailable Error

Andra HTTP-fel som orsakas av problem på klientsidan, som 404 Not Found-felet, liknar också 504-felet. Du kan läsa Kinsta’s detaljerade guide och lista över HTTP-statuskoder för mer information.

Sammanfattning

Din webbplats kan drabbas av 504 Gateway Timeout-felet av flera orsaker. I den här artikeln har du lärt dig hur du felsöker dem alla. Detta fel orsakas vanligtvis av problem på serversidan. Om så är fallet kan du höra av dig till din host och få en snabb lösning.

Det är dock viktigt att förstå att det här felet även kan bero på plugins från tredje part, teman, tjänster, ineffektiva databasfrågor eller en kombination av två eller flera av dessa. Om du maximerar serverns resurser (t.ex.PHP-bearbetare) rekommenderar vi att du optimerar webbplatsen för prestanda.

Om du ändå upptäcker att din webbplats tar timeout, kan det krävas att du uppgraderar din hosting-plan eller antalet PHP-bearbetare. Jag rekommenderar dock att du överväger det här alternativet först efter att du har prövat alla andra lösningar som beskrivs i den här artikeln.

Vi klarar allt från enkla statiska webbplatser till komplexa e-handels– och medlemswebbplatser. Kinstas skalbara hosting-planer är utformade för att rymma alla typer av webbplatser. För att lära dig mer om vårt skalbara moln-hosting, kolla in den här artikeln om de viktigaste sakerna som du bör känna till om Kinsta!

Har vi missat något? Om du fortfarande har svårt att lösa 504 Gateway Timeout-felet på din webbplats kan du lämna en kommentar nedan.