Website nicht erreichbar: Fehlersuche in 5 Schritten

Wenn Ihre Website nicht erreichbar ist, prüfen Sie die Kette in fester Reihenfolge: DNS, Netzwerk und Port, TLS-Zertifikat, Webserver, Anwendung. Die Fehlermeldung im Browser verrät fast immer, auf welcher dieser Ebenen das Problem liegt. Mit einer Handvoll Befehlen ist die Ursache meist in wenigen Minuten eingegrenzt, auch ohne tiefes Serverwissen.

Dieser Ratgeber zeigt die Prüfschritte mit konkreten Befehlen, die häufigsten Ursachen in KMU-Umgebungen und welche Informationen Sie Ihrem Dienstleister geben sollten, damit die Störung schnell behoben wird.

Erst klären: Ist die Website für alle nicht erreichbar oder nur für Sie?

Bevor Sie am Server suchen, grenzen Sie den Kreis der Betroffenen ein. Ein erheblicher Teil der gemeldeten Ausfälle betrifft nur ein Netz, einen Rechner oder einen DNS-Resolver.

Rufen Sie die Seite auf dem Smartphone mit ausgeschaltetem WLAN auf. Funktioniert sie im Mobilfunknetz, liegt das Problem wahrscheinlich im Firmennetz oder bei einer Sperre Ihrer Büro-IP.
Fragen Sie eine Kollegin im Homeoffice. Zwei unabhängige Anschlüsse liefern mehr Aussagekraft als zehn Rechner im selben Büro.
Leeren Sie den lokalen DNS-Cache: unter Windows mit ipconfig /flushdns, unter Linux mit systemd mit resolvectl flush-caches.
Prüfen Sie die hosts-Datei auf alte Einträge, die noch von einem früheren Umzug oder Test stammen.

Ein typisches Muster: Die Website funktioniert unterwegs, aber nicht im Büro. Dann hat häufig ein Schutzmechanismus wie fail2ban oder eine Web Application Firewall die gemeinsame Büro-IP gesperrt, etwa nach mehreren fehlgeschlagenen Anmeldeversuchen im CMS.

Was die Fehlermeldung über die Ursache verrät

Notieren Sie die Meldung wörtlich, bevor Sie irgendetwas ändern. Sie ist der wichtigste Hinweis auf die betroffene Ebene.

ERR_NAME_NOT_RESOLVED oder DNS_PROBE_FINISHED_NXDOMAIN: Der Name lässt sich nicht auflösen. DNS-Eintrag fehlt, Domain ausgelaufen oder Nameserver gestört.
ERR_CONNECTION_TIMED_OUT: Es kommt keine Antwort. Server aus, Netzwerkproblem oder eine Firewall verwirft die Pakete.
ERR_CONNECTION_REFUSED: Der Server ist erreichbar, aber auf dem Port läuft kein Dienst. Meist ist der Webserver gestoppt oder abgestürzt.
NET::ERR_CERT_DATE_INVALID oder ERR_CERT_COMMON_NAME_INVALID: Zertifikat abgelaufen oder für einen anderen Namen ausgestellt.
500 Internal Server Error: Der Webserver läuft, die Anwendung wirft einen Fehler.
502 Bad Gateway: Der Webserver erreicht sein Backend nicht, zum Beispiel PHP-FPM oder einen Anwendungsprozess.
503 Service Unavailable: Überlastung, Wartungsmodus oder kein freier Worker.
504 Gateway Timeout: Das Backend antwortet zu langsam, häufig wegen einer hängenden Datenbankabfrage.

Die Faustregel: Je weiter unten in dieser Liste die Meldung steht, desto weiter ist die Anfrage durch die Kette gekommen und desto näher liegt die Ursache bei der Anwendung selbst. Ein 502 heißt also, dass DNS, Netzwerk und Zertifikat in Ordnung sind und Sie dort nicht suchen müssen.

Website nicht erreichbar: Fehlersuche in fünf Schritten

Die folgenden Schritte bauen aufeinander auf. Ersetzen Sie example.de durch Ihre Domain und 203.0.113.10 durch die IP-Adresse Ihres Servers.

DNS prüfen. Fragen Sie den A- und AAAA-Eintrag ab, einmal über Ihren normalen Resolver und einmal über einen öffentlichen. Unterschiedliche Ergebnisse deuten auf eine laufende Änderung oder einen veralteten Cache hin. Ein leeres Ergebnis bei beiden spricht für einen fehlenden Eintrag oder eine ausgelaufene Domain.
```
dig +short example.de A
dig +short example.de AAAA
dig +short example.de A @9.9.9.9
dig example.de NS +short
```
Ein häufig übersehener Fall: Der AAAA-Eintrag zeigt auf eine IPv6-Adresse, die der Server gar nicht mehr hat. Clients mit IPv6 scheitern dann, Clients ohne IPv6 kommen durch. Hintergründe zu TTL und sekundären Nameservern finden Sie im Beitrag DNS als stiller Single Point of Failure.
Netzwerk und Port prüfen. Testen Sie, ob der Server auf Port 443 antwortet. Mit --resolve umgehen Sie DNS vollständig und sprechen die IP direkt an. Funktioniert das, ist der Server in Ordnung und das Problem liegt im DNS.
```
nc -zv example.de 443
curl -sv -o /dev/null https://example.de
curl -I --resolve example.de:443:203.0.113.10 https://example.de
```
Ein Timeout bei nc bedeutet: Paket kommt nicht an oder wird verworfen. Ein sofortiges Connection refused bedeutet: Server lebt, aber kein Dienst lauscht auf dem Port.
TLS-Zertifikat prüfen. Lesen Sie Laufzeit und Name des ausgelieferten Zertifikats aus. Achten Sie auf das Feld notAfter und darauf, ob die Domain im Zertifikat steht.
```
openssl s_client -connect example.de:443 -servername example.de </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName
```
Abgelaufene Zertifikate sind meist ein Symptom einer gescheiterten automatischen Erneuerung, etwa weil ein Cronjob nach einem Umzug fehlt. Wie Sie das dauerhaft absichern, beschreibt der Beitrag zu TLS-Zertifikaten und automatischer Erneuerung.
Webserver auf dem Server prüfen. Melden Sie sich per SSH an und klären Sie, ob der Webserver läuft, auf welchen Ports er lauscht und ob seine Konfiguration gültig ist. Eine fehlerhafte Konfiguration nach einer Änderung verhindert oft den Neustart.
```
systemctl status nginx
ss -tlnp | grep -E ':80|:443'
nginx -t
journalctl -u nginx --since "30 min ago"
tail -n 50 /var/log/nginx/error.log
```
Bei Apache lauten die Entsprechungen systemctl status apache2 und apachectl configtest. Starten Sie den Dienst erst neu, wenn der Konfigurationstest fehlerfrei ist.
Anwendung und Ressourcen prüfen. Bei 500, 502, 503 oder 504 liegt die Ursache hinter dem Webserver. Prüfen Sie Backend-Dienst, Speicherplatz, Arbeitsspeicher und Datenbank.
```
systemctl status php8.3-fpm
df -h
df -i
free -m
systemctl status mariadb
grep -i "max_children" /var/log/php8.3-fpm.log
```
Eine volle Partition legt erstaunlich viele Dienste lahm: Datenbanken stoppen, Sessions lassen sich nicht schreiben, Logs laufen ins Leere. Wie Sie dabei sicher Platz schaffen, steht im Beitrag Linux-Server: Festplatte voll?. Die Meldung server reached max_children im PHP-FPM-Log zeigt, dass alle Worker belegt sind, häufig durch langsame Abfragen oder einen Bot-Ansturm.

Typische Ursachen in kleinen und mittleren Unternehmen

In der Praxis wiederholen sich wenige Muster. Wer sie kennt, prüft gezielt zuerst die wahrscheinlichsten Kandidaten.

Domain ausgelaufen oder gesperrt

Die Rechnung für die Domainverlängerung ging an eine ehemalige Mitarbeiterin oder die hinterlegte Zahlungsart ist abgelaufen. Prüfen Sie im Kundenbereich Ihres Registrars Status und Laufzeit. Bei einem Wechsel des Anbieters hilft ein begleiteter Domain-Transfer mit DNS-Verwaltung, Lücken zwischen alter und neuer Zone zu vermeiden.

Änderung ohne Rückweg

Ein neues Plugin, ein PHP-Update, eine angepasste Firewallregel oder ein geänderter DNS-Eintrag am Vortag. Fragen Sie immer zuerst: Was wurde zuletzt geändert, und von wem? Diese eine Frage spart oft mehr Zeit als jede technische Analyse.

Eigene IP gesperrt

Schutzmechanismen sperren die Büro-IP nach wiederholten Fehlversuchen. Mit fail2ban sehen Sie die aktiven Sperren und heben eine fälschliche Sperre gezielt auf:

fail2ban-client status
fail2ban-client status nginx-http-auth
fail2ban-client set nginx-http-auth unbanip 198.51.100.25

Entfernen Sie die Sperre nicht blind. Wenn die Fehlversuche tatsächlich aus Ihrem Netz kamen, kann auch ein kompromittierter Rechner im Büro die Ursache sein.

Überlastung durch Bots oder Spitzenlast

Aggressive Crawler, ein Newsletter-Versand oder eine Kampagne können den Server sättigen. Ein Blick in das Access-Log zeigt, ob wenige IP-Adressen den Großteil der Anfragen erzeugen:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Wann Sie eskalieren und was Sie dem Dienstleister mitgeben

Eskalieren Sie spätestens dann, wenn Sie keinen Zugriff auf den Server haben, die Ursache außerhalb Ihres Einflussbereichs liegt oder der Verdacht auf einen Angriff besteht. Eine gute Störungsmeldung verkürzt die Behebung deutlich, weil der Dienstleister nicht von vorn beginnen muss.

Seit wann die Website nicht erreichbar ist, mit Uhrzeit
Die Fehlermeldung wörtlich, idealerweise als Screenshot
Wer betroffen ist: alle, nur das Büro, nur bestimmte Browser oder Geräte
Die Ausgaben von dig und curl -sv aus den Schritten oben
Alle Änderungen der letzten Tage, auch scheinbar unbeteiligte

Sehen Sie unbekannte Prozesse, veränderte Dateien oder eine eingeblendete Erpressungsnachricht, behandeln Sie die Lage als Sicherheitsvorfall und nicht als gewöhnliche Störung. Dann gelten andere Regeln: Beweise sichern, nicht einfach neu starten.

So verhindern Sie, dass der nächste Ausfall Sie überrascht

Die meisten Ausfälle kündigen sich an: ein Zertifikat, das in zehn Tagen abläuft, eine Partition bei 90 Prozent, eine Domain kurz vor dem Verlängerungstermin. Was fehlt, ist meist nicht das Wissen, sondern jemand, der regelmäßig hinsieht.

Externes Monitoring: Ein Check von außerhalb Ihres Netzes, der HTTP-Statuscode und einen erwarteten Textbaustein auf der Seite prüft. Ein reiner Ping erkennt keinen 502.
Zertifikatsablauf überwachen mit Vorwarnung von mindestens 14 Tagen
Speicherplatz und Inodes mit Schwellenwerten, etwa Warnung bei 80 Prozent und Alarm bei 90 Prozent
Domainlaufzeiten zentral dokumentieren, Rechnungsadresse auf ein Funktionspostfach statt einer Person
Ein kurzes Runbook mit den fünf Prüfschritten, Zugangsdaten-Ablageort und Eskalationskontakten

Das Runbook muss nicht lang sein. Eine Seite, die auch eine Vertretung ohne Serverkenntnisse abarbeiten kann, reicht für die erste Eingrenzung.

Betrieb abgeben statt selbst suchen

Ob Sie die Fehlersuche intern abdecken, hängt davon ab, wer nachts und im Urlaub erreichbar ist. Wenn diese Frage offen bleibt, ist ein Dienstleister mit Rufbereitschaft eine Option. NETARO bietet zum Beispiel Managed Hosting mit 24/7-Monitoring und festem Ansprechpartner in Frankfurt an, bei dem Zertifikate, Updates und Backups zum Betrieb gehören. Entscheidend ist bei jedem Anbieter, dass Zuständigkeiten, Reaktionswege und Zugänge schriftlich geregelt sind.

FAQ

Warum ist meine Website nur bei mir nicht erreichbar?

Meist liegt es an einem veralteten DNS-Cache, einem Eintrag in der hosts-Datei, dem Firmennetz oder einer Sperre Ihrer IP-Adresse durch fail2ban oder eine Web Application Firewall. Testen Sie über das Mobilfunknetz und leeren Sie den DNS-Cache, um das einzugrenzen.

Wie lange dauert es, bis eine DNS-Änderung wirkt?

Das hängt von der TTL des alten Eintrags ab. Resolver dürfen die alte Antwort so lange zwischenspeichern, wie die TTL angibt. Wer eine Änderung plant, senkt die TTL deshalb einige Zeit vorher, damit die Umstellung schnell überall ankommt.

Was bedeutet 502 Bad Gateway?

Der Webserver läuft, erreicht aber den dahinterliegenden Dienst nicht, etwa PHP-FPM oder einen Anwendungsserver. Prüfen Sie dessen Status, die Logs und ob alle Worker belegt sind. DNS und Zertifikat sind in diesem Fall nicht die Ursache.

Wie erkenne ich, ob meine Website gehackt wurde oder nur ausgefallen ist?

Hinweise auf einen Angriff sind unbekannte Prozesse, unerwartet geänderte Dateien, Weiterleitungen auf fremde Seiten oder ungewöhnlicher ausgehender Datenverkehr. Ein reiner Ausfall zeigt sich dagegen meist als klare Fehlermeldung in den Logs. Im Zweifel behandeln Sie die Lage als Sicherheitsvorfall und sichern Spuren, bevor Sie etwas ändern.

Website nicht erreichbar: Ursache in fünf Schritten finden, von DNS bis Webserver