Warum Ihr WireGuard VPN auf Auslandsreisen langsam sein kann

Aktualisiert: 2. November 2026

Einleitung

Viele Nutzer sind überrascht, wenn sie sich aus einem anderen Land mit dem WireGuard-Server ihres GL.iNet-Routers verbinden und feststellen, dass die Internetgeschwindigkeit deutlich unter der symmetrischen Gigabit-Geschwindigkeit zu Hause oder der ähnlich schnellen Verbindung am Aufenthaltsort im Ausland, etwa in einer Airbnb-Unterkunft, liegt. Mehrere Faktoren können zu diesem Leistungsunterschied beitragen: Routing und Peering des Internetanbieters, Netzwerküberlastung, die Verarbeitungskapazität des Routers und das Verhalten der Anwendungen, die durch den VPN-Tunnel kommunizieren.

Was ist Latenz und warum ist sie wichtig?

Latenz ist die Zeit, die Daten von Ihrem Gerät zum VPN-Server und zurück benötigen. Sie wird häufig in Millisekunden (ms) gemessen. Verbindet sich beispielsweise Ihr GL.iNet-Router in Vietnam mit einem VPN-Server in Texas, kann die Umlaufzeit (RTT) leicht 250-300 ms betragen.

Hohe Latenz verringert nicht grundsätzlich die Paketweiterleitungskapazität von WireGuard. Anders als TCP verwendet die UDP-basierte Datenübertragung von WireGuard weder Bestätigungen noch Überlastungsfenster, um die Übertragung gewöhnlicher Datenpakete zu regeln. Ein WireGuard-Tunnel mit 300 ms RTT kann theoretisch denselben Paketdurchsatz aufrechterhalten wie einer mit 3 ms RTT, sofern verfügbare Bandbreite, Paketverluste und Verarbeitungskapazitäten vergleichbar sind.

Anwendungen, die durch den VPN-Tunnel kommunizieren, verwenden häufig TCP oder QUIC und sind damit auf Rückmeldungen des empfangenden Endpunkts angewiesen. Die Weiterleitung über einen weit entfernten VPN-Server kann die RTT für diese Anwendungen erhöhen. Das kann ihre Leistung beeinflussen, zeigt aber nicht, ob das Transportverhalten, der Netzwerkpfad oder die Routerverarbeitung den Engpass verursacht.

Auch das Anwendungsverhalten ist wichtig. Das Öffnen von Dateien in einem entfernten freigegebenen Ordner oder das Kopieren vieler kleiner Dateien kann wiederholte Anfragen und Antworten zwischen Gerät und Server erfordern. Jeder notwendige Umlauf erhöht die Verzögerung. Solche Aufgaben können deshalb langsam wirken, obwohl die Verbindung eine einzelne große Datei schnell herunterladen kann. Ein größeres TCP-Empfangsfenster beseitigt diese Wartezeiten auf Anwendungsebene nicht.

Wie TCP-Durchsatz und Latenz zusammenhängen

Ein nützlicher Zusammenhang zum Verständnis des TCP-Durchsatzes bei hoher Latenz ist das Bandbreiten-Verzögerungsprodukt (BDP):

Bandbreiten-Verzögerungsprodukt = Durchsatz x RTT

Das BDP beschreibt, wie viele Daten unterwegs sein müssen, also gesendet, aber noch nicht bestätigt, um bei einer bestimmten RTT einen bestimmten Durchsatz aufrechtzuerhalten. Dieser Zusammenhang allein bestimmt jedoch weder den maximal erreichbaren Durchsatz noch den begrenzenden Faktor einer konkreten Netzwerkverbindung.

Um beispielsweise bei 288 ms RTT einen TCP-Durchsatz von 100 Mbps aufrechtzuerhalten, müssen ungefähr 3.6 MB unbestätigte Daten unterwegs sein, sofern Netzwerkpfad und Endpunkte diese Rate ansonsten unterstützen.

Hier einige wichtige Definitionen:

• TCP-Empfangsfenster (rwnd): Die zusätzliche Datenmenge, die das empfangende Gerät entsprechend dem freien Platz im Empfangspuffer als aufnehmbar meldet.
• TCP-Überlastungsfenster (cwnd): Die Menge unbestätigter Daten, die der Sender entsprechend seinem Überlastungssteuerungsalgorithmus und den Netzwerkbedingungen aufrechterhalten darf.
• Durchsatz: Die effektive Rate, mit der Daten erfolgreich übertragen werden
• RTT (Umlaufzeit): Die Zeit, die Daten zwischen Endpunkten und eine Antwort für den Rückweg benötigen.

Die effektive Grenze für ausstehende TCP-Daten beim Sender ergibt sich neben weiteren Einschränkungen aus dem kleineren Wert von Empfangs- und Überlastungsfenster. Diese Unterscheidung ist wichtig: Ein ausreichend großes Empfangsfenster garantiert keinen hohen Durchsatz, wenn die Überlastungssteuerung oder der Netzwerkpfad verhindert, dass der Sender genügend unbestätigte Daten aufrechterhält.

Paketverluste können den TCP-Durchsatz verringern, weil sie erneute Übertragungen erfordern und den Sender zur Verkleinerung seines Überlastungsfensters veranlassen. Bei hoher Latenz können Rückmeldungen und Wiederherstellung länger dauern. Ein großes Empfangsfenster allein reicht dann möglicherweise nicht aus, um hohe Übertragungsgeschwindigkeiten zu halten.

Ein konkretes Beispiel eines GL.iNet-Subreddit-Mitglieds

Ein Mitglied des GL.iNet-Subreddits in Vietnam meldete folgende Ergebnisse bei der Verbindung mit seinem WireGuard-Server zu Hause in Texas, der auf einem GL.iNet Flint 2-Router lief.

• Serverstandort: Texas, USA
  
  • Lokale Geschwindigkeiten (symmetrische Glasfaser): 700 Mbit/s Download / 940 Mbit/s Upload
• Clientstandort: Vietnam
  
  • Lokale Geschwindigkeiten (ohne VPN): 455 Mbit/s Download / 634 Mbit/s Upload
    
  • Lokale Geschwindigkeiten (mit aktiviertem WireGuard-VPN-Client): 47.3 Mbit/s Download / 12.1 Mbit/s Upload, 288 ms Ping

Denken Sie daran: Beim Herunterladen über einen VPN-Server zu Hause hängt der maximale Download-Durchsatz auch von der Upload-Geschwindigkeit des heimischen Internetanschlusses ab.

Diese Messungen zeigen einen erheblichen Unterschied zwischen der lokalen Internetleistung und der Leistung über die internationale WireGuard-Verbindung. Die Tests messen jedoch nicht unbedingt gleichwertige Netzwerkpfade. Ein lokaler Geschwindigkeitstest in Vietnam kann einen nahe gelegenen Testserver verwenden, während der über das VPN geleitete Datenverkehr zunächst die internationale Verbindung nach Texas durchqueren muss. Dabei kommen andere ISP-Transitnetze, Peering-Vereinbarungen und mögliche Überlastungspunkte ins Spiel. Zwei internationale Verbindungen mit ähnlicher Latenz können je nach Qualität ihrer Routen sehr unterschiedliche Geschwindigkeiten liefern. Die VPN-Verbindung meldete zwar etwa 288 ms RTT, doch dieser Wert allein belegt nicht, dass Latenz die Hauptursache des geringeren Durchsatzes war. Paketverluste, ineffizientes internationales Routing, Überlastung oder andere Faktoren können beigetragen haben.

Betrachten wir zunächst einige häufige Faktoren, die den Netzwerkdurchsatz beeinflussen:

1. Leistungsschwankungen beim Internetanbieter und Überlastung in Ihrer Nachbarschaft: Der Durchsatz kann je nach Überlastung und Netzwerkauslastung erheblich schwanken.
2. Wi-Fi-Leistung: Stark abhängig von der räumlichen Umgebung, Störungen durch andere Funkgeräte, der Leistungsfähigkeit des Clientgeräts und dem grundsätzlich halbduplexen Betrieb von Wi-Fi im Gegensatz zu Vollduplex-Ethernet
   • Eine ausführliche Erklärung zur realistischen Wi-Fi-Leistung finden Sie hier: https://www.wiisfi.com/
3. ISP-Routing und internationales Peering: Länderübergreifender Datenverkehr kann mehrere unabhängig betriebene Netzwerke durchqueren. Überlastete Peering-Verbindungen, ineffiziente Routen oder Paketverluste können den Durchsatz erheblich verringern, selbst wenn beide Endpunkte schnelle lokale Internetanschlüsse haben. Zwei internationale Routen mit ähnlichen RTT-Werten können sehr unterschiedliche Geschwindigkeiten liefern.

Lokale ISP-Überlastung und internationale Routingbedingungen liegen in der Regel außerhalb der direkten Kontrolle des Nutzers. Tests mit anderen Anbietern oder Netzwerkpfaden können aber Leistungsunterschiede aufzeigen. Wenn beide Endpunkte lokal schnelles Internet haben, die Fernverbindung aber langsam ist, sind ungünstiges internationales Routing oder überlastetes Peering häufige Verdachtsmomente. Ein Test über einen anderen Anbieter, etwa in einem Café, oder einen Hotspot kann helfen zu erkennen, ob die Verlangsamung auf dem Übertragungsweg entsteht. Wi-Fi-Beschränkungen lassen sich oft durch kabelgebundene Ethernet-Verbindungen reduzieren. Bei der Fehlersuche zum VPN-Durchsatz sollten auch Verarbeitungsgrenzen des Routers und MTU-Probleme untersucht werden.

Letztlich müssen Sie bei einer langsamen internationalen VPN-Verbindung zwischen den Grenzen des Netzwerkpfads, des VPN-Routers und der durch den Tunnel kommunizierenden Anwendungen unterscheiden.

TCP Window Scaling für bessere Leistung

Ursprünglich war das TCP-Empfangsfenster auf etwa 64 KB begrenzt. Window Scaling (RFC 7323) erhöht diese Grenze auf etwa 1 GiB, und moderne Betriebssysteme passen das Fenster automatisch an. Beispielsweise kann die von Microsoft dokumentierte Autotuning-Einstellung Normal Empfangsfenster von etwa 16.8 MB darstellen. Moderne TCP-Verbindungen sind daher nicht grundsätzlich auf 64 KB begrenzt.

Source: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Wie TCP-Fenstergrenzen und RTT zusammenwirken

Bei einer TCP-Verbindung mit fester Grenze für ausstehende Daten beträgt die ungefähre fensterbedingte Durchsatzobergrenze:

Durchsatz in Bit pro Sekunde ≈ Fenstergrenze in Byte × 8 ÷ RTT in Sekunden

Bei gleichbleibender Fenstergrenze führt eine höhere RTT zu einer niedrigeren fensterbedingten Obergrenze. Die folgenden Beispiele veranschaulichen diesen Zusammenhang; sie sagen den tatsächlichen VPN-Durchsatz nicht voraus.

Theoretische fensterbedingte Obergrenzen (Fenster ÷ RTT), mit 1 MB = 1,000,000 Byte. Dies sind Veranschaulichungen und keine Vorhersagen des tatsächlichen VPN-Durchsatzes.

Der tatsächliche Durchsatz hängt auch von Überlastungssteuerung, Paketverlusten, verfügbarer Bandbreite und Verarbeitungsgrenzen ab. Mehrere TCP-Verbindungen können manchmal einen höheren Gesamtdurchsatz erreichen. Es gibt jedoch keinen allgemeinen RTT-Schwellenwert, ab dem sie die verfügbare Bandbreite nicht mehr ausschöpfen können.

Im Beispiel Vietnam–Texas hätte eine hypothetische einzelne TCP-Verbindung mit höchstens 2 MB ausstehenden Daten bei 288 ms RTT eine fensterbedingte Obergrenze von etwa 55.6 Mbps. Die Zeile mit 300 ms in der Tabelle liegt wegen der höheren RTT etwas darunter. Das erklärt jedoch nicht, warum der Nutzer 47.3 Mbps gemessen hat.

Ohne die Anzahl der Testverbindungen, die tatsächlichen TCP-Fenster und die Netzwerkbedingungen zu kennen, lässt sich nicht feststellen, ob eine Fenstergrenze, Überlastung, Paketverluste, ISP-Routing oder etwas anderes den Engpass verursacht hat.

Was bestimmt Ihre TCP-Fenstergröße?

TCP-Fenstergrößen gehören zu einzelnen Verbindungen und können sich während einer Datenübertragung ändern. Die obigen Beispielwerte sollten daher nicht als feste Einstellungen verstanden werden, die für jede Verbindung auf Ihrem Gerät gelten.

Das Betriebssystem des empfangenden Geräts verwaltet dessen Empfangsfenster. Seine Größe hängt unter anderem vom verfügbaren Empfangspuffer, vom Autotuning und den Grenzen des Betriebssystems, von Anwendungseinstellungen und davon ab, wie schnell die Anwendung eingehende Daten verarbeitet. Beim Herunterladen einer Datei auf Ihren Laptop meldet dieser dem sendenden Server sein Empfangsfenster. Beim Hochladen meldet der empfangende Server sein Fenster an Ihren Laptop.

Der Sender verwaltet sein Überlastungsfenster separat anhand seines Überlastungssteuerungsalgorithmus und der Netzwerkrückmeldungen. Dies kann die Menge ausstehender Daten begrenzen, selbst wenn der Empfänger ein großes Fenster meldet. In einer typischen WireGuard-Konfiguration zwischen Routern gehören diese TCP-Fenster den kommunizierenden Computern und Servern; sie sind keine einzelne Fenstergrößeneinstellung auf den VPN-Routern.

Wie können Sie eine tatsächliche Verbindung prüfen?

Wenn Sie mit Paketanalyse vertraut sind, können Sie das gemeldete TCP-Empfangsfenster in Wireshark anzeigen. Erfassen Sie bei einer Router-zu-Router-Konfiguration den Datenverkehr auf dem Computer, der die Übertragung durchführt. Starten Sie die Aufzeichnung vor dem Aufbau einer neuen TCP-Verbindung, damit Wireshark den anfänglichen Handshake und die Aushandlung der Fensterskalierung aufzeichnet. Untersuchen Sie während eines Downloads eine ausgehende TCP-Bestätigung Ihres Computers für diese Übertragung, erweitern Sie den Abschnitt Transmission Control Protocol und suchen Sie nach Calculated window size. Dieser Wert zeigt das Empfangsfenster, das Ihr Computer zu diesem Zeitpunkt gemeldet hat, einschließlich Skalierung, sofern Wireshark den ausgehandelten Skalierungsfaktor kennt.

Der Wert kann sich während der Übertragung ändern. Er zeigt weder direkt das Überlastungsfenster des Senders noch belegt er, dass das Empfangsfenster die Leistung begrenzt. Auch die Prüfung der Autotuning-Einstellung eines Betriebssystems verrät nicht, welches Fenster eine einzelne Verbindung aktuell tatsächlich meldet.

Ein weiteres Praxisbeispiel: höhere Geschwindigkeiten ohne niedrigeren Ping

In einem anderen Supportfall untersuchte ich eine langsame Tailscale-VPN-Verbindung. Tailscale verwendet WireGuard-Verschlüsselung, doch seine Relay-Optionen können verschlüsselte Pakete unterschiedlich transportieren: DERP-Relays verwenden TCP-basierte Verbindungen, Tailscale Peer Relays dagegen UDP. Das unterscheidet sich von einer eigenständigen WireGuard-Verbindung, die verschlüsselte Pakete normalerweise direkt über UDP sendet. In diesem Fall wurden beide Relays auf derselben AWS Lightsail-Instanz selbst gehostet. Verglichen wurden also zwei privat gehostete Relay-Methoden und nicht die öffentlichen DERP-Server von Tailscale.

Der Internetanschluss des Clients erreichte im Test etwa 83 Mbps; beim Internetanschluss des VPN-Servers wurde eine Upload-Geschwindigkeit von etwa 40.6 Mbps gemessen. Folgende Download-Geschwindigkeiten wurden beobachtet:

SQM steht für Smart Queue Management, eine Routerfunktion zur Verwaltung von Paketwarteschlangen und zur Verringerung übermäßiger Verzögerungen unter Last. Bei diesem Vergleich wurde SQM auf dem Reiserouter auf der Clientseite aktiviert beziehungsweise deaktiviert.

SQM ist keine Universallösung für langsame VPN-Verbindungen. Wenn es nur einen einzigen verschlüsselten Tunnel-Datenstrom sieht, kann es die darin verborgenen Anwendungsverbindungen nicht einzeln priorisieren. Es kann weiterhin die gemeinsame Paketwarteschlange verwalten, doch das verringert die Wartezeit nur dort, wo übermäßige Warteschlangenbildung ein Problem darstellt, das SQM beheben kann. Wenn es keine übermäßige Warteschlangenbildung gibt, die SQM wirksam kontrollieren kann, können unnötig restriktive Bandbreiteneinstellungen oder zusätzlicher Verarbeitungsaufwand den Durchsatz verringern, ohne das Reaktionsverhalten zu verbessern.

Die Latenz blieb ungefähr gleich. Dennoch lieferte das UDP-basierte Relay mit aktiviertem wie deaktiviertem SQM einen erheblich höheren Durchsatz. Die größte Verbesserung ging mit dem Wechsel der Relay-Methode einher, nicht mit niedrigerem Ping oder dem Abschalten von SQM.

Ein möglicher Faktor ist der TCP-basierte Transport von DERP. Jedes Tailscale-Gerät verbindet sich über TCP mit dem DERP-Relay, sodass verschlüsselte Pakete auf beiden Seiten des Relays getrennte TCP-Verbindungen durchlaufen. Mehrere Anwendungsverbindungen innerhalb des Tunnels können diese äußeren TCP-Verbindungen gemeinsam nutzen. Gehen Daten auf einer äußeren TCP-Verbindung verloren, müssen nachfolgende Daten möglicherweise auf die erneute Übertragung warten, bevor sie zugestellt werden können. Dadurch können mehrere Anwendungen gleichzeitig verzögert werden. Ein UDP-basiertes Peer Relay vermeidet diese zusätzliche geordnete TCP-Transportschicht. TCP-Anwendungen im Tunnel verwenden jedoch weiterhin ihre eigenen Bestätigungen und ihre eigene Überlastungssteuerung.

Da beide Relays auf derselben Instanz liefen, blieben Relay-Host und Standort konstant. Das stützt die Interpretation, dass Transport oder Implementierung des Relays zur Verbesserung beitrugen, statt lediglich das Relay näher zu den Nutzern zu verlagern. Derselbe Host garantiert jedoch keine identischen Netzwerkpfade oder Bedingungen. Der Vergleich isoliert TCP gegenüber UDP daher nicht als alleinige Ursache.

Dies sind Beobachtungen aus einem einzelnen Supportfall und keine garantierten Leistungswerte. Sie zeigen jedoch, warum Latenz allein nicht genügt, um VPN-Geschwindigkeiten vorherzusagen.

Fazit

Dieser Artikel hat hoffentlich verständlicher gemacht, warum Download- und Upload-Geschwindigkeiten über weitreichende WireGuard-VPN-Verbindungen erheblich niedriger sein können als die Internetgeschwindigkeiten an beiden Endpunkten. Entscheidend ist die Unterscheidung, dass WireGuard selbst keine RTT-abhängige Durchsatzobergrenze vorgibt. Seine UDP-basierte Datenübertragung implementiert für gewöhnliche Datenpakete weder TCP-typische Überlastungsfenster noch Bestätigungen oder erneute Übertragungen.

TCP- und QUIC-Anwendungen, die durch den Tunnel kommunizieren, unterliegen jedoch weiterhin ihren eigenen Mechanismen zur Überlastungssteuerung und Zuverlässigkeit. Höhere RTT erhöht die Menge ausstehender Daten, die für einen bestimmten Durchsatz erforderlich ist. Mehrere Verbindungen können die Gesamtleistung verbessern, doch weder RTT noch Verbindungsanzahl allein bestimmen die erreichbare Geschwindigkeit. Die tatsächliche Leistung hängt auch von Paketverlusten, Netzwerküberlastung, ISP-Routing und -Peering, verfügbarer Bandbreite, MTU-Konfiguration und Verarbeitungskapazität des VPN-Routers ab.

In einer typischen GL.iNet-WireGuard-Konfiguration zwischen Routern werden TCP-Verbindungen zwischen den Endgeräten und ihren Zielservern aufgebaut. Die VPN-Router verschlüsseln, entschlüsseln und leiten Pakete weiter, ohne die TCP-Empfangsfenster dieser Ende-zu-Ende-Verbindungen direkt zu steuern. Hardwaregrenzen des Routers können den Durchsatz verschlüsselter Pakete beeinflussen, sollten aber nicht mit Einschränkungen des TCP-Empfangsfensters verwechselt werden.

Beginnen Sie bei einer langsamen internationalen WireGuard-Verbindung damit, den Internetanschluss an jedem Ort zu testen, möglichst über kabelgebundenes Ethernet. Prüfen Sie, ob sich die VPN-Leistung zu anderen Tageszeiten oder über einen anderen Internetanschluss, etwa einen mobilen Hotspot, verändert. Diese Vergleiche können helfen einzugrenzen, wo die Verlangsamung entsteht. Für die genaue Ursache können jedoch weitere Tests nötig sein. Hohe Latenz kann Anwendungen verlangsamen, sollte aber nicht automatisch als alleinige Erklärung für eine langsame VPN-Verbindung gelten.

Künftig möchte ich mit strategisch platzierten UDP-Relays experimentieren, um zu prüfen, ob alternative Routen die WireGuard-VPN-Leistung zwischen den USA und Asien verbessern können.

Weitere Informationen und Tipps zur Fehlerbehebung und zum Verständnis Ihrer WireGuard-VPN-Konfiguration finden Sie im folgenden GL.iNet-Forenbeitrag: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502