Wie man VPN wirklich misst: Schritt-für-Schritt-Methode, Kennzahlen und Tools ohne Illusionen

Warum überhaupt die VPN-Leistung messen und was wirklich zählt

Was echte Leistung bedeutet – jenseits von Marketingzahlen

VPN-Leistung ist nicht einfach eine Zahl auf einem schicken Banner, sondern ein Bündel an Kennzahlen, die dein wirkliches Nutzungserlebnis beeinflussen: Wie schnell gehen Downloads, wie stabil läuft ein Videoanruf, und ob dein Spielfigur nicht plötzlich „teleportiert“. Realität ist immer Kontext. Tageszeit, Serverstrecke, Verschlüsselungstyp, Hardwarebelastung, Provider – selbst ein einfacher Router mit heißem Chip kann die Messung verändern.

Wenn wir von „real“ sprechen, meinen wir messbare, reproduzierbare Bedingungen, einen klaren Testplan und eine ehrliche Auswertung. Du brauchst kein Millionen-Labor, sondern Disziplin, passende Werkzeuge und ein Verständnis, welche Zahlen relevant sind und welche nur Rauschen im Diagramm.

Wann macht Testen Sinn und welche Ziele solltest du verfolgen

Tests sind sinnvoll, wenn du einen neuen VPN benutzt, das Protokoll wechselst (z. B. von OpenVPN zu WireGuard), Netzrouten anpasst (neuer Provider, Starlink, 5G), QoS oder MTU einstellst, oder einen Performanceverlust bemerkst – „gestern lief’s, heute hakt es“. Wichtig ist das Ziel: maximaler Durchsatz für Backups? Minimale Latenz fürs Gaming? Geringer Jitter für Anrufe? „Alles auf einmal“ endet oft im Kompromiss – lieber Prioritäten setzen.

Typische Wahrnehmungsfallen und wie du sie vermeidest

Ein einzelner Speedtest sagt nichts aus. Messergebnisse vom Büro-WLAN kannst du nicht mit Kabel zuhause vergleichen. Die Route zum Testserver ist nur die halbe Geschichte; die andere Hälfte ist der VPN-Server und dessen Umgebung. Die Basis ohne VPN ist Pflicht, sonst vergleichst du Äpfel mit Birnen. Und ja, die CPU ist oft Engpass, wenn du starke Verschlüsselungen nutzt – vor allem bei Routern ohne AES-NI oder mit veraltetem Firmware.

Wichtige Kennzahlen: Durchsatz, Latenz, Jitter und Paketverluste

Durchsatz: Die Bandbreite ist das A und O

Der Durchsatz zeigt, wie viele Daten pro Zeiteinheit durch den Tunnel gehen. Gemessen in Mbit/s oder Gbit/s. Relevant ist nicht ein einmaliger Spitzenwert, sondern eine stabile Durchschnittsrate über 30–60 Sekunden bei konstanter Last. Man unterscheidet TCP-Durchsatz (abhängig von Fenstergröße, Verlusten und Latenz) und UDP-Durchsatz (begrenzt durch Sender und Verluste). Für VPN solltest du beide prüfen: TCP spiegelt die Nutzererfahrung wider, UDP die maximale Kapazität unter Berücksichtigung der Verluste.

Normal sind Tests mit 1, 4–8 und vielen parallelen Streams, um reale Last zu simulieren. Anstieg bei Mehrfachstreams zeigt oft versteckte Limits, etwa in einer einzelnen CPU-Verschlüsselungsschleife.

Latenz: die Verzögerung, die du wirklich spürst

Latenz misst die Hin- und Rücklaufzeit (RTT). Wir benutzen Median, 95. und 99. Perzentil. Der Median zeigt die Basis, die „langen Schwänze“ geben den Schmerz an. Für Gaming brauchst du niedrige, konstante RTT. Für Web zählt nicht nur RTT, sondern auch die Varianz: Schwankungen können Seiten deutlich langsamer laden lassen, besonders bei vielen TCP-/QUIC-Verbindungen.

Wichtig: Messe die Latenz bis zum finalen Internetziel über VPN, nicht nur bis zum VPN-Server. Sonst bekommst du eine hübsche Zahl, die nichts über den echten Weg aussagt.

Jitter: Latenzfluktuationen, der Killer für Calls

Jitter beschreibt die zeitliche Streuung der Paketlatenz. Sprache und Video leiden besonders darunter: gleichmäßige 60 ms sind okay, aber schwankende 20–120 ms reißen Puffer auf und sorgen für ruckelige Bilder. Jitter wird über Standardformeln zur Variabilität zwischen Paketen berechnet (z. B. UDP-Stream mit iperf3). Für Reports nutze Mittelwert und 95. Perzentil. Für Calls ist ein Jitter unter 20–30 ms bei Verlusten unter 1% komfortabel.

Paketverluste und deren Zusammenhang mit MOS

Verluste killen TCP-Durchsatz (wegen Wiederholungen) und treiben langfristig die Latenz durch Pufferung nach oben. Bei Multimedia sind sie kritisch: MOS (Sprachqualität) fällt schon bei 2–3% Verlust rapide ab. 2026 schaffen viele VPNs auf QUIC-Basis dank FEC und smarter Flusskontrolle höhere Verluste, aber bei dauerhaft 5% Verlusten leidet die Qualität trotz guter Durchschnittsgeschwindigkeit.

Tools im Jahr 2026: Auswahl und Vorbereitung

iperf3: Goldstandard für Durchsatz und UDP-Kennzahlen

iperf3 ist das Grundtool für TCP und UDP Messungen. Für TCP führst du 30–60 Sekunden Tests aus, variierst die Streamanzahl (-P 1,4,8) und Fenstergröße (standard ist gut, manchmal hilft -w). Bei UDP passt du die Bitrate (-b) schrittweise an, bis Verluste >1–2% erscheinen, dabei erfasst du Jitter. Wichtig: der iperf3-Server sollte außerhalb des VPN-Servers stehen, idealerweise im Zielland oder der Region für deine Tests.

Neu 2026: QUIC-kompatible iperf-Szenarien (Forks und Ergänzungen), aber klassisches iperf3 deckt 95% der Anforderungen. Für perfekte Reproduzierbarkeit nutze Docker und fixe Versionen.

ping, fping, mtr: das Trio für Latenz und Routing-Diagnose

ping misst RTT punktuell. fping skaliert auf viele Hosts und liefert stabile Perzentile. mtr kombiniert traceroute mit ping: du siehst den Weg, Latenzen und Verluste pro Hop. Nutze mtr bis zum Endpunkt über VPN, um Engpässe zu identifizieren, z. B. volle Knoten oder unerwartete Schleifen über andere Kontinente.

Praxis: Nimm mtr 2–3 Mal täglich zu Stoß- und Nebenzeiten auf. Routen ändern sich 2026 oft, da Provider Traffic dynamisch balancieren – vor allem durch SASE und Cloud-Proxies.

Speedtest CLI und selbstgehostete Teststände

Speedtest CLI ist ein schneller Sanity-Check, ersetzt aber kein Labor. Er liefert Ergebnisse, die stark vom gewählten Server abhängen und oft zu gut wirken, wenn man nah am Provider-Cache ist. Besser: LibreSpeed auf eigenem VPS in der Zielregion aufsetzen. Der Browser simuliert reale Last, du kontrollierst den Server. Ideal für Managementberichte – „so fühlt sich der Nutzer“ – und für faire Protokollvergleiche unter gleichen Bedingungen.

Wireshark, tcpdump und eBPF-Profiler

Wireshark hilft bei der Fehlersuche: wir sehen Retransmissions, MSS, MTU, Fenstergrößen, Gründe für Verluste. tcpdump ist leichtgewichtig zum Sammeln von Traffic mit Filtern. 2026 sinnvoll: eBPF-Tools (z. B. bpftrace-Profile für Netzwerk-Stacks) zeigen CPU-Hotspots – Verschlüsselung, Speicher-Copy, Queues. Das öffnet oft die Augen: Schuld ist nicht das Netzwerk, sondern Treiberfehler oder deaktivierte Offloads auf der Netzwerkkarte.

Testmethodik: Von der Basislinie bis zum Vergleich von VPN-Protokollen

Schritt 1. Basislinie: ohne VPN, aber professionell

Zuerst misst du ohne VPN, per Kabel, auf derselben Route zum Testserver. Mache drei Sets: morgens, Spitzenzeit, nachts. Speichere iperf3 TCP/UDP, ping/fping, mtr-Daten. Das ist deine „Referenz für Geschwindigkeit und Stabilität“. Ohne sie weißt du nicht, ob Probleme vom Tunnel, der Route oder dem Server kommen.

Parallel erfasst du Systemmetriken: CPU-Last (vor allem Einzelcore), IRQs, Kernfrequenzen, Temperatur. Beim Router prüfen: Hardwarebeschleunigung, Offload-Status, Pufferzustand. Sonst riskierst du, CPU-Probleme dem VPN anzulasten.

Schritt 2. Experimentplan: Randomisierung, Wiederholbarkeit, Dauer

Plane, welche Protokolle (WireGuard, OpenVPN, IPsec, moderne QUIC-basierte Lösungen), welche Verschlüsselungen (ChaCha20-Poly1305 für ARM und schwache CPUs, AES-GCM für x86 mit AES-NI), welche Standorte (nah, mittel, fern) und welche Lastprofile (einzelner Stream, viel Streams, UDP an der Grenze) getestet werden. Randomisiere die Reihenfolge, um keine Server- oder Netzwerkausfälle einzufangen.

Jeder Test läuft mindestens 30 Sekunden, besser 60. Wiederholungen 3–5 Mal. Für die Auswertung nutze Median und Konfidenzintervalle. Werfe Ausreißer raus (z. B. wenn ein Lauf durch eine Routen-Änderung gestört wurde).

Schritt 3. Vergleich und Kontrolle der Variablen

Wechsle immer nur einen Parameter gleichzeitig. Zuerst WireGuard gegen OpenVPN bei gleichem MTU und Verschlüsselung, dann MTU-Einfluss, dann Mehrfachstreams, dann Standort. Wichtig: gleiche Ports und Transportprotokolle (UDP vs. TCP). Bei Portwechsel kann der Provider QoS anders setzen.

Dokumentiere Client- und Server-Versionen, Konfigurationen, Keepalive-Einstellungen, Schlüsselneuaufsetzintervalle. 2026 haben viele Clients smarte Auto-Switch und Multipath-Funktionen – für saubere Tests ausschalten, sonst vergleichst du Birnen mit Ananas.

Praktische Anwendungsfälle: Gaming, Video, Arbeiten und Filesharing

Gaming: Priorität auf Latenz und stabile Spitzenwerte

Ideal fürs Gaming sind RTT unter 50 ms zu Game-Servern, Jitter unter 15–20 ms, Verluste unter 0,5%. Durchsatz spielt fast keine Rolle außer bei Updates. Teste ping/fping zu echten Spiel-IP-Adressen oder Entwickler-PoPs, mtr um „schiefe“ Hops zu finden. Prüfe MTU – empfindliche Spiele zeigen bei Fragmentierung friedliche RTT-Sprünge unter Last. WireGuard liefert oft 10–20% stabilere Spitzen als TCP-Tunnel, besonders im WLAN.

Videoanrufe und Streaming: Jitter ist alles, Durchsatz zweitrangig

Zoom, Meet, Teams, WebRTC passen sich an. Wichtig ist ein gleichmäßiger Kanal. Als Maßnahme mache einen UDP-Test mit iperf3 zwischen 2–8 Mbit/s für 5–10 Minuten, analysiere Jitter und Verluste. MOS über 4.0 erreichst du meist bei Jitter bis 20 ms und Verlusten bis 1–2%. In der Praxis hilft guter QoS im Router: DSCP-Markierung und Puffervermeidung, vor allem beim Upload.

Remote-Arbeit: Web, IDE, RDP/SSH

Für Web zählt die Kombination aus RTT und Durchsatz. QUIC/HTTP3 ist 2026 überall, 0-RTT-Handshakes reduzieren Verzögerungen beim Tab-Wechsel. VPN-Verzögerungen von 40–60 ms spürt man als „schleppend“. Für RDP/SSH ist ab RTT 80 ms Komfort, wenn kein jitterbedingtes Ruckeln da ist. Checke VPN-Keepalive, um unerwartete Verbindungsabbrüche zu vermeiden.

Filesharing, Torrents und Backups: CPU und Fenstergrößen limitieren

Maximaler Durchsatz ist König. Teste mehrsträngigen TCP (4–16 Streams) und vergleiche mit einem Stream. Wenn du 2–3-fachen Anstieg siehst, bist du am Fenster/RTT-Limit. Bei kaum steigendem Durchsatz liegen Limits bei Verschlüsselung/CPU oder Server. Beim Upload mit Torrents teste 80–90% Auslastung, ob dein VPN stabil bleibt. FQ/Cake im Router löst oft das Problem „alles bricht beim Upload ein“.

Ergebnis-Interpretation: Wo sitzt der Flaschenhals und was tun?

Netzwerk und Route: Provider, Peering, Warteschlangen

Wenn ohne VPN RTT stabil und niedrig ist, mit VPN aber springt, prüfe die Route: mtr zeigt Hop mit Warteschlange oder Verlusten. Oft ist der VPN-Server in günstigen, überlasteten Rechenzentren. Lösung: Standort- oder Providerwechsel, manchmal hilft nur ein anderer Port/Protokoll (UDP 443 via QUIC läuft anders als UDP 51820).

Kryptografie und CPU: die harte Realität

Wenn eine CPU-Kern-Auslastung bei Verschlüsselung 100% erreicht, bist du am Limit. WireGuard auf x86 mit AES-NI und ChaCha20-Poly1305 übertrifft meist OpenVPN im Userspace. Auf ARM-Geräten gewinnt ChaCha20 meistens gegen AES ohne HW-Beschleunigung. Prüfe Offloads: GRO/LRO, TSO, hardwarebeschleunigte Kryptofunktion. Manchmal bringt das Abschalten von Offloads bessere Latenzen, auch wenn die Spitze sinkt – entscheidend ist das Ziel.

MTU, MSS und PMTUD-„Black Holes“

Falsche MTU ist Klassiker. Symptome: instabiler Durchsatz, seltsame Verzögerungen bei Last, Seiten frieren beim Laden ein. Lösung: Experimentieren mit MTU (z. B. oft 1420 bei WireGuard, aber nicht immer), MSS-Clamping im Router, und sicherstellen, dass benötigte ICMP-Pakete für PMTUD nicht blockiert werden. Nach MTU-Korrektur fällt Jitter und Durchsatz wird gleichmäßiger.

Serverseite: versteckte Limits

VPN-Server sind ebenfalls limitiert: Session-Limits, CPU-Pools, NUMA-Effekte, noisy Nachbar-VMs. Für faire Tests mach sie nachts und vergleich mit Spitzenzeiten. Wenn nachts 30–40% mehr Durchsatz geht, hast du Ressourcen- oder Uplink-Engpass im Data Center.

Optimierung und Feintuning: schnelle Erfolge und nachhaltige Lösungen

Protokoll- und Verschlüsselungsauswahl

2026 ist WireGuard (UDP) mit ChaCha20-Poly1305 der beste Startpunkt. Für Netze mit aggressivem QoS/Firewall nimmst du den transparenten QUIC-Modus über 443/UDP (viele kommerzielle und einige Open-Source-Lösungen unterstützen das). OpenVPN eignet sich, wenn komplexes L7-Verhalten gebraucht wird oder Legacy-Kompatibilität, ist aber geschwindigkeitsmäßig meist unterlegen.

TCP/QUIC-Einstellungen und Buffer Management

Nutze moderne Congestion-Control-Algorithmen: BBRv2 bringt oft Gewinn auf langen, verlustbehafteten Strecken. Bei kurzen RTT bleibt CUBIC stabil. Überwache sysctls: rmem, wmem, tcp_timestamps, SACK, ECN. QUIC-Clients passen sich meist dynamisch an, aber Systemlimits bleiben relevant.

MTU/MSS, ECN und QoS gegen Bufferbloat

Finde die richtige MTU und aktiviere MSS Clamping als Basis. Dann QoS: Priorisiere interaktiven Traffic (DSCP CS6/EF für Voice), begrenze schwere Upload-Hintergründe. Setze Cake oder FQ-Codel am Edge-Router ein. Ergebnis: Jitter sinkt 2–3-fach, Calls brechen nicht mehr ab, Web fühlt sich spürbar flotter an, trotz gleicher RTT.

Hardwarebeschleunigung und Architektur

Wenn CPU regelmäßig an Grenzen kommt, erneuere Hardware (x86 mit AES-NI, moderne ARM mit Krypto-Kernen) oder verlagere Verschlüsselung näher zum Kernel (WireGuard im Kernel ist mittlerweile Standard). Bei Geschwindigkeiten von 1–5 Gbit/s sind NICs mit Offloads und passende Treiber wichtig. Manchmal lohnt es, Nutzer auf mehrere kleinere Server zu verteilen statt einen „Monsterserver“ – NUMA und Cache-Optimierungen danken es.

Automatisierung und Reports: Tests als Code

Skripte, Container und Reproduzierbarkeit

Verpack die ganze Methodik in Skripte: Bash oder Python, egal. iperf3, fping/mtr, Systemmetrik-Erfassung, JSON/CSV-Parsen. Wrappen Testservices in Docker, fixe Versionen. So kannst du den Test in 6 Monaten genau wiederholen und Äpfel mit Äpfeln vergleichen.

Scheduler, Monitoring und Alerts

Starte stündlich Kurztests: RTT, Jitter, kleine UDP-Last. Wenn der Graph ausschlägt, weißt du Bescheid, bevor Nutzer meckern. Integriere mit Prometheus/Grafana oder CSV-Exporter in Cloud-BI-Systeme. Alerts bei Jitter im 95. Perzentil und TCP-Durchsatz-Abfällen über 30% relative zum Basis-Median.

Business-Reports und SLA

Überfrachtet nicht mit Zahlen. Zeigt drei Sachen: mittleren Durchsatz, mediane RTT und 95. Perzentil Jitter, Vergleich nach Protokoll und Standort, plus eine klare Zusammenfassung: „Für Videoanrufe Standort A, für Backups Standort B“. Bei internem SLA besser klare Schwellenwerte fixieren: z. B. RTT zu Europa unter 80 ms, Jitter unter 25 ms, Verluste unter 1% in 95% der Zeit.

Häufige Fehler und Anti-Patterns

Tunnel über Tunnel und übertriebene Magie

VPN ins VPN ins Proxy klingt sicher, führt aber zu MTU-Problemen, unnötigen Handshakes und Frust. Für Multipath nimm Lösungen mit MPTCP/QUIC oder native Multi-Channel-Mechanismen. Vermeide unnötige Protokoll-Kaskaden.

Basislinie und Statistik ignorieren

Der größte Fehler: nicht zuerst ohne VPN messen, dann mit VPN unter gleichen Bedingungen und Wiederholungen. Eine Zahl ist keine Zahl. Zwei Läufe sind schon etwas. Drei und mehr erlauben erste Schlüsse. Nutze Median und Perzentile, und filtere nicht nur den „besten“ Lauf raus.

Falsche Interpretation und voreilige Schlüsse

„VPN schlecht, weil Durchsatz geringer“. Vielleicht. Oder der Provider drosselt den Port, CPU ist am Limit, MTU falsch eingestellt. Geh systematisch vor: Route anschauen, CPU, MTU, Protokoll, erst dann Provider wechseln. Und protokolliere Änderungen, sonst verlierst du den Überblick.

Detaillierte Messbeispiele und Cases 2026

Case 1: WireGuard gegen OpenVPN im heimischen Gigabit

Basis ohne VPN: 930–940 Mbit/s TCP, RTT nach Frankfurt 28 ms, Jitter 2–3 ms. WireGuard: 820–860 Mbit/s TCP (4 Streams), UDP verlustfrei bis 900 Mbit/s, RTT 30–32 ms, Jitter 4–6 ms. OpenVPN (UDP): 450–520 Mbit/s, RTT 35–38 ms, Jitter 10–14 ms. Fazit: Für Backups und Surfen WireGuard, für alte Router-Kompatibilität OpenVPN – mit Einbußen bei Speed und Jitter.

Case 2: 5G SA + Laptop, Priorität Videoanrufe

Basis ohne VPN: RTT 22–35 ms, Jitter 5–25 ms in Spitzen, Verluste bis 1%. Mit WireGuard: RTT 28–40 ms, Jitter stabil bei 6–12 ms dank QoS im Router (FQ-Codel). UDP-Test bei 6 Mbit/s mit 0,6% Verlust, Anrufe ohne Störungen. Erkenntnis: VPN muss nicht schneller sein, soll vorhersagbar bleiben. Mit QoS und richtigem MTU besser als ohne VPN.

Case 3: Remote-Office auf Starlink

Basis ohne VPN: RTT 45–80 ms, gelegentliche Sprünge bis 130 ms (Satellitenwechsel), Jitter 8–25 ms. WireGuard + BBRv2: 180–220 Mbit/s TCP-Durchsatz (4 Streams), stabiler Jitter 10–18 ms. OpenVPN: 120–160 Mbit/s, anfälliger für Sprünge. Empfehlung: WireGuard, MTU 1420, MSS-Clamping, leichtes QoS beim Upload, regelmäßige Tests alle 2 Stunden zur Beobachtung der Satelliten-Fenster.

Schritt-für-Schritt-Anleitung: Testlauf in 60 Minuten

Testumgebung vorbereiten

1) Zwei VPS in gewünschter Region: einer für iperf3 und LibreSpeed, einer als Backup. 2) iperf3 als Server installieren (iperf3 -s). 3) Auf Client: iperf3, fping, mtr, speedtest-cli, tcpdump oder Wireshark installieren. 4) VPN-Client einrichten mit Version- und Konfigurations-Logging. 5) Tabelle in Google Sheets oder lokale CSV für Resultate anlegen.

Basislinie

Ohne VPN starten: iperf3 TCP 60 Sekunden mit -P 1 und -P 4, UDP mit -b 50M+ bis ~1% Verlust. fping 300 Pakete, Perzentile speichern. mtr 3 Läufe à 60 Sekunden. Systemmetriken CPU sammeln. Zu verschiedenen Tageszeiten wiederholen.

VPN-Protokolltests

WireGuard verbinden, gleiche Tests wiederholen. Dann OpenVPN UDP. Wenn QUIC-Modus beim Provider möglich, Port 443/UDP fixieren. Für jedes Protokoll gleiche Tests, gleiche Intervalle. Reihenfolge randomisieren, um Kanalauslastung fair zu verteilen.

Auswertung und Berichte

Tabellen erstellen: TCP-Median, 95. Perzentil RTT, Jitter, UDP-Verluste bei 50–100–200 Mbit/s. Szenarien markieren: Gaming, Calls, Backups. Empfehlungen geben: „Für Calls Protokoll X, Standort Y, MTU 1420, Cake aktiv; für Backups Standort Z, -P 8, BBRv2“. Ergebnis: klare, umsetzbare Pläne, nicht „mehr oder weniger okay“.

Trends 2026: Wohin entwickelt sich VPN-Leistung

QUIC-Oberflächen und Maskierung als 443/UDP

QUIC ist jetzt Standard. Viele VPN tarnen Traffic als normalen QUIC, durch Firewall-Hürden hindurch mit niedriger Latenz. Nicht immer Spitzenwerte, aber besseres Tail-Verhalten und stabiler gegen Verluste. Füge QUIC-Modus in deine Vergleichsmatrix ein.

WireGuard als Default und Multipath

WireGuard ist die „Default“-Lösung in den meisten Use-Cases. Multipath hält Einzug – parallele Verbindungen über Wi-Fi+LTE oder LTE+Starlink. Für Tests bedeutet das, Szenarien mit einem und zwei Kanälen zu fahren, Stabilität bei Ausfall und Umschaltung messen, nicht nur Rohzahlen.

BBRv2, eBPF und Hardware-Boosts

Aggressive, aber smarte Congestion-Control-Algorithmen reduzieren TCP-Verzögerung bei Verlusten auf langen Strecken. eBPF-Profiling ist normal geworden und zeigt Performance-Killer. Hardware-Kryptobeschleunigung in Massenchips ist verbreitet – gigabitfähige VPNs auch auf Heimhardware sind Standard.

FAQ: Kurz und knapp

Schnelle Antworten zum Start

• Wie oft sollte man VPN testen? Einmal pro Woche kurzer Check (RTT, Jitter, ein TCP-Test), einmal im Monat vollständiger Satz mit Wiederholungen. Wechsel von Provider oder Protokoll verlangt sofortige Tests.
• Wie lange dauert ein „richtiger“ Test? 30–60 Sekunden für TCP/UDP-Streams, 5–10 Minuten für stabile Jitter-Messungen bei Calls. Wiederholungen und Perzentile sind wichtiger als ein langer einzelner Lauf.
• Sollte man nachts testen? Ja. Der Vergleich zwischen Nacht und Spitzenzeit zeigt oft, ob es am Server oder der Route liegt, nicht am Client.

Kennzahlen und Auswertung

• Welche Kennzahlen sind am wichtigsten? Für Gaming: RTT und 95. Perzentil Jitter. Für Calls: Jitter und Verluste. Für Backups: TCP-Durchsatz und Stabilität bei 4–8 Streams.
• Was tun bei 30% Durchsatzverlust? CPU und Verschlüsselung prüfen, MTU/MSS checken, Route mit mtr analysieren, dann Standort/Port/Protokoll wechseln. Meist liegt es an MTU oder CPU.
• Wie erkennt man ein MTU-Problem? Symptome: Seiten bleiben beim Laden hängen, Geschwindigkeit sinkt mit steigender Last, mehr Wiederholungen. Lösung: MTU anpassen, MSS-Clamping aktivieren.

Praktische Tipps und Tools

• Kann man einem einzelnen Speedtest vertrauen? Nein. Das ist nur ein Indikator, keine Diagnose. Mach iperf3, fping, mtr, prüfe Routen und wiederhole Tests.
• Ist WireGuard immer schneller? Meist ja, aber nicht immer. Auf „schrägen“ Routen ist QUIC-Modus mancher Lösungen stabiler. Leistung hängt von Protokoll plus Route plus Hardware ab.