Paketverlust ist das Netzwerkproblem, das immer wie etwas anderes aussieht. Videoanrufe ruckeln. SSH-Sessions brechen ohne Vorwarnung ab. Uploads hängen sich auf und versuchen es erneut. Man macht einen Speedtest und bekommt 100 Mbit zurück — weil Speedtests Bandbreite messen, nicht ob einzelne Pakete zuverlässig ankommen.
Dabei verschwinden irgendwo im Netzwerk 3 % der Pakete.
Was Paketverlust eigentlich bedeutet
Jede Datenübertragung wird in Pakete aufgeteilt. TCP schickt ein Paket und wartet auf eine Bestätigung. Bleibt die Bestätigung aus, überträgt TCP erneut. Die Daten kommen also trotzdem an — aber die Neuübertragungen addieren Latenz. Bis 1–2 % Verlust kommen die meisten Anwendungen gut klar. Ab 5 % verschlechtert sich TCP-Performance spürbar. Ab 10 % werden interaktive Anwendungen schwer nutzbar. Videoanrufe und Gaming über UDP verlieren einfach Frames — eine Neuübertragung gibt es nicht.
Wie man Paketverlust misst
Der globale Ping-Check zeigt ihn direkt. Jedes Timeout in den Ergebnissen ist ein verworfenes ICMP-Paket. Wenn bestimmte Regionen konstant Verlust zeigen und andere nicht, liegt das Problem auf einem spezifischen Netzwerkpfad — nicht am Server selbst.
Das MTR-Tool geht weiter: Es zeigt Verlust an jedem Hop im Pfad und lässt isolieren, wo Pakete verworfen werden, nicht nur ob.
Die häufigen Ursachen
ICMP-Filterung — der Falsch-Positiv-Klassiker
Firewalls und Server, die ICMP-Echo-Requests begrenzen oder blockieren, verursachen Paketverlust in Ping-Tests, auch wenn der Server HTTP-Traffic problemlos bedient. Wenn der HTTP-Check von allen Regionen funktioniert, aber Ping Verlust zeigt, ist das fast immer die Erklärung. Kein echtes Problem — nur eine Firewall-Konfiguration.
Überlastete Links
Ein Netzwerklink an oder nahe seiner Kapazitätsgrenze verwirft Pakete, wenn der Buffer voll ist. Auf Heimroutern heißt das Bufferbloat, auf Transit-Netzwerken zeigt es sich als Verlust auf einem bestimmten Hop im MTR-Trace — häufig zu Stoßzeiten. Der Verlust setzt an diesem Hop ein und bleibt bei allen nachfolgenden Hops bestehen.
Physikalische Fehler
Beschädigte Kabel, schlechte Stecker oder WLAN-Interferenz verursachen konstanten niedrigschwelligen Verlust. Kabelverbindungen mit einem verschlissenen Kabel können 1–5 % der Pakete verlieren. Dicht besiedelte WLAN-Umgebungen (2,4 GHz in einem Mietshaus) können in Stoßzeiten deutlich mehr verlieren. Wenn der Verlust verschwindet, sobald man von WLAN auf LAN wechselt, ist es physikalisch.
ISP- oder BGP-Routing-Probleme
Ein Link-Ausfall oder BGP-Route-Withdrawal kann dazu führen, dass Pakete über einen viel längeren Pfad geleitet werden oder ganz verloren gehen. Verlust aus bestimmten Regionen bei sauberen Ergebnissen aus anderen ist ein starkes Indiz. MTR aus der betroffenen Region zeigt, wo der Pfad abweicht.
DDoS-Mitigation
Unter einem volumetrischen Angriff werfen Upstream-Provider manchmal Traffic an der Netzwerkgrenze undifferenziert ab. Das trifft auch legitimen Traffic. Der HTTP-Check zeigt dann Timeouts von den meisten Knoten.
Konkrete Diagnose-Schritte
- Globalen Ping-Test starten. Notieren, welche Regionen Verlust zeigen — überall oder nur bestimmte Standorte?
- HTTP-Check für denselben Host. Wenn HTTP geht, wo Ping verliert, ist es ICMP-spezifisch (Firewall). Kein echtes Problem.
- MTR aus der betroffenen Region. Ersten Hop finden, wo Verlust beginnt — alles danach erbt diesen Verlust.
- Ergebnisse zu verschiedenen Tageszeiten vergleichen. Verlust nur in Stoßzeiten = Congestion. Konstanter Verlust = Hardware oder Konfiguration.
Wann den Provider kontaktieren
Kontakt zum Hosting-Provider oder Netzwerk-Team aufnehmen, wenn:
- Verlust konstant über 1 % aus mehreren Regionen liegt.
- MTR Verlust ab einem Hop zeigt, der zum Netzwerk des Providers auflöst.
- Das Problem plötzlich ohne Änderungen auf der eigenen Seite aufgetaucht ist.
Den MTR-Report-Link von Check-Host beim Kontakt mitschicken — er benennt genau den verantwortlichen Hop und beschleunigt die Diagnose erheblich.