VPN funktioniert sogar über Satellit: So beschleunigst du deinen Tunnel bei hohen Latenzen im Jahr 2026

Warum hohe Latenz VPN lahmlegt und wie du das vermeidest

Hohe Latenz und VPN: Wo die Sekunden verloren gehen

Hohe Latenz lässt das Internet wie ein Funkgerät wirken: Du sprichst, wartest, antwortest – und das immer wieder. Mit VPN ist es nicht besser, oft sogar schlimmer. Jeder zusätzliche Round-Trip summiert sich auf Hunderte Millisekunden und wenn darüber noch TCP läuft, wird selbst einfaches Surfen spürbar langsamer. 80 Millisekunden Latenz im 4G-Netz? Das geht gut. Satellit GEO mit 600–800 ms? Jede Kleinigkeit wird zum Flaschenhals.

Die schlechte Nachricht: Latenz verschwindet nicht. Die gute: Wir können Tunnel, Stack und Protokoll so anpassen, dass du das Maximum herausholst. Keine Magie, sondern Ingenieurskunst. Das richtige Protokoll, ein großes TCP-Fenster, sorgfältig eingestelltes MTU, vorhersagbare Warteschlangen – und plötzlich bremst dein VPN nicht mehr. Und das fühlt sich richtig gut an, oder?

Typische Symptome bei Satelliten- und Mobilfunknetzen

Du nutzt eine Satellitenverbindung oder Mobile Netze und bemerkst ruckelnden Traffic, Stocken und Verzögerungen von mehreren Sekunden. Videokonferenzen laufen mal flüssig, mal hängen sie. VPN-Verbindungen „hängen“ gelegentlich im Handshake. Pakete scheinen durch Watte zu fliegen. Kein Mythos von überlasteten Funkmasten – es ist die Kombination aus Latenz, Jitter und 0,5–2 % Paketverlust. Insgesamt ein ziemlich unangenehmes Erlebnis.

Das Wichtigste: Das Problem besteht aus kleinen Dingen – zu viele Handshakes, falsche Protokollwahl, zu kleine Puffer, falsches MTU, fehlende AQMs. Kleinigkeiten beseitigen, Minuten sparen.

Kernidee: Round-Trips minimieren, Fenster aufpumpen, Verluste zähmen

Der Fahrplan für high-latency-Verbindungen ist simpel: weniger Handshakes, weniger ACK-Abhängigkeiten, mehr parallele Paketzustellung, adaptive Überlaststeuerung und keine Fragmentierung. Kombiniert mit Monitoring und Autoanpassung entsteht ein verlässliches, schnelles und „lebendiges“ VPN – selbst wenn der Server fern am anderen Ende der Welt steht und der Client in freier Natur, auf dem Meer oder im Bus zwischen den Städten unterwegs ist.

VPN-Protokollwahl für hohe Latenz

WireGuard: Minimalismus, UDP und Geschwindigkeit

WireGuard bleibt 2026 der »Goldstandard« für Mobilfunk- und Satellitenverbindungen: minimale Handshakes, kompakte Header, zuverlässiger UDP-Betrieb, resilient gegen Jitter und bis zu 1–2 % Paketverlust bei richtiger Konfiguration. Kein schwerfälliger Verbindungsaufbau, keine unnötigen Spielereien. Perfekt für hohe Latenzen: weniger Protokollaufwand – weniger Verzögerung.

Wenn du auf Einfachheit, leichte Handhabung und hohe Performance selbst auf schwacher Hardware setzt, ist WireGuard die erste Wahl. Aber: Manche Unternehmensumgebungen verlangen IPsec oder TLS-basierte VPNs. Dann gilt es, eine Alternative zu wählen und sie auf Latenz zu optimieren.

IKEv2/IPsec: Industriestandard mit verlässlicher Mobilität

IKEv2 über UDP mit NAT-T ist in großen Netzwerken bewährt. Es meistert Adresswechsel problemlos, was in mobilen Szenarien wichtig ist, und läuft bei sauberer Konfiguration recht flott. 2026 haben viele Clients und Gateways IKEv2 optimiert: schneller Rekey, SA-Neuerstellung ohne merkliche Pausen, Hardwarebeschleunigung für AES-GCM. Perfekt, wenn du Kompatibilität und strenge Policies brauchst.

Nachteile sind das etwas schwere Handshake und höherer Protokoll-Overhead im Vergleich zu WireGuard. Bei langen Sessions ist das allerdings unkritisch, wenn MTU passt und keepalive sowie Lebenszeiten gut abgestimmt sind.

OpenVPN UDP und DCO: Klassiker mit Turbo

OpenVPN im UDP-Modus mit Data Channel Offload (DCO) erhält neues Leben. DCO verlagert Kryptooperationen in den Kernel, reduziert Latenz und CPU-Last. Für hohe Latenzen ideal: weniger Kopieroperationen, geringere Verzögerungen im User-Space, schnellere Paketverarbeitung.

Wichtig: Kein TCP-over-TCP! Das führt garantiert zu »Einfroren« bei Verlusten und hohen RTTs. 2026 empfehlen wir weiterhin UDP mit sauberem mssfix und dem Abschalten unnötiger renegotiate-Aufrufe.

TCP vs UDP: Wo lassen sich Millisekunden gewinnen

Warum TCP im Tunnel oft »untergeht«

TCP in VPN-Tunneln kämpft mit doppelter Staukontrolle: Der äußere Kanal mit Verlusten und RTT belastet, und der innere TCP-Stream reagiert obendrein auf Encapsulation. Resultat: langsames Fensterwachstum, Neustarts nach Timeouts, das berühmte »Wellenphänomen«. Besonders auf GEO-Satelliten: Ein Timeout bedeutet Sekundenverlust.

Nutze wenn möglich VPN über UDP und überlass das TCP-Flow-Control den Applikationen ohne zusätzliche »smarte« Schichten. So verhinderst du Kaskadeneffekte und verbesserst Stabilität.

TCP-Algorithmen für hohe Latenzen: BBR v2, RACK, HyStart++

Moderne Stacks mit BBR v2 bringen spürbare Verbesserungen: BBR interpretiert Verlust nicht primär als Stausignal, sondern modelliert Bandbreite und minimale Latenz. Mit RACK und Tail Loss Probe kommen schnellere Retransmissionen und weniger Ausfallzeiten bei Paketverlust. HyStart++ sorgt für einen sanften und weniger nervösen Start auf langen Pfaden.

Die Empfehlung: Aktiviere BBR v2 oder zumindest CUBIC mit RACK, erhöhe Puffer auf mehrere Dutzend Megabyte und achte darauf, dass timestamps und SACK eingeschaltet sind. Das ist das Fundament für stabile Tunnels bei hohen RTT.

Wann QUIC hilft

QUIC auf UDP bringt verschlüsselbaren Transport mit weniger Handshakes und bessere Verlustresistenz. Für Tunnel heißt das: weniger Pausen beim Netzwechsel, gleichmäßigere Durchsatzrate und schnelle Reaktion auf Jitter. 2026 sind Multipath-QUIC-Implementierungen in Experimenten und ersten kommerziellen Produkten verfügbar. Kein Spielzeug mehr, sondern eine echte Option zur Beschleunigung.

VPN »auf QUIC« ist keine Pflicht, aber Proxying oder Traffic-Obfuskation über QUIC beschleunigt oft, besonders in Netzen mit restriktiven Verkehrskontrollen, wo UDP ohne QUIC gedrosselt wird.

MTU, MSS und Fragmentierung: die stillen Durchsatzkiller

Richtiges MTU für den Tunnel

Fragmentierung ist großer Feind bei hohen Latenzen. Höhere Verzögerung verteuert Wiederholungen, und Fragmente erhöhen das Risiko von Paketverlust: Fehlt ein Teil, muss neu gesendet werden. Wähle MTU so, dass eingekapselte Pakete unterwegs niemals fragmentieren.

Praxisbeispiel: WireGuard meist 1280–1420, abhängig von der Umgebung. OpenVPN UDP oft 1400–1450 auf dem Tunnel, mit mssfix ca. 1360–1400. Für IPsec mit NAT-T teste PMTUD sorgfältig und fixiere MTU bei Bedarf auf 1400–1420.

MSS und PMTUD: Segmentgröße anpassen

MSS wird oft vergessen, ist aber entscheidend. Begrenze MSS, damit interner TCP keine »knappen« Segmente sendet, die außen fragmentieren könnten. PMTUD und PLPMTUD helfen, sind aber nicht immer sicher in Netzwerken mit ICMP-Filterung. Deshalb rettet häufig eine sanfte MSS-Begrenzung die Situation.

Resultat: weniger Wiederholungen, weniger unerklärliche Hänger bei hoher Last, daraus echte Geschwindigkeits- und Stabilitätsgewinne.

ECN und DSCP: Damit die Queue nicht erstickt

Setze ECN dort ein, wo sicher: moderne Kernel arbeiten sauber mit ECN, viele Mobilkernels und Heimrouter mit CAKE oder fq_codel markieren fair und entlasten die Queues. DSCP-Markierung für Priorisierung von interaktivem VPN-Traffic ist ebenfalls sinnvoll, besonders für Sprach- und Videoanwendungen. Wichtig ist, dass der Provider diese Bits nicht entfernt oder zerstört.

Der Trick: ECN reduziert Timeouts, korrekt gesetzte DSCPs verschaffen Sprache und Video priorisierten Vortritt bei Volllast. Keine Wunderlösung, aber in Kombination mit richtigem MTU ein spürbarer Boost für die »Lebendigkeit«.

Feinabstimmung von WireGuard für Satelliten- und Mobilfunknetze

PersistentKeepalive und Zeitsteuerung

In CGNAT und Mobilnetzen schließen NATs Verbindungen bei Inaktivität schnell. Setze PersistentKeepalive zwischen 15 und 25 Sekunden. Weniger erzeugt unnötigen Traffic, mehr birgt Risiko für Verbindungsabbrüche. Im Satellitenumfeld sind 20–30 Sekunden akzeptabel, wenn wenig Aktivität herrscht. Finde den Mittelweg zwischen »nicht zu oft wecken« und »Route erhalten«.

Ist der Server weit entfernt, lohnt sich ein schneller Rekey beim Netzwechsel. 2026 beherrschen viele Clients nahtloses Umschalten ohne Sekundenstillstand – wichtig ist, keine Blockaden durch Firewall-Policies zu erzeugen.

MTU, Routing-Tabellen und Policies

Nutze für WireGuard separate Routing-Tabellen und policy-based Routing. Damit steuerst du flexibel, welcher Traffic durch den Tunnel läuft und was bei Ausfall außen bleibt. MTU am Interface je nach Netz zwischen 1280 und 1420. Für Mobilfunk mit aktivem Shaping gilt oft 1392–1412 als goldene Mitte.

Kleiner Tipp: Bei seltsamen Timeouts auf großen Transfers temporär MTU auf 1280 fixieren – die sicherste Lösung, die merkwürdige Pfade meistert, wenn auch mit kleinem Overhead.

Rekeying und Neuaufbau dosiert einsetzen

Häufiges Schlüsselwechseln verbessert Sicherheit, belastet Satellitenverbindungen aber negativ. Wähle Lifetimes klug, um unnötige Pausen zu vermeiden. Teste Netzwechsel zwischen Wi-Fi und 4G, beobachte Tunnelverhalten unter Last. Große Uploads während Rekey verursachen spürbar längere Verzögerungen.

Auch wichtig: Sorge auf Serverseite für CPU-Reserven – schwache VPS lösen Verschlüsselung als Flaschenhals bei großen TCP-Fenstern aus.

OpenVPN und IKEv2/IPsec: Bewährte Klassiker neu gedacht

OpenVPN UDP: mssfix, DCO und Puffer

Nutze OpenVPN mit UDP und aktiviere DCO. Setze mssfix zwischen 1360 und 1400. Achte darauf, dass tun-mtu keine Fragmentierung auslöst. Erhöhe sndbuf und rcvbuf wenn Client und Server leistungsfähig sind und das Netz große Fenster verkraftet. Schalte unnötige renegotiate aus oder begrenze sie auf Leerlaufzeiten.

Bei 1–2 % Paketverlust lieber MTU nochmal um 20–40 Bytes senken. So verringerst du Fragmentierungsrisiko auf mittleren Routern, die bei Spitzenbelastung gern Probleme verursachen.

IPsec IKEv2: Lifetimes, NAT-T und Verschlüsselung

Erhöhe bei IKEv2 die Lifetimes, um seltener SA komplett neu zu starten. NAT-T ist Pflicht in Mobilnetzen und hinter CGNAT. Für schwächere Clients empfiehlt sich ChaCha20-Poly1305, Server mit AES-NI nutzen AES-GCM. 2026 ist das Standard ohne Überraschungen.

Dead Peer Detection sollte nicht zu aggressiv sein, sonst entstehen Fehl-Reconnects auf Satelliten. Weniger, aber genauer ist das Motto bei langen RTT.

TLS-Modi und Handshake-Reduzierung

Bei OpenVPN TLS oder TLS-basierten Lösungen setze TLS 1.3 und 0-RTT-Wiederaufnahme ein (mit Bedacht wegen Sicherheit). Session Resumption spart Round-Trips, besonders auf GEO-Verbindungen. Nutze 0-RTT bewusst und nur bei unkritischen Anwendungen, wiederholte Angriffe bleiben ein Thema.

Cache Sessions wenn möglich und achte auf Lifetimes von Tokens. So werden seltene Handshakes fix.

QUIC, Multipath und Accelerator: Zukunft schneller Tunnel

QUIC für Tunnel und Verschleierung

QUIC ist ideal, wenn schnelle Sitzungen und nahtloser Netzwechsel ohne Knopfdruck gefragt sind. VPN über QUIC oder QUIC-Proxies sind 2026 keine Randerscheinung mehr. Hilft in Netzen, die UDP blockieren, aber QUIC als Webtraffic durchlassen. Dazu kommt solide Verlust- und Jitterhandhabung.

Bei Verbindungsabbrüchen durch Funkzellenwechsel glättet QUIC diese Peaks. Multipath QUIC mit mehreren Interfaces und einem logischen Stream ist für Mobile genau das Richtige.

Multipath: MPTCP, Kanalbündelung und Bonding

MPTCP widersteht Verlust und Jitter dank parallelen Subflows. Lastverteilung, schneller Ersatz schlechter Pfade, Traffic-Persistenz bei Wechsel – in Kombination mit VPN ergibt das eine Art »flexiblen Schlauch«. Drückt man eine Stelle zusammen, fließt der Datenstrom anderswo weiter. Stabilere Geschwindigkeit und weniger Aussetzer beim Wechseln kannst du kaum erzielen.

Wenn MPTCP nicht verfügbar, greife zu Software-Bonding oder Multilink-Lösungen mit eigens entwickelten Agenten. Mehr Komplexität, aber bessere Zuverlässigkeit.

UDP-Acceleratoren und FEC

In schwierigen Netzen bringt ein leichtes FEC viel: Etwas Redundanz sorgt dafür, dass kleine Verluste nicht zu Retransmits führen. Moderate FEC von 5–15 % zahlt sich besonders bei Sprache und Streaming aus. Vorsicht: Übertriebene Redundanz bei Satelliten schlägt teurer zu als auf Glasfaser.

Manche Setups profitieren von QUIC-basierten oder »udp2raw«-Accelerators, die den Datenstrom so verändern, dass Engpässe durchkommen. Teste vor der Praxis, denn der Erfolg hängt stark vom Provider-Netz ab.

Betriebssystem- und Router-Tuning: sysctl, qdisc und Puffer

Linux: TCP-Stack und Queues

Unter Linux 6.x aktiviere BBR v2 oder belasse CUBIC mit RACK/TLP. Erhöhe net.core.rmem_max und wmem_max auf Dutzende Megabyte, setze tcp_rmem und tcp_wmem mit Obergrenzen von 32–128 MB. Achte auf tcp_timestamps, tcp_sack und tcp_window_scaling. Das sind essentielle Einstellungen für große RTT.

Auf den Ausgangsinterfaces fq_codel oder CAKE aktivieren. Für Mobilfunk hilft CAKE mit ack-filter zum Reduzieren des Rückkanal-ACK-Verkehrs und Entlasten des Uplinks. Lege mit Bandbreiten-Shaping vernünftige Limits fest und überlasse AQM die Pufferbloat-Beseitigung.

Windows und macOS: Autotuning und Anpassung

Aktiviere in Windows das Autotuning für die TCP-Receive-Window-Größe und überprüfe, dass der Profilstatus auf normal und nicht restricted steht. macOS moderne Stacks funktionieren meist gut out-of-the-box, schaue aber trotzdem nach aktivem RACK und vernünftigen Puffern. Vergiss nicht die Netzwerktreiber – Latenzprobleme verstecken sich gern in alten NDIS-Versionen oder ungewöhnlichen Offload-Einstellungen.

In beiden OS gilt: Weniger Offload ist besser, wenn er MTU kaputt macht oder ECN nicht richtig weitergibt. Weniger Magie bedeutet mehr Vorhersehbarkeit.

Router und CPE: Klein, aber oho

Home-Router mit CAKE-Support bringen enorm bessere »Lebendigkeit«. Setze CAKE für Up- und Downlink mit realistischen Bandbreiten ein und aktiviere ack-filter. Prüfe, dass VPN-Protokolle effizient verarbeitet werden: WireGuard im Kernel ist Must-Have, OpenVPN DCO falls möglich, IPsec mit Hardware-Offload top.

Teste Energiesparoptionen. »Intelligente« CPU-Modi drosseln oft die Taktung, was Krypto-Latenzen erhöht. Kleinigkeiten, die in Summe spürbar sind.

Monitoring und Tests: Messen statt raten

Labor: netem, iperf3 und der harte Test

Bevor du ins Feld gehst, simuliere hohe Latenzen: 600–800 ms RTT, 1–2 % Paketverlust, 20–50 ms Jitter hinzufügen. Lauf iperf3, sende realen Traffic, beobachte Tunnelverhalten. Variiere MTU, MSS, Puffer, ECN an/aus. So erkennst du Engstellen genau.

Die schlechte Nachricht: Die perfekte Einstellung gibt’s nicht universell. Die gute: Du findest schnell einen Sweet Spot, der im Produktivbetrieb stabil bleibt.

Produktiv: Latenz, Jitter, p95/p99

Im Produktivbetrieb schaue nicht nur auf Durchschnittslatenzen, sondern auf Verzögerungsspitzen (p95, p99). Gerade diese spitzen Latenzen zerstören Anrufe und RDP-Sessions. Überwache Recovery nach Verlusten, Anzahl der Reconnects, Handshake-Zeiten und Fragmentierungsraten. Steigt p99 stark an, such nach Warteschlangen, MTU-Problemen und Retransmissionsmechanismen.

Setz einfache SLOs: etwa »p99 Handshake unter 1,2 Sekunden auf GEO«. Damit triffst du klarere Entscheidungen statt zu raten »fühlt sich langsam an«.

Trace und QoS

Scheue dich nicht vor Traceroute, um Engpässe aufzuspüren – manchmal liegt’s schon beim ersten Router nach dem Modem. Überprüfe mit QoS, ob DSCP-Markierungen bis zum Shaper durchkommen und nicht verwischt werden. Falls ja, lohnt es sich, im Tunnel zu markieren und den Traffic am Ausgang getrennt zu behandeln.

Füge passives Monitoring von Routerlast und Temperatur hinzu. Überhitzte CPEs sind klassische Ursachen für sporadische Verbindungsabbrüche.

Anwendungsfälle und Checklisten: Praxistaugliche Szenarien für GEO, LEO und 4G/5G

GEO-Satellit 600–800 ms RTT: Stabilität vor Geschwindigkeit

Empfehlung: WireGuard oder IKEv2/IPsec über UDP. MTU: Starte bei 1280–1360. MSS: 1200–1300. TCP: BBR v2, große Puffer von bis zu mehreren Dutzend MB. ECN aktiviert, DSCP für Sprache und Video priorisiert. FEC 5–10 % nur bei Budgetspielraum und kritischen Streams.

Weniger Handshakes, gemäßigtes Keepalive, Latenz-Spitzen überwachen. Ergebnis: Vorhersagbare RDP- und Dateiübertragung, auch wenn nicht blitzschnell.

LEO-Satellit 30–70 ms RTT: Fast wie mobile Netze

MTU 1360–1420 möglich, MSS feinjustiert. WireGuard top, QUIC-Proxys ergänzen. CAKE an Uplink/Downlink glättet Peaks. BBR v2 oder CUBIC mit RACK funktionieren ausgezeichnet. FEC nicht übertreiben – meist zu viel Redundanz.

Wichtiger ist der Umgang mit Jitter und Provider-Shaping: Sorgfältiges QoS wirkt gerade in Spitzenzeiten Wunder.

4G/5G Mobilnetze: RTT-Sprünge und CGNAT

CGNAT verlangt PersistentKeepalive 15–25 Sekunden bei WireGuard oder moderate DPD bei IKEv2. MTU um 1392–1412 ist meistens ideal. Priorisiere UDP, markiere interaktiven Traffic und begrenze Hintergrundlast mittels CAKE oder fq_codel. Falls nötig, nutze Multipath: Wi-Fi plus 5G kombiniert sorgen für stabile Übergänge.

Beobachte Funkzellenwechsel: QUIC und WireGuard bleiben bei Handover gelassener als TLS-Tunnel mit schweren Handshakes.

Entlegene Büros und Schiffe: Alles zusammen, aber flexibel

Setze auf hybride Verbindungen: Hauptverbindung LEO, Backup GEO, 4G zur Küstennähe. VPN auf WireGuard mit policy-basierter Routing-Steuerung und MPTCP, wo möglich. Striktes Traffic-Management mit Priorität für missionskritische Anwendungen bei gleichzeitiger Trennung von Video, Daten und Sprache.

Führe ausführliche Logging-Events und plane Nachtwartungsfenster. Im Meer MTU- und Schlüsselkonfigurationen anzupassen ist nur etwas für Profis.

Sicherheit ohne Abstriche: Verschlüsselung, PFS und Handshake-Optimierung

Verschlüsselungen 2026: ChaCha20-Poly1305 und AES-GCM

Auf mobilen und ARM-Devices bleibt ChaCha20-Poly1305 Top wegen Performance und Energieeffizienz. Server mit AES-NI bevorzugen AES-GCM für maximale Durchsatzraten. Wichtig: Kein unnötiges Mixen, um Fluss nicht einzubremsen.

Stelle sicher, dass Implementierungen Hardwarebeschleunigung nutzen und aktuell gepatcht sind. Kryptografie ist kein Ort für Kompromisse.

PFS, Lifetimes und 0-RTT

Perfect Forward Secrecy ist Pflicht. Aber passe Lifetimes so an, dass keine häufigen Neuunterzeichnungen auf Satelliten entstehen. TLS 1.3 0-RTT spart Handshake-Zeit, sollte aber sicher und nur bei niedrig riskanten Szenarien genutzt werden. Im Zweifel lieber verzichten.

Session-Resumption und Caching sind einfache Beschleuniger ohne großes Risiko, die das Reconnecten merklich flinker machen. Nutze diese Tools.

Firewall und Minimierung der Angriffsfläche

Lass nur notwendige Ports offen für den Tunnel, aktiviere Rate-Limiting für Steuerung und setze grundlegende IDS-Regeln ein. Auf öffentlichen Servern halte unnötige Dienste fern. Das ist langweilig, aber schützt vor unangenehmen Überraschungen in der Nacht.

Und bitte: Wechsle Schlüssel und Zertifikate regelmäßig, nicht »später«, gerade wenn kritische Systeme über dieses VPN erreichbar sind.

FAQ: Kurze Antworten auf häufige Fragen

Welches VPN-Protokoll ist 2026 für Satelliteninternet am besten geeignet?

Für die meisten Fälle ist WireGuard dank geringem Overhead und UDP ideal. Für Unternehmenskompatibilität nimm IKEv2/IPsec mit passenden Lifetimes und NAT-T. OpenVPN mit UDP und DCO ist auch gut, verlangt aber sorgfältiges MTU- und mssfix-Tuning.

Warum sollte man OpenVPN nicht über TCP bei hohen Latenzen einsetzen?

Weil TCP-over-TCP doppelte Überlastkontrolle erzeugt und Timeouts verschärft. Hohe RTTs führen zu »Einfrieren« bei Verlusten und langsamen Fensteröffnungen. Der UDP-Modus löst das Problem und sorgt für bessere Reaktion.

Wie wähle ich MTU für den Tunnel ohne Schmerzen?

Beginne konservativ: 1280–1360 für Satellit, 1392–1412 für Mobilnetze. Teste große Übertragungen auf Fragmentierung und Retransmission. Wenn Timeouts bei großen Paketen auftreten, senke MTU in 20-Byte-Schritten bis Stabilität da ist.

Hilft BBR v2 bei hohen Verlusten?

Meistens ja. BBR v2 hält den Datenfluss auch bei moderaten Verlusten und großen RTTs besser dank anderer Staukontroll-Mechanik. Aktiviere RACK/TLP, timestamps und SACK, erhöhe Puffer – die Stabilität, besonders auf Satelliten, verbessert sich deutlich.

Ist QUIC für Firmen-VPNs sinnvoll?

Wenn Sessions oft abbrechen oder du durch CGNAT und restriktive Shaper musst – ja. QUIC verkürzt Handshakes, meistert Migrationen und Durchsatzfilter. Prüfe aber immer Sicherheit und Kompatibilität mit deinem Logging-System.

Was ist wichtiger: FEC oder QoS?

In der Praxis gewinnt häufig gutes QoS mit CAKE oder fq_codel und richtige DSCP-Marken. FEC hilft punktuell, wenn Verluste Medienstreams stören. Übertriebene FEC verschwendet Bandbreite ohne Nutzen.

Womit anfangen, wenn »alles stockt«?

Kurzfazit: VPN auf UDP umstellen, MTU 1392 oder 1280 bei schwierigen Netzen, MSS reduzieren, BBR v2 und RACK aktivieren, CAKE einschalten, Traffic priorisieren, keepalive und Lifetimes prüfen. Dann p95/p99 Latenzen messen und Settings feinjustieren.