Важное, насколько я понимаю, тут обсуждаются схемы и подниматься вопросы по схеме прямого подключение к Proxy, НЕ через CDNs. В заглавной статье вообще было утверждение, что схема "VLESS + TCP (RAW) + TLS + Vision" не работает или плохо работает т.к. РКН научился ее детектировать (здесь уже автору напихали в шапку, что это скорей всего не так, и схема работает, в том числе и у меня и многих коммерческих прокси барыг). Но ради спортивного интереса я купил IPv6 адреса на двух VPS серверах (в России и не в России) и настроил схему общения по двум каналам входящим (IPv6) и исходящему (IPv4) через "xhttp" c VLESS Encryption получил рабочую схему без предупреждений. На Российском промежуточном VPS, так повелось исторически, у меня установлена панель "3x-ui", в ней на данный момент невозможно настроит inbound c "xhttp" и в настройке клиента установить в поле flow "xtls-rprx-vision" - этого поля просто нет. Поэтому подключение между Российским VPS и клиентом вернул на обычную схему "VLESS + TCP (RAW) + TLS + Vision".
Прочитал по ссылке внимательно, насколько смог , позволю себе выделить следующие утверждения:
For scenarios not using CDNs, protocols likeREALITYthat bypass CA certificates should be mandated as a standard solution.
For scenarios using CDNs,VLESS Encryptionshould be adopted to prevent CDNs from snooping on proxied content and to block GFW MITM attacks from exposing plaintext.
Предлагаю обсудить следующий вопрос: При включенном VLESS Encryption появляется ли проблема "TLS-in-TLS" или включение flow “xtls-rprx-vision” убирает ее для "network": "xhttp" ? Если да, хотелось бы ссылку прочитать подтверждение от авторитета.
На данный момент остаюсь на схеме "VLESS + TCP (RAW) + TLS + Vision" на всем пути траффика, все работает нормально, схему с "xhttp" оставил как запасную, пока не вижу смысл куда-то рыпаться, особенно, пока не прояснил для себя лично вопрос есть "TLS-in-TLS" с "VLESS Encryption" или нет? И пока не решена проблема с flow в "3x-ui", если это вообще проблема и может проще просто снести "3x-ui" и использовать конфигурационные файлы и x-ray.
3xui не получится настроить с flow": “xtls-rprx-vision” для клиента, т.к. при включении транспорта “network”: “xhttp” поля с flow в inbounds убираются. И добавлять такой режим авторы не видят смысла в силу искажения имитации поведения браузера (TLS-in-TLS будет устранён только при использовании RAW (TCP)-транспорта с TLS 1.3), почитать можно подробно тут.
Тоже все работает. Есть только одна проблема - это шифрование TLS in TLS что возомжно легко дедектируется. Поэтому сомнительная схема при соединения напрямую клиент - VPS вне России.
Here is why TCP (RAW) paired with Flow (xtls-rprx-vision) is the ultimate standard for simulating browser behavior, and why transports like xHTTP are not ideal for this specific goal:
The Anatomy of a Normal Browser Connection To understand why TCP (RAW) is required, we must look at exactly what a Deep Packet Inspection (DPI) firewall sees when a real user opens Google Chrome and visits a secure website:
Transport Layer: The browser opens a raw TCP connection.
Encryption Layer: The browser immediately sends a TLS Client Hello packet to start the encryption handshake.
Application Layer: Only after the TLS handshake is complete does the browser start sending HTTP/2 or HTTP/3 requests inside the encrypted tunnel.
Why TCP (RAW) + Flow (Vision) is the Perfect Mimic The goal of the xtls-rprx-vision Flow is to make your VLESS traffic mathematically indistinguishable from the standard Chrome behavior described above. It achieves this through two strict requirements:
Zero Encapsulation: By using TCP (RAW), Xray does not wrap your traffic in any proxy-specific transport layers. The outermost layer is pure TCP, immediately followed by pure TLS. This exactly matches a browser.
Packet Size and Timing (Padding): Advanced firewalls (like the GFW) measure the exact byte size of the first 10-15 packets of a connection. xtls-rprx-vision actively analyzes your outbound traffic and injects dummy data (padding) so that your TLS handshake packets match the exact byte-length of a typical Chrome TLS 1.3 handshake.
Why Not xHTTP? (The Problem with Extra Transports) xHTTP is a brilliant, modern transport protocol in Xray (designed to replace WebSocket and gRPC). It provides excellent multiplexing and is highly resilient. However, you can only use xHTTP if you are putting your server behind a CDN (like Cloudflare). If you have a direct connection (like your setup with your own domain and IP), using xHTTP defeats the purpose of Vision for the following reasons:
It Breaks the Byte-Counting: Transports like xHTTP, WebSocket, or gRPC add their own specific headers, framing, and chunking to the data stream before it gets encrypted. Because these frames alter the size and sequence of the packets, the xtls-rprx-vision engine can no longer guarantee that the final encrypted packets will match a normal browser's signature.
The "TLS-in-TLS" Problem: When you use xHTTP, your VLESS traffic (which is often already encrypted HTTPS data from your local browser) is wrapped inside xHTTP frames, and then encrypted again by your server's TLS. This double-encryption creates a heavy, unnatural traffic pattern that DPI firewalls can detect using entropy analysis. Vision specifically eliminates this double-encryption, but it needs direct, raw TCP access to do so.
The Verdict Can you use xHTTP? Yes, but only if you are forced to hide your server behind a CDN where raw TCP is not supported.
If you have a direct IP and a domain, VLESS + TCP (RAW) + TLS + Vision is the absolute apex of anti-censorship technology because it strips away all proxy-like behavior and leaves nothing but a mathematically perfect clone of a normal web browser.
Важное, насколько я понимаю, тут обсуждаются схемы и подниматься вопросы по схеме прямого подключение к Proxy, НЕ через CDNs. В заглавной статье вообще было утверждение, что схема "VLESS + TCP (RAW) + TLS + Vision" не работает или плохо работает т.к. РКН научился ее детектировать (здесь уже автору напихали в шапку, что это скорей всего не так, и схема работает, в том числе и у меня и многих коммерческих прокси барыг). Но ради спортивного интереса я купил IPv6 адреса на двух VPS серверах (в России и не в России) и настроил схему общения по двум каналам входящим (IPv6) и исходящему (IPv4) через "xhttp" c VLESS Encryption получил рабочую схему без предупреждений. На Российском промежуточном VPS, так повелось исторически, у меня установлена панель "3x-ui", в ней на данный момент невозможно настроит inbound c "xhttp" и в настройке клиента установить в поле flow "xtls-rprx-vision" - этого поля просто нет. Поэтому подключение между Российским VPS и клиентом вернул на обычную схему "VLESS + TCP (RAW) + TLS + Vision".
Прочитал по ссылке внимательно, насколько смог , позволю себе выделить следующие утверждения:
For scenarios not using CDNs, protocols like REALITY that bypass CA certificates should be mandated as a standard solution.
For scenarios using CDNs, VLESS Encryption should be adopted to prevent CDNs from snooping on proxied content and to block GFW MITM attacks from exposing plaintext.
Предлагаю обсудить следующий вопрос:
При включенном
VLESS Encryptionпоявляется ли проблема "TLS-in-TLS" или включение flow “xtls-rprx-vision” убирает ее для "network": "xhttp" ? Если да, хотелось бы ссылку прочитать подтверждение от авторитета.На данный момент остаюсь на схеме "VLESS + TCP (RAW) + TLS + Vision" на всем пути траффика, все работает нормально, схему с "xhttp" оставил как запасную, пока не вижу смысл куда-то рыпаться, особенно, пока не прояснил для себя лично вопрос есть "TLS-in-TLS" с "VLESS Encryption" или нет? И пока не решена проблема с flow в "3x-ui", если это вообще проблема и может проще просто снести "3x-ui" и использовать конфигурационные файлы и x-ray.
3xui не получится настроить с flow": “xtls-rprx-vision” для клиента, т.к. при включении транспорта “network”: “xhttp” поля с flow в inbounds убираются. И добавлять такой режим авторы не видят смысла в силу искажения имитации поведения браузера (TLS-in-TLS будет устранён только при использовании RAW (TCP)-транспорта с TLS 1.3), почитать можно подробно тут.
Тоже все работает. Есть только одна проблема - это шифрование TLS in TLS что возомжно легко дедектируется. Поэтому сомнительная схема при соединения напрямую клиент - VPS вне России.
Here is why TCP (RAW) paired with Flow (xtls-rprx-vision) is the ultimate standard for simulating browser behavior, and why transports like xHTTP are not ideal for this specific goal:
The Anatomy of a Normal Browser Connection To understand why TCP (RAW) is required, we must look at exactly what a Deep Packet Inspection (DPI) firewall sees when a real user opens Google Chrome and visits a secure website:
Transport Layer: The browser opens a raw TCP connection.
Encryption Layer: The browser immediately sends a TLS Client Hello packet to start the encryption handshake.
Application Layer: Only after the TLS handshake is complete does the browser start sending HTTP/2 or HTTP/3 requests inside the encrypted tunnel.
Why TCP (RAW) + Flow (Vision) is the Perfect Mimic The goal of the xtls-rprx-vision Flow is to make your VLESS traffic mathematically indistinguishable from the standard Chrome behavior described above. It achieves this through two strict requirements:
Zero Encapsulation: By using TCP (RAW), Xray does not wrap your traffic in any proxy-specific transport layers. The outermost layer is pure TCP, immediately followed by pure TLS. This exactly matches a browser.
Packet Size and Timing (Padding): Advanced firewalls (like the GFW) measure the exact byte size of the first 10-15 packets of a connection. xtls-rprx-vision actively analyzes your outbound traffic and injects dummy data (padding) so that your TLS handshake packets match the exact byte-length of a typical Chrome TLS 1.3 handshake.
Why Not xHTTP? (The Problem with Extra Transports) xHTTP is a brilliant, modern transport protocol in Xray (designed to replace WebSocket and gRPC). It provides excellent multiplexing and is highly resilient. However, you can only use xHTTP if you are putting your server behind a CDN (like Cloudflare). If you have a direct connection (like your setup with your own domain and IP), using xHTTP defeats the purpose of Vision for the following reasons:
It Breaks the Byte-Counting: Transports like xHTTP, WebSocket, or gRPC add their own specific headers, framing, and chunking to the data stream before it gets encrypted. Because these frames alter the size and sequence of the packets, the xtls-rprx-vision engine can no longer guarantee that the final encrypted packets will match a normal browser's signature.
The "TLS-in-TLS" Problem: When you use xHTTP, your VLESS traffic (which is often already encrypted HTTPS data from your local browser) is wrapped inside xHTTP frames, and then encrypted again by your server's TLS. This double-encryption creates a heavy, unnatural traffic pattern that DPI firewalls can detect using entropy analysis. Vision specifically eliminates this double-encryption, but it needs direct, raw TCP access to do so.
The Verdict
Can you use xHTTP? Yes, but only if you are forced to hide your server behind a CDN where raw TCP is not supported.
If you have a direct IP and a domain, VLESS + TCP (RAW) + TLS + Vision is the absolute apex of anti-censorship technology because it strips away all proxy-like behavior and leaves nothing but a mathematically perfect clone of a normal web browser.