Ein Netzwerk-Timeout entsteht, wenn eine Anfrage keine Antwort innerhalb des erwarteten Zeitfensters erhält. Prüfen Sie zuerst Latenz und Paketverlust mit ping und tracert zum Ziel. Danach kontrollieren Sie DNS-Auflösung, Router-Session-Tabelle, MTU und Firewall-Regeln. Der Fehler liegt meist auf einem dieser vier Layer.
Symptome
- Verbindungsversuche brechen nach 10 bis 60 Sekunden mit Fehlermeldung ab
- Webseiten laden teilweise, Bilder oder API-Aufrufe bleiben hängen
- VPN- oder RDP-Sitzungen trennen sich reproduzierbar nach kurzer Idle-Zeit
- ping zum Ziel funktioniert, TCP-Verbindung auf Port 443 schlägt fehl
- tracert bricht mittendrin ab oder zeigt Sternchen ab einem bestimmten Hop
Häufige Ursachen
Paketverlust auf der letzten Meile
Schlechtes WLAN, defektes Patchkabel oder ein überlasteter DSL-Uplink verwerfen einzelne Pakete. TCP wartet auf Retransmits, irgendwann läuft der Timer ab.
Falsche MTU oder PMTU-Blackhole
Wenn ein Provider ICMP Fragmentation-Needed filtert, verschwinden große Pakete stumm. Kleine Requests kommen durch, größere Antworten nicht. Klassisches Symptom bei PPPoE-Anschlüssen.
Firewall- oder NAT-Session-Timeout
Firewalls schließen inaktive TCP-Sessions oft nach 300 bis 900 Sekunden. Ohne TCP-Keepalive fällt danach jede längere Sitzung stumm aus.
DNS-Auflösung hängt
Antwortet der eingetragene Resolver nicht, wartet der Client bis zum Systemtimeout. Anwendungen melden dann Timeout, obwohl die Route intakt ist.
Serverseitige Überlast
Der Zieldienst nimmt TCP-Verbindungen an, antwortet aber nicht innerhalb der Client-Deadline. Betrifft häufig APIs unter Lastspitzen oder überbuchte Shared-Hosting-Umgebungen.
Schritt-für-Schritt-Lösung
- Reproduzieren und den Layer eingrenzen
Notieren Sie das exakte Ziel, den Port und die Uhrzeit. Testen Sie parallel von einem zweiten Gerät im selben Netz und von außerhalb (Mobilfunk-Hotspot). Tritt der Timeout nur intern auf, liegt er im LAN. Trifft es alle Standorte, ist das Ziel selbst verdächtig. - Latenz und Paketverlust messen
Führen Sie ping -n 100 <ziel> unter Windows oder ping -c 100 unter Linux aus. Werte über 1 % Paketverlust oder Jitter über 30 ms erklären sporadische Timeouts. pathping bzw. mtr zeigt anschließend, welcher Hop verliert. - Route mit tracert bzw. traceroute prüfen
tracert <ziel> deckt Routing-Schleifen und tote Hops auf. Bricht die Route beim ISP ab, öffnen Sie ein Ticket mit Zeitstempel und Trace-Ausgabe. Bricht sie im eigenen Netz ab, prüfen Sie den betroffenen Router oder Switch. - DNS isoliert testen
nslookup <hostname> 1.1.1.1 vergleicht die Auflösung mit einem externen Resolver. Löst der externe Server sauber auf, der lokale nicht, liegt das Problem im DNS-Server oder in der DHCP-Verteilung. Setzen Sie temporär einen bekannten Resolver ein und messen Sie erneut. - MTU-Problem ausschließen
ping -f -l 1472 <ziel> unter Windows sendet ein Paket mit gesetztem DF-Bit. Kommt "Paket muss fragmentiert werden", reduzieren Sie die MTU schrittweise (1500, 1492, 1468, 1400). Setzen Sie den Wert am WAN-Interface des Routers und testen Sie danach erneut. - Firewall, NAT und TCP-Keepalive kontrollieren
Sichten Sie die Firewall-Logs zum Fehlerzeitpunkt. Suchen Sie nach DROP-Einträgen für die betroffene Session. Verlängern Sie bei langlaufenden Verbindungen den TCP-Session-Timeout oder aktivieren Sie Keepalive im Client (SO_KEEPALIVE, RDP KeepAliveInterval, SSH ServerAliveInterval 60). - Router und Modem gezielt neu starten
Trennen Sie Modem und Router 30 Sekunden vom Strom, Modem zuerst wieder ein, warten bis Sync steht, dann Router. Der Reboot leert Session-Tabellen und erzwingt eine frische DHCP-Lease vom Provider. Prüfen Sie danach die Firmware-Version und spielen Sie freigegebene Updates ein. - Ergebnisse dokumentieren und Eskalation vorbereiten
Sammeln Sie ping-, tracert- und Firewall-Auszüge in einer Textdatei mit Zeitstempeln. Diese Belege beschleunigen Tickets bei ISP oder Anwendungsbetreiber erheblich. Ohne Messwerte landet jeder Fall in der Standardschleife.
Symptom, wahrscheinliche Ursache und erster Prüfschritt
| Symptom | Wahrscheinliche Ursache | Erster Prüfschritt |
|---|---|---|
| ping ok, HTTPS hängt | MTU-Blackhole oder Firewall-Drop | ping -f -l 1472 auf das Ziel |
| Alle Dienste langsam, hoher Jitter | WLAN-Störung oder ISP-Uplink voll | pathping über 5 Minuten laufen lassen |
| Nur ein Host betroffen | Serverseitige Überlast | Statusseite und HTTP-Statuscodes prüfen |
| Timeout nach ca. 15 Minuten Idle | NAT-Session-Timeout | TCP-Keepalive im Client aktivieren |
| Auflösung dauert Sekunden | DNS-Resolver träge oder ausgefallen | nslookup gegen 1.1.1.1 vergleichen |
| tracert stoppt an Hop 3 | Defekter Uplink beim Provider | Trace mit Zeitstempel an ISP senden |
So beugen Sie vor
- Monitoring mit smokeping oder PRTG einrichten, damit Paketverlust vor dem Nutzer sichtbar wird
- Firmware von Router, Modem und Firewall quartalsweise prüfen und Changelogs lesen
- TCP-Keepalive in VPN-, RDP- und SSH-Clients standardmäßig aktivieren
- MTU nach jedem Providerwechsel oder Tunnel-Setup neu verifizieren
Häufige Fragen
Wie unterscheide ich einen DNS-Timeout von einem TCP-Timeout?
Ein DNS-Timeout meldet meist "Host not found" oder "could not resolve" und tritt schon vor dem Verbindungsaufbau auf. Ein TCP-Timeout erscheint erst nach der Auflösung, häufig als "connection timed out" nach etwa 21 Sekunden. nslookup trennt die beiden Fälle sauber: Löst der Name auf, ist DNS in Ordnung und Sie suchen weiter auf Transportebene.
Warum brechen VPN-Sitzungen nach etwa 15 Minuten Inaktivität ab?
Firewalls und NAT-Router räumen inaktive TCP-Sessions aus ihrer State-Tabelle. Sind auf der Strecke Geräte mit knappen Timeouts, verschwindet die Verbindung stumm. Aktivieren Sie TCP-Keepalive im VPN-Client (typisch 60 Sekunden) oder senken Sie die Keepalive-Intervalle des VPN-Gateways. Damit bleibt die Session offiziell aktiv und wird nicht entsorgt.
Reicht ein Router-Neustart wirklich aus?
Manchmal ja, oft nein. Ein Reboot behebt volle Session-Tabellen, hängende DHCP-Leases und Speicherlecks in älterer Firmware. Wiederholt sich der Timeout innerhalb weniger Stunden, ist der Neustart nur Symptombehandlung. Dann brauchen Sie Messwerte aus ping, pathping und den Firewall-Logs, um die Ursache zu finden.