Een 504 Gateway Timeout-fout treedt op wanneer een server die als gateway of proxy fungeert, niet op tijd antwoord krijgt van een andere server. Dit gebeurt vaak wanneer de backendapplicatie van een website traag of overbelast is, of verbindingsproblemen heeft.
Bezoek je een website? Wacht dan even en vernieuw de pagina. Beheer je de website, controleer dan eerst de server- en applicatielogboeken om te achterhalen waar de vertraging ontstaat.
Hier zijn zeven praktische manieren om de fout te onderzoeken.
Wat veroorzaakt een 504 Gateway Timeout-fout?
Veel websites gebruiken meerdere servers of diensten om verzoeken af te handelen.
Een browser kan bijvoorbeeld verbinding maken met Nginx of een CDN, die het verzoek vervolgens doorstuurt naar een applicatieserver.
Als die applicatie te lang nodig heeft om te antwoorden, kan de gateway in plaats van de gevraagde pagina een 504-fout teruggeven.
Veelvoorkomende oorzaken zijn:
- Overbelaste applicatieservers of applicatieservers die niet reageren.
- Trage databasequery’s of verzoeken aan externe API’s.
- Onvoldoende CPU-capaciteit, RAM of applicatieworkers.
- Netwerkproblemen tussen de gateway en de backend.
- Time-outlimieten van de proxy of applicatie.
- Een verkeerd geconfigureerd CDN of verkeerde configuratie van de hostinginfrastructuur.
Een 504-fout is meestal een probleem aan de serverzijde, hoewel verbindingsproblemen soms individuele bezoekers kunnen treffen.
1. Vernieuw de website en controleer of deze bereikbaar is
Bezoek je de website alleen, wacht dan even en vernieuw de pagina.
Tijdelijke overbelasting van de server of een onderbroken backendverzoek kan vanzelf verholpen worden.
Je kunt ook een andere browser of een ander netwerk proberen om te zien of het probleem specifiek bij jouw verbinding optreedt.
Als iedereen de fout krijgt, moet de website-eigenaar of hostingprovider het probleem doorgaans onderzoeken.
Dien betalingen, bestellingen of formulieren niet herhaaldelijk in. Een bewerking in de backend kan zijn voltooid, ook als de gateway een time-out gaf voordat het antwoord werd teruggestuurd.
2. Controleer de server- en applicatielogboeken
Als je de server beheert, kun je het beste beginnen bij de logbestanden.
Controleer voor Nginx het foutenlogboek:
sudo tail -n 50 /var/log/nginx/error.logZoek naar vergelijkbare meldingen:
upstream timed out (110: Connection timed out)Dit geeft aan dat Nginx te lang op een upstreambewerking heeft gewacht.
Controleer vervolgens de applicatielogboeken om vast te stellen waarom de backend traag reageerde.
Je kunt ook een door systemd beheerde service controleren:
sudo journalctl -u myapp -n 50Vervang myapp door de naam van je eigen service.
3. Controleer het CPU-, RAM- en schijfgebruik
Een drukbezette server kan moeite hebben om verzoeken te verwerken binnen de time-outperiode van de gateway.
Controleer het geheugen:
free -hControleer de schijfruimte:
df -hHoud processen in de gaten:
topLet op aanhoudend hoge belasting, uitgeput geheugen, volle bestandssystemen of ongewoon drukke processen.
Deze resultaten bewijzen niet automatisch waarom het verzoek een time-out kreeg, maar kunnen helpen om knelpunten in de prestaties te vinden.
4. Onderzoek time-outs in Nginx en upstreamservers
Als Nginx als reverse proxy fungeert, controleer dan of de upstreamapplicatie binnen de ingestelde time-outlimieten reageert.
Voor HTTP-backends kan een configuratie het volgende bevatten:
location / {
proxy_pass http://127.0.0.1:3000;
proxy_read_timeout 60s;
}De instelling proxy_read_timeout bepaalt hoe lang Nginx tussen opeenvolgende leesacties van de backend wacht, niet de totale duur van het hele verzoek.
Test de backend rechtstreeks voordat je deze waarde verhoogt:
curl --max-time 15 -i http://127.0.0.1:3000/Vervang het adres door het daadwerkelijke eindpunt van je applicatie. Voor sommige routes binnen de applicatie is authenticatie vereist of is een ander geldig antwoord dan HTTP 200 mogelijk.
Als de applicatie zelf traag is, verhult een langere time-out in Nginx mogelijk alleen het onderliggende probleem.
Als een langere time-out echt nodig is, controleer dan ook de time-outinstellingen van de applicatie. Voor applicaties op basis van PHP-FPM en FastCGI gebruikt Nginx andere directives dan voor HTTP-proxybackends.
Controleer de Nginx-configuratie na wijzigingen voordat je deze opnieuw laadt:
sudo nginx -t
sudo systemctl reload nginxLaad de configuratie alleen opnieuw als de configuratietest slaagt.
5. Controleer Cloudflare of je CDN
Als je website Cloudflare of een ander content delivery network gebruikt, zoek dan uit of de time-out bij het CDN of bij je originserver ontstaat.
Controleer de foutinformatie van je CDN en vergelijk die met de logboeken van je originserver.
Een 504-fout kan afkomstig zijn van een upstreamservice achter je originserver of van een andere schakel in de afhandeling van het verzoek.
Cloudflare hanteert eigen time-outs voor verbindingen en antwoorden. Een hogere waarde in een Nginx-instelling heft een door het CDN opgelegde limiet dus niet per se op.
Schakel beveiligings- of cachefuncties niet uit voordat je de oorzaak van de time-out hebt vastgesteld.
6. Onderzoek trage databasequery’s en externe API’s
Soms werkt de webserver goed, maar wacht de applicatie op een andere service.
Veelvoorkomende voorbeelden zijn:
- Een databasequery die te lang duurt.
- Een externe API die traag reageert.
- Uitgeputte pools van applicatieworkers.
- Achtergrondtaken die om resources concurreren.
- Databasevergrendelingen die verzoeken vertragen.
Bekijk de applicatielogboeken, logboeken voor trage query’s en servicestatistieken om de vertraging te vinden.
Als een databasequery de oorzaak is, onderzoek dan de indexering, uitvoeringsplannen van query’s en het gebruik van verbindingen.
Stel voor aanroepen van externe API’s redelijke time-outs en foutafhandeling in. Langlopende taken kunnen beter asynchroon worden verwerkt als de applicatie dat ondersteunt.
7. Neem contact op met je hostingprovider
Kun je de 504 Gateway Timeout-fout niet oplossen, neem dan contact op met je hostingprovider en deel de informatie die je hebt verzameld.
Vermeld het getroffen domein, wanneer het probleem begon, of het met tussenpozen optreedt en eventuele relevante logmeldingen.
Noem ook recente wijzigingen aan je applicatie, database, CDN of reverseproxyconfiguratie.
Een hostingprovider kan helpen bij het onderzoeken van resourcebeperkingen en infrastructuurproblemen die buiten jouw beheerrechten vallen.
502- versus 504-gatewayfouten: wat is het verschil?
Deze fouten houden verband met elkaar, maar duiden op verschillende upstreamproblemen.
| Fout | Betekenis |
|---|---|
| 502 Bad Gateway | Een gateway heeft een ongeldig antwoord ontvangen van een upstreamserver |
| 504 Gateway Timeout | Een gateway heeft het benodigde antwoord van een upstreamserver niet op tijd ontvangen |
Een applicatie die onverwacht een verbinding sluit, kan bijvoorbeeld een 502-fout veroorzaken, terwijl een applicatie die te lang nodig heeft om te antwoorden een 504-fout kan veroorzaken.
504 Gateway Timeout-fouten voorkomen
Niet elke time-out is te voorkomen, maar goed infrastructuurbeheer helpt het aantal time-outs te verminderen.
- Houd de responstijden van de applicatie en het resourcegebruik in de gaten.
- Onderzoek trage databasequery’s.
- Gebruik passende caching voor content die vaak wordt opgevraagd.
- Stel passende time-outs in voor upstreamservers en applicaties.
- Houd backendservices en de beschikbaarheid van workers in de gaten.
- Test grote configuratiewijzigingen voordat je ze doorvoert.
Verhoog time-outlimieten alleen na zorgvuldige afweging, niet als eerste stap bij het onderzoeken van het probleem.
Veelgestelde vragen
Ja. HTTP 504 is een statuscode voor een fout aan de serverzijde. De code geeft aan dat een gateway of proxy niet op tijd antwoord heeft ontvangen van een upstreamserver.
Meestal niet. Het wissen van de browsercache helpt niet als een backendserver overbelast is of niet reageert. Een andere browser of verbinding proberen kan wel helpen om lokale problemen uit te sluiten.
Dat kan. Tijdelijke overbelasting of een traag backendverzoek kan snel verholpen zijn, maar terugkerende time-outs wijzen op een probleem dat onderzocht moet worden.
Ja. WordPress en andere applicaties kunnen een 504-fout krijgen als databasequery’s, PHP-verwerking of upstreamservices te lang duren.
Alleen als de applicatie daadwerkelijk meer tijd nodig heeft en de andere limieten binnen de infrastructuur dat toelaten. Stel eerst vast waarom het antwoord van de backend vertraagd is.
Conclusie
Een 504 Gateway Timeout-fout betekent dat een gateway te lang heeft gewacht op een antwoord van een upstreamserver.
Bezoekers kunnen controleren of het probleem tijdelijk is. Beheerders moeten de logboeken, serverresources, applicatieprestaties en proxyinstellingen onderzoeken.
De betrouwbaarste oplossing is de oorzaak van de vertraging te vinden, in plaats van zonder verder onderzoek time-outlimieten te verhogen of services opnieuw te starten.
