Serverfouten

Bijgewerkt op: 11 november 2026

De uptimemonitoring van Kinsta controleert je site regelmatig en stuurt je een e-mail bij een 500-, 502– of 504-fout. Andere fouten op deze pagina, zoals 501 en 503, leiden niet tot een melding. Die merk je dus pas als jij of je bezoekers ze zien.

500 Internal Server Error

Een 500 Internal Server Error betekent dat de code van je site op een probleem is gestuit waarvan hij niet kon herstellen. Op WordPress sites is de oorzaak meestal een fatale PHP fout in een plugin, een thema of custom code, of een proces dat zonder geheugen komt te zitten. Omdat de fout binnen je site optreedt, staat hij bijna altijd in je logs.

Foutlog controleren

Noteer het tijdstip van de fout en de URL.
Open in MyKinsta de error.log van je site en zoek naar vermeldingen van hetzelfde tijdstip. Fatal errors bevatten PHP Fatal error en noemen meestal het bestand en de regel waar het misging.
Aan het bestandspad zie je meestal de oorzaak. Een pad onder wp-content/plugins/ of wp-content/themes/ wijst naar die plugin of dat thema.

Staat er geen passende vermelding in error.log, kijk dan of WordPress debugging is ingeschakeld in MyKinsta. Zolang dat aanstaat, gaan fouten naar de debuglog in plaats van naar error.log.

Veelvoorkomende oorzaken en oplossingen

Plugin- of themafouten: Deactiveer de plugin of het thema dat in de fout wordt genoemd. Kun je niet bij het WordPress dashboard, hernoem dan de map van de plugin in File Manager of via SFTP, of gebruik WP-CLI. Is de fout ontstaan na een update, herstel dan een backup of draai de update terug en stuur de fout daarna naar de ontwikkelaar.
Geheugenlimietfouten (Allowed memory size ... exhausted): Een plugin of proces gebruikte meer geheugen dan PHP toestaat, standaard 256 MB per PHP thread. Hoe vaak dit gebeurt, zie je in de grafiek PHP geheugenlimiet bereikt in MyKinsta onder Sites > sitenaam > Analytics > Performance. Pak eerst de plugin of het proces uit de foutmelding aan, want een kapot script kan elke hoeveelheid geheugen opmaken. Heeft je site echt meer geheugen per thread nodig, dan kun je de PHP prestatie-instellingen aanpassen onder Sites > sitenaam > Info > PHP prestaties. Het aantal PHP threads en het geheugen per thread stel je samen in, dus meer geheugen per thread kan betekenen dat er minder threads draaien. Zie PHP threadgebruik verminderen en optimaliseren.
Tijdslimietfouten (Maximum execution time ... exceeded): Deze komen van processen die niet via een browser lopen, zoals WP-CLI commando’s of cron jobs, of van een plugin die een eigen, lagere tijdslimiet instelt. Kijk welk commando, welke geplande taak of welke plugin op dat moment draaide.
Incompatibele PHP versie: Zijn de fouten begonnen na een wijziging van de PHP versie, dan werkt een plugin of thema mogelijk niet met de nieuwe versie. Werk die bij of schakel tijdelijk terug.

Wanneer neem je contact op met support?

Vind je de oorzaak niet, of blijven de fouten terugkomen nadat je deze stappen hebt geprobeerd? Neem dan contact op met support en geef de URL, het tijdstip en de tijdzone van de fout door, plus eventuele bijbehorende vermeldingen uit error.log.

501 Not Implemented

Een 501 Not Implemented fout betekent dat de server niet ondersteunt wat de request vraagt. Dit komt zelden voor bij Kinsta en ligt meestal niet aan je plugins of thema.

Een gestopte testomgeving: Zie je een 501 in een testomgeving, dan is die mogelijk gestopt. Open in MyKinsta de testomgeving en start hem.
Een ongebruikelijke requestmethode: Tools en integraties die requests versturen met een methode die de server niet ondersteunt, zoals sommige clients voor bestandssynchronisatie, kunnen een 501 krijgen. Controleer de instellingen of documentatie van de tool.

Zie je een 501 op je live site, kijk dan op de statuspagina van Kinsta en neem daarna contact op met support. Geef de URL en het tijdstip en de tijdzone van de fout door.

502 Bad Gateway

Een 502 Bad Gateway fout betekent dat de webserver geen geldig antwoord kreeg van PHP, het deel van de server van je site waarop WordPress draait. Meestal is PHP gecrasht tijdens het verwerken van een request of draaide het niet. Deze fouten ontstaan op de server van je site en komen dus in de logs van je site terecht.

Fouten tussen Cloudflare en je site zien er anders uit. Bezoekers krijgen dan een foutpagina van Cloudflare met een Ray ID, en deze fouten komen nooit in de logs van je site terecht.

Controleren of de fout je site heeft bereikt

Noteer het tijdstip van de fout.
Heb je de fout zelf gezien, kijk dan welke pagina verscheen:
- Een effen witte pagina met 502 Bad Gateway en “nginx” eronder kwam van de server van je site. Ga verder met de volgende stap.
- Bij een foutpagina van Cloudflare met een Ray ID ging het mis voordat de request je site bereikte. Neem contact op met support.
Open in MyKinsta de access.log van je site en zoek rond dat tijdstip naar 502.
Vind je een passende vermelding, dan kwam de fout van de server van je site. Kijk in error.log naar vermeldingen van hetzelfde tijdstip. connect() to unix:...php-fpm.sock failed betekent dat PHP geen requests accepteerde, en een PHP Fatal error noemt het bestand dat de crash veroorzaakte.
Vind je geen passende vermelding, dan ging het mis voordat de request je site bereikte. Gebruik je een CDN van een derde partij, kijk dan hieronder. Neem anders contact op met support.

Als de fout van de server van je site kwam

PHP is gestopt of reageert niet: Staat er in error.log connect() to unix:...php-fpm.sock failed, start PHP dan opnieuw op in MyKinsta. Blijft het gebeuren, zoek dan in error.log naar fatale fouten vlak voor de 502-fouten.
Plugins en thema’s: Een plugin of thema kan een PHP proces halverwege een request laten crashen. Staat er in error.log een fatale fout of crash op het moment van de 502, deactiveer dan de betreffende plugin of het thema, of test door alle plugins te deactiveren en over te schakelen op een standaardthema.

Als je een CDN of proxy van een derde partij gebruikt

Gebruikt je site naast de Cloudflare integratie van Kinsta ook een CDN of proxy van een derde partij, omzeil die dan tijdelijk. Stoppen de 502-fouten daarmee, neem dan contact op met je CDN provider over de instellingen of firewallregels.

Wanneer neem je contact op met support?

Blijven de fouten optreden, staat er geen passende 502 in je access.log of verklaart niets in je logs de fouten? Neem dan contact op met support en geef de URL, het tijdstip en de tijdzone van de fout door, en hoe vaak hij voorkomt. Hebben bezoekers een foutpagina van Cloudflare gezien, vermeld dan de Ray ID die daarop staat.

503 Service Unavailable

Een 503 Service Unavailable fout betekent dat je site tijdelijk requests weigert. Op WordPress sites komt dat meestal doordat de site in onderhoudsmodus staat, expres of omdat een update niet is afgerond.

“Briefly unavailable for scheduled maintenance”: WordPress toont dit tijdens het installeren van updates en haalt de melding weg zodra die klaar zijn. Wordt een update onderbroken, dan kan de site in onderhoudsmodus blijven staan. Verwijder via SFTP het bestand .maintenance uit de hoofdmap van je site. Controleer daarna of de update van de plugin, het thema of WordPress is afgerond en voer hem anders opnieuw uit.
Een plugin voor onderhoudsmodus of “binnenkort beschikbaar”: Deze plugins geven een 503 terug, zodat zoekmachines weten dat de site terugkomt. Zet de onderhoudsmodus uit in de instellingen van de plugin, of deactiveer de plugin.
Een plugin of thema dat een 503 teruggeeft: Is geen van beide het geval, deactiveer je plugins dan één voor één om te achterhalen welke de oorzaak is.

Vind je de oorzaak niet, neem dan contact op met support en geef de URL en het tijdstip en de tijdzone van de fout door.

504 Gateway Timeout

Een 504 Gateway Timeout fout betekent dat een request aan je site te lang duurde. Requests aan je site mogen tot 180 seconden duren. Is een request dan nog niet klaar, dan stopt de webserver met wachten en geeft hij een 504 terug. Bezoekers zien dan een effen witte pagina met 504 Gateway Time-out en “nginx” eronder. Soms is de eigen limiet van 180 seconden van Cloudflare eerder bereikt en zien bezoekers in plaats daarvan de pagina Cloudflare 524: A timeout occurred. Beide fouten betekenen hetzelfde: de request duurde te lang.

Time-outs ontstaan meestal doordat één request te veel werk doet, of doordat er veel requests tegelijk binnenkomen en sommige zo lang in de rij staan dat de tijd op is.

De trage request opsporen

Time-outs komen in de logs van je site terecht, dus je kunt de request vinden die te lang duurde:

Noteer het tijdstip van de fout.
Open in MyKinsta de access.log van je site en zoek rond dat tijdstip naar 504. Een request met een time-out heeft een upstream_response_time (de laatste waarde op elke regel) van ongeveer 180 seconden. Noteer de URL’s.
In de error.log van je site staat voor elke request een bijbehorende vermelding: upstream timed out ... while reading response header from upstream, gevolgd door de URL van de request.
Kregen bezoekers in plaats daarvan een Cloudflare 524-pagina te zien, zoek dan in access.log naar vermeldingen met statuscode 499 en een request time van ongeveer 180 seconden.
Zijn er geen passende vermeldingen, dan ontstond de time-out voordat de request je site bereikte. Gebruik je een CDN van een derde partij, kijk dan hieronder. Neem anders contact op met support.

Als één request of actie traag is

Als de trage vermeldingen allemaal naar dezelfde URL of actie wijzen:

Imports, exports en bulkbewerkingen: Voer deze rechtstreeks op de server uit met WP-CLI of een script. Daarvoor geldt de limiet van 180 seconden niet.
Uploads: Bij uploads ontstaat een time-out meestal door wat er gebeurt nadat het bestand is binnengekomen: afbeeldingen schalen of optimaliseren, of plugins die bestanden kopiëren naar cloudopslag zoals Amazon S3 of Google Cloud Storage. Controleer de instellingen van de plugin die dat werk doet, of laat hem op de achtergrond werken als dat kan.
Plugins en thema’s: Een plugin of thema kan trage code uitvoeren of op een trage externe dienst wachten. Spoor het trage proces op met de APM tool van Kinsta, of deactiveer plugins één voor één.
Database: Door trage of geblokkeerde databasequery’s kan een request niet klaar raken.

Als er veel requests tegelijk traag zijn

Zijn de trage vermeldingen verspreid over veel URL’s, dan krijgt je site mogelijk meer requests binnen dan de PHP threads aankunnen. Requests wachten in de rij op een vrije thread, en elke request die langer dan 180 seconden wacht, krijgt een time-out. Is het eenmaal zover, dan kan bijna elke request een time-out krijgen, omdat PHP blijft werken aan requests waarvoor bezoekers al een foutmelding hebben gekregen.

Kijk in het rapport Bezoeken in Analytics of er verkeerspieken zijn, en controleer kinsta-cache-perf.log op een groot aantal niet-gecachete requests.
Is het verkeer legitiem en regelmatig, dan heeft je site misschien meer PHP threads nodig. Je kunt het aantal PHP threads verhogen via PHP prestaties. Meer threads betekent wel minder geheugen per thread, tenzij je ook de PHP geheugenpool vergroot. Lees er meer over in PHP threadgebruik verminderen en optimaliseren.
Bij korte verkeerspieken die je ziet aankomen, zoals een uitverkoop of lancering, kan een wachtrijdienst zoals Queue-it, Queue-Fair of CrowdHandler beperken hoeveel bezoekers tegelijk je site bereiken.

Als je een CDN of proxy van een derde partij gebruikt

Sommige CDN’s hebben kortere time-outs dan Kinsta. Omzeil het CDN tijdelijk. Stoppen de fouten daarmee, controleer dan de time-outinstellingen of neem contact op met je CDN provider.

Wanneer neem je contact op met support?

Blijven de fouten optreden en vind je de trage request niet, neem dan contact op met support en geef de URL, het tijdstip en de tijdzone van de fout door, en hoe vaak hij voorkomt.