Je laadt een pagina, maar het duurt… en duurt. En dan verschijnt de melding: 504 Gateway Timeout. Geen duidelijke aanwijzing, geen uitleg, alleen die technische fout. Toch zegt deze statuscode je meer dan je denkt. In tegenstelling tot fouten zoals 404 of 403, die vaak op de client of de toegang duiden, vertelt deze code dat de server zélf aan het wachten is.
De 504 status code is onderdeel van de 5xx-familie: server-side errors. Maar deze foutcode heeft een specifieke boodschap: de ene server vroeg iets aan een andere server, en kreeg op tijd geen antwoord terug. Dat wachten is automatisch afgekapt. De gateway of proxy (denk aan Nginx, Varnish, of Cloudflare) trok de stekker eruit omdat de achterliggende service traag of onbereikbaar was.
Waarom je een 504 krijgt
Bij moderne websites gaat zelden alles via één server. Reverse proxies, load balancers en API-koppelingen zorgen ervoor dat verzoeken op verschillende plekken worden afgehandeld. Denk aan een frontend die praat met een applicatieserver, die op zijn beurt gegevens opvraagt bij een database of externe dienst. Als één van die lagen te langzaam is, ontstaat er een kettingreactie die eindigt in een time-out, en dus in foutcode 504.
Een veelvoorkomende situatie is dat de webserver zelf prima draait, maar dat een afhankelijk component (zoals een externe API) traag reageert of tijdelijk niet bereikbaar is. Omdat de gateway of proxy geen antwoord binnen de gestelde tijd ontvangt, geeft deze op en retourneert een 504 status code naar de browser of tool die het verzoek deed.
Heb je regelmatig last van dit soort meldingen op je WordPress-website? Dan is het verstandig om over te stappen naar een snellere en stabielere WordPress hosting oplossing.
Wat je als ontwikkelaar of beheerder kunt doen
Zodra je weet dat je met een 504 fout te maken hebt, wil je logisch gaan uitsluiten:
- Werkt je back-end wel als je deze direct aanspreekt, buiten de proxy om?
- Reageert de database of externe API binnen de verwachte tijd?
- Heb je ergens een blocking call of synchronisatieprobleem?
In de praktijk is het vaak een kwestie van debuggen aan de serverkant. Logfiles, tracing en performance monitoring (zoals New Relic of Datadog) geven vaak inzicht in waar het stokt.
Tools zoals Screaming Frog kunnen 504-fouten blootleggen wanneer je een volledige crawl uitvoert van je website. Dit is handig als je wilt weten of slechts één route tijdelijk is vastgelopen, of dat meerdere endpoints structureel tegen dit probleem aanlopen.
Gevolgen voor gebruikers en SEO
Een 504 gateway time-out is frustrerend voor gebruikers. In tegenstelling tot een 404 weten ze: de server is er wél, maar hij doet niets. Dat wekt vaak weinig vertrouwen. Als de fout kort duurt, merken zoekmachines er weinig van, ze proberen het verzoek gewoon later opnieuw. Maar als je status 504 structureel blijft teruggeven op belangrijke URLs, kan dit gevolgen hebben voor je crawlfrequentie of zelfs je rankings.
Cloudflare bijvoorbeeld kan in zo’n geval een 504 error tonen, of in sommige configuraties zelfs de verwante foutmelding 520 Web Server Returned an Unknown Error tonen. Let dus goed op of je foutmelding werkelijk een 504 is, of een gateway-specifieke variant.
Hoe los je het op?
De oplossing hangt volledig af van de oorzaak. Soms ligt het aan een te korte time-outinstelling bij je reverse proxy. Soms draait een onderliggende service onder te hoge druk, of is je database tijdelijk overbelast. Ook DDoS-aanvallen of netwerkstoringen kunnen de oorzaak zijn, zeker als je infrastructuur over meerdere datacenters verspreid is.
Het verhogen van de time-out is een lapmiddel, zelden de structurele oplossing. Kijk liever naar cachingstrategieën, queueing (bijvoorbeeld met een message broker zoals RabbitMQ), of herstructurering van je API-calls. Zorg dat je afhankelijkheden robuust omgaan met vertraging of falen.
Tot slot
Een http 504 fout is in veel gevallen tijdelijk, maar niet onschuldig. Het zegt iets over de robuustheid van je serverketen, over hoe je services met elkaar communiceren en hoe je website piekmomenten aankan. Blijft een foutcode 504 te lang onopgelost, dan merken niet alleen gebruikers het, ook crawlers, monitoringtools en API-partners zullen uiteindelijk afhaken.
Zorg dus dat je deze statuscode niet negeert. Zie het als een kans om je infrastructuur veerkrachtiger te maken. En als je dan toch gaat optimaliseren: log slim, monitor realtime en test je time-outs regelmatig onder belasting.
