WireGuard, OpenVPN und VLESS im Vergleich

WireGuard ist ein moderner Tunnel, der auf den meisten Systemen im Kernel läuft. Rund viertausend Zeilen Code, ein einziger fester Satz moderner Kryptografie ohne Aushandlung, und ausschließlich UDP. Es gibt keine Anmeldung, keinen Sitzungsaufbau und keine Verschlüsselungsauswahl: Ihr Client sendet ein verschlüsseltes Paket, und die Gegenstelle antwortet oder eben nicht.

OpenVPN ist älter, viel größer und endlos konfigurierbar. Es läuft über UDP oder TCP, auf jedem Port, mit vielen Chiffren, und kann am Anfang einen vollen TLS-Handshake tragen. Genau diese Konfigurierbarkeit ist der Grund, warum es Netze übersteht, die WireGuard nicht durchlassen, und zugleich der Grund, warum es langsamer und schwerer ist.

VLESS ist in diesem Sinne gar kein VPN-Tunnel. Es ist ein schlanker Proxy-Transport aus der Xray-Familie, der Datenströme trägt statt Pakete zu routen, keine eigene Verschlüsselung hat und darunter auf TLS setzt. Es existiert, um von normalem HTTPS nicht unterscheidbar zu sein. Wer das Protokoll richtig erklärt haben will, findet das auf /what-is-vless/, ohne dass dort etwas verkauft wird.

WireGuard gewinnt in allen drei Punkten deutlich. Weil es klein ist, im Kernel sitzt und nichts aushandelt, fügt es sehr wenig Latenz hinzu und erreicht auf ordentlicher Hardware fast die Geschwindigkeit Ihrer unverschlüsselten Leitung. Auf dem Telefon ist es auch am akkuschonendsten, weil es still bleibt, wenn nichts zu senden ist, und keine gesprächige Sitzung unterhält.

OpenVPN über UDP ist respektabel schnell, aber merklich schwerer: mehr Verarbeitung pro Paket, mehr Kontextwechsel, weil es im Userspace läuft, und eine längere Verbindungszeit wegen des TLS-Handshakes am Anfang. OpenVPN über TCP ist die langsame Variante, und der Grund ist strukturell. TCP in TCP heißt zwei Ebenen von Neuübertragung und Staukontrolle, die gegeneinander arbeiten: für Surfen in Ordnung, für große Übertragungen auf einer verlustbehafteten Leitung schmerzhaft.

VLESS liegt dazwischen und hängt stark vom Weg ab. Der Protokoll-Overhead ist winzig, aber eine CDN-gestützte Verbindung ist keine direkte: Ihr Verkehr erreicht einen CDN-Knoten und wird weitergereicht, und dieser zusätzliche Sprung zeigt sich als Latenz. Dafür ist ein CDN-Knoten oft besser angebunden als eine direkte Route, sodass das Ergebnis in Regionen mit schlechtem Direktrouting schneller ausfallen kann als erwartet.

Eine ehrliche Anmerkung zu Tempoversprechen allgemein: In einem guten Netz sind alle drei meist schnell genug, dass der Unterschied nichts entscheidet. Entschieden wird er, wenn das Netz schlecht ist, und dort zählen Fehlerbilder mehr als Benchmarks.

WireGuard ist von den dreien am leichtesten zu erkennen und zu sperren. Sein Handshake hat in den ersten Bytes eine feste, gut dokumentierte Form, und es läuft nur über UDP, ein Netz kann es also per Muster blockieren oder schlicht UDP zu unbekannten Zielen verwerfen. UDP zu sperren kostet ein Netz fast nichts, deshalb tun es so viele. WireGuard wurde für Tempo und Korrektheit entworfen, nicht fürs Verstecken, und seine Autoren haben nie etwas anderes behauptet.

OpenVPN liegt in der Mitte. Sein eigener Handshake ist ebenfalls erkennbar, und mehrere nationale Filtersysteme haben genau das vorgeführt. Aber es kann auf TCP-Port 443 laufen, verlässt Ihr Gerät also auf demselben Port wie jede HTTPS-Verbindung, und schon das bringt es durch die große Klasse von Netzen, die nach Port statt nach Inhalt filtern. Gegen ein System, das die Nutzlast prüft, ist die Tarnung schwächer, als sie wirkt.

VLESS über TLS ist von den dreien das stärkste und genau dafür gebaut. Der Verkehr ist eine TLS-Sitzung, der Handshake-Fingerabdruck lässt sich einem gängigen Browser angleichen, und mit CDN-Fronting ist die Zieladresse eine, die auch Tausende gewöhnlicher Websites ausliefert. REALITY geht weiter und beantwortet eine aktive Sonde mit dem echten Handshake einer realen, unbeteiligten Seite.

Nichts davon ist ein Versprechen. Ein Netz, das nur eine Whitelist erlaubt, stoppt alle drei, und Erkennungsmethoden ändern sich. Nützlicher als die Frage, welches Protokoll gewinnt, ist die Frage, welches den Netzbetreiber mehr kostet: UDP zu verwerfen ist gratis, TCP 443 zu sperren zerstört das Web für alle, und eine CDN-Adresse zu sperren zerstört einen großen Teil davon.

WireGuard hat die beste Unterstützung und die geringste Reibung. Es gibt einen offiziellen Client auf jeder Desktop- und Mobilplattform, es steckt im Linux-Kernel, und es ist in den meisten brauchbaren Router-Firmwares eingebaut, darunter OpenWrt, OPNsense, pfSense und MikroTik. Eine Konfiguration importiert man auf dem Telefon per QR und überall sonst als Datei.

OpenVPN läuft ebenfalls überall, aber mit mehr beweglichen Teilen: Der Client ist größer, die Konfigurationsdatei hat weit mehr Optionen, die falsch sein können, und der Verbindungsaufbau dauert einige Sekunden statt sofort zu klappen. Auf Routern und in Firmenumgebungen ist es sehr gut unterstützt, und genau dort braucht man es oft.

VLESS braucht einen Drittanbieter-Client, und einen offiziellen gibt es nicht, weil es ein Transport und kein Produkt ist. In der Praxis nimmt man v2rayNG oder Hiddify unter Android, Shadowrocket oder Streisand unter iOS und v2rayN, Nekoray oder Hiddify auf dem Desktop. Die iOS-Optionen sind kostenpflichtig und teils regional eingeschränkt, was man vorher wissen sollte. Router-Unterstützung ist selten.

Das Plattformdetail, an dem viele hängenbleiben, ist der Kill Switch. Er ist eine Funktion des Clients oder des Betriebssystems, nicht des Protokolls, und existiert in unterschiedlicher Stärke. Ausführlich steht das auf /wireguard-vpn-config/, weil die Frage meist bei einer WireGuard-Konfiguration aufkommt.

Das Fehlerbild zu kennen nützt mehr als der Benchmark, weil es Ihnen sagt, was als Nächstes zu tun ist. WireGuard scheitert lautlos: Der Tunnel gilt als aktiv, gesendete Bytes steigen, empfangene bleiben null, und der letzte Handshake aktualisiert sich nie. Es gibt keine Fehlermeldung. Dieses Bild bedeutet fast immer gesperrtes UDP, und die Antwort ist ein Protokollwechsel und kein Serverwechsel.

OpenVPN scheitert laut. Es schreibt ein Log, und das Log sagt, ob der Server nicht erreichbar war, das Zertifikat nicht überprüft werden konnte oder die Gegenstelle den Handshake zurückgesetzt hat. Eine Verbindung, die zustande kommt und dann wiederholt abbricht, bedeutet meist gezielte Störung durch das Netz und nicht fehlende Unterstützung.

VLESS scheitert auf der TLS-Ebene. Sie bekommen eine abgewiesene Verbindung oder einen Handshake-Fehler, oder, verwirrender, eine Sitzung, die zustande kommt und dann ohne Daten stehenbleibt. Die üblichen Ursachen sind eine unpassende Transporteinstellung, ein falsches SNI oder eine gesperrte CDN-Route, und die Lösung ist meist ein anderer Endpunkt statt einer Änderung in der Konfiguration.

Ein Fehlerbild teilen sich alle drei, und es kostet viel Zeit: ein funktionierender Tunnel mit kaputter Namensauflösung. Alles meldet Verbindung, IP-Adressen antworten, und kein Hostname lädt. Das ist DNS, nicht das Protokoll, und wird in der Client-Konfiguration behoben.

Standard ist WireGuard. Auf einer Heimleitung, im Mobilfunk, in einem normalen Café oder einem gewöhnlichen Büro ist es schneller, leichter und einfacher, und es gibt keinen Grund für etwas anderes. Wer nur dort unterwegs ist, kann hier aufhören.

Wechseln Sie zu OpenVPN über TCP 443, wenn das Netz UDP drosselt oder sperrt. Hotel-WLAN, Kongresszentren, Gastnetze von Firmen und Universitätsnetze sind die üblichen Verdächtigen. Das Anzeichen ist ein WireGuard-Tunnel, der aktiv meldet und null empfangene Bytes zeigt. Nehmen Sie die Geschwindigkeitseinbuße in Kauf, denn eine langsame Verbindung ist unendlich schneller als keine.

Gehen Sie zu VLESS, wenn beides gesperrt ist, denn dann prüft das Netz Inhalte statt nur Ports zu filtern. Probieren Sie zuerst den nächstgelegenen Endpunkt und dann die anderen, denn CDN-Routing unterscheidet sich je nach Region, und der schnellste für Sie ist nicht der schnellste für alle.

Zwei Situationen drehen die Reihenfolge um. Wenn Sie ausdrücklich ein Ausgangsland brauchen, in dem wir keinen VLESS-Endpunkt betreiben, bleibt Ihnen ungeachtet des Obigen nur WireGuard oder OpenVPN. Und wenn Sie einen Router einrichten, nehmen Sie WireGuard oder OpenVPN, weil VLESS in Router-Firmware selten unterstützt wird.

Das übliche Modell dieser Branche ist eine App, die das Protokoll für Sie wählt. Das macht den Einstieg leicht und genau eine Sache unmöglich: etwas zu tun, das die App nicht vorgesehen hat. Wenn die App nicht verbindet, gibt es keinen nächsten Schritt, und ihr automatischer Protokollwechsel wählt nur zwischen dem, was sie mitgebracht hat.

Wir geben stattdessen die Konfigurationsdateien heraus. WireGuard als .conf oder QR, OpenVPN als .ovpn in UDP- und TCP-Varianten, VLESS als vless://-Link und QR, alles auf einem Konto mit fünf gleichzeitigen Verbindungen und ohne Preisunterschied je Protokoll. Die oben beschriebene Ausweichkette funktioniert, weil Sie alle drei bereits besitzen, bevor Sie die zweite brauchen.

Es entfernt außerdem ein Stück Software, dem Sie sonst vertrauen müssten. Eine VPN-App läuft mit Netzwerkrechten auf Ihrem Gerät, eine Konfigurationsdatei ist Text, den Sie lesen können. Sie nehmen den offiziellen WireGuard-Client oder den Xray-Client Ihrer Wahl, und das Einzige, worauf Sie uns vertrauen, ist das Netz selbst.

Wo das die Ehrlichkeitsgrenze zieht: keine Protokolle, das heißt Quell-IP-Adressen und Verbindungszeitpunkte werden nicht gespeichert, und Server laufen aus dem RAM, sodass ein Neustart sie leert. Das kontrollieren wir. Ein VPN verschiebt das, was Ihr lokales Netz und Ihr Zugangsanbieter sehen, auf das VPN-Netz, das ist eine Verlagerung von Vertrauen und keine Anonymität, und kein Protokoll auf dieser Seite ändert daran etwas. Laufzeiten von 7 bis 365 Tagen auf /vpn/, in Krypto bezahlt, ohne automatische Verlängerung.