Server down oder nicht erreichbar: was du zuerst prüfst

Dieser Ratgeber dreht sich um den Server selbst: einen VPS, einen dedizierten oder einen Cloud-Server, den du betreibst. Fällt nur eine einzelne Website aus und alles andere auf der Maschine läuft, oder liegt deine Seite im Shared Hosting, fang besser mit dem Ratgeber Website nicht erreichbar an. Hier geht es um die Maschine: Antwortet sie überhaupt, kommst du drauf, und was ist stehen geblieben?

Schritt 1: Was genau ist down?

„Der Server ist down“ kann drei ganz verschiedene Dinge heißen, und jedes hat seine eigene Lösung. Prüfe zuerst von außen, aus einem Netz, das nicht deins ist. Für Websites auf dem Server sagt dir der Website-Down-Checker in Sekunden, ob der Name auflöst, ob der Port antwortet und welcher Statuscode zurückkommt. Für die Maschine selbst nimmst du Ping und einen Port-Test von deinem Rechner aus:

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

Lies die Ergebnisse zusammen:

• Kein Ping, kein SSH, kein Web-Port: Die Maschine ist aus, hängt, oder das Netz davor ist gestört. Weiter mit Schritt 2.
• Ping antwortet, SSH nicht: Die Maschine läuft, aber SSH ist gesperrt, gestoppt, oder der Server ist zu überlastet, um zu antworten. Weiter mit Schritt 3.
• SSH geht, die Website nicht: Der Server ist in Ordnung, ein Dienst nicht. Weiter mit Schritt 4.

Manche Server beantworten Ping absichtlich nicht. Hat Ping noch nie funktioniert, verlass dich auf die Port-Tests.

Schritt 2: Nichts antwortet

Öffne zuerst das Kundenpanel oder die Cloud-Konsole deines Anbieters. Drei Fragen klären die meisten Fälle in einer Minute:

1. Läuft der Server? Eine gestoppte Instanz, ein gesperrtes Konto oder eine fehlgeschlagene Zahlung sieht von außen genauso aus wie ein Ausfall.
2. Gibt es eine bekannte Störung? Schau auf die Statusseite des Anbieters für deine Region oder dein Rechenzentrum.
3. Was zeigt die Konsole? Die Web- oder serielle Konsole zeigt den Bildschirm der Maschine auch ohne Netz. Ein Kernel Panic, „Out of memory: Killed process“ in Endlosschleife oder ein Start, der bei der Dateisystemprüfung hängt, sagen dir, wo das Problem liegt.

Hängt die Maschine, holt ein Neustart über die Konsole sie meist zurück. Mach vorher einen Screenshot der Konsole: Nach dem Neustart ist der Hinweis weg. Startet sie nicht mehr, bieten die meisten Anbieter ein Rettungssystem, aus dem du die Platte einhängst, die Logs liest und /etc/fstab oder eine kaputte Netzwerkkonfiguration reparierst.

Schritt 3: Ping antwortet, SSH nicht

Die Maschine lebt, also liegt die Ursache auf ihr. Melde dich über die Konsole an und prüf die üblichen Verdächtigen:

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'

Eine schnell eingefügte Firewall-Regel, deine eigene IP-Adresse nach ein paar falschen Passwörtern gesperrt oder eine SSH-Konfiguration, die ihren Test nicht bestanden hat, sind die häufigsten Sperren. Deine Adresse gibst du mit sudo fail2ban-client set sshd unbanip DEINE_IP wieder frei, und vor jedem SSH-Neustart läuft sudo sshd -t. Läuft SSH, ist aber extrem langsam, ist der Server überlastet: weiter mit Schritt 4.

Schritt 4: Du bist drin, jetzt vier Zahlen lesen

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

• Last (uptime): Weit über der Zahl der CPU-Kerne heißt, die Maschine ist überlastet. top oder htop zeigt, welcher Prozess schuld ist.
• Speicher (free -m): Kein freier Speicher, kein Swap und „Killed process“ in dmesg heißt, der Kernel hat einen Prozess beendet, um zu überleben. Meist war es die Datenbank oder PHP.
• Festplatte (df -h): Eine volle Platte ist die häufigste Ursache für Server-Probleme. Datenbanken schreiben nicht mehr, Logs brechen ab, Sitzungen schlagen fehl. df -i prüft die Inodes: Eine Platte kann mit Gigabytes frei „voll“ sein, wenn Millionen kleiner Dateien alle Inodes belegen.
• I/O-Fehler oder ein schreibgeschütztes Dateisystem in dmesg: Die Platte selbst hat ein Problem. Hör auf zu schreiben, sichere, was noch geht, und melde dich bei deinem Anbieter.

Platz schaffst du sicher zuerst über das Systemjournal und alte Archive:

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

Lösch nie Datenbank- oder Website-Dateien, um Platz zu schaffen.

Schritt 5: Welcher Dienst steht, und warum?

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

systemctl --failed listet jeden Dienst, der mit Fehler gestoppt ist. Sein Journal nennt den Grund: ein belegter Port, ein Syntaxfehler in einer Konfigurationsdatei, ein fehlendes Zertifikat, kein Platz mehr. Teste die Konfiguration vor jedem Neustart (nginx -t, apachectl configtest, php-fpm -t) und starte dann mit sudo systemctl restart DIENST. Ein Neustart ohne Test kann einen Dienst lahmlegen, der noch halb lief.

Schritt 6: Was hat sich geändert?

Ausfälle haben Ursachen, und meist ist es die letzte Änderung. So findest du sie:

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, ein neuer Kernel, der auf einen Neustart wartet, ein Deployment, ein Cronjob, der die Platte mit Backups gefüllt hat, ein abgelaufenes Zertifikat oder eine Konfigurationsänderung von jemand anderem: Passt eins davon zum Beginn des Ausfalls, hast du deine Spur.

Wenn dieselben Server-Probleme wiederkommen

Ein Server, der einmal wegen voller Platte oder gestoppter Datenbank ausgefallen ist, tut es wieder. Die Prüfung von außen sagt dir, wann er down ist; die Prüfung von innen sagt es dir vorher. Der Server-Agent meldet Last, Speicher, Festplatten und Dienste aus der Maschine heraus und alarmiert dich, wenn eine Platte deine Schwelle überschreitet oder ein angehakter Dienst stoppt, solange noch Zeit zum Handeln ist. Server-Monitoring mit Agent gehört zu den bezahlten Tarifen.

Wenn du das nicht um drei Uhr nachts machen willst

Ist dein Server down und willst du ihn lieber reparieren lassen als selbst suchen, übernimmt ein Schnelleingriff die häufigen Ursachen zum Festpreis: Er startet einen gestoppten Dienst nach bestandenem Konfigurationstest neu, schafft Platz auf einer vollen Platte und erneuert ein abgelaufenes Zertifikat, vorher mit Sicherungskopie. Reicht das nicht, übernimmt ein Intensiveingriff rund um die Uhr, im 15-Minuten-Takt abgerechnet, den Preis siehst du vor dem Auftrag. Beides läuft über den Responder, SSH als root oder SSH-Zugang zu deinem Webspace. Einzelheiten auf der Seite Server-Reparatur und Server-Notdienst.