De 504 Gateway Timeout fout is één van de meest voorkomende HTTP 5xx fouten die websitebeheerders en bezoekers zien. Voor veel WordPress 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!

De 504 Gateway Timeout foutmelding is één van de meest voorkomende HTTP 5xx fouten. 🤔 Leer in dit artikel hoe je deze fout snel kan oplossen. ⬇️Click to Tweet

Wat is de 504 Gateway Timeout fout?

Elke keer wanneer je via je browser een website bezoekt, verstuurt je browser een verzoek naar de webserver waar de website wordt gehost. De server verwerkt dit verzoekt en stuurt de benodigde bestanden terug.

Hoe HTTP requests en responses werken

Hoe HTTP requests en responses werken

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 (500501502503, 504). Maar je kan ook nog verschillende onofficiële codes tegenkomen (506, 507, 509520, etc.).

De Internet Engineering Task Force (IETF) definieert de 504 Gateway Timeout error zo:

De statuscode 504 (Gateway Timeout) geeft aan dat de server, in de rol van gateway of proxy, niet op tijd een respons heeft ontvangen van een upstream server waarvan toegang nodig was om het verzoek af te ronden.

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).

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

De ‘HTTP ERROR 504’ in de Chrome browser

De ‘HTTP ERROR 504’ in de Chrome browser

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).

De ‘504 GATEWAY TIMEOUT’ statuscode in Chrome DevTools

De ‘504 GATEWAY TIMEOUT’ statuscode in Chrome DevTools

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:

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!

De aangepaste 504 foutpagina van GitHub

De aangepaste 504 foutpagina van GitHub

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.

De crawlfouten bekijken in Google Search Console

De crawlfouten bekijken in Google Search Console

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

Oorzaken van de fout 504 Gateway Timeout

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)

Zo los je de 504 Gateway Timeout error op

Als je weinig details weet over de WordPress website, zoals de precieze serveropstelling, hostingpakket, externe plugins, en het binnenkomende verkeer, kan het nogal frustrerend en lastig zijn om een 504 Gateway Timeout fout 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.

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.

Verversen van een webpagina in Chrome

Verversen van een webpagina in Chrome

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?

Testen van Kinsta.com op Down for Everyone en Just Me

Testen van Kinsta.com op Down for Everyone en Just Me

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.

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.

Veranderen van de "Proxy" instellingen in Windows 10

Veranderen van de “Proxy” instellingen in Windows 10

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.

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 voorkomende reden voor een server-side DNS probleem is dat de FQDN (Fully Qualified Domain Name) niet verwerkt wordt naar het juiste IP adres. Dit komt vooral vaak voor als je net je WordPress 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.

Controleren van de DNS propagatie van je domein via whatsmydns.net

Controleren van de DNS propagatie van je domein via whatsmydns.net

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
Legen van de DNS Cache via de Command Prompt in Windows

Legen van de DNS Cache via de Command Prompt in Windows

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 DNSCloudflare 1.1.1.1Quad9 DNS, en Cisco OpenDNS.

Instellingen van custom DNS servers in Windows 10

Instellingen van custom DNS servers in Windows 10

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).

Instellen van de ‘Cache Everything’ paginaregel in Cloudflare

Instellen van de ‘Cache Everything’ paginaregel in Cloudflare

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.

Uitschakelen van alle plugins door de map met plugins een andere naam te geven

Uitschakelen van alle plugins door de map met plugins 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.

Cloudflare’s custom Error 504 scherm

Cloudflare’s custom Error 504 scherm

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:

Error screen for 504 Gateway Timeout caused by Cloudflare

Error screen for 504 Gateway Timeout caused by Cloudflare

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.

Controleer de Cloudflare System Status via cloudflarestatus.com

Controleer de Cloudflare System Status via cloudflarestatus.com

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.

Cloudflare’s ‘Maximum Upload Size’ limieten voor verschillende pakketten

Cloudflare’s ‘Maximum Upload Size’ limieten voor verschillende pakketten

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.

Serverproblemen (neem contact op met 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 WordPress 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 WordPress 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 WordPress 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 verbetering van 212,5% qua prestaties na het switchen naar C2.

Een verbetering van 212,5% qua prestaties na het switchen naar C2.

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 WordPress 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 WordPress 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 WordPress 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.

Monitor your website with updown.io

Monitor your website easily with updown.io

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.

WebGazer website monitoring tool dashboard

WebGazer website monitoring tool dashboard

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 managed WordPress hosts regelen dit namelijk al voor je, wat dan ook de reden is dat we die altijd aanraden.

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

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.

MyKinsta Analytics dashboard

MyKinsta Analytics dashboard

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.

Het bekijken van de 'Top client IPs' in het MyKinsta dashboard

Het bekijken van de ‘Top client IPs’ in het MyKinsta dashboard

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.

Het scherm ‘Cache analyse in MyKinsta

Het scherm ‘Cache analyse in MyKinsta

Als laatste kan je ook een WordPress 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.

Heb je last van downtime en andere problemen met WordPress? Kinsta is als hostingoplossing speciaal ontworpen met performance en veiligheid in het achterhoofd. Bekijk onze pakketten

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 WordPress 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 WordPress website en over hoe Sucuri een DDoS aanval voorkomt.

WordPress database met fouten

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.

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.

Alle WordPress plugins uitschakelen via het WP admin dashboard

Alle WordPress plugins uitschakelen via het WP admin dashboard

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 New Relic 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.

Controleer je foutlogs

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

Ben je klant bij Kinsta, dan kan je fouten eenvoudig weergeven in de logviewer in je MyKinsta dashboard.

Bekijken van foutlogs in MyKinsta dashboard

Bekijken van foutlogs in MyKinsta dashboard

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.

WordPress error logbestanden map via SFTP openen

WordPress error logbestanden map via SFTP openen

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:

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

Juist instellen van Apache of Nginx

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:

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.

Hoe los je een 504 Gateway Timeout fout op als je niet weet wat de oorzaak is, voordat al je zuurverdiende bezoekers verdwijnen? 🤷‍♂‍ Je vindt alle antwoorden in dit artikel. ⬆️Click to Tweet

Samenvatting

Je WordPress 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 hostingpakketten zijn ontworpen om alle typen websites aan te kunnen. Zelfs als je website meer servercapaciteit gebruikt dan je hostingpakket aanbiedt, zorgt de automatisch schalingsfuncties van Kinsta ervoor dat je website altijd online is.

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


Als je dit artikel leuk vond, dan ga je Kinsta’s WordPress hosting platform ook heel erg leuk vinden! Of het nu gaat om het versnellen van je website of de 24/7 support van ons ervaren WordPress-team. Onze door Google Cloud aangedreven infrastructuur is gericht op automatische schaalbaarheid, prestaties en beveiliging. Laat ons jou het Kinsta verschil tonen! Bekijk onze pakketten