Sådan løses 504 Gateway Timeout-fejlen på dit websted

504 Gateway Timeout-fejlen er en af ​​de mest almindelige HTTP 5xx-fejl, som webstedsejere og besøgende på webstedet står over for. For mange blogs og e-handelsplatforme er det afgørende at vide, hvordan man retter en serverfejl som denne, for at holde deres hårdt tjente besøgende fra at hoppe til konkurrerende websteder.

Da 504 Gateway Timeout-fejlen ikke fortæller dig, hvorfor den opstod, er det svært at finde ud af, hvad der forårsager server-timeout. Denne artikel hjælper dig med at forstå det detaljeret, lære at diagnosticere årsagen og derefter rette det.

Efter at have prøvet alle de forskellige løsninger, der er nævnt i indlægget, vil dit websted være i gang på ingen tid.

Lyder det interessant? Så lad os dykke ind!

Se vores videoguide til at rette 504 Gateway Timeout-fejlen på dit websted

For at forenkle det yderligere opstår denne fejl, når to servere er involveret i behandlingen af ​​en anmodning. Den første server (typisk hovedserveren) timeout og venter på svar fra den anden server (upstream-server).

Fejlkode	504 Gateway Timeout Error
Fejltype	Server-side
Fejlvariationer	504 Gateway Timeout504 Gateway Timeout NGINX NGINX 504 Gateway Timeout Gateway Timeout Error Error 504 HTTP Error 504 HTTP Error 504 — Gateway Timeout HTTP 504 504 Error Gateway Timeout (504)
Fejlårsager	Problemer med serverforbindelse Netværksforbindelsesproblemer DNS problemer Firewall problemer

Sådan fungerer processen: Hver gang du besøger et websted i din browser, sender browseren en anmodning til den webserver, hvor webstedet er hostet. Serveren behandler anmodningen og svarer med de ønskede ressourcer.

Serversvaret inkluderer en af ​​mange HTTP-statuskoder for at angive svarets status til browseren. Men ikke alle disse HTTP-statuskoder er fejl. For eksempel betyder en 200 OK-statuskode, at serveren behandlede anmodningen med succes og “Alt er OK.”

5xx-klassen af ​​HTTP-statuskoder indikerer, at der er noget galt med serveren, serveren er opmærksom på det, og den kan ikke udføre klientanmodningen. Som et resultat kaldes de også statuskoder for serverfejl 5xx.

Officielt er fem statuskoder specificeret under 5xx-klassen (500, 501, 502, 503, 504). Du kan også komme over mange uofficielle koder (506, 507, 509, 520 osv.).

504 Gateway Timeout-fejl manifesterer sig i forskellige former. Her er nogle måder, det normalt vises på:

504 Gateway Timeout-fejlen svarer til 502 Bad Gateway-fejlen, hvilket indikerer, at den første server modtog et ugyldigt svar fra den anden server (upstream-server).

Variationer af 504 Gateway Timeout-fejl

Browseren viser enhver 504 Gateway Timeout-fejl inde i den, ligesom enhver anden fejl. Da der er forskellige operativsystemer, webservere, browsere og brugeragenter, kan det vises på flere måder.

Nedenfor er et par almindelige 504-fejlmeddelelsesvarianter, som du kan støde på:

• 504 Gateway timeout
• 504 Gateway Timeout NGINX
• NGINX 504 Gateway-timeout
• Gateway timeout-fejl
• Fejl 504
• HTTP-fejl 504
• HTTP-fejl 504 – Gateway-timeout
• HTTP 504
• 504 Fejl
• Gateway timeout (504)
• Denne side fungerer ikke – Domænet tog for lang tid til at svare
• 504 Gateway-timeout – Serveren reagerede ikke i tide
• Sideanmodningen blev annulleret, fordi det tog for lang tid at fuldføre
• Besøgende på webstedet: Der var et problem med at betjene din anmodning, prøv venligst igen om et par minutter.
• Webstedsejere: Der var en gateway-timeout. Du bør besøge din fejllog for mere information.
• En blank hvid skærm

Alle ovenstående fejlresponser, selv om de er formuleret forskelligt, peger på den samme 504 Gateway Timeout-serverfejl.

Webservere og websteder kan tilpasse, hvordan de viser 504 Gateway Timeout-fejlen til brugerne. Nogle af dem kan være ret cool! Det er en fremragende taktik til at dæmpe deres besøgendes skuffelse.

Hvad er årsagerne til 504 Gateway Timeout-fejlen?

Da 504-fejlen skyldes en timeout mellem servere, er problemet sandsynligvis ikke med klientens enhed eller internetforbindelse. Det inkluderer også din enhed og forbindelse.

En 504 Gateway Timeout-fejl angiver, at webserveren venter for længe på at svare fra en anden server og laver “timing out”. Der kan være mange grunde til denne timeout: den anden server fungerer ikke korrekt, overbelastet eller nede.

Den anden server behøver ikke altid være ekstern (f.eks. CDN, API-gateway). Det kan også være en serverlignende enhed inden for den primære webserver (f.eks. Reverse proxyserver, databaseserver).

SEO-virkning af 504 Gateway Timeout-fejl

Alle 5xx-fejl forhindrer en webside i at indlæses, hvilket gør dem skadelige for brugeroplevelsen. Derfor tager søgemaskiner som Google disse fejl alvorligt. Hvis fejlen vedvarer i lang tid, kan det endda føre til af-indeksering af websiden fra søgemaskinens resultater.

For eksempel, når Google-edderkopper snubler over en 503-service, der ikke er tilgængelig, vil de forstå, at det er et midlertidigt problem, da det for det meste bruges til at aktivere tilstand til vedligeholdelse af websteder. De prøver således at gennemgå siden igen senere.

En 504 Gateway Timeout-fejl er ikke nødvendigvis midlertidig, da den kan skyldes flere årsager. Hvis dit websted er nede i et par minutter, og hvis edderkopper forsøger at gennemgå det flere gange hvert minut, vil de forsøge at betjene siden fra deres cache. De ville ikke engang bemærke det.

Men hvis dit websted er nede i mere end 6 timer, vil Google betragte 504-fejlen som et alvorligt problem, der dækker hele websitet, som du skal rette så hurtigt som muligt. Dette kan påvirke din SEO negativt..

Google Search Console er et af de bedste SEO-værktøjer til at overvåge dit websteds HTTP 5xx-fejl.

Sådan rettes 504 Gateway Timeout-fejlen?

Uden at kende nøjagtige detaljer om webstedet, såsom dets serverkonfiguration, hostingplan, tredjeparts plugins og den trafik, det tiltrækker, kan du finde det frustrerende og overvældende at rette en 504 Gateway Timeout-fejl.

Da mange variabler er involveret, anbefaler jeg, at du starter med at rette problemer på klientsiden, som er ret sjældne, og derefter gå i retning af at løse problemer på serversiden. De er normalt synderne ved en 504 fejl.

1. Prøv at genindlæse websiden

En af de første ting, du kan prøve, når du støder på en 504 Gateway Timeout-fejl, er at vente et par minutter og prøve at genindlæse siden.

Du kan trykke på F5 for at opdatere/genindlæse websiden i de fleste browsere. For at fjerne sidens browser-cache inden genindlæsning kan du trykke på CTRL+F5 i stedet.

Mens du er ved det, kan du også prøve at indlæse webstedet i en anden browser for at udelukke det som et problem. Da de fleste 504-fejl skyldes midlertidigt overbelastede servere, skal du bruge denne løsning til at få dit websted til at komme tilbage.

Hvis venter og genindlæser webstedet ikke løser 504-fejlproblemet, kan du kontrollere, om et websted er nede for alle eller bare dig. To nyttige onlineværktøjer til at teste et sted for nedetid er Down for Everyone or Just Me og Is It Down Right Now?

2. Genstart dine netværksenheder

Nogle gange kan problemer med dine netværksenheder som modem eller router føre til en 504 Gateway Timeout-fejl. Genstart af disse enheder kan hjælpe dig med at løse problemet.

Mens du kan slukke for alle disse netværksenheder i en hvilken som helst rækkefølge, er den rækkefølge, du tænder dem igen, vigtig. Tænd typisk disse enheder fra “outside-in” efter forbindelsesordren fra internetudbyderen til din hovedklientenhed.

3. Tjek dine proxyindstillinger

En proxyserver sidder mellem din enhed og internettet. Det bruges mest til at forbedre online privatliv ved at skjule private oplysninger (f.eks. enhedsplacering) fra websteder og webservere (f.eks. ved hjælp af en VPN).

Selvom det sjældent er, at proxyservere forårsager en 504-fejl, kan forkerte proxyserverindstillinger undertiden være årsagen. Du kan deaktivere proxyserveren og prøve at genindlæse websiden for at se, om den løser fejlen.

De fleste klienter bruger ikke en proxytjeneste, så du kan springe dette trin over, hvis du er sikker på, at du ikke bruger nogen proxyserver. Du kan dog have indstillet det uden at du engang vidste om det. Jeg vil foreslå, at du tjekker din enheds og browsers proxyindstillinger for at udelukke denne sag.

4. Tjek for DNS-problemer

En 504 Gateway Timeout-fejl kan også skyldes DNS-problemer på serversiden eller klientsiden (eller begge dele).

Den mest sandsynlige årsag til et DNS-problem på serversiden er, at FQDN (fuldt kvalificeret domænenavn) ikke løser den korrekte IP-adresse, eller at DNS-serveren ikke svarer. Normalt sker dette, når du lige har migreret dit sted til en ny server eller vært. Derfor er det vigtigt at vente på, at domænes DNS-poster udbredes fuldt ud, hvilket kan tage op til 24 timer.

Du kan bruge gratis værktøjer som whatsmydns.net DNS Checker eller DNSMap for at se, om din DNS er spredt over hele kloden.

For at løse DNS-problemer på klientsiden kan du prøve at skylle din lokale DNS-cache. Det er som at rydde din browsercache, undtagen her skyller du DNS-cachen fra operativsystemet.

Hvis du bruger Windows, kan du skylle DNS-cachen ved at åbne command promt og indtaste følgende direktiv:

ipconfig /flushdns

Du skal se en “Gennemskyllet DNS-resolvercache med succes.” besked, hvis det fungerede.

For de nyeste macOS-versioner kan du åbne terminalen og køre følgende kommando:

sudo killall -HUP mDNSResponder

Du kan ikke se noget underretning i macOS, når processen er færdig, men du kan ændre det ved at tilføje kommandoen med din tilpassede besked.

sudo killall -HUP mDNSResponder; DNS Cache was cleared successfully

Hvis du bruger ældre macOS-versioner, varierer den kommando, du skal indtaste, afhængigt af hvilken version af macOS du kører. For flere detaljer kan du henvise til macOS-sektionen i Kinstas dybtgående flush DNS tutorial.

Hvis du bruger Linux-operativsystemet, er processen meget lig macOS, da selv Linux bruger Terminal som kommandolinjegrænseflade. Da der er mange Linux-distributioner, kan den nøjagtige kommando, du skal køre, variere fra en distro til en anden. Du kan tjekke Kinstas guide for at få flere oplysninger.

Endelig kan du ændre dine klientsides DNS-servere midlertidigt. Som standard tildeler din internetudbyder DNS-serverne automatisk til dig. Men du kan midlertidigt ændre disse til offentlige DNS-IP’er.

Nogle pålidelige DNS-servere, du kan prøve, er Google Public DNS, Cloudflare 1.1.1.1, Quad9 DNS, OG Cisco OpenDNS.

5. Deaktiver dit websteds CDN midlertidigt

Nogle gange kan problemet også være med dit content delivery network (CDN). Hvis et websteds oprindelsesserver ikke kan nås, vil de fleste CDN’er forsøge at betjene den fulde webside fra deres cache.

Men de fleste CDN’er aktiverer ikke denne funktion som standard, da det er komplekst at cache dynamiske aktiver på de fleste websteder (f.eks. WordPress admin dashboard).

En ligetil måde at foretage fejlfinding på er at deaktivere din CDN midlertidigt. For eksempel, hvis du bruger det gratis CDN Enabler WordPress-plugin til at linke dine sideaktiver til CDN-URL’erne, kan du deaktivere plugin’et og teste at genindlæse dit websted.

Det samme gælder for brug af ethvert andet plugin, du måtte bruge til at oprette forbindelse til din CDN (f.eks. WP Rocket, Breeze, W3 Total Cache).

Hvis du ikke kan få adgang til dit websteds admin-dashboard, kan du deaktivere plugi’et via SFTP ved at omdøbe pluginets mappenavn.

CDN’er som Cloudflare or Sucuri, som leverer fuld proxytjenester, har ekstra firewalls mellem deres kantservere og din oprindelsesserver. Derfor kan du støde på HTTP 5xx-fejl oftere, mens du bruger dem. De fleste af dem cache 5xx errors returneret af din origin server, så det er let at foretage fejlfinding af dem.

Cloudflares gratis plan er tilbøjelig til at smide en 5xx-fejl. Desværre, da det er en fuld proxytjeneste, er der ingen hurtig måde at deaktivere den på. Men inden du bebrejder Cloudflare for det, skal du vide, at Cloudflare viser to variationer af 504 Gateway Timeout error.

504 Gateway Timeout ved Cloudflare (Variation 1)

Cloudflare viser dig en brugerdefineret 504 Gateway Timeout-fejlskærm, når dit websteds origin server reagerer med et standard HTTP 504-svar.

Her ligger problemet på din webserver og ikke Cloudflare. Du kan prøve at rette det med de andre løsninger, der er nævnt nedenfor, eller kontakte din hostingudbyders support for teknisk hjælp.

504 Gateway Timeout ved Cloudflare (Variation 2)

Hvis Cloudflare forårsager 504 Gateway Timeout-fejlen, vil fejlskærmen nævne “cloudflare”, som i øjeblikket er standardservernavnet for alle Cloudflare-aktiver. Normalt vises fejlskærmen som nedenfor:

Da Cloudflare i sig selv ikke reagerer, kan du ikke se nogen Cloudflare-mærket fejlskærm her.

Mest sandsynligt er Cloudflare allerede opmærksom på problemet og arbejder allerede på en løsning. Du kan bekræfte dette ved at kontrollere Cloudflare System Status websiden. Alternativt kan du komme i kontakt med Cloudflare-support for en hurtigere løsning.

504 Gateway-timeout ved Cloudflare på grund af store uploads

Størrelsen på dine uploads til dit websted kan også være en årsag til serverens timeouts. Cloudflare begrænser uploadfilstørrelsen (pr. HTTP POST-anmodning) til kun 100 MB på både Free- og Pro-planer.

Problemet kan komme fra ​​din host side eller med Cloudflare. Du kan finde ud af den nøjagtige årsag ved at omgå Cloudflare med din DNS-hostfil og prøve at uploade igen.

Hvis du bruger Cloudflare med WordPress, anbefaler jeg, at du bruger deres gratis plugin og ekskluderer kritiske webadresser fra caching (såsom WordPress admin dashboard). Du kan henvise til Kinstas detaljerede indlæg om, hvordan du konfigurerer Cloudflare-indstillinger til WordPress.

Foreslået læsning: Sådan oprettes Cloudflare APO til WordPress.

6. Tjek serverproblemer med din host

Serverproblemer er en af ​​de mest almindelige årsager til en 504 Gateway Timeout-fejl. Da de fleste WordPress-websteder er hostet på Nginx eller Apache-webservere, venter Nginx eller Apache på et svar fra noget og tager tid.

Mange kunder kommer til Kinsta for netop dette problem, de står over for hos andre hosts. Samtalen går sådan her:

Vi får omkring 100.000 besøgende om måneden med mere end 200.000 visninger. I øjeblikket hoster vi med ____, og vi oplever konstant 504 fejl på grund af serveroverbelastning. Jeg kan ikke lide, hvordan ____ håndterede problemet, og vi blev også rådet til, at vi snart bliver nødt til at flytte til deres dedikerede planer, hvilket jeg ikke mener er nødvendigt.

Websteder med høj trafik og e-handel er mere tilbøjelige til at få 504 fejl på grund af serveroverbelastning, da de genererer mange uoprettelige anmodninger. Dette problem kan dog beskære på ethvert websted, inklusive enkle blogs. Mange hosts vil bede dig om at opgradere til en højt plan for at løse problemet, hvilket i de fleste tilfælde er unødvendigt

Kinsta bruger LXD-styrede værter og orkestrerede LXC-softwarecontainere til hvert websted. Således er hvert sted anbragt i sin egen isolerede container med adgang til al den software, der kræves til at køre det (Linux, Nginx, PHP, MySQL). Ressourcerne er 100% private og deles ikke med noget andet websted, heller ikke dine websteder.

De fleste hosts, der leverer delte hostingplaner, har ikke denne mulighed. Derfor kan et websted med høj trafik, der hostes på den samme server som din, også få dit websted til at kaste en 504-fejl.

Bortset fra at isolere hvert sted i sin container, har Kinsta også designet sin infrastruktur til nemt at håndtere tusindvis af samtidige forbindelser. Kinsta er endda host for MySQL-databaser på localhost, ikke en ekstern server. Dette betyder ingen latens mellem maskiner, hvilket resulterer i hurtigere forespørgsler og færre chancer for, at timeouts opstår.

Mange kunder, der migrerer til Kinsta, ser enorme fald i den samlede belastningstid.

En overbelastet server er ikke den eneste årsag til en server-timeout. Der kan være mange andre grunde til 504-fejlen:

Langsom serverinfrastruktur

Den server, du bruger til at være host for dit websted, har muligvis ikke nok ressourcer til at håndtere belastningen. Det er som at spille et moderne, grafikintensivt videospil på en ældgammel pc.

Serveren lægger bare på forsøg på at betjene hjemmesiden. Den eneste løsning på dette problem er at opgradere til en server med bedre infrastruktur. Af denne grund vil selv Kinstas mest basale hostingplan håndtere et statisk sebsted med medium trafik.

Brug for flere PHP-arbejdere

PHP-arbejdere bruges til at udføre dit websteds kode. Et e-handelswebsted, der får 50.000 besøgende pr. måned, har brug for meget flere ressourcer end en simpel blog med samme mængde trafik. Hvis alle serverens PHP-arbejdere har travlt, opbygger de en kø.

Når køen bliver for stor, ser serveren bort fra gamle anmodninger, hvilket kan få serveren til at kaste en 504 gateway-fejl. Du kan spørge din vært om at øge dit antal PHP-medarbejdere. Dette giver dit websted mulighed for at udføre flere anmodninger samtidigt.

Firewall-problemer

Din servers firewall kan have nogle fejl eller en forkert konfiguration. Måske forhindrer et par af dens regler serveren i at oprette en forbindelse korrekt. For at vide, om din firewall er synderen, kan du kontrollere serverens fejllogfilers.

Problemer med netværksforbindelse

Forbindelsesproblemer mellem proxyserveren og webserveren kan medføre forsinkelser i svaret på HTTP-anmodninger. Hvis du bruger en belastningsafbalancering, kan der også være problemer med netværksforbindelsen.

HTTP-timeouts

HTTP-timeouts kan forekomme, når en forbindelse mellem webserveren og klienten holdes åben for længe. På WordPress-sider sker dette normalt, når WordPress-import køres. En måde at løse dette problem er at skifte til en hurtigere internetforbindelse.

Du kan også bruge et værktøj med understøttelse af WP-CLI til at køre scripts direkte på serveren og helt omgå HTTP-forbindelsen. For eksempel kan du bruge wp import WP-CLI command til at køre WordPress Importer-plugin direkte via kommandolinjegrænsefladen.

Vigtigt: 504 Gateway Timeout-fejl ligner 503 Service Utilgængelige fejl eller 502 Bad Gateway-fejl. Men de er alle forskellige. Hvis du oplever en 504-fejl i Kinsta, skal du åbne en supportbillet for at få dit problem rettet med det samme.

For at overvåge dit websteds nedetid alene kan du bruge et værktøj som updown.io. Det kontrollerer dit websteds status (eller enhver URL) med jævne mellemrum ved at sende en HTTP-anmodning til det. Du kan indstille kontrolfrekvensen fra 15 sekunder til 1 time. Hvis dit websted ikke svarer korrekt, underretter det dig med en e-mail eller en sms.

Du får en generøs mængde gratis kreditter med hver konto af updown.io, men hvis du leder efter billigere alternativer, kan du tjekke WebGazer eller UptimeRobot. Begge disse værktøjer hjælper dig med at overvåge dit websteds oppetid hvert 5. minut gratis. Det er anstændigt nok for de fleste webstedsejere.

Overvågning af dit websted giver dig en idé om, hvor ofte det er nede. Dette er især nyttigt, hvis du bruger en delt hostingudbyder. De fleste applikationer, databaser og administrerede WordPress-hosts (som Kinsta) tager sig af dette automatisk for dig. Derfor anbefales det altid at tage med dem.

For en detaljeret forklaring, se Kinstas indlæg om vigtigheden af administreret WordPress-hosting.

7. Tjek for spam, bots eller DDoS-angreb

Ondsindede angribere kan bringe din webserver til en gennemgang ved at sende for mange og/eller ressourceintensive anmodninger. Hvis dit websted bliver spammet af bots eller gennemgår et DDoS-angreb, kan det overvælde din server og resultere i 504 Gateway Timeout-fejl for mange ægte brugere.

Du kan se på din servertrafik og analyse for at se, om du kan se uregelmæssige mønstre i webstedstrafikken. Hvis du bruger Kinsta til at være host for dit websted, kan du nemt se disse data ved at gå til MyKinsta Analytics-dashboardet.

Start din undersøgelse ved at se på de bedste klient-IP’er. Det giver dig en idé om, hvem der genererer det maksimale antal anmodninger, og hvorfra. Hvis din server pludselig bruger enorm båndbredde eller tiltrækker meget trafik, så kommer denne rapport meget praktisk.

Dernæst kan du tjekke rapporten Cache-analyse. Her kan du se, hvor mange anmodninger der omgår eller mangler cachen eller serveres fra cachen. Af hensyn til ydeevne og stabilitet vil du cache så mange anmodninger som muligt, men det er ikke altid muligt at opnå det.

For eksempel genererer WooCommerce-websteder mange uoprettelige anmodninger om funktioner såsom indkøbskurv og kassen.

Endelig kan du bruge et sikkerheds-plugin til at forbedre dit websteds sikkerhed ved at spotte og blokere for bekymrende trafik/IP’er. Du kan også bede din host om at blokere bestemte IP’er.

Afhængigt af angrebets længde og skala kan dette være en uendelig proces med blokering af IP’er, da mange angribere ændrer deres IP’er og proxy-adresser, efter at de er blevet blokeret.

Bemærk: Kinsta tillader ikke sine klienter at installere sikkerheds-plugins, da de kan have en enorm effekt på webstedets ydeevne, især dets scanningsfunktioner. Da Kinsta bruger load balancers med Google Cloud Platform, fungerer blokering af IP’er ikke altid som beregnet.

Du kan bruge dedikerede sikkerhedsløsninger såsom Cloudflare eller Sucuri til at beskytte dine sider mod DDoS-angreb og spambots. For mere kan du tjekke Kinstas artikler om, hvordan du installerer Cloudflare på dit websted, og hvordan Sucuri hjalp med at stoppe et DDoS-angreb i dets spor.

8. Reparer din ødelagte WordPress-database

Nogle gange kan en 504 Gateway Timeout-fejl skyldes en korrupt database, især på WordPress-websteder. Dette skyldes typisk beskadigede databasetabeller eller filer. Nogle gange kan det også være forårsaget af et alvorligt sikkerhedsproblem som dit websted eller din database bliver hacket.

Reparation af en beskadiget WordPress-database afhænger af problemet. Plugins som WP-DBManager gør det let at diagnosticere databaseproblemer og reparere dem. Jeg anbefaler dig at læse Kinstas detaljerede gennemgang af reparation af WordPress-databaseproblemer for at komme i gang.

9. Tjek dit websteds plugins og temaer

I de fleste tilfælde forårsager tredjeparts plugins og temaer ikke 504 fejl. Men der er en lille chance for, at de kan forårsage server-timeouts, normalt ved at stille mange ikke-cachede anmodninger i kø, der genereres af pluginet/temaet. Da dette binder mange af din servers PHP-medarbejdere, kan det forårsage 504 fejl.

Et godt eksempel på dette problem er WooCommerce, et plugin installeret til at tilføje e-handelsfunktionalitet til WordPress-websteder.

Den enkleste måde, du kan fejlfinde dette problem på, er ved at deaktivere alle dine plugins. Husk, du mister ingen data, hvis du bare deaktiverer et plugin.

Hvis du har adgang til dit admin dashboard, kan du gå til skærmen Plugins, vælge Deaktiver fra menuen for bulkhandlinger, markere alle plugins og derefter trykke på knappen Apply. Dette deaktiverer alle dine plugins.

Hvis du ikke kan få adgang til dit admin-område, kan du deaktivere plugins via SFTP ved hjælp af den metode, der er beskrevet før. Omdøb bare hovednavnet til plugin-mappen for at deaktivere alle plugins i bulk.

Når du har deaktiveret alle plugins, skal du kontrollere, om dit websted indlæses korrekt. Hvis det fungerer, skal du aktivere hvert plugin og teste webstedet efter aktivering af hvert plugin.

Endelig skal du sørge for, at dine plugins, temaer og WordPress-kernen er opdaterede. Sørg også for, at din server kører den anbefalede version af PHP.

Hvis du føler, at dette er for overvældende, kan du altid kontakte din host og bede om hjælp. Kinsta bruger Kinsta APM og andre fejlfindingsteknikker til at hjælpe klienter med at indsnævre, hvilket plugin, forespørgsel eller script der kan forårsage fejlen.

I værste tilfælde, som en ineffektiv forespørgsel eller dårlig kode i et plugin / tema, kan du hente en WordPress-udvikler for at løse problemet.

10. Tjek fejllogfiler

Visning af fejllogfiler kan være meget nyttigt, når du fejler og fejler 504 fejl på dit websted. Dette kan hjælpe dig med at indsnævre et problem på dit websted hurtigt, især hvis det skyldes et krævende plugin på dit websted.

Hvis du er Kinsta-kunde, kan du nemt se loggede fejl i MyKinsta-dashboardet. Start med at vælge WordPress-websteder i sidebarmenuen, vælg det websted, du vil undersøge, og vælg derefter Logs for at åbne logfremviser-siden.

Hvis din vært ikke har et logningsværktøj, kan du aktivere WordPress-fejlretningstilstand ved at tilføje følgende kode til din wp-config.php-fil:

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

WP_DEBUG-konstanten aktiverer eller deaktiverer WordPress-fejlretningstilstand. Den har to valgfri ledsagerkonstanter, der kan udvide dens funktioner. WP_DEBUG_LOG-konstanten dirigerer alle fejl, der skal gemmes, til en debug.log-fil i /wp-content/ biblioteket. Hvis du ikke kan se denne fil, kan du altid oprette en.

WP_DEBUG_DISPLAY-konstanten kontrollerer, om debug-logfiler vises på HTML-siden. Hvis du indstiller dette til falsk, skjules alle fejl, men du kan gennemgå fejlene senere, da du også har defineret WP_DEBUG_LOG som sand.

Vigtigt: Hvis du har aktiveret WP_DEBUG i Kinsta-miljøet, dirigeres alle fejl til debug.log-filen og ikke error.log i MyKinsta-dashboardet.

Du kan også downloade de rå WordPress-fejllogfiler via SFTP. Du kan typisk finde fejllogfiler i din servers rodmappe i en mappe med navnet “logs”.

Kinsta-brugere kan også aktivere WordPress-fejlretningstilstand fra deres MyKinsta-dashboard. For at gøre det skal du navigere til Sites > Tools > WordPress Debugging og klikke på knappen Enable. Dette giver dig mulighed for at se PHP-fejl og meddelelser uden at aktivere fejlretningstilstand via SSH eller SFTP.

Endelig kan du kontrollere serverlogfiler. Afhængigt af hvilken server du bruger til at være vært for dit WordPress-websted, findes de ofte på disse steder:

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

Du kan henvise til loggerelateret dokumentation for Apache eller Nginx for at få flere oplysninger.

11. Konfigurer Apache- eller Nginx-indstillinger korrekt

Du kan redigere dine serverkonfigurationsfiler for at øge ressourcegrænserne for specifikke direktiver. Dette kan hjælpe dig med at løse 504 Gateway Timeout-fejlen.

For Apache-webservere

Først skal du tilføje følgende kode til din httpd.conf:

TimeOut 600

Denne indstilling definerer, hvor længe serveren skal vente på visse anmodninger, før den markerer det som et netværkstimeout-problem. Dens standardværdi er 60 sekunder (Apache 2.4-version).

Du kan kun tilføje dette direktiv i din httpd.conf-fil, ikke i din .htaccess-fil. Da de fleste delte hostingudbydere ikke tillader dig at ændre httpd.conf-filen, kan du i stedet prøve at øge værdien af ​​LimitRequestBody-direktivet i din .htaccess-fil.

Føj derefter følgende linje til din php.ini-fil:

max_execution_time 300

Standardværdien af ​​PHP’s max_execution_time-direktiv er 30 sekunder. Hvis du øger det, kan dit websteds PHP-scripts køre længere.

For Nginx webservere

Hvis du kører dine WordPress-sider på Nginx + FastCGI Process Manager (PHP-FPM) eller bruger Nginx som en omvendt proxy til Apache, kan du finjustere serverindstillingerne for at forhindre 504 Gateway Timeout-fejl.

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

Først skal du redigere din PHP-FPM poolkonfigurationsfil. Du kan finde den på /etc/php7.4/fpm/pool.d/www.conf placeringen på din Nginx-server (den nøjagtige sti kan variere afhængigt af PHP-versionen). Alternativt kan du køre følgende kommando i din terminal for at redigere PHP-FPM-poolkonfigurationsfilen:

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

Indstil derefter følgende direktiv:

request_terminate_timeout = 300

Herefter skal du redigere din php.ini-fil. Du kan finde den på /etc/php.ini. Åbn filen, og tilføj / ændre værdien for max_execution_time-direktivet til 300 sekunder.

max_execution_time = 300

Endelig tilføj følgende kode til din nginx.conf-fils placeringsblok:

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

Genindlæs Nginx og PHP-FPM for at ændringerne skal træde i kraft.

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

Den nøjagtige kode for at genindlæse PHP-FPM vil variere afhængigt af den PHP-version, der er installeret på din server. Test dit websted for at se, om det har løst problemet.

504 Gateway Timeout-fejl på Nginx Proxy

Hvis du bruger Nginx som en omvendt proxyserver til Apache, kan du gøre det mere skånsomt over for server-timeouts ved at tilføje følgende direktiver til din nginx.conf-fil:

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

Glem ikke at genindlæse Nginx, når du har foretaget dine ændringer.

sudo service nginx reload

Andre HTTP-fejl som 504 Gateway Timeout

Som nævnt tidligere i artiklen er mange andre HTTP 5xx-fejl ligesom 504 Gateway Timeout-fejlen. Det er fordi de alle sker på serversiden. Disse fejl inkluderer:

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

Andre HTTP-fejl, der skyldes problemer på klientsiden, som 404 Not Found-fejlen, er også som 504-fejlen. Du kan se Kinstas detaljerede vejledning og en liste over HTTP-statuskoder for at få flere oplysninger.

Resumé

Dit websted kan blive påvirket af 504 Gateway Timeout-fejlen af ​​flere årsager. I denne artikel lærte du, hvordan du fejler dem alle. Disse fejl skyldes typisk problemer på serversiden, i hvilket tilfælde du kan nå ud til din host og få det løst hurtigt.

Du skal dog også forstå, at denne fejl kan skyldes tredjeparts plugins, temaer, tjenester, ineffektive databaseforespørgsler eller en kombination af to eller flere af disse. Hvis du maksimerer din servers ressourcer (f.eks. PHP-arbejdere), anbefales det at optimere dit websted til ydeevne.

Hvis du stadig finder ud af, at dit websted udløber, kan det meget vel være, at du har brug for at opgradere din hostingplan eller antallet af PHP-arbejdere. Jeg anbefaler dig kun at overveje denne mulighed, når du har udtømt alle de andre løsninger, der er beskrevet i denne artikel.

Fra enkle statiske websteder til komplekse e-handels- og medlemswebsites, Kinstas skalerbare hostingplaner er designet til at rumme alle typer websteder. For at lære mere om vores skalerbare cloud-hosting, tjek denne artikel om de vigtigste ting, du bør vide om Kinsta!

Savnede vi noget? Hvis du stadig har svært ved at rette 504 Gateway Timeout-fejlen på dit sted, skal du efterlade en kommentar nedenfor.