ServBay Webserver Probleemoplossingsgids

ServBay ondersteunt meerdere standaard webservers, waaronder Caddy, NGINX en Apache, en biedt een flexibele lokale ontwikkelomgeving. Tijdens het gebruik kun je geconfronteerd worden met onbereikbare websites, trage laadtijden of foutmeldingen zoals een 500 Internal Server Error. Deze gids helpt je bij het diagnosticeren en oplossen van veelvoorkomende webserverproblemen in je ServBay-omgeving.

Gebruik van ServBay’s Ingebouwde Diagnosetool

ServBay biedt een krachtige ingebouwde diagnosetool om automatisch veelvoorkomende configuratie- en serviceproblemen op te sporen en te melden. We raden sterk aan deze tool te gebruiken als eerste stap bij probleemoplossing.

Open de ServBay-app en klik in de linkernavigatiebalk op Probleemdiagnose om het geïntegreerde diagnosepaneel te openen.

De tool controleert essentiële componenten van ServBay, controleert poortbezetting, en valideert configuratiebestanden op syntaxfouten, waarbij duidelijke aanwijzingen en adviezen worden gegeven zodat je snel de oorzaak van problemen kunt achterhalen.

Controleren van Webserver Configuratiebestanden

Fouten in webserverconfiguratiebestanden zijn een van de meest voorkomende oorzaken van ontoegankelijke websites. ServBay voorziet voor elke server in aparte syntax-checking tools.

Caddyfile Controle

Gebruik het ingebouwde validate-commando van Caddy om je Caddyfile te controleren op fouten.

/Applications/ServBay/bin/caddy validate -c /Applications/ServBay/etc/caddy/Caddyfile

Als de syntax correct is, krijg je Valid configuration als resultaat. Bij fouten ontvang je een melding met details over het type fout.

Let op: Het caddy validate-commando geeft mogelijk veel INFO of WARN meldingen — deze tonen voornamelijk intern laadprocesinformatie van Caddy en betekenen niet automatisch dat je configuratie fout is. Zolang je Valid configuration als laatste ziet, is de syntax in orde.

Veelvoorkomende Caddyfile-fouten:

• Niet-bestaand certificaatbestand:

  2024/12/09 17:24:16.970 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  ... (overige INFO/WARN meldingen) ...
  Error: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open /Applications/ServBay/ssl/private/tls-certs/mail.servbay.host/mail.servbay.host.1crt: no such file or directory

  Een foutmelding zoals loading certificates: open xxxxx: no such file or directory betekent dat het in de Caddyfile opgegeven SSL-certificaatbestand niet bestaat of de padnaam fout is. Controleer of je het juiste certificaatbestand (.crt/.cer/.pem) en de private key (.key) correct hebt vermeld, en dat de bestanden daadwerkelijk op die locatie staan. ServBay ondersteunt zowel handmatig importeren als automatische SSL-aanvraag via ACME; controleer hiervoor je ServBay SSL-instellingen.

• Foute root-directorypad (met spaties):

  2024/12/09 17:26:37.371 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  Error: adapting config using caddyfile: parsing caddyfile tokens for 'root': too many arguments; should only be a matcher and a path, at /Applications/ServBay/etc/caddy/Caddyfile:1388

  De fout parsing caddyfile tokens for 'root': too many arguments wordt meestal veroorzaakt door spaties in het pad naar de webroot. Bijvoorbeeld, in root * /Applications/ServBay/www/public web beschouwt Caddy public web als twee losse argumenten. Gebruik altijd aanhalingstekens voor paden met spaties: root * "/Applications/ServBay/www/public web".

  Advies: Vermijd gebruik van spaties en speciale tekens in bestands- en mapnamen. Gebruik indien mogelijk een koppelteken - of een underscore _, bijvoorbeeld public-folder of public_dir.

• Foute Rewrite-regels:

  Het overnemen van rewrite-regels uit NGINX die niet compatibel zijn met de Caddy-syntax zorgt vaak voor validatiefouten. Raadpleeg de Rewrite-module documentatie van Caddy of ServBay’s eigen migratiegids van NGINX naar ServBay voor correcte regels.

NGINX Configuratie Controle

Test je NGINX-configuratie met de ingebouwde -t parameter.

/Applications/ServBay/bin/nginx -t

Bij een geldige configuratie zie je het volgende:

nginx: the configuration file /Applications/ServBay/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /Applications/ServBay/etc/nginx/nginx.conf test is successful

Bij een fout geeft NGINX de naam van het configuratiebestand en het regelnummer waar het foutging. Veelvoorkomende fouten zijn:

1. Syntaxfouten: Zoals een ontbrekend puntkomma ; of een niet gesloten accolade }.
2. Verkeerde bestandslocaties: Bij een include-opdracht of een pad naar bestanden/directories die niet bestaan.
3. Poortconflict: De opgegeven poort wordt al door een andere applicatie gebruikt.

Apache Configuratie Controle

Gebruik apachectl configtest om je Apache-configuratie te valideren.

/Applications/ServBay/bin/apachectl configtest

Bij een correcte configuratie zie je Syntax OK. Bij fouten wordt een duidelijke foutmelding getoond. Veel voorkomende Apache-fouten zijn:

1. Module niet gevonden: Een geactiveerde module (LoadModule) bestaat niet of het pad is onjuist.
2. .htaccess-syntaxfouten: Onjuiste regels in een .htaccess-bestand binnen de website map kunnen niet alleen de test laten falen, maar ook tot errors bij het bezoeken van (sub)mappen leiden.
3. Verkeerde permissie-instellingen: Instellingen zoals Require, Allow of Deny binnen Directory of Files-blokken kunnen toegang tot websitebestanden blokkeren.

500 Internal Server Error oplossen

De 500 Internal Server Error is een generieke HTTP-statuscode die aangeeft dat op serverniveau een onverwachte fout optrad. Dit duidt bij webapplicaties meestal op falende backendscripts (PHP, Python, Node.js enzovoorts).

Algemene stappen voor probleemoplossing

Wanneer je een 500-fout tegenkomt, volg dan deze stappen:

1. Raadpleeg de foutlogboeken van de webserver: Dit is altijd de eerste stap. De logs bevatten details over fouten, zoals scriptfouten, ontbrekende bestanden of rechtenproblemen.

   • Caddy: /Applications/ServBay/var/logs/caddy/error.log
   • NGINX: /Applications/ServBay/var/logs/nginx/error.log
   • Apache: /Applications/ServBay/var/logs/apache/error.log Kijk naar de laatste logregels voor berichten met error of critical.

2. Controleer of backend-services (zoals PHP-FPM) actief zijn: Bij PHP-gebaseerde sites, kijk of PHP-FPM draait.

   ps aux | grep php-fpm

   Zoek regels met php-fpm: master process of php-fpm: pool www. Ontbreken deze, dan is PHP-FPM niet actief of gecrasht. Start in dat geval PHP via de ServBay UI of met het servbayctl-commando.

3. Check het logbestand van backendscripts (zoals PHP): Als uit de webserverlogs blijkt dat de fout bij FastCGI of een backend-script ligt, controleer dan het specifieke errorlog van die taal.

   • PHP: /Applications/ServBay/var/logs/php/php_error.log Zoek naar Fatal error, Parse error, Warning, Notice enzovoort, zeker in relatie tot het script dat je aanroept. Zet display_errors in productie uit voor veiligheid, maar zet het in de ontwikkelfase gerust tijdelijk aan (meestal in je php.ini).

4. Controleer bestands- en maprechten: Webservers draaien doorgaans onder een specifieke gebruikersnaam, bijvoorbeeld _www, en hebben voldoende rechten nodig om bestanden/directories te lezen of te beschrijven.

   ls -la /Applications/ServBay/www/your-site/

   Controleer of de webservergebruikers lees- (en indien noodzakelijk schrijf-)rechten hebben op de mappen en bestanden. Zet nooit te ruime rechten (zoals 777) zonder reden, en gebruik chmod/chown correct.

Specifieke aandachtspunten voor 500-fouten per webserver

• Caddy:

  1. FastCGI-configuratie: Controleer de php_fastcgi of reverse_proxy regels in de Caddyfile; deze moeten verwijzen naar het juiste PHP-FPM adres (bijv. 127.0.0.1:9000 of unix:/pad/naar/php-fpm.sock).
  2. PHP-FPM-status: Controleer in ServBay of de juiste PHP-versie én PHP-FPM service actief zijn.
  3. Reverse proxy-instellingen: Als je een reverse proxy naar een andere backend gebruikt (zoals Node.js), check dan of de adres- en poortcombinatie klopt, én of de achterliggende dienst draait.

• NGINX:

  1. fastcgi_pass instelling: Zorg ervoor dat het adres in nginx.conf (of de specifieke website config) overeenkomt met het adres waar PHP-FPM naar luistert.
  2. client_max_body_size: Grote uploads kunnen tot een 500-fout leiden als deze waarde te laag is ingesteld; verhoog waar nodig.
  3. try_files: Check of deze regel goed is opgezet, zodat verzoeken correct worden afgehandeld of doorgestuurd.

• Apache:

  1. mod_rewrite module: Gebruik je .htaccess-bestanden voor URL-rewrites, zorg dan dat het mod_rewrite-module is geladen.
  2. .htaccess-inhoud: Syntaxfouten in .htaccess zorgen direct voor 500-fouten. Let op spelling, paden en vooral RewriteRule regels.
  3. AllowOverride instelling: Controleer dat AllowOverride in je Apache-configuratie correct staat voor de betreffende directory, meestal All, of in ieder geval met FileInfo en Limit.

Servicebeheer

Na het aanpassen van configuraties of na backend-oplossingen moet je de webserver of betrokken diensten vaak herstarten.

Diensten Herstarten

Gebruik het volgende commando om specifieke webserverdiensten te herstarten:

# Herstart de Caddy service
servbayctl restart caddy -all

# Herstart de NGINX service
servbayctl restart nginx -all

# Herstart de Apache service
servbayctl restart apache -all

De -all parameter zorgt ervoor dat alle aan de webserver gekoppelde subdiensten (zoals PHP-FPM) ook worden herstart.

Status van diensten bekijken

Gebruik dit commando om de huidige status van een service te checken:

# Status van Caddy
servbayctl status caddy -all

# Status van NGINX
servbayctl status nginx -all

# Status van Apache
servbayctl status apache -all

De uitvoer geeft aan of een dienst running (draait), stopped (gestopt) of een andere status heeft — handig om zeker te weten dat je wijzigingen zijn toegepast.

Geavanceerde Probleemoplossing

Als bovenstaande methoden het probleem niet verhelpen, kun je diepgaander onderzoeken met deze stappen:

1. Gebruik browserontwikkelaarstools: Open de devtools (vaak F12), en bekijk het tabblad Console en Netwerk. Controleer op JS-fouten, exacte HTTP-statuscodes, response headers en bodies — zo ontdek je snel waar het spaak loopt: frontend of backend.
2. Gebruik curl -v in de terminal:
   Test je website via curl -v jouw-website.servbay.demo. De -v flag toont alle connectie-info, inclusief request/response headers en SSL/TLS details. Vervang jouw-website.servbay.demo door jouw eigen domeinnaam in ServBay.
3. Tijdelijk de firewall uitschakelen: Soms blokkeert de lokale (macOS) firewall of security-software verzoeken. Schakel de firewall even uit ter test; opgelost? Maak dan een uitzondering aan voor de relevante ServBay-poorten (80, 443 enzovoorts).
4. Test op andere browsers/apparaten: Kijk of het probleem zich ook voordoet op andere browsers of een ander device; zo sluit je cache issues of specifieke gebruikersinstellingen uit.
5. Controleer je lokale DNS of hosts-bestand:
   Gebruik je een custom domein (dus niet ‘localhost’ of een IP-adres), controleer dan /etc/hosts of je lokale DNS-configuratie: het domein moet (voor IPv4) verwijzen naar 127.0.0.1 of (voor IPv6) naar ::1.

Samenvatting

Webserverproblemen zijn een van de meestvoorkomende uitdagingen bij lokaal ontwikkelen. Door systematisch configuraties te controleren, logs te analyseren, serviceruns te valideren en rechten te controleren, zijn de meeste issues goed op te lossen. Gebruik de ingebouwde diagnose- en commandlinetools van ServBay als je belangrijkste hulp. Kom je er echt niet uit, raadpleeg dan de uitgebreide ServBay-documentatie of neem contact op met het supportteam voor hulp.