Der moderne VLESS-Stack im Jahr 2026

Auch 2026 ist VLESS ein schlankes, zustandsloses Proxy-Protokoll, doch „VLESS hat keine Verschlüsselung“ ist keine vollständige Beschreibung mehr. Xray-core bietet inzwischen optional VLESS Encryption. Je nach Bedrohungsmodell lässt sich VLESS außerdem mit TLS, REALITY, XTLS Vision, XHTTP und XUDP kombinieren. Diese Schichten lösen unterschiedliche Probleme und sollten nicht zu einem einzigen Protokoll zusammengeworfen werden.

Quellenhinweis: Dieser Leitfaden stützt sich auf Primärquellen von Project X, Xray-core, sing-box und AnyTLS. Pull Requests und Diskussionen auf GitHub dokumentieren Design und Implementierung der Maintainer; sie sind keine unabhängigen Sicherheitsaudits. Verweise auf SingLink sind Architekturvergleiche und keine Aussage, dass SingLinkVPN diese Projekte implementiert.

1. Der moderne VLESS-Stack im Überblick

• VLESS: eine schlanke Schicht für Identität, Befehl und Ziel.
• VLESS Encryption: eine optionale native Schutzschicht für die Nutzdaten im aktuellen Xray-core.
• TLS 1.3 / REALITY: äußere Transportsicherheit, Authentifizierung und Erscheinungsbild im Netz.
• XTLS Vision: Flusskontrolle und Optimierung des Datenpfads, keine eigene Verschlüsselung.
• RAW / XHTTP / gRPC / WebSocket: Transporte, die die Proxy-Daten tragen.
• XUDP: eine Option zur Kodierung von UDP-Paketen im Xray-Ökosystem.
• XMUX und andere MUX-Systeme: Verfahren, um zugrunde liegende Verbindungen gemeinsam zu nutzen.
• Padding / FinalMask / Browser Dialer: Werkzeuge für Länge, Timing, äußeres Transportverhalten oder Browser-Netzwerkverbindungen.

Eine Verbindung lässt sich daher so modellieren: Anwendungsverkehr → VLESS-Identität und Ziel → Protokoll- oder äußere Sicherheit → Vision-Flusskontrolle → ein Transport wie RAW oder XHTTP → TCP oder UDP. Nicht jedes Modul wird in jedem Design gebraucht oder ist damit kompatibel.

2. Was das VLESS-Grundprotokoll leistet

Die Dokumentation von Project X definiert VLESS als schlankes, zustandsloses Transportprotokoll, das nicht von der Systemzeit abhängt und zur Authentifizierung eine UUID oder eine zugeordnete ID nutzt. Die öffentliche Kodierungsimplementierung von Xray-core zeigt Version, Nutzer-ID, Addons, Befehl, Zielport, Adresse und die folgenden Daten.

Praktisch beantwortet die Grundschicht: Wer ist der Client, welche Verbindung wird angefordert und wohin soll sie gehen? Intelligentes Routing, Knotenauslastung, Tarifberechtigungen und automatisches Neuverbinden gehören normalerweise zu höheren Produkt- und Steuerungsebenen.

Klassische Konfigurationen nutzen meist `encryption: "none"`. Die aktuellen Vorgaben von Project X verlangen eine äußere Transportsicherheit, es sei denn, Gegenstelle und Verbindung sind vertrauenswürdige private Infrastruktur oder VLESS Encryption ist aktiviert.

3. Was VLESS Encryption ändert

VLESS Encryption ist eine optionale native Schutzschicht, die 2025 in Xray-core aufgenommen wurde. Der zusammengeführte PR #5067 und die aktuelle Konfigurationsdokumentation beschreiben den Handshake `mlkem768x25519plus`, die Erscheinungsformen `native`, `xorpub` und `random`, das Sitzungsverhalten `1rtt` und `0rtt` sowie variables Padding.

Veröffentlichte Designziele

• Session-Schlüssel über eine Kombination aus ML-KEM-768 und X25519 ableiten;
• VLESS-Nutzdaten schützen, ohne äußeres TLS zu benötigen;
• Tickets für spätere 0-RTT-Wiederaufnahme und kurzlebige Zustände nutzen, um das Replay-Risiko zu verringern;
• mit variablem Padding und optionalen XOR-Modi feste Längen oder das Erscheinungsbild öffentlicher Schlüssel verändern.

Das sind Aussagen der Maintainer zu Design und Implementierung. Wir haben kein unabhängiges kryptografisches Audit gefunden, das alle Eigenschaften abdeckt; dieser Leitfaden bezeichnet das Design deshalb nicht als „replay-sicher“ oder „absolut quantensicher“.

Was es nicht automatisch ersetzt

VLESS Encryption schützt die Nutzdaten des Protokolls. Es erzeugt nicht automatisch eine gewöhnliche HTTPS-Zertifikatskette, einen Website-Handshake, HTTP/2- oder HTTP/3-Verhalten oder CDN-Kompatibilität. Es ist daher nicht gleichwertig mit TLS oder REALITY.

4. TLS 1.3 und REALITY

TLS bietet standardisierte Zertifikatsprüfung, Schlüsselaustausch, Integrität und Transportverschlüsselung. Es lässt sich mit RAW, XHTTP, gRPC oder WebSocket kombinieren; ausgehandelte Version, ALPN und Zertifikatsprüfung hängen weiterhin von Konfiguration und Unterstützung der Gegenstelle ab.

Die REALITY-Dokumentation von Project X beschreibt eine abgewandelte Sicherheitsschicht im TLS-Stil mit den Einstellungen target, serverNames, X25519-Schlüsseln und shortId sowie optionalen ML-DSA-65-Prüfdaten. REALITY lässt sich mit RAW, XHTTP und gRPC kombinieren.

REALITY sollte nicht auf „TLS ohne Zertifikat“ reduziert werden. Sein Verhalten verbindet die Autorisierung des Clients mit dem Erscheinungsbild eines externen Handshakes. Die Ergebnisse hängen weiterhin von Ziel, Client-Fingerprint, Transport und Qualität der Bereitstellung ab; Unsichtbarkeit gegenüber jedem Klassifikator kann es nicht garantieren.

5. XTLS Vision ist kein Verschlüsselungsprotokoll

Die VLESS/Vision-Dokumentation stuft Vision als Flusskontrolle ein. Unter unterstützten Bedingungen kann es inneren TLS-Verkehr erkennen und zusätzliche Verschlüsselung oder Kopiervorgänge verringern. Auf kompatiblen Linux- und TCP-Pfaden kann der Kern `splice` versuchen, sodass der Kernel Daten direkt überträgt.

Die genaue Aufteilung lautet: TLS, REALITY oder VLESS Encryption liefern die Sicherheit; Vision optimiert, wie geschützte Daten durch die Proxy-Schicht laufen. Nicht jede Plattform, jeder Transport und jede Verkehrsart kann splice nutzen.

6. Die drei XHTTP-Modi

Die Designdiskussion der Maintainer zu XHTTP beschreibt ein HTTP-Transportsystem, das in Umgebungen mit HTTP/1.1, HTTP/2 und HTTP/3 arbeiten kann:

• packet-up: mehrere Upstream-POST-Anfragen mit einer fortlaufenden Downstream-Antwort; ausgelegt auf breite Kompatibilität mit Zwischenstellen.
• stream-up: ein streamender Upstream-POST und ein separates streamendes Downstream-GET.
• stream-one: eine einzige bidirektionale Streaming-Anfrage; Leistung und Kompatibilität hängen von den Zwischenstellen ab.

XHTTP kann außerdem Header-Padding, getrennte Upload- und Download-Pfade sowie XMUX nutzen. Ob es über ein bestimmtes CDN funktioniert, hängt von Modus, HTTP-Version, Verhalten des Reverse Proxys und Konfiguration des Anbieters ab.

7. XMUX, allgemeines Multiplexing und Head-of-Line-Blocking

XMUX verwaltet bei XHTTP Parallelität, Anzahl der zugrunde liegenden Verbindungen, Wiederverwendung, Lebensdauer und Keepalive. Ziel ist nicht, für immer genau eine Verbindung zu halten, sondern Handshake-Kosten, Parallelität und langlebige Verbindungsmuster auszubalancieren.

Die Multiplex-Dokumentation von sing-box nennt außerdem smux, yamux und h2mux. Multiplexing kann Handshakes einsparen, doch Verlust oder Blockierung auf einer zugrunde liegenden TCP-Verbindung kann mehrere Streams betreffen. HTTP/3 vermeidet streamübergreifendes Head-of-Line-Blocking auf TCP-Ebene, während ein einzelner QUIC-Stream weiterhin auf die Verlustbehebung warten kann.

8. XUDP ist eine Option zur UDP-Kodierung

Die VLESS-Dokumentation von sing-box führt `xudp` als Option zur Paketkodierung auf, neben `packetaddr` und dem Deaktivieren zusätzlicher Kodierung. Das stützt nur die begrenzte Schlussfolgerung, dass XUDP in diesem Ökosystem UDP transportiert; es ist keine vollständige, versionierte Paketspezifikation.

Detailliertes Verhalten bei Sitzungen, Adressen, Grenzen und Migration sollte anhand der genauen Kernversion und des Codes überprüft werden. Dieser Leitfaden vermeidet bewusst, abgeleitete Details zur Rahmenbildung als allgemeinen Standard darzustellen.

9. Padding, FinalMask, ECH und Browser Dialer

• Padding: verändert Längen- oder Timing-Merkmale; es ist keine Verschlüsselung.
• FinalMask: seine Konfigurationsdokumentation ordnet es einer äußeren Stufe der Transportverarbeitung mit Einstellungen für TCP, UDP und QUIC zu.
• ECH: die TLS-Dokumentation von sing-box enthält die Konfiguration von Encrypted ClientHello zum Schutz eines Teils des ClientHello; ECH ersetzt keine Tunnelverschlüsselung.
• Browser Dialer: laut Dokumentation von Project X baut ein echter Browser die TLS- und HTTP-Verbindungen auf; das ergibt authentischeres Browserverhalten, kostet aber Einschränkungen bei Bereitstellung und Leistung.

10. Was Fallback kann und was nicht

Die Fallback-Dokumentation von Project X zeigt, wie nicht passende SNI, Pfade oder Protokollverkehr an Nginx, Caddy oder eine normale Website weitergeleitet werden können, sodass ein Einstiegspunkt Proxy- und gewöhnliche Dienste beherbergen kann.

Fallback kann verhindern, dass jede fehlgeschlagene Authentifizierung mit demselben offensichtlichen Fehler beantwortet wird. Es macht aber nicht immun gegen aktives Sondieren; die Erkennbarkeit hängt weiterhin von TLS, Transport, Antworten, Timing und Serverkonfiguration ab.

11. AnyTLS ist ein Vergleich, keine VLESS-Komponente

Das AnyTLS-Protokolldokument beschreibt TCP → TLS → Authentifizierung per `SHA-256(password)` → eine Session → mehrere Streams. Frames enthalten Command, Stream ID, Data Length und Data, mit den Befehlen SYN, PSH, FIN, Settings, Padding, Heartbeat und dem SYNACK der Version 2.

Sein Session-Modell, mehrere Streams, dynamisches Padding und Verbindungsprüfungen eignen sich gut zum Vergleich. AnyTLS bleibt ein eigenständiges Protokoll; VLESS übernimmt diese Funktionen nicht automatisch.

12. Gängige Kombinationen und ihre Grenzen

• VLESS + REALITY + Vision + RAW: ausgerichtet auf direkte Leistung und ein äußeres Erscheinungsbild im TLS-Stil; keine Abhängigkeit von einem CDN.
• VLESS + TLS/REALITY + XHTTP: ausgerichtet auf Transport über HTTP, Reverse Proxys und bedingte CDN-Kompatibilität.
• VLESS Encryption + Vision: schützt die Nutzdaten des Protokolls für Relay- oder nicht standardisierte Szenarien äußerer Sicherheit, ohne gewöhnliches HTTPS-Erscheinungsbild.
• VLESS + TLS + XHTTP + Browser Dialer: nutzt den Netzwerkstack eines echten Browsers bei höherem Betriebsaufwand.
• AnyTLS + TLS: ein eigenständiges Design mit Session/Stream und Padding, kein VLESS-Stack.

Keine Konfiguration ist gleichzeitig immer die beste für Leistung, Kompatibilität, Wartbarkeit, Erscheinungsbild und Sicherheit. Die Auswahl sollte mit einem Bedrohungsmodell, dem Netzwerkpfad, CDN- oder Proxy-Einschränkungen, den Client-Plattformen und den Anforderungen an die Beobachtbarkeit beginnen.

13. Was das für die Forschung von SingLink bedeutet

Öffentliche Unterlagen zu VLESS und AnyTLS können die Forschung zu Identität, Schlüsselaustausch, Sessions, Streams, UDP, Padding, Multiplexing, Wiederherstellung und Versionsaushandlung bereichern. Dieser Artikel belegt nicht, dass SingLink 2.0 auf VLESS, REALITY, XHTTP oder AnyTLS basiert.

SingLinkVPN sollte weiterhin veröffentlichtes Verhalten, Forschungsrichtungen und nicht offengelegte Implementierung voneinander trennen. Den derzeit veröffentlichten Umfang finden Sie im Open-Source-Plan von SingLinkVPN.

14. Häufige Fragen (FAQ)

Verschlüsselt VLESS den Verkehr selbst?

Das klassische `encryption: "none"` schützt die Nutzdaten des Protokolls nicht und erfordert vertrauenswürdige private Infrastruktur oder äußere Sicherheit. Der aktuelle Xray-core kann VLESS Encryption aktivieren; die Antwort hängt also von Implementierung und Konfiguration ab.

Kann VLESS Encryption TLS oder REALITY ersetzen?

Nicht gleichwertig. VLESS Encryption schützt die VLESS-Nutzdaten, liefert aber nicht automatisch ein Standard-HTTPS-Zertifikat, einen Handshake oder das Erscheinungsbild einer Website.

Verschlüsselt XTLS Vision?

Nein. XTLS Vision bietet vor allem Flusskontrolle und Optimierung des Datenpfads.

Wie wählt man zwischen den drei XHTTP-Modi?

packet-up setzt auf Kompatibilität, stream-up trennt die Streaming-Richtungen, und stream-one nutzt einen einzigen bidirektionalen Stream. Jeder Modus muss mit dem tatsächlichen Pfad über Zwischenstellen getestet werden.

Worin unterscheidet sich XUDP von einem allgemeinen UDP-Proxy?

XUDP ist eine Option zur UDP-Kodierung im Xray-Ökosystem. Das genaue Verhalten hängt von Kern und Version ab und sollte nicht allein aus dem Namen abgeleitet werden.

Basiert SingLink 2.0 auf VLESS oder AnyTLS?

Es gibt nicht genug öffentliche Belege, um diesen Zusammenhang festzustellen. Dieser Artikel ist ein technischer Vergleich, keine Offenlegung der Implementierung.

15. Fazit und Stand der Quellen

Modernes VLESS ist ein zusammensetzbarer Stack: VLESS trägt Identität und Ziel, VLESS Encryption ergänzt optionalen Schutz auf Protokollebene, TLS oder REALITY liefern die äußere Sicherheit, Vision optimiert den Datenfluss, XHTTP und XUDP transportieren den Verkehr, und Multiplexing oder Padding verändern das Verbindungsverhalten zusätzlich.

Ursprünglich veröffentlicht am 20. Mai 2026. Technische Quellen geprüft am 28. Juli 2026. Diese Projekte verändern sich laufend; prüfen Sie vor dem Einsatz Dokumentation, Änderungsprotokoll und Kompatibilität der genauen Version.