VLESS-Protokoll: V2Ray VPN, Xray-Server und Leitfaden zur Umgehung der Zensur
Etwa ein halbes Jahrzehnt nach seinem Auftauchen in einem wenig beachteten GitHub-Repository hat sich VLESS still und leise zum Standardprotokoll der Proxys entwickelt, die in Russland, Iran und China tatsächlich genutzt werden. Die Gründe dafür sind wenig romantisch: Es ist klein, verschlüsselt selbst keine Daten und ist zudem das einzige weit verbreitete Protokoll, das die größten staatlichen Deep-Packet-Inspection-Systeme (DPI) bis Mitte 2026 noch nicht endgültig überwunden haben.
Dieser Leitfaden erklärt, was VLESS als schlankes Protokoll ist, wie es intern funktioniert, welche Dienste darauf aufbauen (Xray, XTLS, REALITY), wie es sich im Vergleich zu VMess, Trojan, Shadowsocks, WireGuard und traditionellen VPN-Protokollen wie OpenVPN verhält und wie eine VLESS-VPN-Konfiguration in der Praxis aussieht. Es handelt sich um eine technische Erklärung, nicht um eine Konfigurationsanleitung. Falls Sie nach dem Lesen noch Serverbefehle zum Kopieren und Einfügen benötigen, sind die Projektdokumente unter xtls.github.io der richtige nächste Schritt.
Was VLESS ist und warum die V2Ray-Community es entwickelt hat
VLESS, kurz für „VMess Less“, ist ein zustandsloses, leichtgewichtiges Proxy-Protokoll, das 2020 von dem Entwickler RPRX eingeführt wurde, der seit 2019 ein Inkubations-Repository unter RPRX/v2ray-vless unterhielt. Es wurde als bewusste Reduzierung von VMess, dem ursprünglichen V2Ray-Protokoll, konzipiert, das Ende der 2010er Jahre durch seine eigenen Verschlüsselungs-, Replay-Schutz- und Taktsynchronisationsmechanismen unhandlich geworden war.
VLESS ist heute hauptsächlich in zwei Codebasen enthalten. Das ursprüngliche v2fly/v2ray-core-Repository enthält es aus Kompatibilitätsgründen. Der ebenfalls von RPRX gepflegte XTLS/Xray-core-Fork ist die aktiver entwickelte Implementierung: 38.600 GitHub-Sterne und rund 5.400 Forks (Stand: Mai 2026) gegenüber 33.900 Sternen bei v2fly/v2ray-core. Xray bietet die wichtigsten Funktionen, nämlich die XTLS Vision-Flusssteuerung und den REALITY-Transport, die v2fly nicht enthält.
So funktioniert das VLESS-Protokoll: UUID, keine Verschlüsselung, TLS außerhalb
Das VLESS-Protokoll ist so kurz, dass es in einem Absatz beschrieben werden kann. Ein Client öffnet eine Verbindung und sendet einen Header. Dieser Header enthält ein Versionsbyte, eine 16-Byte-UUID des Benutzers, einen Längenindikator für das optionale Addons-Feld, die Addons selbst, einen Ein-Byte-Befehl (TCP oder UDP), den Zielport, ein Byte für den Adresstyp und die Adresse. Das entspricht 25 bis 50 Byte pro Verbindung. OpenVPN hingegen benötigt über 100 Byte pro Paket.
Der Header wird von VLESS selbst in keiner Weise verschlüsselt. Das Protokoll erfordert explizit `encryption: "none"` in seiner JSON-Konfiguration, und die v2fly-Dokumentation besagt, dass dieses Feld nicht leer bleiben darf – es muss explizit "none" enthalten, um die Betreiber daran zu erinnern, dass das Protokoll die gesamte Vertraulichkeit an das zugrunde liegende Transportprotokoll delegiert. In der Praxis ist dies fast immer TLS 1.3.
Diese Designentscheidung ist die Grundlage aller interessanten Eigenschaften von VLESS. Da VLESS keine eigene Verschlüsselungsschicht verwendet, vermeidet es den Fehler, der VMess in zensierten Netzwerken zum Verhängnis wurde. Eine zweite Verschlüsselungsschicht innerhalb eines äußeren TLS-Tunnels erzeugt sogenannte „TLS-in-TLS“-Muster, wie sie von Verkehrsanalysten genannt werden. Staatliche DPI-Systeme, die darauf trainiert sind, genau diese doppelte Verschlüsselungsstruktur zu erkennen, waren der Hauptgrund dafür, dass die Erkennungsrate von VMess an der chinesischen Großen Firewall bis September 2025 auf über 80 Prozent stieg. VLESS, das lediglich einen Authentifizierungs-Blob und Routing-Metadaten überträgt, ähnelt einer einzelnen, gewöhnlichen TLS-Kommunikation, wodurch die Art von Protokoll-Fingerprinting, auf der Deep-Packet-Inspection-Systeme basieren, unterbunden wird.
Die zweite bewusste Auslassung ist die Zustandsbeschränkung. VMess basiert auf synchronisierten Uhren zwischen Client und Server, wobei Paketzeitstempel verwendet werden, um Replay-Angriffe zu verhindern. Dies führte jahrelang zu verwirrenden Verbindungsabbrüchen, sobald die Uhrzeit eines Telefons abwich, ein Laptop im Dual-Boot-Modus lief oder sich ein Server in der falschen Zeitzone befand. VLESS ist zustandslos. Die UUID ist die einzige Authentifizierungsmethode. Stimmt die UUID überein, wird die Verbindung autorisiert; andernfalls wird sie beim ersten Byte abgelehnt. Nichts ist von der Zeit abhängig.
UUIDs in VLESS sind Standard-RFC-4122-Identifikatoren. Sie werden mit dem Befehl `xray uuid` generiert; jeder gängige UUID-Generator funktioniert ebenfalls. Benutzerdefinierte Zeichenketten mit bis zu 30 Bytes werden akzeptiert und gemäß dem in der Dokumentation als „VLESS UUID Mapping Standard“ bezeichneten Verfahren UUIDs zugeordnet. Die meisten Installationen verwenden kanonische UUIDs, da die Zuordnung in der Praxis keine Auswirkungen hat.
Die Transportoptionen liegen dem Protokoll zugrunde: TCP (mit oder ohne TLS), mKCP, WebSocket, gRPC und QUIC werden unterstützt. Jede Option beeinflusst den Datenverkehr auf unterschiedliche Weise. WebSocket ermöglicht es VLESS, sich hinter einem normalen HTTP/1.1-Upgrade-Handshake zu verbergen und den Datenverkehr über CDNs wie Cloudflare zu leiten. gRPC nutzt das HTTP/2-Multiplexing. QUIC transportiert den gesamten Datenverkehr innerhalb einer äußeren, UDP-basierten TLS-1.3-Sitzung. Dem Protokoll ist es egal, welches Transportprotokoll verwendet wird. Diese Trennung macht es portabel.
Xray, REALITY und XTLS: Der Stack, auf dem VLESS tatsächlich läuft
In der Praxis läuft niemand nackt VLESS. Interessant ist, was drumherum läuft.
Xray-core ist die dominierende Laufzeitumgebung. Es handelt sich um einen Fork von V2Ray-core, der von RPRX und den XTLS-Mitwirkenden nach einer Spaltung der Community ins Leben gerufen wurde, und er enthält zwei Technologien, auf die VLESS für ernsthafte Zensurumgehungsarbeiten angewiesen ist: XTLS Vision und REALITY.
XTLS Vision (in der Konfiguration als `flow: "xtls-rprx-vision"` angegeben) ist ein Padding-Verfahren für TLS-1.3-Datenverkehr. Das damit gelöste Problem ist subtil: TLS-1.3-Datensätze weisen vorhersehbare Längensignaturen auf, wenn sie interne Anwendungsdaten fester Form enthalten – die Längen geben Informationen darüber preis, was getunnelt wird. Vision fügt während der frühen Handshake-Phase Padding-Bytes hinzu. Sobald die Verbindung hergestellt ist, wird auf das Kopieren direkt im Socket umgeschaltet. Unter Linux verwendet es den Systemaufruf `splice()`, um TCP-Pakete im Kernel weiterzuleiten, ohne sie über den Benutzermodus zu kopieren. Das Ergebnis ist ein Durchsatz, der dem einer nicht-proxied TCP-Verbindung nahekommt, wobei das Lecken der Längensignatur beseitigt wird.
REALITY, veröffentlicht 2023 und gepflegt unter github.com/XTLS/REALITY, verfolgt einen radikaleren Ansatz. Ein herkömmlicher VLESS+TLS-Server präsentiert sein eigenes TLS-Zertifikat, was bedeutet, dass er eine Domain besitzt, Certbot ausführt und einen Zertifikat-Fingerabdruck bereitstellt, den ein DPI-System mit der Proxy-Nutzung korrelieren kann. REALITY verwirft dieses Konzept vollständig. Anstatt ein eigenes TLS zu betreiben, imitiert der Server den Handshake einer echten Drittanbieter-Website. Der Betreiber wählt das Ziel: `microsoft.com`, `apple.com` oder eine beliebige andere Domain. Der Server verwendet SNI-Fälschung und einen X25519-Schlüsselaustausch. Clients, die den korrekten öffentlichen REALITY-Schlüssel kennen, führen einen echten TLS-1.3-Handshake mit der imitierten Zertifikatskette durch, genau wie ein Browser mit einem echten Webserver, und werden anschließend in den VLESS-Tunnel geleitet. Clients, die diesen Schlüssel nicht kennen, einschließlich DPI-Systeme, sehen eine scheinbar normale Verbindung zur imitierten Website, inklusive des echten Zertifikats.
Die Kombination aus VLESS als internem Protokoll, XTLS Vision zur Glättung der Längensignatur und REALITY zur Verschleierung des Handshakes ist das, was gemeint ist, wenn man von „VLESS+REALITY“ oder „VLESS+Vision+REALITY“ spricht. Es ist die Konfiguration, die auch Mitte 2026 noch in Umgebungen funktioniert, in denen fast nichts anderes funktioniert.
VLESS vs VMess vs Trojan vs Shadowsocks vs WireGuard
Der Protokollraum um VLESS ist klein, und die Unterschiede sind bedeutsam. Die Kurzfassung folgt unten; die Langfassung ist in der Tabelle dargestellt.
VMess ist der Vorgänger von VLESS. Es verfügt über eine eigene AEAD-Verschlüsselung, Schutz vor Replay-Angriffen und alterId-basierte Varianten. In einem unzensierten Netzwerk kosten diese Funktionen einige Prozent Durchsatz und bieten keinen zusätzlichen Nutzen. In einem zensierten Netzwerk ist das Muster der Verschlüsselung innerhalb von TLS erkennbar, und die GFW-Telemetrie zeigt seit September 2025 eine Erkennungsrate von etwa 80 Prozent an.
Trojan ist ein verwandtes Design eines anderen Teams. Es ist sogar noch einfacher als VLESS: ein Passwort statt einer UUID, kein Add-ons-Feld und TLS-Verschlüsselung. Jahrelang war es aufgrund dieses Minimalismus sehr sicher; das GFW-Upgrade im August 2025 änderte dies jedoch, und Trojan erreicht nun eine Erkennungsrate von etwa 90 Prozent.
Shadowsocks gehört einer völlig anderen Familie an. Es handelt sich um eine symmetrische AEAD-Verschlüsselung ohne TLS-Fassade, die wie zufällige Bytes und nicht wie HTTPS aussieht. Dieser Ansatz funktionierte, bis die GFW begann, vollständig verschlüsselten Datenverkehr standardmäßig als verdächtig einzustufen. Moderne Shadowsocks-Implementierungen nutzen Transport-Plugins (v2ray-Plugin, Cloak), die die Verschlüsselung in TLS oder HTTP einbetten und so die VLESS-Architektur quasi von der anderen Seite nachbilden.
WireGuard gehört in eine ganz andere Diskussion. Es handelt sich um ein VPN auf Kernel-Ebene, nicht um ein Proxy-Protokoll. In einem sauberen Netzwerk ist es im Vergleich zu VLESS+XTLS beim reinen Datendurchsatz etwa 2–3 Prozent schneller, mit deutlich geringerem CPU-Overhead, und bleibt die richtige Lösung für normale Anwendungsfälle zum Schutz der Privatsphäre gegenüber Internetanbietern. In zensierten Netzwerken lässt sich sein festes Handshake-Byte 0x01 leicht identifizieren, und der effektive Datendurchsatz sinkt gegen null.
| Protokoll | Familie | Äußere Schicht | DPI-Widerstand | Am besten geeignet für |
|---|---|---|---|---|
| VLESS+REALITY | V2Ray/Xray-Proxy | TLS 1.3 wurde imitiert. | Hoch (≤5 % Nachweisrate in Feldberichten) | Feindliche Netzwerke |
| VMess | V2Ray-Proxy | Selbstverschlüsselung innerhalb von TLS | Niedrig (~80% GFW) | Nur Kompatibilität mit älteren Systemen |
| Trojan | TLS-Fronting-Proxy | Eigenes TLS | Niedrig (~90 % GFW nach August 2025) | Einfacheres Selbsthosting |
| Shadowsocks (AEAD) | Symmetrische Verschleierung | Zufällige Bytes / TLS-Plugin | Gemischt (abhängig vom Plugin) | Mobile Nutzer mit instabilen Links |
| WireGuard | Kernel-VPN | UDP + Noise-Handshake | Sehr niedrig (DPI-erkennbar) | Saubere Netzwerkdaten, hohe Privatsphäre und Geschwindigkeit |
VLESS, Zensur und die russische DPI-Blockade
VLESS wäre in der Geschichte der Proxy-Software wohl nur eine Fußnote, wenn es nicht die Zensur in Russland und ähnlichen Regimen zuverlässiger umgehen würde als jedes andere weit verbreitete Protokoll. Seit 2024 versuchen die größten staatlichen DPI-Systeme der Welt aktiv, es zu unterbinden. Seitdem hat sich die Situation zu einem schleichenden, öffentlichen Eskalationsspiel entwickelt.
In Russland meldete Roskomnadzor bis Januar 2026 die Sperrung von 439 VPN-Diensten. Das Budget des Bundes für die VPN-Sperrung belief sich für den Zeitraum 2025–2027 auf rund 60 Milliarden Rubel (ca. 780 Millionen US-Dollar). Weitere 2,27 Milliarden Rubel (ca. 29 Millionen US-Dollar) waren laut einem Bericht von zona.media vom April 2026 speziell für KI-basierte Verkehrsfilterung vorgesehen. Am 17. Februar 2026 verschärfte Roskomnadzor die Maßnahmen erneut mit einer massiven Sperrwelle, die sich gezielt gegen VLESS-over-TCP-with-TLS richtete, wie Mezha und digirpt dokumentierten. Innerhalb weniger Stunden wichen die Nutzer auf REALITY, gRPC und CDN-basierte Transportprotokolle aus. Die gemeldete Umgehungsrate von VLESS+REALITY gegenüber russischem DPI lag während dieser Welle bei nahezu 99,5 Prozent – ein Wert, der eher als Richtwert denn als exakter Messwert zu verstehen ist.
In China durchlief die Große Firewall 2025 eine ähnliche Entwicklung. Die Erkennungsrate von Trojanern sank im August auf etwa 90 Prozent, die von VMess im September auf etwa 80 Prozent. Ein separater Cybersicherheitsvorfall im September 2025 – ein von Cybernews gemeldeter Datenverlust von 600 GB bei einem chinesischen Auftragnehmer der Großen Firewall – legte Teile der internen Klassifizierungsinfrastruktur offen, hatte aber allein keinen Einfluss auf die Wirtschaftlichkeit des Einsatzes. Tests der Community auf greatfirewallguide.com ergaben Anfang 2026 eine Umgehungsrate von 98 Prozent für VLESS+REALITY+Vision.
Im Iran setzt die IRGFW von MCI REALITY-IP-Adressen mindestens seit April 2024 auf die Graylist, wie in der XTLS/Xray-core-Diskussion #3269 dokumentiert ist. Betreiber berichten, dass eine IP-Adresse, die etwa 100 GB REALITY-Datenverkehr transportiert, in der Regel innerhalb von 48 Stunden von Irancell blockiert wird. Aus diesem Grund sind Serverrotation und CDN-Fronting dort gängige Praxis geworden.
So sieht eine VLESS-VPN-Konfiguration aus: Server, Clients, Konfigurationen
Eine funktionierende VLESS-Bereitstellung besteht aus drei Teilen: einem Server an einem beliebigen Ort, einem Client auf jedem Gerät und einer Verbindungszeichenfolge, die diese verbindet.
Die Serverseite ist unkompliziert. Jeder günstige VPS ist ausreichend: Hetzner, Vultr, OVH – jeder Anbieter mit öffentlicher IPv4-Adresse genügt. Installieren Sie Xray-core über die Release-Binärdateien des Projekts oder einen Paketmanager, generieren Sie eine UUID (`xray uuid`), ein X25519-Schlüsselpaar für REALITY (`xray x25519`), wählen Sie ein Ziel für die Identitätswechsel (eine echte HTTPS-Website, die TLS 1.3 und HTTP/2 unterstützt) und erstellen Sie eine JSON-Serverkonfiguration, die an Port 443 bindet. Die Einrichtung dauert nach einmaliger Durchführung maximal zehn Minuten. Web-Panels wie 3X-UI und Hiddify-Manager bieten dieselbe Konfiguration in einer Browseroberfläche für Betreiber, die JSON nicht bearbeiten möchten. Auch Managed Appliances sind verfügbar. Im AWS Marketplace wird ein Xray VLESS VPN-Server-Image für 0,063 $ pro Stunde auf einem t3.micro-Server mit einer fünftägigen kostenlosen Testphase angeboten.
Auf Clientseite ist das Ökosystem zwar fragmentiert, aber zuverlässig. v2rayN und Nekoray sind die führenden Windows-Clients. v2rayNG, NekoBox und Hiddify decken Android ab. Hiddify läuft zudem plattformübergreifend auf macOS und Linux. Auf iOS, wo Apples App-Store-Richtlinien die Nutzung erschweren, ist Streisand die kostenlose Option, während Shadowrocket und V2Box kostenpflichtig sind. Alle unterstützen VLESS; die meisten auch REALITY. Die Konfiguration wird üblicherweise über ein `vless://`-URI-Schema importiert – eine einzelne URL mit UUID, Adresse, Port, Transportprotokoll und REALITY-Parametern – oder als QR-Code vom serverseitigen Bedienfeld gescannt.
Leistung, Risiken und wann VLESS nicht das richtige Werkzeug ist
Leistung steht an erster Stelle. Community-Benchmarks zeigen, dass VLESS im Vergleich zu VMess über dasselbe Transportprotokoll einen um etwa 15 bis 25 Prozent höheren Durchsatz erzielt. Dies liegt hauptsächlich daran, dass der VLESS-Header deutlich kürzer ist und keine interne Verschlüsselung erfolgt. Mit XTLS Vision und der Linux-Splice-Optimierung erreicht eine optimal konfigurierte VLESS-Implementierung nahezu den nativen TCP-Durchsatz. Die Begrenzung liegt lediglich in der Bandbreite des VPS und der Roundtrip-Zeit zum Server. WireGuard ist in unzensierten Netzwerken, in denen der Handshake keine Rolle spielt, weiterhin 2–3 Prozent schneller.
Risiken sind real. Das VLESS-Protokoll ist neutral und Open Source, doch die rechtliche Lage bei der Umgehung staatlicher Zensur variiert stark je nach Rechtsordnung. Russlands Bundesgesetz zu Umgehungstools stellt die Verbreitung funktionierender Konfigurationen unter Strafe, nicht aber die private Nutzung; Chinas Regulierungspolitik ist strenger und willkürlicher; im Iran werden Betreiber großer Proxy-Pools strafrechtlich verfolgt. Unternehmensnetzwerke verbieten häufig jeglichen Proxy- und VPN-Verkehr. Nutzer in solchen Umgebungen sollten sich daher vor der Einrichtung jeglicher Verbindungen über die geltenden Regeln informieren. Kostenlose VPN-Apps mit vorinstallierten VLESS-Abonnements fallen in einigen Ländern unter eine separate Regulierungskategorie und können daher anderen Kontrollen unterliegen.
Ein letzter, weniger dramatischer Punkt: Wenn Sie sich nicht in einem zensierten Netzwerk befinden, ist VLESS übertrieben. Für den normalen Schutz Ihrer Privatsphäre gegenüber Ihrem Internetanbieter über eine sichere Verbindung ist WireGuard oder eine moderne OpenVPN-Konfiguration schneller, einfacher und wird bereits von allen kommerziellen VPN-Anbietern unterstützt. VLESS+REALITY ist ein Werkzeug für ein spezifisches Problem; der Einsatz bei anderen Problemen führt meist nur zu mehr Komplexität.
