Zo los je de 504 Gateway Timeout foutmelding op in je website

De 504 Gateway Timeout fout is één van de meest voorkomende HTTP 5xx fouten die websitebeheerders en bezoekers zien. Voor veel blogs en e-commerce platforms is het van essentieel belang om te weten hoe je dit soort foutmeldingen oplost, zodat je zuurverdiende bezoekers niet afhaken en naar de concurrent gaan.

Aangezien de 504 Gateway Timeout error niet vermeldt wat de oorzaak van de fout is, kan het lastig zijn om de precieze reden van de servertime-out te achterhalen. Dit artikel helpt je om de fout helemaal te begrijpen, de oorzaak te achterhalen, en natuurlijk op te lossen.

Nadat je de verschillende oplossingen die we in dit artikel geven hebt geprobeerd, zou je website weer soepel moeten draaien.

Klinkt goed, toch? Laten we meteen beginnen!

Bekijk onze videohandleiding voor het oplossen van de 504 Gateway Timeout Error op je site

Om het wat simpeler te zeggen: deze fout treedt op wanneer twee servers samen een verzoek proberen te verwerken, en de eerste server (meestal de hoofdserver) te lang moet wachten op een antwoord van de tweede server (ook wel de upstream server genoemd).

Foutcode	504 Gateway Timeout Error
Fouttype	Server-side
Foutvariaties	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)
Oorzaken fout	Problemen met de serververbinding Problemen met netwerkverbinding DNS problemen Firewall problemen

Dit is hoe het proces werkt: elke keer dat je een website bezoekt in je browser, stuurt de browser een verzoek naar de webserver waar de site gehost wordt. e server verwerkt dit verzoekt en stuurt de benodigde bestanden terug.

Het antwoord van de server bevat een HTTP statuscode die een indicatie geeft van de aard van het antwoord. Niet alle HTTP statuscodes zijn foutmeldingen. Zo betekent een 200 OK statuscode simpelweg dat de server het verzoek geaccepteerd heeft, aan het verwerken is, en dat alles goed gaat.

HTTP statuscodes van de 5xx klasse betekenen wél dat er een probleem met de server is, dat de server hiervan op de hoogte is, en dat het verzoek van de bezoeker niet uitgevoerd kan worden. Daardoor worden ze vaak ook Server Error 5xx statuscodes genoemd.

Officieel zijn er vijf statuscodes die onder de 5xx klasse vallen (500, 501, 502, 503, 504). Maar je kan ook nog verschillende onofficiële codes tegenkomen (506, 507, 509, 520, etc.).

De 504 Gateway Timeout fout is in verschillende vormen te zien. Hier zijn enkele van de gebruikelijke meldingen:

De 504 Gateway Timeout fout lijkt erg op de 502 Bad Gateway fout, die aangeeft dat de eerste server een ongeldig verzoek heeft gekregen van de tweede server (de upstream server).

Variaties van de 504 Gateway Timeout Error

Het is de browser die de 504 Gateway Timeout foutmelding weergeeft, net zoals bij andere fouten. Aangezien er verschillende besturingssystemen, webservers, browsers en user agents bestaan, kan de precieze melding variëren.

Hieronder zie je een paar 504 foutmeldingen die je vaker ziet:

• 504 Gateway Timeout
• 504 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)
• This page isn’t working — Domain took too long to respond
• 504 Gateway Time-out — The server didn’t respond in time
• Het paginaverzoek is geannuleerd omdat het te lang duurde om te voltooien
• Sitebezoekers: er is een probleem opgetreden bij het beantwoorden van je verzoek. Probeer het over een paar minuten opnieuw.
• Site Owners: er was een gateway time-out. Ga naar je foutenlogboek voor meer informatie.
• Een wit leeg scherm

Alle bovenstaande foutmeldingen, ook al gebruiken ze verschillende termen, wijzen op dezelfde 504 Gateway Timeout serverfout.

Webservers en websites kunnen in principe zelf bepalen hoe ze de 504 Gateway Timeout fout aan gebruikers laten zien. Ze kunnen er daardoor zelfs best grappig of cool uitzien. Het kan natuurlijk geen kwaad om de frustratie van bezoekers in te perken!

Wat zijn de oorzaken van de 504 Gateway Timeout Error?

Aangezien de 504 fout ontstaat door een time-out tussen twee servers, ligt het probleem meestal niet bij het apparaat of de internetverbinding van de bezoeker (dus ook niet bij je eigen apparaat of verbinding).

Een 504 Gateway Timeout fout geeft aan dat de webserver te lang moet wachten op het antwoord van een andere server, waardoor er een “time-out” ontstaat. Er kunnen allerlei redenen zijn voor deze time-out: de andere server werkt niet goed, moet teveel verzoeken verwerken, of is offline.

De andere server is overigens niet per se een externe server (bijv. een CDN of API gateway). Het kan ook een server-achtige eenheid zijn binnen de hoofdserver (bijv. een reverse proxyserver, databaseserver)

SEO impact van de 504 Gateway Timeout fout

Alle 5xx fouten voorkomen dat de pagina wordt geladen, wat natuurlijk desastreus is voor de gebruikerservaring. Daarom nemen zoekmachines zoals Google deze fouten erg serieus. Als de fout voor langere tijd blijft optreden, kan het zelfs leiden tot het deïndexeren van een webpagina, waarbij deze dus uit de resultaten wordt verwijderd.

Wanneer Google spiders bijvoorbeeld de fout 503 Service Unavailable tegenkomen, snappen ze dat dit slechts een tijdelijk fout is, aangezien het meestal wordt gebruikt voor het onderhoud van een website. Ze komen daarom gewoon later terug om het nog eens te proberen.

Een 504 Gateway Timeout fout is echter niet noodzakelijkerwijs tijdelijk, doordat het zoveel verschillende oorzaken kan hebben. Als je website offline is voor slechts enkele minuten, en de spiders het meerdere keren per minuut proberen te doorzoeken, zullen ze de pagina gewoon uit de cache laden. De fout wordt dan niet eens opgemerkt.

Maar als je website langer dan 6 uur offline is, zal Google de 504 fout als een serieus probleem met je website beschouwen, dat je zo snel mogelijk moet zien op te lossen. En dit kan wél een negatieve impact op je SEO hebben.

Google Search Console is één van de beste SEO tools om de HTTP 5xx fouten van je website te monitoren.

Hoe los je de 504 Gateway Timeout Error op?

Zonder exacte details over de site te kennen, zoals de serverconfiguratie, het hosting pakket, externe plugins, en het verkeer dat de site aantrekt, kan het frustrerend en moeilijk zijn om een 504 Gateway Timeout Error op te lossen.

Aangezien er veel variabelen bij betrokken zijn, raad ik je aan om te beginnen bij problemen aan de client-side, die zelden voorkomen, en dan verder te gaan richting server-side problemen, die vaak 504 fouten veroorzaken.

1. Probeer de webpagina opnieuw te laden

Eén van de eerste dingen die je kan doen als je de 504 Gateway Timeout fout tegenkomt, is even een paar minuten wachten, en de pagina opnieuw laden.

Je kan in de meeste browsers op F5 drukken om de pagina te verversen of opnieuw te laden. Om de browsercache van de pagina vóór het opnieuw laden te verwijderen, druk je op CTRL+F5.

Nu je er toch mee bezig bent, kan je ook meteen de website opnieuw proberen te laden in een andere browser, zodat je dat ook meteen kan afstrepen. Aangezien de meeste 504 fouten ontstaan door overbelaste servers, zorgt deze oplossing er meestal voor dat de website alsnog laadt.

Als even wachten en opnieuw proberen de 504 fout niet oplost, kan je kijken of de website voor iedereen offline is, of alleen voor jou. Twee goede online tools om de downtime van een website te testen zijn Down for Everyone or Just Me en Is It Down Right Now?

2. Herstart je netwerkapparaten

Er zijn gevallen waarin een probleem met je netwerkapparaten zoals je modem of router de 504 Gateway Timeout fout veroorzaakt. Het herstarten van die apparaten kan het probleem dan oplossen.

Je kan de apparaten in een willekeurige volgorde uitzetten, maar de volgorde waarop je ze weer inschakelt, maakt wel uit. Idealiter zet je alle apparaten “van buiten naar binnen” aan, waarbij je de verbinding volgt vanaf de internetserviceprovider tot aan je belangrijkste apparaat.

3. Controleer je proxyinstellingen

Een proxyserver bevindt zich tussen jouw apparaat en het internet. Deze wordt meestal gebruikt om je privacy online te verbeteren door bepaalde informatie te verbergen (bijvoorbeeld de precieze locatie) voor websites en webservers die je bezoekt, bijvoorbeeld door een VPN te gebruiken.

Alhoewel het zelden voorkomt dat proxyservers een 504 fout veroorzaken, kunnen foutieve instellingen van de proxyserver toch de reden zijn. Je kan je proxyserver uitschakelen en de webpagina opnieuw proberen te laden om te zien of dat het probleem oplost.

De meeste gebruikers zullen geen proxyservice hebben, dus je kan deze stap ook overslaan als je zeker weet dat je geen proxyserver gebruikt. Maar het kan soms zo zijn dat je een hebt ingesteld zonder dat je het doorhebt. Ik raad je daarom aan om de proxyinstellingen van zowel je apparaat als je browser te controleren, al is het maar voor de zekerheid.

4. Controleer op DNS problemen

Een 504 Gateway Timeout fout kan ontstaan door DNS problemen aan zowel de server-side of de client-side (of allebei).

De meest waarschijnlijke reden voor een DNS probleem aan de serverzijde is dat de FQDN (fully qualified domain name) het juiste IP adres niet resolvet of dat de DNS server niet reageert. Dit komt vooral vaak voor als je net je website naar een nieuwe server of host hebt gemigreerd. Daarom is het belangrijk om te wachten tot de DNS gegevens van het domein volledig zijn gepropageerd, wat tot 24 uur kan duren.

Je kan een gratis tool zoals whatsmydns.net DNS Checker of DNSMap gebruiken om te zien of je DNS al volledig is gepropageerd.

Voor het oplossen van client-side DNS problemen, kan je proberen je lokale DNS cache te legen. Dit is bijna hetzelfde als het legen van je browsercache, maar dan de DNS cache van het besturingssysteem.

Wanneer je Windows gebruikt, kan je de DNS cache eenvoudig legen door de Command Prompt te openen en de volgende opdracht in te typen:

ipconfig /flushdns

Als dit werkt zie je een melding: “Successfully flushed the DNS resolver Cache”.

Voor de nieuwste macOS versies, kan je de Terminal openen en de volgende opdracht uitvoeren:

sudo killall -HUP mDNSResponder

Bij macOS zie je geen melding wanneer dit klaar is, maar je kan dit aanpassen door een eigen melding toe te voegen aan je opdracht:

sudo killall -HUP mDNSResponder; DNS Cache was cleared successfully

Gebruik je een oudere macOS versie, dan hangt de opdracht af van de versie van macOS die je gebruikt. Voor meer informatie kan je even kijken naar het macOS gedeelte binnen de uitgebreide Kinsta handleiding over het legen van je DNS.

Gebruik je het Linux besturingssysteem, dan lijkt het proces sterk op macOS, aangezien Linux ook de Terminal gebruikt als opdrachtregel. Aangezien er allerlei versies van Linux bestaan, hangt de precieze opdracht af van de distributie. Je kan de uitleg van Kinsta bekijken voor meer details.

Als laatste kan je ook tijdelijk je client-side DNS servers veranderen. Standaard wijst je internetprovider je automatisch DNS servers toe. Maar je kan deze tijdelijk veranderen naar openbare DNS IP adressen.

Enkele betrouwbare opties die je kan proberen zijn  Google Public DNS, Cloudflare 1.1.1.1, Quad9 DNS, en Cisco OpenDNS.

5. Tijdelijk uitschakelen van het CDN van je site

Soms kan het probleem ook veroorzaakt worden door je Content Delivery Network (CDN). Als de origin server van je website niet bereikt kan worden, zullen de meeste CDN’s de webpagina proberen te laden vanuit de cache.

Maar de meeste CDN’s hebben deze functie niet standaard ingeschakeld staan, aangezien het voor de meeste sites vrij complex is om dynamische assets te cachen (bijv. bij het WordPress admindashboard).

Een eenvoudige manier om dit op te lossen is door je CDN tijdelijk uit te zetten. Gebruik je bijvoorbeeld de gratis CDN Enable WordPress plugin om de assets van je site te linken aan de URL’s van het CDN, dan kan je de plugin simpelweg deactiveren en je website opnieuw laden.

Hetzelfde geldt voor soortgelijke plugins die verbinding maken met je CDN (zoals WP Rocket, Breeze, W3 Total Cache).

Als je niet bij het admindashboard van je website kan komen, kan je de plugin ook via SFTP uitschakelen door de map van de plugin een andere naam te geven.

CDN’s zoals Cloudflare of Sucuri die full proxyservices bieden hebben extra firewalls tussen hun edge servers en jouw origin server. Hierdoor zul je bij hen vaker HTTP 5xx fouten tegenkomen. De meeste cachen 5xx fouten die je origin server verstuurt, zodat je ze makkelijk kan oplossen.

Het gratis pakket van Cloudflare geeft regelmatig een 5xx fout. Helaas is er geen snelle manier om dit uit te schakelen, doordat het een full proxyservice is. Maar voordat je Cloudflare de schuld van de fout geeft, is het goed om te weten dat Cloudflare twee variaties van de 504 Gateway Timeout fout geeft.

504 Gateway Timeout bij Cloudflare (variatie 1)

Cloudflare laat je een aangepaste 504 Gateway Timeout foutmelding zien wanneer de origin server van je website een standaard HTTP 504 response geeft.

In dat geval ligt het probleem bij je eigen webserver, niet bij Cloudflare. Je kan proberen deze op te lossen via de manieren die we hieronder beschrijven, of door contact op te nemen met je hostingprovider voor technische support.

504 Gateway Timeout bij Cloudflare (variatie 2)

Wanneer Cloudflare de 504 Gateway Timeout fout veroorzaakt, zal de foutmelding “cloudflare” vermelden, wat momenteel de standaard servernaam is voor alle Cloudflare assets. Meestal ziet het foutscherm er zo uit:

Aangezien het in dit geval Cloudflare zelf is dat niet reageert, zul je hier geen foutmelding met Cloudflare branding zien.

Waarschijnlijk is Cloudflare op dat moment al op de hoogte van het probleem en bezig met een oplossing. Je kan dit controleren door op hun Cloudflare System Status pagina te kijken. In plaats daarvan kan je ook contact opnemen met de ondersteuning van Cloudflare voor een snellere oplossing.

504 Gateway Timeout fout bij Cloudflare door grote uploads

De grootte van de uploads naar je site kunnen ook servertime-outs veroorzaken. Cloudflare beperkt de grootte van uploads (per HTTP POST request) tot slechts 100 MB op zowel het Free als Pro pakket.

Dit probleem kan zowel bij je host als bij Cloudflare optreden. Je vindt de precieze oorzaak door Cloudflare te omzeilen via je DNS hosts bestand en je upload opnieuw te proberen.

Gebruik je Cloudflare voor een WordPress website, dan raad ik je aan om hun gratis plugin te gebruiken en kritieke URL’s uit te sluiten van caching, zoals bijvoorbeeld het WordPress admindashboard. Je kan ook het uitgebreide artikel van Kinsta lezen over het instellen van Cloudflare voor WordPress.

Lees meer: Zo stel je Cloudflare APO in voor WordPress.

6. Controleer serverproblemen bij je host

Serverproblemen zijn de meest gebruikelijke oorzaak van een 504 Gateway Timeout fout. Aangezien de meeste WordPress websites gehost worden op Nginx of Apache webservers, betekent een time-outfout dat Nginx of Apache op een antwoord wachten vanaf een andere locatie, en dat het verzoek inmiddels verlopen is.

Veel van onze huidige klanten zijn precies vanwege dit probleem overgestapt naar Kinsta. Ze kwamen dit probleem geregeld tegen bij hun andere host en het gesprek gaat vervolgens meestal zo:

We krijgen ongeveer 100k bezoekers per maand, met meer dan 200k views. Momenteel worden we gehost door ____ en we zien aldoor 504 fouten vanwege serveroverloads. Ik ben niet blij met de oplossing van ____, en we kregen daarnaast de aanbeveling om naar hun duurdere pakketten over te stappen, wat volgens mij niet nodig is.

Websites met veel verkeer en webshops krijgen sneller 504 fouten door een serveroverload, omdat ze veel verzoeken genereren die niet gecachet kunnen worden. Maar dit probleem kan bij elke website optreden, ook bij simpele blogs. Veel hosts zullen je dan vragen om naar een duurder pakket te migreren om het probleem op te lossen, ook al is dit meestal niet nodig.

Kinsta gebruikt door LXD beheerde hosts en georkestreerde LXC softwarecontainers voor elke website. Daardoor wordt elke website gehost in een eigen, aparte container met toegang tot alle benodigde software (Linux, Nginx, PHP, MySQL). De resources zijn 100% privé en worden niet gedeeld met andere sites, zelfs niet met je eigen sites.

De meeste hosts die gedeelde hostingpakketten bieden, hebben deze mogelijkheid niet. Daardoor kan een website met veel verkeer – die gehost wordt op dezelfde server als jouw website – ervoor zorgen dat jouw website ook een 504 foutmelding geeft.

Naast het isoleren van websites in de containers, heeft Kinsta de infrastructuur ook zo opgezet dat er eenvoudig duizenden gelijktijdige verbindingen afgehandeld kunnen worden. Kinsta host zelfs de MySQL databases op localhost, niet op een remote server. Dit betekent dat er geen vertraging tussen machines zit, waardoor je query’s sneller zijn en de kans op time-outs kleiner.

Veel klanten die naar Kinsta migreren zien enorme verbetering in laadtijden.

Een overbelaste server is niet de enige oorzaak van een servertime-out. Er kunnen ook allerlei andere redenen zijn voor de 504 fout:

Langzame serverinfrastructuur

De server die je gebruikt voor het hosten van je website kan te weinig capaciteit hebben om de vraag aan te kunnen. Vergelijk het met het spelen van een moderne, grafisch intensieve computergame op een PC van tien jaar oud.

De server gooit het bijltje er gewoon bij neer. De enige oplossing hiervoor is de server te upgraden met betere infrastructuur. Hierom kunnen zelfs de goedkopere hostingpakketten van Kinsta zonder problemen een statische site met een gemiddelde hoeveelheid verkeer aan.

Meer PHP workers nodig

PHP workers zijn nodig om de code van je website uit te voeren. Een e-commerce website die 50.000 bezoekers per maand krijgt, heeft een hoop meer capaciteit nodig dan een simpele blog die net zoveel bezoekers krijgt. Als alle PHP workers van de server bezig zijn, zal er een wachtrij ontstaan.

Wanneer die rij te lang wordt, gaat de server oude verzoeken weggooien, waardoor er een 504 Gateway Timeout fout op kan treden. Je kan je host vragen om het aantal PHP workers te verhogen. Hierdoor kan je website meer verzoeken tegelijkertijd afhandelen.

Firewall problemen

De firewall van je server kan verkeerd ingesteld zijn of fouten bevatten. Wellicht zorgen enkele van de regels ervoor dat de server geen goede verbinding kan maken. Om erachter te komen of je firewall de boosdoener is, kan je de errorlogs van je server bekijken.

Problemen met de netwerkverbinding

Verbindingsproblemen tussen de proxy server en de webserver kunnen vertragingen veroorzaken in het beantwoorden van HTTP verzoeken. Wanneer je een loadbalancer gebruikt, kan die ook voor netwerkproblemen zorgen.

HTTP time-outs

HTTP time-outs kunnen optreden wanneer de verbinding tussen de webserver en de client te lang open staat. Bij WordPress websites zie je dit het vaakst gebeuren bij het uitvoeren van een WordPress import. Je kan dit oplossen door naar een snellere internetverbinding over te gaan.

Je kan ook een tool gebruiken die WP-CLI ondersteunt zodat de scripts rechtstreeks op de server worden uitgevoerd, waardoor je de hele HTTP verbinding omzeilt. Zo kan je bijvoorbeeld de opdracht wp import WP-CLI gebruiken om de WordPress Importer plugin direct via de opdrachtregel te gebruiken.

Belangrijk: 504 Gateway Timeout fouten lijken sterk op 503 Service Unavailable fouten of 502 Bad Gateway fouten. Dit zijn echt verschillende problemen. Wanneer je een 504 fout krijgt bij Kinsta, kun je het beste meteen een supportticket openen zodat we het probleem meteen kunnen oplossen.

Om zelf de downtime van je website bij te houden, kan je een tool zoals updown.io gebruiken. Deze checkt de status van je website (of welke URL dan ook) regelmatig door er een HTTP verzoek naartoe te sturen. Je kan de frequentie van de controle zelf instellen tussen elke 15 seconden tot elk uur. Wanneer je website niet juist reageert, krijg je een melding via mail of SMS.

Je krijgt een ruime hoeveelheid gratis credits bij elk account op updown.io, maar als je op zoek bent naar een goedkoop alternatief, dan kan je WebGazer of UptimeRobot eens bekijken. Beide tools zullen je website elke 5 minuten controleren, gratis. Dat is meer dan genoeg voor de meeste beheerders.

Door je website te monitoren krijg je een idee hoe vaak deze offline is. Dat is vooral erg nuttig wanneer je bij een gedeelde hostingprovider zit. De meeste Applicatie Hosting, Database Hosting en Managed WordPress Hosting (zoals Kinsta) regelen dit automatisch voor je. Vandaar dat het altijd aan te raden is om met een dergelijke host in zee te gaan.

Voor een gedetailleerde uitleg kan je het artikel van Kinsta lezen over het belang van managed WordPress hosting.

7. Controleer op spam, bots of DDoS aanvallen

Kwaadwillenden kunnen je webserver flink vertragen door heel veel of heel zware verzoeken te versturen. Als je website gespamd wordt door bots, of een DDos aanval te verwerken krijgt, kan dat je server overbelasten, waardoor normale gebruikers een 504 Gateway Timeout fout te zien kunnen krijgen.

Je kan de analytics en verkeersstromen van je server bekijken om te zien of je abnormale patronen ziet in het verkeer naar je website. Als je Kinsta gebruikt om je site te hosten, kan je deze data eenvoudig bekijken door naar je MyKinsta Analytics dashboard te gaan.

Begin je onderzoek door naar de belangrijkste client IP adressen te kijken. Daardoor krijg je een idee van wie je de meeste verzoeken krijgt, en waar die vandaan komen. Wanneer je website opeens extreem veel bandbreedte gebruikt of veel verkeer krijgt, kan deze rapportage extra handig zijn.

Vervolgens kan je de Cache analyse bekijken. Hier zie je hoeveel verzoeken de cache missen of omzeilen, en hoeveel er wél vanuit de cache afgehandeld worden. Vanwege de prestaties en stabiliteit, wil je zo veel mogelijk verzoeken vanuit de cache afhandelen, maar dat lukt niet altijd.

Zo maken WooCommerce websites bijvoorbeeld veel verzoeken aan die niet via de cache geleverd kunnen worden, voor functies zoals het winkelkarretje en het afrekenen.

Als laatste kan je ook een beveiligingsplugin gebruiken om je website beter te beveiligen door verdacht verkeer te detecteren en blokkeren. Je kan ook je host vragen om bepaalde IP adressen te blokkeren.

Afhankelijk van de lengte en schaal van de aanval, kan dit een oneindig proces zijn waarbij je steeds meer IP adressen moet blokkeren, doordat veel aanvallers van IP adres en/of proxy adres veranderen nadat ze geblokkeerd zijn.

Noot: Kinsta staat geen beveiligingsplugins toe op sites van klanten, aangezien ze een grote impact kunnen hebben op de prestaties van je website, vooral door de scanfuncties. Aangezien Kinsta loadbalancers gebruikt, samen met Google Cloud Platform, zou het blokkeren van IP adressen ook niet altijd werken zoals gewenst.

Je kan in plaats daarvan gespecialiseerde beveiligingsoplossingen gebruiken, zoals Cloudflare of Sucuri om je website te beschermen tegen spambots en DDoS aanvallen. Voor meer informatie kan je de Kinsta artikelen lezen over hoe je Cloudflare installeert op je website en over hoe Sucuri een DDoS aanval voorkomt.

8. Repareer je beschadigde WordPress database

Soms wordt een 504 Gateway Timeout fout veroorzaakt door een beschadigde database. Dit zie je vooral vaak bij WordPress websites. Dit komt meestal door een fout in databasetabellen of -bestanden. Het kan soms ook komen door serieuze beveiligingsproblemen, bijvoorbeeld wanneer je website of database gehackt wordt.

Hoe je een corrupte WordPress database repareert, hangt af van de oorzaak. Plugins zoals WP-DBManager maken het vrij makkelijk om problemen met je database te diagnosticeren en op te lossen. Ik raad je aan om de gedetailleerde uitleg van Kinsta te lezen over het repareren van problemen met je WordPress database.

9. Controleer de plugins en het thema van je website

In de meeste gevallen zullen externe plugins en thema’s geen 504 fouten kunnen veroorzaken. Maar er is wel een kleine kans dat ze servertime-outs veroorzaken wanneer ze bijvoorbeeld een lange rij met ongecachete verzoeken genereren. Aangezien dit veel van je PHP workers vergt, kan dat resulteren in 504 fouten.

Een goed voorbeeld hiervan is WooCommerce, een plugin waarmee je eenvoudig e-commerce functionaliteit aan je WordPress website toevoegt.

De eenvoudigste manier om dit op te lossen is door al je plugins te deactiveren. Je raakt geen data kwijt wanneer je een plugin alleen maar deactiveert.

Als je bij je admindashboard kan, kun je naar het venster Plugins gaan, klikken op Deactiveren in het menu met bulkacties, alle plugins aanvinken, en op de knop Toepassen klikken. Hiermee schakel je al je plugins uit.

Als je niet bij je admin kan, zou je alle plugins kunnen uitschakelen via SFTP, zoals we eerder beschreven. Je geeft daarbij gewoon de hoofdmap met plugins een andere naam.

Nadat je alle plugins hebt gedeactiveerd, kijk je of je website nu wel goed laadt. Zo ja, dan kan je nu elke plugin één voor één activeren, waarbij je de website test na elke plugin.

Als laatste is het belangrijk om ervoor te zorgen dat je plugins, thema’s en WordPress versie helemaal bijgewerkt zijn tot de laatste versie. En zorg ervoor dat je server de aanbevolen versie van PHP gebruikt.

Vind je dit allemaal te veel van het goede, dan kan je altijd contact opnemen met je host voor meer ondersteuning. Kinsta gebruikt Kinsta APM en andere probleemoplossingstechnieken om klanten te helpen bij het bepalen van welke plugin, query of script de fout veroorzaakt.

In het ergste geval, zoals een inefficiënte query of slechte code in een belangrijke plugin of belangrijk thema, kan je een WordPress developer inhuren om het probleem op te lossen.

10. Controleer foutenlogs

Het bekijken van je foutlogs kan erg helpen bij het bepalen van de oorzaak van 504 fouten op je website. Hierdoor kan je sneller de oorzaak achterhalen, vooral wanneer het door een zware plugin op je website komt.

Als je klant bent van Kinsta, kun je gemakkelijk gelogde fouten zien in het MyKinsta dashboard. Begin met het selecteren van WordPress Websites in het zijbalkmenu, kies de site die je wilt onderzoeken en selecteer dan Logs om de pagina Log viewer te openen.

Heeft je host geen logtool, dan kan je de WordPress debugmodus inschakelen door de volgende code toe te voegen aan je wp-config.php bestand:

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

De WP_DEBUG constante schakelt de WordPress debugmodus in of uit. Er zijn twee optionele bijbehorende constanten waarmee je extra functies kan gebruiken. De WP_DEBUG_LOG constante zorgt ervoor dat alle fouten opgeslagen worden in een debug.log bestand binnen de map /wp-content/. Als je dit bestand momenteel niet ziet, kan je die ook zelf aanmaken.

De WP_DEBUG_DISPLAY constante bepaalt of de debug logs ook te zien zijn binnen de HTML pagina. Door dit op ‘false’ te zetten worden alle fouten verborgen, maar kan je ze later alsnog bekijken in het logboek, aangezien je WP_DEBUG_LOG op ’true’ hebt staan.

Belangrijk: Als je WP_DEBUG ingeschakeld hebt binnen de Kinsta omgeving, zullen alle fouten naar het bestand debug.log gaan, en niet naar error.log binnen het MyKinsta dashboard.

Je kan ook de onbewerkte WordPress errorlog bestanden via SFTP downloaden. Over het algemeen vind je de errorlogs in de root map van je server in een map die “logs” heet.

Kinsta gebruikers kunnen de WordPress debugmodus ook inschakelen vanuit hun MyKinsta dashboard. Om dat te doen, ga je naar  Websites > Tools > WordPress debugging en klik je op Inschakelen. Hierdoor kan je PHP fouten en meldingen zien zonder dat je de debugmodus hoeft in te schakelen via SSh of SFTP.

Als laatste kan je ook de serverlogbestanden bekijken. Afhankelijk van het soort server waarop je WordPress site gehost wordt, kan je die meestal op deze plek vinden:

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

Je kan voor meer informatie over logbestanden kijken in de documentatie van Apache of Nginx.

11. Configureer Apache of Nginx instellingen goed

Je kan de serverconfigbestanden bewerken om voor bepaalde taken de beperkingen aan te passen. Hierdoor kan je mogelijk de 504 Gateway Timeout fout voorkomen.

Voor Apache webservers

Allereerst voeg je de volgende code toe aan je httpd.conf bestand:

TimeOut 600

Deze instelling bepaalt hoe lang de server wacht op antwoord bij bepaalde verzoeken voordat het als netwerkfout wordt aangemerkt. De standaardwaarde is 60 seconden (Apache 2.4)

Je kan deze regel alleen toevoegen in je httpd.conf bestand, niet in het .htaccess bestand. Aangezien de meeste gedeelde hostingproviders niet toestaan dat je het httpd.conf bestand bewerkt, kan je ook proberen de waarde van de LimitRequestBody directive te verhogen in je .htaccess bestand.

Vervolgens voeg je de volgende regel toe aan het php.ini bestand:

max_execution_time 300

De standaardwaarde van de max_execution_time directive is 30 seconden. Door dit te verhogen, kunnen je PHP scripts langer draaien voordat er een foutmelding wordt gegeven.

Voor Nginx webservers

Als je je WordPress website op Nginx + FastCGI Process Manager (PHP-FPM) draait, of Nginx als reverse proxy gebruikt voor Apache, dan kan je ook de serverinstellingen aanpassen om 504 Gateway Timeout fouten te voorkomen.

504 Gateway Timeout fout op Nginx + FASTCGI (PHP-FPM)

Allereerst moet je het PHP-FPM pool configbestand aanpassen. Dit bestand is te vinden op /etc/php7.4/fpm/pool.d/www.conf in je Nginx server (het precieze bestandspad hangt af van je PHP versie). In plaats daarvan kan je ook de volgende opdracht uitvoeren in je terminal om het PHP-FPM pool config bestand aan te passen:

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

Vervolgens stel je de volgende regel in:

request_terminate_timeout = 300

Daarna bewerk je je php.ini bestand. Dit is te vinden op /etc/php.ini. Open het bestand en verander de waarde voor max_execution_time naar 300 seconden (of voeg deze regel toe).

max_execution_time = 300

Als laatste voeg je de volgende code toe aan je nginx.conf location block:

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

Laad Nginx en PHP-FPM opnieuw om de aanpassingen te activeren.

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

De exacte code voor het herstarten van PHP-FPM hangt af van de PHP versie van je server. Test vervolgens je website om te kijken of het probleem nu opgelost is.

504 Gateway Timeout fout op Nginx proxy

Als je Nginx als reverse proxy server voor Apache gebruikt, dan kan je het wat minder strikt maken voor server timeouts door de volgende regels toe te voegen aan je nginx.conf bestand:

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

Vergeet niet Nginx opnieuw te laden na het opslaan van je veranderingen.

sudo service nginx reload

Andere HTTP foutmeldingen die lijken op de 504 Gateway Timeout

Zoals eerder gezegd, zijn er veel HTTP 5xx fouten die sterk lijken op de 504 Gateway Timeout fout. Dat komt doordat ze allemaal aan de kant van de server zitten. Dit zijn onder meer de fouten:

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

Andere HTTP fouten worden veroorzaakt door problemen aan de client-side, zoals de 404 Not Found, maar lijken soms wat op 504 fout. Je kan de uitgebreide uitleg en lijst van HTTP statuscodes van Kinsta bekijken voor meer informatie.

Samenvatting

Je website kan de 504 Gateway Timeout fout krijgen door verschillende oorzaken. In dit artikel heb je geleerd hoe je die problemen kan oplossen. Over het algemeen worden dit soort fouten veroorzaakt door problemen aan de kant van de server, waardoor je snel contact op kan nemen met je host voor een oplossing.

Maar het is goed om te begrijpen dat de fout ook kan ontstaan door externe plugins, thema’s, diensten, onvoldoende databasequery’s of een combinatie hiervan. Wanneer de capaciteit van je server niet toereikend is (bijv. te weinig PHP workers), raden we je aan om je website te optimaliseren voor betere prestaties.

Krijgt je website nog steeds time-outs, dan moet je misschien je hostingpakket upgraden of het aantal PHP workers uitbreiden. Ik raad je aan deze optie pas te overwegen nadat je alle andere oplossingen in dit artikel hebt geprobeerd.

Van eenvoudige statische websites tot complexe e-commerce en ledenwebsites, Kinsta’s schaalbare hostingpakketten zijn ontworpen om alle typen websites aan te kunnen. Als je meer wilt weten over onze schaalbare cloudhosting, bekijk dan dit artikel over de belangrijkste dingen die je moet weten over Kinsta!

Hebben we nog iets gemist? Als je nog steeds moeite hebt om de 504 Gateway Timeout fout op je website op te lossen, laat het ons dan weten in de reacties.