netcup-Server nicht erreichbar: Checkliste für die Fehlersuche

Dies ist Teil 31 unserer netcup-Serie. Davor: Teil 30: VNC-Konsole. Danach: Teil 32: IPv6.

Der Server antwortet nicht, und jetzt zählt die richtige Reihenfolge. Wer sofort neu startet oder Einstellungen ändert, verwischt oft die Ursache. Diese Checkliste geht von außen nach innen: erst prüfen, ob es überhaupt am eigenen Server liegt, dann Oberfläche, Konsole, Firewall und zuletzt das Rettungssystem.

Diese Anleitung ist mit der netcup-Dokumentation und der Oberfläche des SCP abgeglichen (Stand 30.10.2026). Die Befehle wurden nicht auf einem netcup-Server getestet.

Voraussetzungen

• Zugang zum SCP, siehe Teil 1
• Ein zweiter Internetanschluss für Tests, zum Beispiel das Handy, um Probleme des eigenen Netzes auszuschließen
• Das Root-Passwort des Servers für die Konsole, siehe Teil 26

Schritt 1: Liegt es an netcup?

Öffnen Sie die Status-Seite netcup-status.de. Dort veröffentlicht netcup aktuelle Störungen. Wird eine Störung für Ihren Standort gemeldet, warten Sie ab und ändern Sie nichts am Server.

Prüfen Sie zusätzlich, ob der Fehler auch über ein anderes Netz auftritt. Antwortet der Server per Mobilfunk, liegt das Problem bei Ihrem Anschluss oder einer Sperre, zum Beispiel durch Fail2ban.

Verifizieren: Sie wissen, ob eine Störung bekannt ist und ob der Fehler von mehreren Anschlüssen aus auftritt.

Schritt 2: Status und Protokoll im SCP

Öffnen Sie im SCP den Server. Der Reiter Allgemein zeigt den Status und unter Läuft seit, wie lange der Server seit dem letzten Einschalten läuft. Ist der Wert kürzer als erwartet, prüfen Sie im Protokoll, was passiert ist. Ein Neustart aus dem System heraus muss den Wert nicht zurücksetzen.

Der Reiter Protokoll zeigt Änderungen wie Ein- und Ausschalten, Firewall-Konfiguration oder Image-Installationen. Laut netcup lässt sich dort auch nachvollziehen, wann eine Störungsmeldung zu Ihrem Server verschickt wurde. Prüfen Sie außerdem im CCP unter Abuse-Hinweise, ob eine Meldung vorliegt. Ist der Server wegen eines Abuse-Falls gesperrt, gehen Sie nach Teil 23 vor.

Ist der Server ausgeschaltet, starten Sie ihn unter Steuerung mit Starten.

Verifizieren: Der Status steht auf GESTARTET, und Sie kennen die letzte Änderung aus dem Protokoll.

Schritt 3: Anmeldung über den Bildschirm

Öffnen Sie den Reiter Bildschirm und melden Sie sich an. Die VNC-Konsole funktioniert auch ohne Netzwerk des Servers, wie Teil 30 zeigt.

• Anmeldung klappt: Das System läuft. Weiter mit Schritt 4.
• Falsches Passwort: Setzen Sie es nach Teil 26 neu.
• Schwarzer Bildschirm, Boot-Fehler, Dateisystemfehler: Weiter mit Schritt 6.

Verifizieren: Sie sehen den Prompt oder wissen, an welcher Stelle der Start hängt.

Schritt 4: Firewall ausschließen

Eine Fehlkonfiguration der Firewall ist eine häufige Ursache. netcup empfiehlt, sie zu deaktivieren und die Anwendung erneut zu starten. Alternativ legen Sie eine Allow-All-Policy mit je einer eingehenden und ausgehenden ACCEPT-Regel je Protokoll an und schieben sie an die erste Stelle.

Achtung: Beides öffnet alle Ports. Machen Sie das nur kurz und stellen Sie den alten Zustand danach wieder her. Prüfen Sie auch die Firewall im System:

sudo ufw status verbose
sudo ss -tulpen

Verifizieren: Der Dienst lauscht laut ss, und Sie wissen, welche Firewall den Zugriff blockiert hat.

Schritt 5: SSH-Meldungen richtig lesen

Unter Debian und Ubuntu kann der Dienst auch ssh heißen. Prüfen Sie außerdem PermitRootLogin in /etc/ssh/sshd_config.

Verifizieren: Sie haben die Meldung einer Ursache zugeordnet.

Schritt 6: Neustart in der richtigen Reihenfolge

Laut netcup ist Powercycle ein regulärer Neustart über ACPI. Das ist der erste Schritt.

Zurücksetzen ist ein erzwungener Neustart mit möglichem Datenverlust. Nutzen Sie ihn nur, wenn der reguläre Neustart nichts gebracht hat. Das Gleiche gilt für Ausschalten gegenüber ACPI Herunterfahren.

Verifizieren: Der Server startet, und Sie sehen im Reiter Bildschirm den Anmeldedialog.

Schritt 7: Prüfen im Rettungssystem

Bleibt das Problem, schließen Sie das Betriebssystem aus. Das Rettungssystem ist aktiv, wenn der Server ausgeschaltet ist und Sie es unter Medien, Rettungssystem aktivieren. Notieren Sie das angezeigte Passwort. Die SCP-Firewall ist währenddessen deaktiviert. Die Einzelheiten stehen in Teil 9.

netcup nennt diese Prüfungen im Rettungssystem:

dhclient -v eth0
mtr -r -c 500 IP-IHRES-ANSCHLUSSES
iperf3 -c speedtest.wtnet.de -p 5200 -P 10 -4
iperf3 -c speedtest.wtnet.de -p 5200 -P 10 -4 -R
iperf3 -c speedtest.wtnet.de -p 5200 -P 10 -6
iperf3 -c speedtest.wtnet.de -p 5200 -P 10 -6 -R

netcup verlangt mindestens 500 Pings in beide Richtungen. Der Befehl oben misst vom Server zu Ihrem Anschluss. Die Gegenrichtung messen Sie von Ihrem Rechner mit mtr -r -c 500 IHRE-SERVER-IP, unter Windows mit WinMTR. Die Option -r erzeugt einen Bericht statt der laufenden Ansicht, -c 500 legt die Zahl der Pings fest. Ersetzen Sie eth0 durch den Namen, den ip a zeigt. Fehlt im Rettungssystem das Netz, richten Sie es mit grml-network ein. Nach der Prüfung deaktivieren Sie das Rettungssystem. Der Server fährt dabei herunter, starten Sie ihn dann von Hand.

Verifizieren: Sie haben die Ausgaben als Textdateien gesichert, und der Server läuft wieder im normalen System.

Schritt 8: Daten sichern und Dateisystem reparieren

Startet das System wegen Dateisystemfehlern nicht, kommen Sie im Rettungssystem an die Festplatte. Sichern Sie zuerst, was noch lesbar ist, und reparieren Sie erst danach. Binden Sie die Partition dafür nur lesend ein. lsblk zeigt, welche Partition Ihr System enthält:

lsblk
mount -o ro /dev/vda3 /mnt
ls /mnt
rsync -a /mnt/var/www/ benutzer@backup.example.com:/sicherung/www/
umount /mnt

Passen Sie Partition, Quellordner und Ziel an. Das Ziel ist ein Server, den Sie selbst betreiben. Das Einbinden beschreibt netcup in der Anleitung zum Zugriff auf die Festplatte, die Option -o ro und das Kopieren per rsync sind unsere Empfehlung. Verschlüsselte Partitionen müssen Sie vorher entsperren, siehe Teil 9.

Für die Reparatur nennt netcup fsck. Die Partition darf dabei nicht eingebunden sein:

fsck -C0 -y -f /dev/vda3

Achtung: Der Befehl behebt Fehler ohne Rückfrage. Bei stark beschädigtem Dateisystem kann das laut netcup zu Datenverlust führen, netcup empfiehlt ihn nur mit umfangreichen Kenntnissen und auf eigene Gefahr.

Verifizieren: Die wichtigen Daten liegen außerhalb des Servers, fsck meldet keine verbleibenden Fehler, und nach dem Deaktivieren des Rettungssystems und dem Start von Hand bootet der Server.

Schritt 9: Support richtig informieren

netcup verlangt für ein Ticket zu Netzwerkproblemen folgende Angaben, am besten die Ausgaben als Textdatei im Anhang:

• Kundennummer
• Servername und IP-Adresse
• Ausgabe von dhclient
• Ausgabe von MTR
• Ausgabe von iperf3
• Die Angabe, ob in das Rettungssystem gebootet wurde

Geben Sie als Servername den Namen aus dem Reiter Allgemein an, nicht Ihren Spitznamen.

Verifizieren: Das Ticket enthält alle sechs Punkte.

Troubleshooting

Häufige Fragen

Kann ich den Server einfach neu installieren?

Das ist der letzte Schritt. Laut netcup entspricht es einem vollständigen Reset, eigene Daten werden gelöscht. Sichern Sie vorher im Rettungssystem, was noch erreichbar ist, wie in Schritt 8 beschrieben.

Warum im Rettungssystem prüfen?

Es läuft unabhängig vom installierten System. So lässt sich laut netcup ein Problem auf Betriebssystemebene ausschließen.

Fazit

Gehen Sie von außen nach innen vor und ändern Sie immer nur eine Sache. Notieren Sie, was Sie geändert haben, und stellen Sie Firewall und Einstellungen nach dem Test wieder her.

Weiterführende Anleitungen und Quellen

• Teil 9: Rescue-System
• Teil 30: VNC-Konsole
• Linux-Server absichern mit ufw und Fail2ban
• netcup Helpcenter: Netzwerkprobleme beheben
• netcup Helpcenter: Fehlerbehebung beim Log-in
• netcup Helpcenter: Server-Steuerung
• netcup Helpcenter: Rettungssystem
• netcup Helpcenter: Protokoll
• netcup Helpcenter: Dateisystemfehler beheben