Warum EU-Server langsamer sind, als Speedtest zeigt?

Diese Situation kennen viele. Speedtest meldet 600/700 Mbit/s, doch die tatsächliche Geschwindigkeit bei der Arbeit mit Servern in der EU steigt nie über 20 Mbit/s. Die Werte unterscheiden sich um das Zehnfache oder mehr, und das wirft verständliche Fragen auf. Im Folgenden erklären wir ausführlich, woran das liegt, und zeigen, dass die Ursache fast immer bei den Backbone-Leitungen Ihres Anbieters liegt und nicht bei Ihrer Technik oder bei unserem Dienst.

Kurz zusammengefasst

Speedtest und eine echte Verbindung zu einem entfernten Server messen grundsätzlich verschiedene Dinge. Speedtest prüft die reine Kapazität Ihrer lokalen Leitung über eine sehr kurze Strecke. Die Arbeit mit EU-Servern hängt dagegen von der Latenz, vom Zustand der internationalen Leitungen und von der Qualität der Route ab. Ein hoher Speedtest-Wert bestätigt also, dass Ihre Leitung in Ordnung ist, während die geringe Geschwindigkeit in die EU auf die Physik weiter Verbindungen und die Auslastung der Transitnetze zurückgeht.

Was Speedtest tatsächlich misst

Speedtest ist darauf ausgelegt, die höchstmögliche Zahl anzuzeigen, deshalb spiegelt sein Ergebnis die echte Arbeit mit entfernten Servern nur teilweise wider.

1. Er wählt den nächsten Server. Speedtest sucht automatisch den Server mit der geringsten Latenz, und das ist meist einer im Netz Ihres Anbieters selbst oder in derselben Stadt. Der Datenverkehr dorthin nimmt eine kurze Strecke und berührt internationale Leitungen nie.

2. Er öffnet viele parallele Verbindungen. Speedtest startet mehrere gleichzeitige TCP-Streams (in der Regel 4 bis 16) und summiert deren Geschwindigkeit. So umgeht er die Grenze, an die eine einzelne Verbindung auf langen Strecken stößt (dazu gleich mehr). Echte Anwendungen arbeiten oft über eine Verbindung oder nur wenige und bekommen diesen Schub deshalb nicht.

3. Die Latenz ist minimal. Auf einer kurzen Strecke beträgt die Umlaufzeit (RTT) nur wenige Millisekunden, sodass TCP Zeit hat, auf die volle Geschwindigkeit der Leitung hochzulaufen.

Das Ergebnis: Speedtest zeigt den "Labor-Durchsatz" Ihrer Leitung, nicht die Geschwindigkeit, die Sie beim Datenaustausch mit einem Server in einem anderen Land tatsächlich erreichen.

Die Hauptursache: Bandbreiten-Verzögerungs-Produkt und das TCP-Fenster

Das ist der entscheidende technische Punkt, und er erklärt den größten Teil der Differenz.

TCP sendet Daten in "Fenstern". Der Absender schickt eine Datenportion los und wartet auf die Bestätigung des Empfangs, bevor er weitermacht. Die maximale Geschwindigkeit einer einzelnen TCP-Verbindung folgt einer einfachen Formel:

Geschwindigkeit = Fenstergröße / Latenz (RTT)

Um die Leitung vollständig zu füllen, muss das Fenster mindestens so groß sein wie das sogenannte Bandbreiten-Verzögerungs-Produkt (BDP):

BDP = Bandbreite × RTT

Rechnen wir das für eine Leitung mit 600 Mbit/s und einer Latenz zu einem EU-Server von rund 50 ms durch:

BDP = 600 000 000 Bit/s × 0,05 s = 30 000 000 Bit = 3,75 MB

Das bedeutet: Um die Leitung auszulasten, müssen sich rund 3,75 MB Daten gleichzeitig "in der Luft" befinden. Steckt eine Seite jedoch bei einer alten oder begrenzten Fenstergröße fest (die klassischen 64 KB ohne Window Scaling), liegt die Obergrenze für eine einzelne Verbindung bei:

Geschwindigkeit = 65 536 Byte × 8 Bit / 0,05 s ≈ 10,5 Mbit/s

Genau deshalb erreicht eine einzelne Verbindung zu einem entfernten Server höchstens 10 bis 20 Mbit/s, selbst wenn die Leitung selbst für Hunderte Megabit ausgelegt ist. Auf einer kurzen Strecke (RTT von 2 ms) würde dasselbe Fenster über 260 Mbit/s liefern, und genau darum tritt das Problem in Speedtest nie auf. Je höher die Latenz, desto stärker der Effekt, und das ist kein Hardwarefehler, sondern eine grundlegende Eigenschaft des Protokolls.

Latenz (RTT) und die Physik langer Verbindungen

Die Latenz auf langen Strecken setzt sich aus mehreren Teilen zusammen, und einige davon lassen sich überhaupt nicht beseitigen.

Licht breitet sich in Glasfaser mit etwa 200 000 km/s aus, also deutlich langsamer als im Vakuum, weil der Brechungsindex des Glases bremst. Jede tausend Kilometer Strecke fügen rund 5 ms in eine Richtung hinzu, also etwa 10 ms für den Hin- und Rückweg. Eine reale Route verläuft zudem selten geradlinig und ist daher meist länger als die geografische Entfernung.

Dazu kommt die Verzögerung an jedem Zwischenknoten (Router): das Verarbeiten des Pakets, das Einreihen in die Warteschlange und das Weiterleiten. Auf dem Weg zu einem EU-Server gibt es typischerweise 10 bis 20 solcher Knoten (Hops), und jeder steuert seinen Anteil bei. Je höher die resultierende RTT, desto niedriger die Obergrenze für eine einzelne Verbindung nach der obigen Formel.

Paketverlust und seine Wirkung auf TCP

Schon geringe Paketverluste auf einer internationalen Leitung senken die erreichbare Geschwindigkeit drastisch. TCP wertet ein verlorenes Paket als Zeichen von Überlast, drosselt daraufhin die Übertragung und baut die Geschwindigkeit anschließend wieder auf. Diesen Zusammenhang beschreibt die Mathis-Gleichung:

Geschwindigkeit ≈ MSS / (RTT × √p)

Dabei ist MSS die maximale Segmentgröße (meist etwa 1460 Byte), RTT die Latenz und p der Anteil der verlorenen Pakete. Die Formel zeigt: Die Geschwindigkeit sinkt umgekehrt zur Wurzel aus der Verlustrate und hängt direkt von der Latenz ab.

In der Praxis wirkt das dramatisch. Bei einer RTT von 50 ms und einer Standard-MSS begrenzt schon 0,1 Prozent Verlust eine einzelne Verbindung auf etwa 73 Mbit/s, 1 Prozent Verlust drückt sie auf rund 23 Mbit/s und 2 Prozent Verlust auf unter 17 Mbit/s. Auf langen Transitstrecken sind Verluste von 1 bis 2 Prozent zur Hauptverkehrszeit völlig normal und oft der größte einzelne Begrenzer.

Routing und Peering

Der Weg Ihres Datenverkehrs zu einem EU-Server verläuft nicht direkt. Er führt über eine Kette von Betreibern und das Routing-Protokoll BGP, das eine Route nach kommerziellen und technischen Kriterien wählt und nicht nach der kürzesten Entfernung.

Daraus ergeben sich mehrere typische Probleme. Die Route kann ungünstig verlaufen, etwa über ein Drittland, was sowohl die Latenz als auch das Verlustrisiko erhöht. Der Verkehr passiert die Übergänge zwischen Netzen (Peering-Punkte und Transitleitungen), und ist einer dieser Übergänge überlastet, bricht genau dort die Geschwindigkeit ein. Auch asymmetrisches Routing kommt häufig vor, bei dem Pakete hin und zurück verschiedene Wege nehmen, was die Diagnose erschwert. Und bei günstigen Anbietern wird die internationale Anbindung mitunter nach dem Restprinzip eingekauft, sodass ihre Kapazität zur Hauptverkehrszeit nicht ausreicht.

Überlastung der internationalen Leitungen Ihres Anbieters

Der lokale Verkehr (innerhalb der Stadt und innerhalb des Landes) hat bei den meisten Anbietern reichlich Reserve, deshalb zeigt Speedtest zu einem nahen Server stets eine hohe Zahl. Internationale Leitungen dagegen sind teurer und werden in begrenztem Umfang eingekauft. Zur abendlichen Hauptverkehrszeit, wenn die Last am höchsten ist, werden diese Leitungen zum Nadelöhr. Das erklärt, warum die Geschwindigkeit in die EU im Tagesverlauf merklich schwanken kann, während der lokale Speedtest gleichbleibend hoch ist.

Weitere technische Faktoren

Über die Hauptursachen hinaus beeinflussen noch einige Dinge die Geschwindigkeit zu einem entfernten Server.

MTU und Fragmentierung. Ist die MTU entlang der Route kleiner als erwartet, werden Pakete fragmentiert, was die Effizienz senkt. Eine fehlerhaft eingerichtete PMTUD (Path MTU Discovery) kann zu "schwarzen Löchern" und hängenden Übertragungen führen.

Bufferbloat. Überdimensionierte Puffer an Zwischenknoten erhöhen die Latenz unter Last und bringen die Flusskontrolle von TCP durcheinander, was die reale Geschwindigkeit zusätzlich senkt.

Shaping und Priorisierung (QoS). Manche Anbieter drosseln internationalen Verkehr oder eine bestimmte Verkehrsart gezielt oder stufen sie zurück, was die Geschwindigkeit direkt beeinflusst.

Protokoll-Overhead. Die Header von TCP, IP und Verschlüsselung (TLS) belegen einen Teil der Bandbreite. Auf einer kurzen Strecke fällt das nicht auf, in Kombination mit Verlust und Latenz auf einer langen Strecke summiert es sich jedoch.

Ihre lokale Umgebung. WLAN statt Kabel, ein überlasteter Heimrouter, Antivirensoftware oder ein VPN auf dem Gerät können die reale Geschwindigkeit ebenfalls senken, daher lohnt es sich, diese bei der Diagnose auszuschließen.

Warum das kein Problem der Hardware oder des Dienstes ist

Ein hoher Speedtest-Wert ist ein eindeutiger Beleg dafür, dass Ihre Technik, die Verkabelung und die lokale Leitung in Ordnung sind und die vorgesehene Geschwindigkeit liefern. Der Einbruch bei der Arbeit mit EU-Servern stammt von der Latenz auf der langen Strecke, von der Fenstergrenze einer einzelnen TCP-Verbindung, von Paketverlust und vom Zustand der internationalen Leitungen Ihres Anbieters. All diese Faktoren liegen außerhalb unseres Dienstes und außerhalb Ihrer Technik: Sie betreffen den Netzabschnitt zwischen Ihrem Anbieter und den Backbone-Betreibern.

So prüfen Sie es selbst

Um die Ursache zu bestätigen, führen Sie ein paar einfache Tests durch.

1. Starten Sie Speedtest manuell und wählen Sie einen Server im betreffenden EU-Land (zum Beispiel Deutschland oder die Niederlande, wo sich unsere Server befinden). Das zeigt die echte Geschwindigkeit entlang genau der Route, die in der Praxis genutzt wird, und nicht zum nächsten lokalen Server.

2. Verfolgen Sie die Route. Der Befehl tracert (Windows) oder traceroute (macOS, Linux) zu unserem Server zeigt die Kette der Knoten und die Latenz an jedem einzelnen. Für ein klares Bild von Verlust und Latenz eignet sich das Werkzeug mtr (oder WinMTR unter Windows) besonders, und es läuft am besten einige Minuten lang zur Hauptverkehrszeit.

3. Vergleichen Sie eine Verbindung mit mehreren. Ist ein Download über mehrere Streams schnell, ein einzelner Stream aber langsam, bestätigt das direkt die TCP-Fenstergrenze auf der langen Strecke.

4. Falls Sie die technischen Mittel haben, nutzen Sie iperf3, um den Durchsatz zum entfernten Knoten direkt zu messen, sowohl mit einem als auch mit mehreren Streams.

Was Sie tun können

Zeigen Ihre Tests hohe Latenz oder Paketverlust auf dem internationalen Abschnitt, lohnt es sich, Ihren Anbieter mit konkreten Daten zu kontaktieren: der Routenverfolgung und einer mtr-Messung mit Angabe der Tageszeit. Die Route anzupassen oder die internationale Anbindung auszubauen, liegt in der Verantwortung des Anbieters. Wir stellen Ihnen gern die Adressen unserer Server für eine gezielte Diagnose bereit und helfen, die Ergebnisse einzuordnen.

Fazit

Ein Speedtest-Wert von 600/700 Mbit/s bestätigt, dass Ihre Leitung in Ordnung ist. Der Einbruch auf 20 Mbit/s bei der Arbeit mit EU-Servern ist zu erwarten und stammt von der Latenz auf der langen Strecke, der Fenstergrenze einer einzelnen TCP-Verbindung, von Paketverlust und von der Auslastung der internationalen Leitungen Ihres Anbieters. Mit Ihrer Technik oder unserem Dienst hat das nichts zu tun, und die genaue Ursache lässt sich mit einer einfachen Routendiagnose feststellen.

Aktualisiert am: 21/06/2026