ERR_CONNECTION_TIMED_OUT

Was dieser Fehler bedeutet und wie du ihn erkennst

• Der Browser zeigt eine Meldung wie „Diese Website ist nicht erreichbar“ mit ERR_CONNECTION_TIMED_OUT an.
• Der Fehler tritt nach einer merklichen Wartezeit auf und nicht sofort.
• Der Hostname funktioniert in einem Netzwerk, läuft in einem anderen aber in ein Timeout.
• Anfragen an die öffentliche Adresse des Servers können ebenfalls in ein Timeout laufen, während die Hosting-Konsole die Instanz weiterhin als aktiv anzeigt.
• Das Problem betrifft viele Besucher, wenn Host, Netzwerkschnittstelle, Route oder vorgelagertes Netzwerk nicht verfügbar sind.
• Ein Server unter starker CPU-, Speicher-, Prozess- oder Verbindungsbelastung kann eingeschaltet bleiben, aber neue Verbindungen nicht rechtzeitig abschließen.
• Ein CDN, Reverse Proxy oder Load Balancer kann erreichbar sein, während seine Verbindung zum Origin in ein Timeout läuft.

Hauptursachen nach Wahrscheinlichkeit

1. Der Host oder die Netzwerkschnittstelle ist nicht erreichbar — Der Server, die VM, die Netzwerkschnittstelle, die Route oder das vorgelagerte Netzwerk kann nicht verfügbar sein.
2. Eine Firewall oder Security Group verwirft Datenverkehr stillschweigend — Eine Drop-Regel verursacht häufig ein Timeout, während eine explizite Ablehnung normalerweise schneller fehlschlägt.
3. Der Server ist überlastet — Erschöpfte Ressourcen, Prozesslimits oder zu viele offene Verbindungen können verhindern, dass der TCP-Handshake oder die Anwendungsantwort abgeschlossen wird.
4. DNS verweist auf das falsche Ziel — Der Hostname kann in eine veraltete oder nicht erreichbare Adresse aufgelöst werden oder auf eine Infrastruktur zeigen, die die Website nicht mehr bereitstellt.
5. Der Netzwerkpfad des Besuchers ist unterbrochen — Ein Routing-Problem beim ISP, ein VPN, Proxy, eine lokale Firewall oder ein Filtergerät kann den Zugriff aus einem Netzwerk blockieren.
6. IPv6 ist falsch konfiguriert — Ein nicht nutzbarer AAAA-Eintrag kann bei Netzwerken, die IPv6 bevorzugen, zu Fehlern führen, selbst wenn der IPv4-Dienst funktioniert.
7. Ein CDN, Reverse Proxy, Load Balancer oder eine vorgelagerte Schutzschicht ist falsch konfiguriert — Das Frontend kann den Origin möglicherweise nicht erreichen, obwohl der Origin selbst läuft.

So behebst du den Fehler

1. Aus einem zweiten Netzwerk testen

Öffnen Sie die Website über mobile Daten oder eine andere unabhängige Verbindung. Wenn ein VPN oder Proxy aktiv ist, testen Sie die Verbindung, sofern zulässig, ohne diesen.

• Funktioniert im zweiten Netzwerk: Untersuchen Sie das ursprüngliche WLAN, die ISP-Route, die lokale Firewall, das VPN, den Proxy oder das Filtergerät.
• Timeout in allen Netzwerken: Fahren Sie mit der Prüfung von DNS, Server, Firewall und Hosting-Provider fort.

Nehmen Sie nicht an, dass ein einzelner erfolgreicher Test beweist, dass die Website für alle Nutzer gesund ist. Routing- und Adressfamilienprobleme können nur bestimmte Netzwerke betreffen.

2. DNS und beide Adressfamilien prüfen

Verwenden Sie ein DNS-Tool wie nslookup oder dig, um die für den Hostnamen zurückgegebenen IPv4- und IPv6-Adressen zu ermitteln. Vergleichen Sie jede zurückgegebene Adresse mit dem Server, Load Balancer, CDN oder einem anderen Dienst, der den Datenverkehr empfangen soll.

Achten Sie auf eine veraltete Adresse, einen unerwarteten Eintrag oder ein IPv6-Ziel, das nicht konfiguriert ist. Wenn DNS kürzlich geändert wurde, prüfen Sie die autoritativen Einträge und berücksichtigen Sie die konfigurierte Cache-Dauer, bevor Sie die Änderung anhand eines einzelnen Netzwerks bewerten.

3. Den Dienst testen, ohne sich auf den Browser zu verlassen

Führen Sie aus einem Netzwerk, das die Website erreichen können sollte, eine schreibgeschützte Anfrage aus, zum Beispiel:

curl -v --connect-timeout 10 https://[your hostname]

Die ausführliche Ausgabe zeigt, ob der Fehler bei der Hostnamenauflösung, beim Aufbau der TCP-Verbindung oder bei der HTTPS-Aushandlung auftritt. Testen Sie den tatsächlichen Dienst-Port und das tatsächliche Protokoll. Ein fehlgeschlagenes ping allein ist nicht eindeutig, da ICMP blockiert sein kann.

Wenn Sie den Dienst administrieren, vergleichen Sie das Verhalten von IPv4- und IPv6-Verbindungen separat und verwenden Sie dafür geeignete schreibgeschützte Tests. Ein Fehler nur bei einer Adressfamilie grenzt die Untersuchung auf die betreffende Route, den Listener, die Firewall-Richtlinie oder den DNS-Eintrag ein.

4. Die Konsole des Hosting-Providers prüfen

Verwenden Sie bei fehlschlagendem Netzwerkzugriff das Dashboard oder die Out-of-Band-Konsole des Providers, statt sich auf SSH zu verlassen. Bestätigen Sie, dass die Instanz läuft, die Netzwerkschnittstelle verbunden ist, die öffentliche Adresse korrekt ist und die Zustandsprüfungen des Providers keinen Fehler melden.

Wenn die Konsole anzeigt, dass der Host nicht reagiert, verwenden Sie ein autorisiertes Wiederherstellungsverfahren. Ein Neustart oder Aus- und Einschalten ist eine betriebliche Änderung: Bestätigen Sie die Berechtigung, berücksichtigen Sie die Auswirkungen auf aktive Nutzer und nicht gespeicherte Arbeit und befolgen Sie den dokumentierten Wiederherstellungsprozess des Providers.

5. Cloud- und Host-Firewall-Regeln prüfen

Prüfen Sie Security Groups, Netzwerk-ACLs und Firewall-Richtlinien des Providers auf den erwarteten eingehenden Dienst-Port, normalerweise HTTP oder HTTPS gemäß der Konfiguration. Prüfen Sie anschließend, sofern Konsolenzugriff verfügbar ist, die Firewall des Betriebssystems, beispielsweise ufw oder iptables.

Prüfen Sie Regeln, die während einer Härtungsmaßnahme, eines Deployments, einer Adressänderung oder einer Migration eingeführt wurden. Bestätigen Sie, dass Datenverkehr aus den relevanten Quellbereichen zugelassen ist und die Regel für die korrekte Schnittstelle und Adressfamilie gilt. Deaktivieren Sie den Schutz nicht pauschal. Nehmen Sie nur die kleinste autorisierte Änderung vor und dokumentieren Sie diese.

6. Ressourcenerschöpfung prüfen

Untersuchen Sie über die Provider-Konsole oder eine bestehende administrative Sitzung CPU, Arbeitsspeicher, Festplattenauslastung, Prozesslimits, lauschende Sockets und Verbindungsanzahl. Ein Rechner kann eingeschaltet erscheinen und dennoch zu stark ausgelastet sein, um neue Verbindungen anzunehmen.

Vergleichen Sie die aktuellen Werte mit den normalen Werten und prüfen Sie die Protokolle rund um den ersten Fehler. Wenn ein Dienst erschöpft ist, befolgen Sie das genehmigte Verfahren zur Kapazitätsanpassung oder Wiederherstellung, statt ihn wiederholt neu zu starten. Ein Neustart kann aktiven Datenverkehr unterbrechen und das zugrunde liegende Lastproblem verdecken.

7. Proxy, CDN oder Load Balancer prüfen

Wenn DNS auf ein CDN, einen Reverse Proxy oder einen Load Balancer verweist, überprüfen Sie, ob das Frontend den Origin am konfigurierten Port erreichen kann. Prüfen Sie die Origin-Adresse, den Status der Zustandsprüfung, TLS-Einstellungen, die Netzwerkroute und Allowlists.

Ein gesunder Origin schließt eine fehlerhafte Richtlinie oder Route zwischen Frontend und Origin nicht aus. Umgekehrt beweist ein gesundes Frontend nicht, dass der Origin Verbindungen annimmt.

8. Mit verwertbaren Nachweisen eskalieren

Dokumentieren Sie den betroffenen Hostnamen, die ungefähre Uhrzeit und Zeitzone, das Client-Netzwerk, die aufgelösten IPv4- und IPv6-Adressen, das unterschiedliche Verhalten der beiden Adressfamilien, sofern vorhanden, die ausführliche Verbindungsausgabe sowie den vom Provider gemeldeten Gesundheitszustand. Diese Nachweise helfen, DNS-, Routing-, Filter-, Host- und Vermittlerfehler voneinander zu unterscheiden.

Vorbeugung und Überprüfung der Lösung

• Überwachen Sie die Website von mehreren externen Standorten und lösen Sie bei Verbindungs-Timeouts unabhängig von HTTP-Statusfehlern einen Alarm aus.
• Dokumentieren und prüfen Sie DNS-Einträge, öffentliche Adressen, CDN-Origins und die IPv4-/IPv6-Konfiguration nach Migrationen.
• Testen Sie Änderungen an Firewalls und Security Groups über einen kontrollierten Prozess mit einem Wiederherstellungsweg über die Provider-Konsole.
• Halten Sie Reserven bei CPU, Arbeitsspeicher, Dateideskriptoren, Prozessen und Verbindungen vor, damit Lastspitzen neue Verbindungen nicht verhindern.
• Überwachen Sie den Zustand des Origins unabhängig vom Zustand des CDNs oder Load Balancers.
• Nehmen Sie Tests aus einem zweiten Netzwerk und Nachweise zu Verbindungs-Timeouts in die Checkliste für Vorfälle auf.
• Verwenden Sie für legitime Dienst-Ports ein klares, bewusst konfiguriertes Firewall-Verhalten und halten Sie gleichzeitig die erforderlichen Sicherheitsrichtlinien der Umgebung ein.

Häufig gestellte Fragen