Software Tips
11 minuten

Eerste hulp bij de 500 internal server error en hoe je deze serverfout snel oplost

Een HTTP 500-fout is een van de meest hardnekkige en frustrerende storingen in de e-commerce en webwereld, simpelweg omdat het een algemene verzamelnaam is voor honderden verschillende achterliggende problemen. Gelukkig hoef je niet in paniek te raken, want met een gestructureerde aanpak en een gezonde dosis logica kun je deze digitale blokkade in de meeste gevallen prima zelf diagnosticeren en verhelpen. In dit uitgebreide blog leggen we je in begrijpelijke taal uit wat deze serverfout precies betekent en hoe je jouw website stap voor stap weer online krijgt.

Developers van Wux overleggen tijdens het oplossen van een technische 500 internal server error.

Geschreven door Remco Thijssen

Zwaaiende emoji

Remco Teamlead software

Meer over Remco

Inhoudsopgave

Wat is een 500 internal server error?

Om de storing effectief op te lossen, moeten we eerst de taal van de server leren begrijpen. Telkens wanneer iemand jouw website bezoekt, stuurt de internetbrowser (zoals Google Chrome of Safari) een verzoek naar de server waar jouw websitebestanden op zijn opgeslagen. Als alles goed gaat, antwoordt de server met de juiste pagina.

Maar als er ergens in dat communicatieproces iets misgaat, stuurt de server een driecijferige HTTP-statuscode terug. De 500-statuscode is de universele code voor een intern serverprobleem. Het is in feite het digitale equivalent van het ‘motormanagement’-lampje in je auto: de server weet dat er onder de motorkap iets misgaat waardoor de website niet getoond kan worden, maar hij kan op dat specifieke moment helaas niet concreet of specifiek genoeg zijn over de exacte oorzaak van de storing.

De verschillende gedaanten van de 500-foutmelding

Het verwarrende aan deze specifieke fout is dat hij er op vrijwel iedere website en in elke browser weer net even anders uit kan zien. Dit hangt volledig af van de software die je server gebruikt en de manier waarop je website is opgebouwd. Soms zie je een volledig opgemaakte pagina van de website zelf, maar vaker zie je een van de onderstaande kale varianten op je scherm verschijnen:

  • “500 Internal Server Error”
  • “HTTP 500 – Internal Server Error”
  • “Temporary Error (500)”
  • “HTTP Error 500”
  • “500 Error”
  • Een volledig wit scherm zonder enige tekst (ook wel de White Screen of Death genoemd)

Ongeacht welke variant je ook op je scherm te zien krijgt, de achterliggende betekenis blijft exact hetzelfde: er staat een fout in de code of in de configuratie op de server die de uitvoering van de website onmiddellijk blokkeert.

Wat te doen als websitebezoeker?

Voordat we diep in de technische codes en de achterkant van je website duiken, is het goed om te weten dat een 500-fout in een klein aantal gevallen ook veroorzaakt kan worden door een lokale, tijdelijke storing aan de kant van de internetgebruiker zelf. Als je als bezoeker tegen deze melding aanloopt op een externe website, zijn er een aantal snelle handelingen die je kunt verrichten om uit te sluiten dat het probleem bij jou ligt.

Vernieuw de pagina en wis je tijdelijke browsergegevens

Mensen zijn in het digitale tijdperk ongeduldig, en dat is in dit geval juist een voordeel. Wacht na het zien van de melding simpelweg een minuutje en vernieuw de pagina handmatig door op Ctrl + F5 (op Windows) of Cmd + Shift + R (op Mac) te drukken. Vaak is een server heel even overbelast door een tijdelijke piek in het dataverkeer, en laadt de website na een harde verversing weer als vanouds.

Mocht dat niet direct werken, dan kan het helpen om je browsercache volledig te wissen of de website te openen in een incognito-venster. Als de website in de incognitomodus wel gewoon functioneert, weet je dat er verouderde gegevens in je lokale browser opgeslagen staan die het conflict veroorzaakten. Blijft de melding ook daarna hardnekkig in beeld staan? Dan ligt het probleem echt dieper in de serverstructuur van de website-eigenaar.

Een ontwikkelaar van Wux analyseert de code en error logs op het scherm om een serverstoring op te lossen.

Wat te doen als website-eigenaar?

Als eigenaar van de website is het jouw verantwoordelijkheid om het probleem zo snel mogelijk te verhelpen om imagoschade en misgelopen omzet te voorkomen. Omdat de foutmelding zelf zo algemeen is, moeten we als een detective te werk gaan en de meest voorkomende oorzaken systematisch gaan uitsluiten. We werken hierbij altijd van de meest waarschijnlijke en eenvoudig op te lossen oorzaken naar de complexere technische ingrepen.

1. Een beschadigd of foutief .htaccess-bestand herstellen

De nummer één oorzaak van een plotselinge 500 internal server error is een corrupt of onjuist geconfigureerd .htaccess-bestand. Dit is een klein maar krachtig configuratiebestand in de hoofdmap van je server dat onder andere je linkstructuren, omleidingen (redirects) en de algehele beveiliging regelt. Een foutieve punt, een verkeerde spatie of een plugin die zonder toestemming een ongeldige regelcode in dit bestand heeft weggeschreven, kan de server direct volledig laten crashen.

Om te controleren of dit bestand de boosdoener is, moet je met behulp van een FTP-programma (zoals FileZilla) of via de bestandsbeheerder in het controlepaneel van je hostingpartij inloggen op je server. Zoek in de hoofdmap naar het bestand met de naam .htaccess. Klik met de rechtermuisknop op het bestand en verander de naam naar bijvoorbeeld .htaccess_oud. Door dit te doen, kan de server het bestand tijdelijk niet meer lezen en negeert hij de eventuele foutieve instellingen. Ga nu terug naar je browser en ververs je website. Werkt je website ineens weer naar behoren? Dan heb je de boosdoener gevonden! Je kunt nu binnen het dashboard van je CMS (bij WordPress onder Instellingen > Permalinks) simpelweg op ‘Wijzigingen opslaan’ klikken om automatisch een gloednieuw, schoon .htaccess-bestand te laten genereren.

2. Het PHP-geheugenlimiet van je server verhogen

Een andere veelvoorkomende oorzaak van de 500-storing is het overschrijden van de zogenaamde PHP Memory Limit. Je website draait op de programmeertaal PHP, en je hostingpartij wijst een maximale hoeveelheid servergeheugen toe die een script mag verbruiken om je pagina te laden.

Als je website groeit, je zwaardere plugins gaat installeren, of als er een complex script wordt uitgevoerd dat veel rekenkracht vereist, kan dit geheugenlimiet plotseling bereikt worden. De server trekt op dat moment direct aan de handrem en reageert met een interne foutmelding om oververhitting of totale uitval van de server te voorkomen.

Je kunt dit probleem gelukkig relatief eenvoudig oplossen door het geheugenlimiet handmatig op te schroeven via de achterkant van je website. Open via je FTP-programma het centrale configuratiebestand van je website (bij WordPress is dit het bestand wp-config.php). Voeg vlak voor de regel die zegt dat je moet stoppen met bewerken, de volgende regel code toe:

define(‘WP_MEMORY_LIMIT’, ‘256M’);

Hiermee geef je de website toestemming om tot 256 megabyte aan geheugen te gebruiken, wat voor veruit de meeste websites meer dan voldoende is om zware processen soepel te verwerken. Mocht je geen toegang hebben tot dit bestand, dan kun je de PHP-instellingen vaak ook rechtstreeks aanpassen via het controlepaneel van je hostingomgeving (zoals Plesk of cPanel) onder de PHP-instellingen.

3. Conflicterende plugins, extensies of desastreuze thema-updates

Heb je onlangs een nieuwe plugin geïnstalleerd, een update doorgevoerd aan een extensie of het visuele thema van je website vernieuwd net voordat de 500-fout optrad? Dan is de kans groot dat er een zwaar codeconflict is ontstaan. Soms zijn twee plugins simpelweg niet compatibel met elkaar omdat ze dezelfde functies proberen aan te roepen, of sluit de code van een verouderde plugin niet meer aan bij een nieuwere PHP-versie van de server.

Omdat je door de foutmelding waarschijnlijk niet meer kunt inloggen in het reguliere administratieve dashboard van je website, moeten we de plugins handmatig gaan uitschakelen via FTP. Navigeer op je server naar de map waar al je plugingegevens staan (meestal is dit de map /wp-content/plugins/). Selecteer deze map en hernoem hem tijdelijk naar bijvoorbeeld plugins_gedeactiveerd.

Als je nu je website ververst en de foutmelding is verdwenen, weet je zeker dat een van je plugins de crash veroorzaakt heeft. Verander de naam van de map weer terug naar plugins en hernoem vervolgens binnen die map de plugins één voor één om te testen welke specifieke plugin de boosdoener is. Zodra de site crasht bij het activeren van een specifieke map, heb je de dader te pakken en kun je deze verwijderen of vervangen door een alternatief.

4. Onjuiste bestandsrechten op de server corrigeren

Ieder bestand en elke map op jouw webserver heeft een specifieke set met digitale rechten, ook wel File Permissions genoemd. Deze rechten bepalen wie een bestand mag lezen, wie er wijzigingen in mag aanbrengen, en wie een script mag uitvoeren. Dit is een cruciaal onderdeel van de beveiliging van je website. Als deze rechten per ongeluk verkeerd komen te staan kan het gebeuren dat de server weigert om een essentieel script uit te voeren, met een 500 internal server error tot direct gevolg.

Als vuistregel geldt binnen de e-commerce en webdevelopment dat de rechten van mappen en bestanden aan een strakke standaard moeten voldoen om zowel de werking als de veiligheid te garanderen. Je kunt deze rechten inzien en aanpassen door via FTP met de rechtermuisknop op een map of bestand te klikken en te kiezen voor ‘Bestandsrechten’ (of File Permissions).

Zorg ervoor dat de rechten overal als volgt zijn ingesteld:

  • Alle mappen moeten ingesteld staan op de numerieke waarde 755
  • Alle individuele bestanden moeten ingesteld staan op de numerieke waarde 644

Staan de rechten van een cruciale map bijvoorbeeld per ongeluk op 777 (wat betekent dat iedereen alles mag aanpassen)? Dan zal een goed beveiligde server de uitvoering uit veiligheidsoverwegingen direct blokkeren en de site platleggen met een interne foutmelding.

Een backend specialist van Wux controleert de serverinstellingen om websitefouten te herstellen.

Duik gericht in de Error Logs van je server

Als je alle bovenstaande stappen hebt doorlopen en je website na uren puzzelen nog steeds die hardnekkige 500-foutmelding toont, is het tijd om te stoppen met gissen en de server zelf om het antwoord te vragen. Servers zijn namelijk ontzettend plichtsgetrouw; ze houden achter de schermen nauwkeurig een digitaal logboek bij waarin elke waarschuwing, elke crash en elke fout tot op de milliseconde nauwkeurig wordt opgeschreven. Dit logboek noemen we de Error Log.

Hoe vind en lees je deze logboeken?

Je kunt de error logs meestal direct inzien door in te loggen op het controlepaneel van je hostingprovider. Zoek onder het kopje ‘Geavanceerd’ of ‘Statistieken’ naar een optie genaamd “Error Logs”, “Foutlogboeken” of “Logbeheer”. Als alternatief kun je via FTP in de hoofdmap of in een aparte map genaamd /logs/ zoeken naar een tekstbestand met de naam error_log. Open dit bestand met een simpele tekstverwerker en scroll helemaal naar de onderste regels, want daar staan de meest recente gebeurtenissen.

Voorbeeld
In plaats van een vage "500 Internal Error" zie je hier plotseling een zeer gedetailleerde regel tekst staan, zoals bijvoorbeeld:[PHP Fatal error: Call to undefined function... in /public_html/wp-content/plugins/contact-form/contact.php on line 42]

In één oogopslag zie je nu wat de crash veroorzaakt: een fatale fout in de code van een contactformulier-plugin, specifiek op regel 42 van het bestand contact.php. Het bekijken van de logs bespaart je uren aan frustrerend zoekwerk en wijst je direct de weg naar de definitieve oplossing.

Tijd om de controle over jouw website weer volledig terug te pakken

Een 500 internal server error is een van de meest vervelende hindernissen waar je als website-eigenaar tegenaan kunt lopen. Het blokkeert je bezoekers, schaadt je conversie en zorgt voor onnodige stress. Gelukkig hebben we gezien dat de fout met een systematische uitsluitingsprocedure, het controleren van je .htaccess-bestand, het verhogen van je PHP-geheugen en het raadplegen van de error logs in veruit de meeste gevallen snel en effectief op te lossen is. Het belangrijkste is om rustig te blijven en logisch na te denken over de wijzigingen die kort voor de crash hebben plaatsgevonden.

Merk je dat je ondanks de stappen in dit blog nog steeds tegen een hardnekkig wit scherm aanstaart? Wij nemen deze technische zorg graag volledig uit handen. Neem vandaag nog contact met ons op of plan direct een vrijblijvend kennismakingsgesprek in, dan duiken onze ontwikkelaars meteen diep in de serverlogs om jouw probleem snel, veilig en definitief voor je op te lossen.

Remco Thijssen Teamlead software

Meer over Remco

Ik heb de opleiding Applicatie en mediaontwikkelaar niveau 4 gevolgd bij Gildeopleidingen in Venray. Daarnaast ben ik momenteel aan het afstuderen aan de HAN voor de opleiding HBO-ICT in Arnhem. Dit is een deeltijdopleiding die ik volg naast mijn werk bij Wux. Ik werk sinds 2021 bij Wux als back-end developer. Hier ben ik als stagiaire begonnen. Ondertussen ben ik doorgegroeid en heb ik meerdere functies zoals back-end developer en projectmanager. Dit betekent dat ik alles wat ik tijdens mijn studie leer kan toepassen in mijn werk, maar ook veel praktijkervaring op doe naast de theorie. Ik pak complexe problemen aan en ben altijd op zoek naar de beste oplossing. Dit doe ik door mijn kennis die ik heb opgedaan toe te passen en up to date te blijven met de nieuwste technieken.