Server down of niet bereikbaar: wat je controleert en in welke volgorde

Deze pagina gaat over de server zelf: een VPS, een dedicated server of een cloudserver die je zelf beheert. Werkt één website niet terwijl al het andere op de machine wel draait, of staat je site op shared hosting, begin dan liever bij website down. Hier kijken we naar de machine: antwoordt hij nog? Kom je erin? Wat is er gestopt?

Stap 1: wat is er precies down?

“De server is down” kan drie heel verschillende dingen betekenen, elk met een eigen oplossing. Controleer eerst van buitenaf, vanaf een ander netwerk dan het jouwe. Voor de websites op de server vertelt de Website down checker je in een paar seconden of de naam wordt gevonden, of de poort antwoordt en welke statuscode er terugkomt. Voor de machine zelf gebruik je ping en een poorttest vanaf je eigen computer:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Lees de resultaten samen:

• Geen ping, geen SSH, geen webpoort: de machine staat uit, is vastgelopen, of het netwerk ervoor is onderbroken. Ga naar stap 2.
• Ping antwoordt, SSH niet: de machine draait, maar SSH is geblokkeerd of gestopt, of de server is te overbelast om te antwoorden. Ga naar stap 3.
• SSH werkt, de website niet: de server is in orde, een dienst niet. Ga naar stap 4.

Sommige servers antwoorden met opzet niet op ping. Heeft ping nooit gewerkt, vertrouw dan op de poorttests.

Stap 2: niets antwoordt

Open eerst het klantenpaneel of de cloudconsole van je hostingprovider. Drie vragen lossen de meeste gevallen binnen een minuut op:

1. Staat de server aan? Een gestopte instantie, een opgeschort account of een geweigerde betaling zien er van buitenaf precies zo uit als een storing.
2. Is er een bekend probleem? Kijk op de status page van de hostingprovider voor jouw regio of datacenter.
3. Wat laat de console zien? De web- of seriële console toont het scherm van de machine, ook zonder netwerk. Een kernel panic, steeds opnieuw “Out of memory: Killed process” of een opstart die blijft hangen bij de controle van het bestandssysteem vertellen je waar het probleem zit.

Is de machine vastgelopen, dan brengt een herstart vanuit de console hem meestal terug. Maak vóór de herstart een schermafbeelding van de console: na de herstart is de aanwijzing weg. Start hij niet meer op, dan bieden bijna alle hostingproviders een herstelsysteem waarmee je de schijf koppelt, de logs leest en /etc/fstab of een kapotte netwerkconfiguratie repareert.

Stap 3: ping antwoordt, SSH niet

De machine leeft, dus de oorzaak zit erin. Ga via de console naar binnen en controleer de gebruikelijke verdachten:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Een haastig toegevoegde firewallregel, je eigen IP-adres dat na een paar verkeerde wachtwoorden is geblokkeerd of een SSH-configuratie die de test niet doorstaat: dat zijn de meest voorkomende blokkades. Deblokkeer je adres met sudo fail2ban-client set sshd unbanip JOUW_IP en voer altijd sudo sshd -t uit voordat je SSH herstart. Werkt SSH wel, maar tergend traag, dan is de server overbelast: ga naar stap 4.

Stap 4: je bent binnen, lees vier getallen

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Belasting (uptime): ver boven het aantal cores betekent dat de machine overbelast is. top of htop laat zien welk proces de schuldige is.
• Geheugen (free -m): geen vrij geheugen en geen swap meer, plus “Killed process” in dmesg: de kernel heeft een proces beëindigd om te overleven. Meestal de database of PHP.
• Schijf (df -h): een volle schijf is de meest voorkomende oorzaak van een server die down is. Databases stoppen met schrijven, logs breken af, sessies mislukken. df -i controleert de inodes: een schijf kan “vol” zijn met gigabytes vrij als miljoenen kleine bestanden alle inodes bezetten.
• I/O-fouten of een bestandssysteem in alleen-lezen in dmesg: de schijf zelf heeft een probleem. Stop met schrijven, kopieer wat je kunt en neem contact op met je hostingprovider.

Om veilig ruimte vrij te maken begin je bij het systeemjournaal en bij oude bestanden:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Verwijder nooit database- of websitebestanden om ruimte te maken.

Stap 5: welke dienst is gestopt, en waarom?

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed noemt elke dienst die met een fout is gestopt. Het log geeft de reden: een poort die al bezet is, een syntaxfout in een configuratiebestand, een ontbrekend certificaat, geen ruimte meer. Test de configuratie vóór elke herstart (nginx -t, apachectl configtest, php-fpm -t) en voer dan sudo systemctl restart DIENST uit. Een herstart zonder test kan een dienst onderuithalen die nog half werkte.

Stap 6: wat is er veranderd?

Storingen hebben een oorzaak, en bijna altijd is dat de laatste wijziging. Zoek die op:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Automatische updates, een nieuwe kernel die op een herstart wacht, een deploy, een cronjob die de schijf met back-ups heeft volgeschreven, een verlopen certificaat of een configuratiewijziging door iemand anders: valt een daarvan samen met het begin van de storing, dan heb je je aanwijzing.

Als dezelfde problemen terugkomen

Een server die één keer down ging door een volle schijf of een gestopte database doet dat opnieuw. De controle van buitenaf vertelt je wanneer hij down is; de controle van binnenuit waarschuwt je eerder. De serveragent stuurt belasting, geheugen, schijven en diensten vanaf de machine zelf door en waarschuwt je wanneer een schijf boven je drempel komt of een dienst stopt die je hebt gemarkeerd, zolang er nog tijd is om iets te doen. Server monitoring met agent hoort bij de betaalde abonnementen.

Als je dit niet om 3 uur ’s nachts wilt doen

Is je server down en laat je hem liever repareren dan zelf te zoeken, dan lost de Quick Fix, de automatische reparatie tegen een vaste prijs, de meest voorkomende oorzaken op: hij herstart een gestopte dienst als de configuratietest slaagt, maakt een volle schijf vrij en vernieuwt een verlopen certificaat, met eerst een back-up. Is dat niet genoeg, dan neemt de Deep Fix het over, 24 uur per dag, gefactureerd per blok van 15 minuten, met de prijs in beeld voordat je bestelt; de schatting is de bovengrens. Allebei werken ze via de Responder, SSH als root of SSH-toegang tot je shared hosting. Alle details op de pagina serverreparatie 24/7.

Down? Wij fixen het. Quick Fix tegen een vaste prijs of Deep Fix per blok van 15 minuten, op je eigen server of op shared hosting met SSH-toegang.