Shadowsocks und Xray: Wenn VPN blockiert wird

Ich beschäftige mich beruflich oft mit VPNs. Nicht als theoretisches Thema, sondern ganz praktisch: Standorte verbinden, Kunden ins Firmennetz bringen, Server erreichbar halten, Firewalls sauber konfigurieren, Zertifikate erneuern, IPsec-Tunnel stabil bekommen, SSL-VPN-Clients debuggen und irgendwann herausfinden, warum ein Standort plötzlich nicht mehr durchkommt.

Normalerweise ist das langweilige, solide Netzwerkarbeit. Genau so soll es sein.

Aber es gibt Fälle, in denen ein technisch korrektes VPN trotzdem nicht mehr reicht. Besonders bei Kunden aus Ländern mit stark reguliertem Internet, etwa China oder Russland, sieht man immer wieder Situationen, in denen klassische VPN-Protokolle blockiert, gestört oder gezielt erkannt werden. Da ich in Dubai mit sehr internationaler Kundschaft zu tun habe, ist das kein abstraktes Thema. Man arbeitet mit Menschen und Unternehmen aus vielen Regionen zusammen, und die operative Frage ist dann nicht, welche politische Grosswetterlage gerade dahintersteht. Die Frage ist: Wie bleibt ein legitimer Zugriff auf die eigene Infrastruktur möglich, wenn die Verbindung auf dem Weg dorthin gefiltert wird?

Genau in diesem Bereich tauchen Begriffe wie Shadowsocks, ShadowsocksR, V2Ray, Xray-core, VLESS, Trojan, REALITY oder XHTTP auf. Das wirkt am Anfang wie eine unübersichtliche Mischung aus Projekten, Forks und Abkürzungen. Und ehrlich gesagt: Ein Teil davon ist auch genau das.

Warum Shadowsocks überhaupt entstanden ist

Shadowsocks kommt nicht aus der klassischen Enterprise-VPN-Welt. Es entstand nicht, weil jemand eine schönere Site-to-Site-Lösung bauen wollte oder weil IPsec zu kompliziert war. Der Ursprung war viel direkter: Ein Entwickler mit dem Pseudonym clowwindy wollte 2012 einen eigenen, schlanken Weg bauen, um aus einem stark gefilterten Netz heraus auf das offene Internet zuzugreifen.

Das erklärt viel vom Design. Shadowsocks sollte leicht, schnell und praktisch sein. Kein schwerer VPN-Client, kein grosses Gateway-Produkt, keine ganze Remote-Access-Suite mit Identitätsmanagement und Compliance-Reporting. Sondern ein lokaler SOCKS5-Proxy, der Traffic verschlüsselt an einen Server ausserhalb der Blockade schickt.

Der Bedarf war also nicht “mehr Security-Features für Unternehmen”, sondern “ich brauche einen funktionierenden Ausgang aus einem Netz, das bestimmte Protokolle und Ziele filtert”. Genau deshalb ist Shadowsocks bis heute so interessant und gleichzeitig so missverständlich. Es ist sehr gut als schlanker Transportbaustein. Es ist aber nicht automatisch ein vollständiges Unternehmens-VPN.

2015 wurde die Geschichte politischer: clowwindy schrieb auf GitHub, dass die Polizei bei ihm gewesen sei und er die Arbeit daran einstellen müsse. Danach ging die Entwicklung durch Forks und andere Implementierungen weiter. Das passt zur ganzen Historie solcher Tools: Sie entstehen oft aus einem sehr konkreten technischen Schmerz, werden dann aber Teil eines viel grösseren Wettrüstens zwischen Nutzern, Entwicklern und Filterinfrastrukturen.

Warum ein VPN überhaupt auffällt

Viele denken bei VPN zuerst an Verschlüsselung. Das ist richtig, aber es ist nur ein Teil der Geschichte.

Ein Zensor, Provider oder eine grosse nationale Firewall muss den Inhalt einer verschlüsselten Verbindung nicht unbedingt lesen können, um sie zu stören. Oft reicht es, die Verpackung zu erkennen. Ein IPsec-Tunnel, ein SSL-VPN, WireGuard oder OpenVPN haben typische Merkmale: Ports, Paketgrössen, Handshake-Muster, Zertifikatsverhalten, Timing, UDP-Verhalten, Wiederholungen, Fehlermeldungen oder schlicht bekannte Server-IP-Adressen.

Eine Analogie: Stell dir nicht den Briefinhalt vor, sondern den Umschlag. Der Brief ist verschlüsselt, aber der Umschlag hat eine bestimmte Grösse, eine bestimmte Farbe, einen bestimmten Stempel und kommt immer vom gleichen Absender. Wenn jemand nur Umschläge sortiert, muss er den Text nicht lesen. Er kann trotzdem sagen: Diese Art Umschlag kenne ich, der geht in die Sonderkontrolle.

Bei Netzwerktraffic ist es ähnlich. Deep Packet Inspection und Traffic Classification schauen nicht nur auf Ports. Sie analysieren Muster. Bei TLS-Verbindungen können etwa Client-Hello-Fingerprints, SNI, Zertifikatsketten oder ALPN-Informationen auffallen. Bei vollständig verschlüsselten Protokollen kann wiederum gerade die scheinbare Zufälligkeit zum Signal werden. Forschung zur Great Firewall hat gezeigt, dass nicht nur bekannte Protokollsignaturen relevant sind, sondern auch Eigenschaften wie Paketlängen, Entropie und druckbare ASCII-Zeichen in frühen Paketen.

Das ist der unangenehme Punkt: “Alles sieht zufällig aus” ist nicht automatisch unauffällig. Manchmal ist genau das verdächtig.

Was die Forschung dazu zeigt

Aus meiner Erfahrung ist der entscheidende Punkt nicht, dass Zensursysteme “VPN erkennen”. Das wusste man grob schon. Spannend ist, wie unspektakulär viele dieser Erkennungen technisch anfangen.

Ein guter Einstieg ist eine Messarbeit von GFW Report, die 2020 auf der ACM Internet Measurement Conference vorgestellt wurde. GFW Report ist kein Produkt und kein Hersteller, sondern ein Forschungs- und Messprojekt rund um die Great Firewall. Die Abkürzung IMC steht hier einfach für die Konferenz, auf der die Arbeit veröffentlicht wurde.

Der wichtige Punkt aus dieser Arbeit: Es ging nicht um einen magischen Entschlüsselungsangriff. Die Great Firewall kombinierte passive Beobachtung und aktives Nachfragen. Zuerst wurden Verbindungen anhand von Merkmalen wie Länge und Entropie des ersten Datenpakets verdächtig. Danach kamen aktive Probes: Der Zensor baut selbst Verbindungen zum mutmasslichen Server auf, spielt alte oder veränderte Pakete nach und beobachtet, ob die Gegenseite wie ein Shadowsocks-Server reagiert.

Das ist für Admins wichtig, weil es zwei unterschiedliche Verteidigungsebenen zeigt:

• Der Traffic darf passiv nicht zu auffällig aussehen.
• Der Server darf bei aktiven Tests nicht wie ein Proxy antworten.

2023 wurde es noch unangenehmer. Eine weitere GFW-Studie zeigte, dass vollständig verschlüsselter Traffic anhand einfacher Heuristiken blockiert werden kann. Vereinfacht gesagt: Wenn das erste TCP-Payload weder nach TLS, noch nach HTTP, noch nach druckbarem Text aussieht, sondern wie ein zufälliger Datenblock, ist das selbst schon ein Signal. Deshalb ist “maximal zufällig” nicht immer das beste Tarnziel.

Und 2024 kam mit der Forschung zu eingekapselten TLS-Handshakes ein weiterer Punkt dazu: Selbst wenn der äussere Tunnel verschlüsselt und gut getarnt ist, kann ein innerer TLS-Handshake als Muster in einem verschachtelten Protokollstack auffallen. Das ist besonders relevant für alle Setups, bei denen normaler HTTPS-Traffic durch einen weiteren verschlüsselten Proxy-Tunnel läuft. Zufälliges Padding hilft dort nur begrenzt; Stream-Multiplexing wirkt in der Forschung vielversprechender, löst das Problem aber nicht automatisch, wenn am Ende nur ein einzelner Anwendungsstream sichtbar ist.

Dazu kommt neuere Forschung zu Timing und Cross-Layer-RTTs. Der unangenehme Teil daran ist strukturell: Ein Proxy verschiebt Transport- und Anwendungssitzungen gegeneinander. Diese zeitlichen Unterschiede können messbar sein, unabhängig davon, ob der Client nahe am Proxy sitzt oder weit weg. Das kann man nicht einfach mit einem anderen Header wegkonfigurieren.

Die Konsequenz ist ernüchternd, aber gesund: Nicht das Protokolllabel entscheidet, sondern das gesamte Verhalten des Setups.

Shadowsocks ist kein klassisches VPN

Shadowsocks wird oft in denselben Topf wie VPN geworfen. Für den Alltag ist das verständlich, technisch aber ungenau.

Shadowsocks ist ein verschlüsselter Proxy, lose angelehnt an SOCKS5. Lokal läuft ein Client, der Anwendungen einen Proxy anbietet. Dieser Client verschlüsselt den Traffic und schickt ihn an einen entfernten Shadowsocks-Server. Der Server entschlüsselt die Anfrage, baut die Verbindung zum eigentlichen Ziel auf und leitet die Antwort verschlüsselt zurück.

Das ist schlanker als ein vollwertiges VPN. Shadowsocks zieht nicht automatisch das ganze Betriebssystem in einen Tunnel. Es ist eher ein Werkzeug, um ausgewählten Traffic über einen anderen Weg zu schicken. Je nach Client, Betriebssystem und Zusatzkomponenten kann man daraus natürlich ein fast VPN-artiges Verhalten bauen, aber der Grundgedanke bleibt Proxy statt Site-to-Site-VPN.

Für Administratoren ist das wichtig, weil es die Erwartung korrigiert:

• Shadowsocks ersetzt kein sauberes Site-to-Site-IPsec.
• Shadowsocks ist kein magischer Schutz vor jeder Erkennung.
• Shadowsocks ist aber sehr nützlich, wenn ein einfacher, schneller, verschlüsselter Proxy aus einem restriktiven Netz heraus gebraucht wird.

Technisch hat sich Shadowsocks über die Jahre weiterentwickelt. Alte Stream-Cipher-Setups sollte man heute nicht mehr als Massstab nehmen. Moderne Shadowsocks-Deployments gehören in die AEAD-Welt, und Shadowsocks 2022 geht noch einen Schritt weiter: Es nutzt eine vorab geteilte symmetrische Schlüsselbasis, moderne Verfahren wie BLAKE3-basierte Ableitung, Replay-Schutz und andere Korrekturen gegenüber älteren Editionen. Wichtig ist aber auch die Einschränkung: Shadowsocks 2022 bietet laut Spezifikation keine Forward Secrecy. Wenn ein Schlüssel kompromittiert wird, ist saubere Rotation also nicht optional.

Mit shadowsocks-rust gibt es eine moderne Implementierung, die sich auch per Docker betreiben lässt. Auf der Serverseite läuft zum Beispiel ssserver, auf der Clientseite sslocal. Dazwischen braucht es nicht einfach irgendein Passwort, sondern sauber generierte Secrets, einen erreichbaren Port, aktuelle Cipher und eine klare Entscheidung, ob TCP, UDP oder beides benötigt wird.

Warum Xray-core eine andere Kategorie ist

Xray-core ist nicht einfach “Shadowsocks, aber neuer”. Es ist eher ein Framework für Proxy- und Tunnel-Szenarien.

Xray kann verschiedene Inbound- und Outbound-Protokolle kombinieren: VLESS, VMess, Trojan, Shadowsocks, WireGuard, Hysteria, SOCKS und HTTP. Darüber legt man Transports wie RAW, WebSocket, gRPC, XHTTP oder Hysteria und kombiniert sie mit TLS, REALITY oder XTLS Vision. VMess taucht in vielen alten Setups noch auf, ist für neue Deployments aber eher Legacy; in aktuellen Xray-Setups steht meistens VLESS im Zentrum.

Shadowsocks ist der schnelle Schraubenzieher. Xray ist der Werkzeugkoffer. Man kann damit einfache Setups bauen, aber auch Konstruktionen, bei denen ein lokaler SOCKS- oder TUN-Client den Traffic annimmt, über VLESS mit REALITY zu einem Server schickt und dort über ein normales freedom-Outbound ins Internet weiterleitet.

Dabei muss man VLESS richtig einordnen: VLESS ist nicht die Tarnung selbst, sondern ein leichtes Proxy-Protokoll mit UUID-basierter Authentifizierung. Die Vertraulichkeit und die eigentliche Tarnwirkung kommen erst durch die darunterliegende Transport- und Security-Schicht, also etwa TLS, REALITY oder XTLS Vision.

REALITY ist der spannendere Baustein, weil es nicht einfach “nochmal TLS” macht. Der Server leiht sich nach aussen den TLS-Handshake einer echten, fremden HTTPS-Seite aus. Für einen Beobachter sieht das nicht nach einem selbstgebastelten Proxy-Zertifikat aus, sondern nach einem echten Zertifikat einer echten Website. Erst ein autorisierter Client erkennt über das konfigurierte Schlüsselmaterial, dass er mit dem eigenen Xray-Server spricht.

Das adressiert vor allem die serverseitige TLS-Fingerprint- und Active-Probing-Ebene. uTLS hilft zusätzlich auf der Clientseite, Browser-Client-Hellos nachzuahmen. Trotzdem bleibt Xray kein Tarnumhang: Timing, Paketgrössen, ALPN, Serververhalten und verschachtelte TLS-Muster können weiter Signale liefern. XTLS Vision und XHTTP sind deshalb interessante Bausteine, aber keine fertige Garantie. Ein bisschen Padding hilft wenig, wenn das Grundmuster des verschachtelten Traffics sichtbar bleibt.

Dazu kommt ein praktischer Punkt: UDP-basierte Ansätze wie Hysteria oder QUIC können sehr performant sein, werden in restriktiven Netzen aber oft gedrosselt, blockiert oder schlechter behandelt als ausgehendes TCP/443. Genau deshalb braucht Xray im Betrieb mehr Disziplin als Shadowsocks: Versionen pinnen, Änderungen testen, Release Notes lesen und nicht blind jede neue Empfehlung aus einem Forum übernehmen.

Die Verwirrung um Forks und Namen

Wer anfängt zu recherchieren, landet schnell in alten Blogposts, GitHub-Forks und halb gepflegten Clients. Das liegt an der Geschichte dieser Werkzeuge.

Shadowsocks selbst ist ein Protokoll und ein Ökosystem mit mehreren Implementierungen. shadowsocks-rust ist heute eine naheliegende Wahl, wenn man einen modernen Server betreiben will. Ältere Implementierungen wie shadowsocks-libev sind weiterhin bekannt, werden aber je nach Projektstatus eher als Legacy oder bugfix-orientiert betrachtet.

ShadowsocksR war ein Fork mit zusätzlichen Obfuscation- und Protokollideen. In vielen alten Anleitungen taucht SSR noch auf. Ich wäre damit heute vorsichtig. Nicht weil jede alte Installation automatisch schlecht ist, sondern weil man bei solchen Projekten sehr genau prüfen muss, ob Client, Server, Krypto, Updates und Community noch vertrauenswürdig sind.

Xray-core wiederum stammt aus dem V2Ray-Umfeld, hat sich aber eigenständig weiterentwickelt. Deshalb ist es gefährlich, alte V2Ray-Tutorials blind auf Xray zu übertragen. Manche Konzepte ähneln sich, aber Konfigurationen, Features und Empfehlungen haben sich verändert.

V2Fly, also das heutige Community-Projekt rund um V2Ray, ist weiterhin relevant. Es ist eher der konservativere Baukasten. Xray-core ist aggressiver in neuen Features wie REALITY, XTLS Vision oder XHTTP. Daneben gibt es sing-box als moderne Universalplattform, die viele dieser Protokolle ebenfalls zusammenführt. Für diesen Artikel bleibt Xray im Fokus, aber im Lab würde ich sing-box mindestens mit anschauen, weil viele Clients und mobile Setups inzwischen genau dort landen.

Mein pragmatischer Rat wäre deshalb:

• Für neue einfache Setups: Shadowsocks mit aktueller Implementierung prüfen.
• Für schwierigere Netze: Xray-core mit sauberem, aktuellem Design prüfen.
• Für alte SSR- oder V2Ray-Anleitungen: erst Projektstatus und Sicherheitslage prüfen, dann entscheiden.
• Für produktive Kundenszenarien: kein Setup aus einem Copy-Paste-Blog übernehmen, ohne es selbst zu verstehen.

Was man auf beiden Seiten braucht

Ein minimales Setup besteht immer aus zwei Seiten.

Auf der entfernten Seite braucht man einen Server ausserhalb des restriktiven Netzes. Das kann ein kleiner VPS sein, ein eigener Server in einem Rechenzentrum oder eine kontrollierte Infrastruktur in einer Region, die vom Kundenstandort aus erreichbar ist. Dieser Server muss gehärtet, gepatcht, überwacht und sauber dokumentiert sein. Wer hier einfach irgendeine günstige Instanz hochzieht und nie wieder reinschaut, baut sich langfristig ein Risiko.

Auf der Clientseite braucht man ein passendes Programm. Bei Shadowsocks ist das häufig ein lokaler SOCKS-Client oder eine App, die System-Proxy-Regeln setzen kann. Bei Xray kann es ein Xray-basierter Client sein, ein TUN-Modus, ein Router-Setup oder eine App, die Profile importiert.

Dazwischen braucht es:

• einen klar definierten Zweck
• eine saubere Authentifizierung
• aktuelle Softwarestände
• kontrollierte DNS-Auflösung
• Logging ohne unnötige Kundendaten
• Monitoring der Erreichbarkeit
• einen Plan für Rotation von Servern, Ports und Secrets
• eine rechtliche und vertragliche Prüfung, ob der Betrieb zulässig ist

Der letzte Punkt ist nicht Dekoration. In manchen Ländern kann schon die Nutzung solcher Werkzeuge rechtlich problematisch sein. In einem Firmenkontext muss ausserdem klar sein, ob man damit eigene Systeme erreichbar macht, Kundennetze betreibt oder Mitarbeitenden allgemeinen Internetzugang verschafft. Das sind unterschiedliche Risiken.

DNS ist dabei oft der unterschätzte Teil. Wenn der Browser oder das Betriebssystem die Ziel-Domain weiterhin über den lokalen Provider auflöst, ist der Tunnel nur halb so hilfreich. Der Inhalt läuft dann vielleicht durch den Proxy, aber die DNS-Anfrage erzählt trotzdem, wohin der Benutzer wollte. Bei SOCKS-, HTTP-Proxy- und TUN-Setups muss man deshalb separat prüfen, ob DNS wirklich durch den gewünschten Pfad läuft, ob IPv6 sauber behandelt wird und was bei Tunnelabbruch passiert.

Logging ist ähnlich heikel. Für Troubleshooting will man sehen, ob ein Tunnel lebt. Für Datenschutz und Kundenschutz will man möglichst wenig speichern. Ein gutes Setup sammelt deshalb eher technische Zustände, Latenzen, Fehlerraten und Volumenindikatoren als vollständige Verbindungslisten mit Ziel-Domains. Debug-Logs, TLS-Keylogs oder unmaskierte Access-Logs gehören nicht dauerhaft auf produktive Systeme.

Auch Monitoring muss anders gedacht werden als bei einem normalen VPN-Gateway. Es reicht nicht, dass der Container läuft. Wichtig ist, ob ein echter Testpfad durch den Tunnel funktioniert, ob DNS korrekt geroutet wird, ob einzelne Zielregionen plötzlich blockiert sind und ob ein Knoten aus dem betroffenen Land anders aussieht als von meinem Büro aus.

Wie ich es operativ einordnen würde

Für mich ist Shadowsocks oder Xray kein Ersatz für Firewall-Architektur, Zero Trust, MFA oder saubere Segmentierung. Es ist ein Transport-Werkzeug für Spezialfälle.

Ein sinnvoller Firmenansatz könnte so aussehen:

1. Zuerst prüfen, ob normales SSL-VPN, IPsec oder WireGuard stabil funktioniert.
2. Wenn es blockiert wird, sauber messen: DNS? Port? Protokoll? Server-IP? TLS-Fingerprint? UDP-Drosselung?
3. Dann einen alternativen Transport testen, zum Beispiel Shadowsocks oder Xray-core.
4. Den Tunnel nur für benötigte Ziele nutzen, nicht blind das ganze Kundennetz öffnen.
5. Serverseitig restriktiv filtern, welche internen Dienste erreichbar sind.
6. Monitoring bauen, damit man nicht erst vom Kunden erfährt, dass der Weg wieder geblockt ist.
7. Einen Rückfallplan haben: zweiter Exit, anderer Provider, andere Region, anderes Protokoll.
8. Secrets und Clientprofile pro Standort oder Benutzer trennen, damit ein Leak nicht alles kompromittiert.
9. Logs und Metriken so bauen, dass Betrieb möglich bleibt, aber keine unnötige Spurensammlung entsteht.

Gerade bei Standorten ist es verführerisch, “Hauptsache es geht wieder” als Erfolg zu betrachten. Das verstehe ich. Wenn ein Kunde nicht mehr auf seine Systeme kommt, will man zuerst wieder Verbindung haben.

Aber danach muss man aufräumen. Sonst wird aus einem temporären Workaround ein unsichtbarer Produktionspfad, den niemand dokumentiert hat.

Warum Blockaden oft nachziehen

Man sollte bei diesen Tools nie vergessen: Die Gegenseite passt ihre Erkennung laufend an.

Wenn viele Menschen denselben Docker-Compose-Snippet, denselben Port, denselben TLS-Fingerprint, dieselbe Domain-Strategie und denselben VPS-Provider verwenden, wird das Muster irgendwann sichtbar. Dann wird nicht unbedingt “Xray” oder “Shadowsocks” im abstrakten Sinn blockiert, sondern ein konkretes Muster: bestimmte Handshakes, bestimmte Paketgrössen, bekannte IP-Ranges, typische Clients, schlecht konfigurierte Fallbacks oder auffällige Fehlerantworten.

Deshalb ist Tarnung nicht nur ein Feature im Tool. Tarnung ist Betrieb: gleiche Tools, andere Domains, andere Provider, andere Clientprofile und andere Traffic-Muster können in der Praxis sehr unterschiedlich aussehen.

Das ist auch der Grund, warum ich bei manchen Projekt- oder Community-Aussagen vorsichtig wäre. Wenn ein Tool behauptet, es sei nicht erkennbar, ist das zunächst eine Projektbehauptung. Wenn ein Paper zeigt, dass ein bestimmtes Merkmal in einem realen Netz erkannt wurde, hat das eine andere Qualität. Für die Praxis braucht man beides: die Innovationsgeschwindigkeit der Projekte und die Nüchternheit der Forschung.

Meine Einschätzung

Wenn ich das Thema für mich sortiere, komme ich auf eine einfache Einordnung.

Shadowsocks ist sinnvoll, wenn man einen schlanken, schnellen, relativ einfachen verschlüsselten Proxy braucht. Es ist gut für erste Tests, temporäre Zugriffe und Umgebungen, in denen keine extrem aggressive Erkennung aktiv ist.

Xray-core ist sinnvoll, wenn das Netz schwieriger ist, wenn mehrere Transportvarianten gebraucht werden oder wenn man bewusst mit VLESS, REALITY, WebSocket, gRPC oder XHTTP arbeiten will. Dafür muss man aber mehr verstehen. Xray verzeiht weniger, weil seine Flexibilität auch mehr Fehlkonfiguration ermöglicht.

Für Kundenumgebungen würde ich beides nie als “VPN-Ersatz” verkaufen. Ich würde es als alternativen Transportpfad für legitime Zugriffe beschreiben. Das klingt weniger spektakulär, ist aber ehrlicher.

Der wichtigste Unterschied ist am Ende nicht Shadowsocks gegen Xray. Der wichtigste Unterschied ist: Verstehe ich, welches Problem ich löse?

Wenn das Problem ein normales Remote-Access-Szenario ist, nehme ich normale VPN-Technik. Wenn das Problem staatliche oder providerseitige Protokollerkennung ist, muss ich über Erkennbarkeit, Fingerprints und Betriebsstrategie reden. Und wenn ich das nicht sauber erklären kann, sollte ich es nicht produktiv für Kunden betreiben.

Fazit

Shadowsocks und Xray-core sind Werkzeuge aus einer Welt, in der Netzwerkverbindungen nicht einfach nur “funktionieren” oder “nicht funktionieren”. Manchmal werden sie klassifiziert, gedrosselt, aktiv getestet oder blockiert. Wer international Kunden betreut, kommt früher oder später mit solchen Realitäten in Kontakt.

Ich finde das Thema gerade deshalb spannend, weil es Netzwerktechnik sehr konkret macht. Es geht nicht nur um Verschlüsselung. Es geht um Muster, Fingerprints, Routing, DNS, Betrieb, Recht, Verantwortung und darum, dass ein funktionierender Tunnel nicht automatisch ein gutes Design ist.

Für mich ist der nächste Schritt klar: Ich will Shadowsocks und Xray-core nicht nur oberflächlich kennen, sondern in einem kleinen Lab nachvollziehen. Nicht, um blind Zensur zu umgehen, sondern um besser zu verstehen, warum klassische VPNs manchmal auffallen und welche Alternativen technisch seriös betrieben werden können.

Bis zum nächsten Mal,
Euer Joe

FAQ