Drei Arten, wie Russland Ihren Xray-Server bricht – und nur eine davon ist eine Sperre

Alle paar Wochen trifft dasselbe Ticket ein. Der VPS einer Kundin funktionierte aus Russland, dann eines Tages nicht mehr, und nun wirkt die Adresse aus Moskau tot, während sie von überall sonst einwandfrei antwortet. Der Schluss schreibt sich von selbst: Die DPI hat VLESS erkannt, der Server steht auf einer Liste, die IP ist verbrannt.

Manchmal trifft genau das zu. Häufiger ist es eines von zwei anderen Dingen, die sich vom Stuhl des Clients aus identisch anfühlen und völlig andere Lösungen brauchen.

Das ist wichtig, denn der übliche Rat – „stell den Transport auf gRPC um“ – ist auf eine Weise halb richtig, die schwer zu widerlegen ist. Er hilft tatsächlich, aus einem Grund, den man genau verstehen sollte. Nur hilft er nicht gegen den Ausfall, der Sie die Adresse wirklich kostet – und viele greifen danach, statt zu dem zu greifen, was helfen würde.

Was tatsächlich passiert, geordnet nach dem angerichteten Schaden:

1. Der Scan: Ihr Server antwortet auf eine Sonde, und die Antwort verrät ihn

Das ist der Mechanismus, der Sie wirklich die ganze IP kostet.

Im Mai 2026 ließ jemand einen VPN-Scanner russischer Bauart gegen den eigenen Server laufen und veröffentlichte den Bericht. Es ist das nützlichste Dokument zu diesem Thema, weil es die Begründung zeigt und nicht bloß das Urteil. 7

Der Scanner beschränkt sich nicht auf 443. Er überstreicht den gesamten Portbereich, 1 bis 65535, mit 500 Threads und wirft alles Mögliche auf jeden Port, der antwortet: ein HTTP GET, ein CONNECT, ein TLS ClientHello mit absichtlich ungültigem SNI und rohe Binärdaten. Dann vergleicht er die Antworten.

Ein echter Webserver reagiert auf verschiedenen Unsinn verschieden. Ein Proxy mit statischem Fallback nicht. Auf dem getesteten Server lieferte Port 2096 dieselben 41 Bytes, Byte für Byte, auf jede Sonde – beginnend mit der Statuszeile HTTP/0.0 307 Temporary Redirect. Kein echtes nginx, Apache oder Caddy gibt jemals die Version HTTP/0.0 aus. Diese eine Antwort kommt einem Geständnis nahe.

Der Bericht trägt weitere leise Hinweise zusammen:

• Kein Server:-Header. Jeder gängige Webserver setzt einen. Sein Fehlen sagt „eigener Handler“, nicht „Website“.
• Ein Zertifikat mit sechs Tagen Gesamtgültigkeit. Öffentliche CAs stellen für 30 bis 90 Tage aus. Alles unter etwa zwei Wochen sagt: selbst gebaut – also Testaufbau, also Proxy.

Der Scanner bewertete den Host mit 48 von 100 und gab das Urteil OBVIOUSLY-VPN zurück. Die Folge, in den Worten des Berichts: Die aufgelaufenen Auffälligkeiten überschreiten die TSPU-Schwelle, und „die IP wird der Reputationsliste hinzugefügt, und künftige Flüsse werden verworfen oder gedrosselt, bis sich die Signatur ändert“.

Das ist der Mechanismus, den Leute meinen, wenn sie sagen, die IP sei gesperrt worden. Es gibt ihn wirklich, er wirkt auf Adressebene, und ausgelöst wird er davon, was Ihr Server sagt, wenn man ihn anspricht – nicht davon, welches Protokoll Sie tunneln.

2. Der Burst: drei Handshakes binnen fünfzig Millisekunden

Der zweite Mechanismus ist verhaltensbasiert und hat mit Sondieren nichts zu tun.

Ein Thread im Xray-core-Projekt beschreibt, wie die TSPU das TLS ClientHello liest und es nach Subnetz und autonomem System des Servers, nach SNI und nach Browser-Fingerabdruck bewertet. Fingerabdrücke von Chrome, Safari und iOS aus einem verdächtigen Bereich werden festgehalten; Firefox, Android, OkHttp und Edge kommen durch. 3

Ausgelöst wird es durch Intensität. Drei oder mehr gleichzeitige TLS-Verbindungen zum selben Host binnen etwa 20 bis 50 Millisekunden frieren das Ganze für rund 120 Sekunden ein. Wechselt der Client daraufhin mitten im Einfrieren seinen Fingerabdruck, werden 600 Sekunden daraus.

Deshalb ist ein Browser, der eine Seite über den Tunnel öffnet, so viel schlimmer als ein einzelner Download. Moderne Browser fächern konstruktionsbedingt sechs Verbindungen auf einmal auf. Genau nach dieser Form sucht der Erkenner.

3. Der Zähler: Ihr fünfzehntes Kilobyte

Der dritte ist gröber und, in seiner eigenen Logik, elegant. Der Zensor beobachtet eine TLS-Verbindung zu einem ausländischen Server und friert sie ein, sobald die zurückgelieferten Daten etwa 15 bis 20 KB überschreiten – später genauer bestimmt auf rund 25 Pakete in einer der beiden Richtungen.

Der Thread, der das dokumentiert und am 27. Juni 2025 eröffnet wurde, sagt ausdrücklich, dass es sich nicht um eine Protokollerkennung handelt: „Es spielt keine Rolle, ob es ‚legitimer' HTTPS-Verkehr ist oder ob jemand ihn nachahmt.“ 2

Das ist die Meldung „läuft ein paar Sekunden und stirbt dann“. Ein Handshake und ein paar kleine Anfragen passen ins Budget. Eine Seite mit Bildern nicht.

Sie auseinanderhalten, mit einem Test

Die drei sehen gleich aus, weil der Zensor Verbindungen einfriert statt sie zurückzusetzen. Kein RST, kein ICMP – der Handshake kommt schlicht nie zustande, und der Client sitzt da, bis er in eine Zeitüberschreitung läuft. Von einer im Nichts endenden Route ist das nicht zu unterscheiden.

Holen Sie aus dem betroffenen Netz etwas Kleines und Schlichtes über HTTP von derselben Adresse.

• Klartext-HTTP funktioniert, TLS nicht – Mechanismus 2 oder 3. Mit der Adresse ist alles in Ordnung. In einer Meldung vom November 2025 über blockiertes REALITY bei einem russischen Provider prüfte der Melder genau das und stellte fest, dass die Website auf derselben IP weiterhin lud. 4
• Gar nichts antwortet – Mechanismus 1. Sie stehen auf der Reputationsliste, und nur eine neue Adresse hilft.

Die Unterscheidung ist die zwei Minuten wert, denn einen Server wegen Mechanismus 2 oder 3 zu ersetzen, verschafft Ihnen ungefähr fünfzehn Kilobyte Ruhe, bevor sich die neue Adresse genauso verhält. Manche lesen das so, als wäre die neue IP sofort verbrannt. Verbrannt wurde nichts. Das Budget war nur erneut aufgebraucht.

Wo gRPC tatsächlich hilft – und wo nicht

Betreiber berichten immer wieder, dass gRPC wochenlang durchhält, wo einfaches TCP binnen Tagen erkannt wurde. Das ist weder Folklore noch Glück. Es ist Mechanismus 2, und der Grund ist mechanisch.

gRPC läuft über HTTP/2, und die Xray-Dokumentation sagt deutlich, was das bringt: „gRPC (HTTP/2) hat eingebautes Multiplexing. Es wird nicht empfohlen, mux.cool zu aktivieren, wenn gRPC und HTTP/2 verwendet werden.“ 5

Multiplexing heißt, dass viele Ströme sich eine TCP-Verbindung teilen – und damit einen TLS-Handshake. Der Burst-Erkenner sucht nach drei oder mehr Handshakes zum selben Host binnen fünfzig Millisekunden. Ein Browser über einfaches TCP fächert sechs Verbindungen auf und erzeugt genau diese Form. Derselbe Browser über gRPC erzeugt einen Handshake mit sechs HTTP/2-Strömen darin. Es bleibt kein Burst mehr zu erkennen.

Wenn Sie also auf gRPC umgestellt haben und Ihr Problem verschwunden ist: Das ist der Grund, und Sie sollten sich davon nicht abbringen lassen.

Was es nicht tut, ist auf eine Sonde zu antworten. Dieselbe Seite warnt, dass „gRPC-Dienste dem Risiko aktiver Sondierung ausgesetzt sind“, und empfiehlt einen vorgeschalteten Reverse Proxy, der den Verkehr nach Pfadpräfix aufteilt. Nacktes gRPC auf Port 443 antwortet dem Scanner weiterhin – und Mechanismus 1 ist der, der die Adresse auf die Reputationsliste bringt. Dagegen richtet Multiplexing nichts aus.

Es lohnt auch zu wissen, wohin das läuft. Der gRPC-Transport gilt als veraltet: Die Dokumentation sagt inzwischen, „es wird empfohlen, zu XHTTP zu wechseln“. 5 Das ist ein Migrationshinweis und kein Grund, etwas Funktionierendes herauszureißen. XHTTP, im Dezember 2024 eingeführt, multiplext über XMUX auf dieselbe Weise und ergänzt, was gRPC fehlt: Header-Padding und eine Trennung von Hin- und Rückrichtung, sodass der Rückweg auf unabhängigen GET-Anfragen reitet – was zugleich die gRPC-Grenzen mancher CDNs umgeht. Gegenüber WebSocket vermeidet es das auffällige ALPN http/1.1. 6

Planen Sie den Wechsel. Überstürzen Sie ihn nicht.

Stapeln Sie sie; es sind keine Alternativen

Der Fehler hinter den meisten dieser Diskussionen ist, das Ganze als eine einzige Wahl zu behandeln – REALITY oder gRPC, dieser Transport oder jener. Die drei Mechanismen sind unabhängig, also sind es die Gegenmittel auch – und sie lassen sich kombinieren:

Ein Server mit REALITY hinter nginx über einen multiplexenden Transport antwortet auf alle drei. Ein Server mit nur einem davon antwortet auf einen.

Stellen Sie ein echtes nginx davor und richten Sie die Fallbacks darauf. Das ist die wertvollste einzelne Änderung und zugleich die erste Empfehlung des Berichts: Betreiben Sie ein echtes nginx mit einer ordentlichen Fehlerseiten-Zuordnung und lenken Sie Xrays Fallbacks dorthin, damit alles, was kein gültiger Handshake ist, echtes HTTP von echter Webserver-Software erhält. 7 Das beseitigt die Statuszeile HTTP/0.0, stellt den Server:-Header wieder her und sorgt dafür, dass die Antworten je nach Anfrage variieren, wie es bei einer Website der Fall ist. Stellen Sie eine echte Website darauf. Eine nginx-Standardseite ist besser als ein statisches 307, und eine echte Website ist besser als beides.

Nutzen Sie ein echtes Zertifikat. Let's Encrypt mit automatischer Erneuerung. Ein sechs Tage gültiges, selbst signiertes Zertifikat ist für sich genommen schon ein Hinweis – und es kostet nichts, ihn zu beseitigen.

Achten Sie auf das SNI. Sich bei Microsoft, Apple oder Google zu bedienen, zieht Aufmerksamkeit auf sich; stark frequentierte inländische Hosts gelten als deutlich stabilere Vorlage. Die Sperren sind selektiv statt pauschal, und eine frische Subdomain auf einer sauberen Adresse kommt oft durch. 8

Achten Sie auf den Fingerabdruck, aber nicht nur auf ihn. Es wird berichtet, dass ein Wechsel von uTLS-Chrome zu Firefox die Verbindung bei Anbietern wiederherstellt, bei denen Chrome festgehalten wird. 8 Die Bewertung wiegt aber auch Subnetz und AS – ein perfekter Fingerabdruck auf einem schlecht bewerteten Bereich bleibt eine schlechte Verbindung.

Nutzen Sie einen multiplexenden Transport und lassen Sie ihn multiplexen. gRPC oder XHTTP, mit ausgeschaltetem mux.cool – die Dokumentation sagt ausdrücklich, dass es oberhalb von HTTP/2 nicht empfohlen wird. Betreiben Sie gRPC hinter nginx, heißt das grpc_pass mit einem Pfadpräfix: Sie bekommen den Schutz gegen Sonden und den gegen Bursts aus einer einzigen Installation.

Lassen Sie sonst nichts auf der Maschine sprechen. Der Scanner überstreicht alle 65535 Ports. Jeder Dienst, der antwortet, ist eine weitere Gelegenheit, Auffälligkeitspunkte zu sammeln. Legen Sie SSH von Port 22 auf einen hohen Port und beschränken Sie ihn per Firewall auf bekannte Adressen.

Halten Sie einen zweiten Standort. Nicht eine Ersatzadresse im selben Bereich zum Durchwechseln, sondern wirklich woanders. Wenn der Ausfall regional ist, hilft ein anderer Weg – nicht eine andere Nummer auf demselben Weg.

Und rechnen Sie damit, dass es sich weiterbewegt

Roskomnadsor blockierte VLESS Ende 2025 mittels TSPU, und die meisten Anbieter antworteten binnen Tagen mit neuen Konfigurationen. 1 In diesem Rhythmus hat sich das eingependelt, und das Budget dahinter wächst: Die TSPU-Kapazität soll sich bis 2030 auf das Zweieinhalbfache erhöhen, auf 954 Terabit pro Sekunde, für rund 186 Millionen US-Dollar – nach der Rechnung des Ministeriums genug, um den gesamten Runet-Verkehr mit Reserve zu analysieren.

Nichts von den obigen Ratschlägen ist dauerhaft. Zwei Dinge lassen sich verallgemeinern.

Sie werden nicht dafür erwischt, was Sie tunneln. Sie werden dafür erwischt, wie eine Maschine auszusehen, die zum Tunneln existiert – daran, was sie antwortet, wie sie Verbindungen aufbaut und wie viel sie sendet. Alles, was den Server wie einen gewöhnlichen Webserver aussehen lässt, der nebenbei anderen Verkehr trägt, verschafft Ihnen Zeit.

Und keine einzelne Einstellung ist die Antwort. Die Erkennung ist geschichtet, also muss es die Verteidigung auch sein. Wenn Ihnen jemand sagt, ein Transport löse das, fragen Sie nach, welchen der drei er löst.

Quellen

1. Russia's internet censorship in 2026: VPN crackdowns, mobile shutdowns, Telegram blocks and the state messenger Max, Zona Media, 7. April 2026
2. [Russia] Censor has a new method of blocking, net4people/bbs, eröffnet am 27. Juni 2025
3. Russia blocks 2026, XTLS/Xray-core, 2026
4. TCP + Reality gets blocked, XTLS/Xray-core, 23. November 2025
5. gRPC transport, Project-X-Dokumentation
6. XHTTP, XTLS/Xray-core, Dezember 2024
7. How Bye Bye VPN Works in Russia, MHSanaei/3x-ui, 6. Mai 2026
8. Bypassing Russian GFW, XTLS/Xray-core