WireGuard vs OpenVPN auf einem VPS: Durchsatz, Latenz und Kompatibilität im Vergleich (2026)

Sie sind hin- und hergerissen zwischen WireGuard und OpenVPN für Ihr selbstgehostetes VPN. Überall liest man, dass "WireGuard schneller ist", ohne viel Erklärung, warum das so ist oder wann OpenVPN dennoch die richtige Wahl ist. Dieser Leitfaden vergleicht beide Protokolle ehrlich in den Aspekten, die für ein selbstgehostetes VPS-VPN wirklich wichtig sind: Durchsatz, Latenz, CPU-Kosten, Sicherheitsmodell und Kompatibilität — und gibt ein Urteil pro Anwendungsfall.

Kurzversion: WireGuard gewinnt in der Regel bei der reinen Leistung und Einfachheit, aber OpenVPN behält in zwei spezifischen Situationen einen legitimen, manchmal entscheidenden Vorteil.

Ist WireGuard auf einem VPS schneller als OpenVPN?

Im Allgemeinen ja. WireGuard läuft im Linux-Kernel, verwendet eine einzige moderne Chiffre-Suite und fügt jedem Paket nur minimalen Overhead hinzu. Auf einer schnellen VPS-Verbindung liefert es typischerweise einen Durchsatz nahe der Rohleitungsgeschwindigkeit, während es nur einen Bruchteil der CPU beansprucht. OpenVPN läuft als Userland-Daemon: Jedes Paket überquert die Grenze zwischen Kernel und Userland zur Verschlüsselung, was CPU und Durchsatz kostet — insbesondere auf leistungsschwacher Hardware. OpenVPN verbindet sich auch langsamer bei Netzwerkänderungen, während WireGuards zustandsloses Design fast sofort wiederaufnimmt.

WireGuard vs OpenVPN auf einem 1 Gbps VPS — qualitativer Vergleich:

Urteil: Wählen Sie WireGuard für Leistung und Einfachheit auf jedem modernen VPS. Wählen Sie OpenVPN, wenn Sie TCP/443-Firewall-Umgehung benötigen (Unternehmens-/Hotelnetzwerke) oder ältere Geräte unterstützen müssen (DD-WRT-Router, OpenWRT <21, sehr alte Client-Betriebssysteme).

Dieser Vergleich basiert auf den veröffentlichten, gut dokumentierten Eigenschaften beider Protokolle und nicht auf einem einzigen privaten Testlauf. Unsere Methodik →

Warum WireGuard in der Regel schneller ist

Der Leistungsunterschied ist kein Marketing — er ergibt sich direkt aus der Bauweise jedes Protokolls.

WireGuard läuft im Kernelraum. Es wird als Kernelmodul (wireguard.ko) geliefert, das in den Mainline-Linux-Kernel in Version 5.6 (März 2020) integriert wurde. Pakete werden verschlüsselt und weitergeleitet, ohne den Kernel zu verlassen, wodurch die kostspieligen Kontextwechsel zwischen Userland und Kernel vermieden werden, die bei OpenVPN auf stark ausgelasteten Verbindungen dominieren.

WireGuard ist klein und festgelegt. Etwa 4.000 Zeilen C mit einer einzigen modernen Chiffre-Suite (Curve25519, ChaCha20-Poly1305, BLAKE2s). Es gibt nichts zu optimieren und keinen Verhandlungs-Overhead — Sie erhalten jedes Mal denselben schnellen Pfad.

OpenVPN läuft im Userland auf Basis von TLS. Es ist ein Daemon, der OpenSSL verwendet; jedes Paket macht eine Kernel → Userland → Kernel-Rundreise zur Verschlüsselung. Das ist flexibel (es kann fast alles), kostet aber CPU und Durchsatz, und der Effekt ist auf leistungsschwacher Hardware ohne AES-Beschleunigung viel größer.

Der Protokoll-Overhead selbst ist bei beiden gering. Ein VPN-Header plus UDP/IP-Rahmen verbraucht ein paar Prozent jeder Verbindung, unabhängig vom Protokoll — dieser Teil ist einfach Arithmetik, keine Ineffizienz.

Latenz und Jitter

WireGuard fügt in der Regel weniger Round-Trip-Latenz hinzu als OpenVPN, und OpenVPN über TCP ist der schlimmste Fall: Das Ausführen von TCP in einem TCP-Tunnel ("TCP-over-TCP") verursacht kaskadierende Neuübertragungen, sobald die zugrunde liegende Verbindung ein Paket verliert, was die Latenz und den Jitter in die Höhe treibt. Auf einer sauberen Kabelverbindung ist es erträglich; auf verlustbehaftetem WLAN oder Mobilfunk verschlechtert es sich stark.

Für den täglichen Gebrauch — Surfen, 4K-Streaming, Videoanrufe — ist der Overhead von WireGuard nicht wahrnehmbar, und OpenVPN über UDP bleibt ebenfalls flüssig. Der Fall, den man für latenzempfindliche Anwendungen (kompetitives Gaming, anspruchsvolle VoIP) vermeiden sollte, ist OpenVPN über TCP, es sei denn, man benötigt es speziell, um eine Firewall zu umgehen.

CPU-Verbrauch

Da WireGuard im Kernel läuft, verbraucht es merklich weniger CPU pro Megabit als OpenVPN, das Zyklen damit verbringt, jedes Paket zwischen Userland und Kernel zu verschieben. Auf einem Multi-Core-VPS spielt das für einen persönlichen Tunnel selten eine Rolle. Es spielt eine große Rolle auf leistungsschwacher ARM-Hardware (z.B. ein Raspberry Pi ohne AES-NI), wo OpenVPN einen Kern sättigen kann, lange bevor die Verbindung voll ist, während WireGuard komfortabel bleibt — und CPU-Reserven für andere Aufgaben des Geräts lässt (einen Passwortmanager, eine kleine Cloud, Analysen).

Auf Hardware mit AES-Beschleunigung (die meisten modernen x86-CPUs, Apple Silicon) wird OpenVPNs AES-256-GCM hardwarebeschleunigt und die CPU-Lücke wird kleiner; auf Hardware ohne diese Beschleunigung ist ChaCha20 die bessere OpenVPN-Chiffre-Wahl. WireGuards ChaCha20-Poly1305 ist auf beiden schnell.

Stabilität und mobiles Roaming

WireGuard ist zustandslos konzipiert: Es gibt keine "Verbindung" herzustellen, nur bekannte Peers. Wenn ein Client von WLAN zu mobilen Daten wechselt und zurück, wird der Tunnel fast sofort ohne Neuverhandlung wieder aufgenommen. OpenVPN muss bei jedem Netzwerkwechsel ein TLS-Handshake erneut durchführen, was einige Sekunden dauert. Für ein Telefon, das den ganzen Tag über Netzwerke wechselt, ist WireGuards Roaming-Verhalten ein echter, greifbarer Vorteil.

Ein Datacenter-Gang: Ein selbstgehostetes VPN läuft auf einem einzigen VPS in einer solchen Einrichtung — die Protokollwahl beeinflusst hauptsächlich, wie effizient dieser eine Server Ihren Datenverkehr bewegt.

Sicherheitsanalyse

Die Sicherheitsdebatte wird oft durch "OpenVPN existiert seit 20 Jahren, also ist es ausgereifter" verzerrt. Schauen wir uns die Fakten an:

WireGuard:

• Moderne, feste Kryptoprimitive: Curve25519 (Schlüsselaustausch), ChaCha20-Poly1305 (AEAD), BLAKE2s (Hash), SipHash24 (Hashtabelle).
• ~4.000 Zeilen C im Kernelmodul — eine kleine, überprüfbare Angriffsfläche.
• Formales Audit von Cure53 veröffentlicht 2018 — keine kritische Schwachstelle gefunden. Ein separates Review von Trail of Bits (2020) untersuchte die macOS-Implementierung.
• Seit Kernel 5.6 (März 2020) im Mainline-Linux-Kernel, überprüft von der netdev-Community.
• Keine kryptografische Konfiguration möglich: Sie können nicht versehentlich eine schwache Option wählen.

OpenVPN:

• Konfigurierbare Primitive: Der moderne Standard ist AES-256-GCM, aber eine unvorsichtige Konfiguration, die aus einem alten Tutorial kopiert wurde, könnte immer noch etwas Schwaches auswählen.
• ~70.000 Zeilen C plus OpenSSL als große Abhängigkeit — eine viel größere Fläche, über die man nachdenken muss.
• OSTIF-Audits in 2017 und 2018 — einige Fehler gefunden und behoben, keine kritischen RCE.
• Historisch anfällig für OpenSSL-Probleme (z.B. Heartbleed 2014 betraf Deployments, die OpenSSL verwendeten).

Ehrliches Urteil: Beide sind 2026 solide. WireGuard hat einen architektonischen Vorteil (kleine Angriffsfläche, moderne Primitive, keine Stolperfallen). OpenVPN hat einen Reifevorteil (zwei Jahrzehnte in Produktion, weitgehend auditiert, enorme Einsatzbasis). Für ein Selbsthosting ist WireGuard die einfache Standardwahl — das Verhältnis von Einfachheit zu Sicherheit ist ausgezeichnet.

Durchsatz nach Client-Plattform

Auf den Desktop-Plattformen mit nativer WireGuard-Unterstützung (Linux, macOS, Windows) ist der anhaltende Durchsatz im Großen und Ganzen ähnlich, wobei neuere Kernel und der moderne native Windows-Treiber die meisten der historischen Unterschiede geschlossen haben. Wo Sie einen echten Unterschied sehen werden, ist auf Telefonen: Unter einer anhaltenden, voll ausgelasteten Übertragung drosseln mobile Geräte aus thermischen und Batteriegründen und erreichen nicht die Leistung eines Desktops. Das ist erwartetes mobiles Verhalten und für den normalen Gebrauch (Surfen, Streaming) irrelevant — es zeigt sich nur, wenn Sie ein Telefon mit iperf3 oder einem schweren Backup belasten.

Wenn Sie Ihre eigene Einrichtung messen möchten, anstatt sich auf die Zahlen anderer zu verlassen, finden Sie die reproduzierbaren Testbefehle am Ende dieses Artikels.

Wann OpenVPN 2026 noch relevant bleibt

Das WireGuard-Marketing ist so dominant, dass wir vergessen, dass OpenVPN immer noch solide Anwendungsfälle hat. Hier sind die Situationen, in denen es immer noch das richtige Werkzeug ist.

Fall 1: Umgehung von Unternehmens-/Hotel-Firewalls

Viele Unternehmensfirewalls (Fortinet, Palo Alto, Check Point) blockieren ausgehendes nicht-DNS-UDP. Sie können dies auf einem Kunden-WLAN, in einigen Hotels oder auf einigen Onboard-Transport-Hotspots erleben. Da WireGuard nur UDP ist, schlägt der Tunnel stillschweigend fehl (der Handshake wird nie abgeschlossen). Sie können WireGuard mit wstunnel oder Cloak umwickeln, um es über TCP/443 zu transportieren, aber das ist eine zusätzliche Schicht, die gewartet werden muss.

OpenVPN unterstützt nativ TCP auf Port 443, mit einem TLS-Handshake, der gewöhnlichem HTTPS-Verkehr ähnelt, sodass es an vielen einfacheren DPI-Setups vorbeischlüpft. Als "Backup-VPN für den Fall, dass ich auf einem unfreundlichen Unternehmens-WLAN bin", ist es pragmatisch, ein OpenVPN TCP/443-Profil bereit zu halten.

Minimale Einrichtung auf demselben Contabo VPS, neben einer bestehenden WireGuard-Installation:

sudo apt install -y openvpn easy-rsa
sudo make-cadir /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
sudo ./easyrsa init-pki
sudo ./easyrsa build-ca nopass
sudo ./easyrsa build-server-full vpnsmith nopass
# Konfiguration /etc/openvpn/server/server.conf mit:
# proto tcp
# port 443
# dev tun
# cipher AES-256-GCM

Öffnen Sie TCP/443 auf UFW, dann systemctl enable --now openvpn-server@server. Der Client wählt aus, welches Profil verwendet werden soll (standardmäßig WireGuard, OpenVPN TCP/443 als Fallback).

Fall 2: Kompatibilität mit älteren Betriebssystemen

Wenn Sie einem Windows 7/8.1-Rechner, einem alten Synology DSM oder einer alternden Android-TV-Box Tunnelzugang gewähren müssen, existiert der offizielle WireGuard-Client möglicherweise nicht oder wird dort nicht mehr gepflegt. OpenVPN hat seit vielen Jahren einen Client für fast alles — einschließlich alter DD-WRT-Router, die niemals WireGuard unterstützen werden. Für einen Verwandten, der auf einem alten Betriebssystem festsitzt, ist das Einrichten einer zweiten OpenVPN-Instanz, die diesem Konto auf demselben VPS gewidmet ist, eine saubere Lösung.

Fall 3 (Bonus): Detaillierte Audit-Protokollierung

OpenVPN protokolliert jede Verbindung, Trennung und TLS-Erneuerung sauber. WireGuard hält die Protokollierung aus Designgründen minimal (Sie sehen hauptsächlich Schnittstellen hoch/runter über journalctl -u wg-quick@wg0). Wenn Ihr Bedrohungsmodell oder Ihr Compliance-Regime (z.B. DORA, NIS2, ISO 27001) einen formalen Audit-Trail verlangt, ist OpenVPN einfacher aus der Box zu erfüllen.

Ehrliches Urteil: Für ein persönliches VPN im Jahr 2026, zuerst WireGuard. Aber das Beibehalten eines OpenVPN TCP/443-Profils als sekundäre Konfiguration auf demselben VPS ist vernünftiger Pragmatismus — es kostet ein paar Minuten, um es einzurichten, und rettet Sie, wenn UDP blockiert ist.

Urteil pro Anwendungsfall

Wenn Sie von Grund auf neu beginnen, um Ihr eigenes VPN auf einem Contabo VPS zu hosten, folgen Sie unserem Schritt-für-Schritt WireGuard-Leitfaden — und Sie kopieren die Skripte.

Wenn Sie gegen Unternehmens- oder staatliche DPI kämpfen, schauen Sie sich den benutzerdefinierten Routing-Leitfaden mit DPI-Umgehung an, der WireGuard mit einer Verschleierungsschicht kombiniert.

Wenn Sie noch beim VPS-Anbieter zögern (Contabo vs Hetzner vs OVH), haben wir die drei unter realen Bedingungen verglichen.

Messen Sie es selbst mit iperf3

Anstatt sich auf veröffentlichte Zahlen zu verlassen, messen Sie Ihren eigenen VPS und die Verbindung. Installieren Sie iperf3 auf dem Server, führen Sie es als Server aus und testen Sie von Ihrem Client mit und ohne aktivem Tunnel:

# Serverseite (Ihr VPS)
sudo apt install -y iperf3
sudo iperf3 -s -D

# Clientseite (Mac/Linux)
# Basislinie (kein VPN)
iperf3 -c IP_VPS -t 30 -O 5 --json > baseline.json

# WireGuard (Tunnel aktiv)
iperf3 -c 10.66.66.1 -t 30 -O 5 --json > wireguard.json

# OpenVPN UDP (Tunnel aktiv)
iperf3 -c 10.8.0.1 -t 30 -O 5 --json > openvpn-udp.json

Führen Sie mehrere Iterationen in einer for-Schleife aus und berechnen Sie den Median mit jq:

jq -s 'map(.end.sum_received.bits_per_second) | sort | .[length/2]' wireguard.json

Wenn Ihre Zahlen nicht stimmen, überprüfen Sie die MTU (ping -M do -s 1372 IP), die Qualität Ihrer Verbindung (ein mtr zum VPS sollte <1% Verlust zeigen) und dass der VPS nicht unter CPU-Steal leidet (mpstat -P ALL 1).

Bestellen Sie einen VPS für Ihren Tunnel

Ein kleiner VPS reicht für einen persönlichen WireGuard-Tunnel aus: Contabo VPS S Cloud, 24-Monats-Plan (~€5,49/Monat äquivalent). Er betreibt bequem einen persönlichen Tunnel neben ein paar leichten selbstgehosteten Diensten.

Sobald Ihr VPS bereit ist, überspringen Sie den manuellen Schlüsselschreibschritt: Unser WireGuard-Konfigurationsgenerator gibt eine wg0.conf mit den richtigen Kryptoparametern in Sekunden aus. Für eine breitere Protokoll- und Anbieterentscheidung, siehe den besten selbstgehosteten VPN-Hub für 2026 — er behandelt WireGuard, Tailscale, Headscale, Nebula und OpenVPN.

Quellen

• Cure53 — WireGuard formale Verifizierung (2018)
• WireGuard Whitepaper (Jason A. Donenfeld)
• Offizielle OpenVPN 2.6 Dokumentation
• iperf3 Benutzerhandbuch
• Phoronix WireGuard Benchmarks auf Kernel 6.x
• Trail of Bits WireGuard macOS Audit (2020)

Dieser Artikel ist ein qualitativer technischer Vergleich basierend auf den öffentlichen, dokumentierten Eigenschaften von WireGuard und OpenVPN. Er berichtet nicht über einen privaten Benchmark-Lauf. Für spezifische Zahlen zu Ihrer Hardware und Verbindung führen Sie das iperf3-Verfahren oben auf Ihrem eigenen VPS durch.

Affiliate-Hinweis: Der obige Contabo-Link ist ein getrackter Link, der uns eine Provision zahlt, wenn Sie abonnieren. Er ändert Ihren Preis nicht.