Xray-core: VMess, VLESS, Trojan, XTLS-Vision
Xray-core — это не «один протокол», а швейцарский нож proxy/VPN индустрии 2024-2026. Внутри: набор протоколов (VMess, VLESS, Trojan) × набор транспортов (TCP, WS, gRPC, HTTPUpgrade, XHTTP) × набор «маскировок» (TLS, XTLS-Vision, Reality). Любая комбинация. На этой матрице построены почти все современные anti-detect решения.
- История: V2Ray → Xray fork (2020) — почему разделились
- Протоколы Xray: VMess (старый), VLESS (новый), Trojan — формат пакета, отличия
- Транспорты: TCP, WebSocket, gRPC, HTTPUpgrade, XHTTP — когда что выбирать
- XTLS-Vision — как splice убирает TLS-in-TLS overhead
- Mux.cool — мультиплексирование соединений
- uTLS — подделка JA3 fingerprint под Chrome/Firefox
- Практический пример: VLESS + WS + TLS + CDN-фронтинг (Cloudflare)
1. История: V2Ray → Xray
V2Ray (Project V) — китайский open-source proxy-фреймворк, начат в 2015. Идея: модульная архитектура «inbound → routing → outbound», поддержка многих протоколов, Linux/Win/Mac/Android.
В 2020 один из core-разработчиков (RPRX) форкнул проект под именем Xray-core. Причина — споры о направлении развития и философии. Xray стал агрессивнее включать новые анти-DPI техники: XTLS, Reality, mux.cool. Сегодня Xray — основа для 80% современных панелей (3x-ui, Marzban, Hiddify). V2Ray ещё жив, но проигрывает в фичах.
В этом курсе под «Xray» понимаем именно xray-core от XTLS-команды
(github.com/XTLS/Xray-core).
2. Архитектура Xray
Главная сила Xray — матрица: каждый протокол можно завернуть в любой транспорт. «VMess поверх WebSocket поверх TLS» — нормально. «VLESS поверх gRPC поверх TLS» — нормально. «Trojan поверх XHTTP» — тоже. Эта гибкость и убила конкурентов.
3. VMess — старый, но всё ещё живой
VMess (V2Ray Message) — оригинальный протокол V2Ray, 2015 год. Идея — собственный формат шифрования с встроенной аутентификацией и обфускацией. Без HTTPS-обёртки выглядит как случайный шум.
| Свойство | Значение |
|---|---|
| Аутентификация | UUID + alterID + timestamp (HMAC) |
| Шифрование | AES-128-GCM, ChaCha20-Poly1305, auto |
| Длина handshake | ~32-128 байт (зависит от cipher) |
| Анти-DPI | Бесформенный шум — но детектится статистикой |
| Используется в 2026 | Постепенно вытесняется VLESS |
Уязвим к replay-атаке и detected via active probing
У старого VMess (до AEAD-обновления 2021) была дыра — replay допускался в окне 2 минут. GFW писал старые пакеты от детектированных IP и пере-отправлял на подозрительные — если «нормальный» ответ, значит, VMess-сервер. После 2022 это пофиксили (AEAD-only режим), но stigma осталась.
Сегодня VMess используют разве что в комбо с WebSocket + TLS + Cloudflare CDN — тогда внешне это обычный HTTPS к Cloudflare, никакой DPI «прямого» VMess не видит.
4. VLESS — «облегчённый» наследник
VLESS (Very Light, 2020) — переосмысленный VMess. Главные отличия:
- Нет собственного шифрования. VLESS полагается на внешний слой (TLS, Reality). Меньше overhead, проще код.
- UUID для аутентификации, без timestamp (replay невозможен по-другому)
- Минималистичный handshake — ~22 байта + payload
- Поддержка XTLS (Vision, Reality) — нативно
Видим: всего ~34 байта overhead, нет своего шифрования. Это позволяет «склеить» транспорт с TLS в одно — никакого TLS-in-TLS.
5. Trojan — «выглядим как HTTPS-сервер»
Trojan (2019, неизвестный автор) — другая философия: вместо «делаем шум» — «полностью маскируемся под обычный HTTPS-сервер». Если запрос имеет правильный «пароль» в первых 56 байтах — это Trojan-клиент. Если нет — отдать обычный сайт через fallback.
Fallback на nginx
Если первые 56 байт ≠ ожидаемый хеш — Trojan-сервер проксирует TCP-стрим в локальный nginx, обслуживающий настоящий сайт. Active probe увидит «обычный wordpress» — не подозрительно.
TLS-in-TLS detection
Trojan требует настоящего домена и сертификата. Внутри TLS-канала идёт второй TLS (когда клиент идёт на HTTPS-сайт через прокси). С 2022 GFW научился это видеть. Trojan без Vision/Reality сегодня небезопасен в Китае.
6. Транспорты: TCP, WS, gRPC, HTTPUpgrade, XHTTP
| Транспорт | Как выглядит снаружи | Где использовать | Минусы |
|---|---|---|---|
| TCP + TLS | Обычный HTTPS | Прямое подключение к VPS | Нужен домен и сертификат, простой паттерн |
| WebSocket + TLS | WS-соединение (Upgrade: websocket) | За CDN (Cloudflare) | +5% overhead, но проходит через CDN |
| gRPC | HTTP/2 binary stream | Низкий latency, multiplexing | Сложнее настройка, нужен HTTP/2 |
| HTTPUpgrade | Похоже на WS, но без WS-frame | Альтернатива WS, меньше overhead | Не везде поддерживается клиентами (2024+) |
| XHTTP | Полноценные HTTP-запросы (POST/GET) | За CDN с агрессивным DPI, мобильник, плохие сети | Новый, ещё не везде поддержан (2025+) |
CDN-фронтинг через Cloudflare
Самая популярная техника 2023-2025: VLESS+WS+TLS, домен проксируется через Cloudflare. DPI видит TLS-handshake с серверами Cloudflare (104.x, 172.67.x). Заблокировать Cloudflare целиком — значит положить миллионы сайтов. Это редко делают (хотя в Иране иногда — да).
Как работает
- Ты регистрируешь домен
vpn.example.com, направляешь его CNAME на Cloudflare - Cloudflare становится для DPI «лицом» твоего домена — TLS-handshake клиент видит с CF
- В настройках CF включаешь «WebSockets» (бесплатно) и origin = IP твоего VPS
- CF проксирует WS-соединение на твой VPS, где работает Xray + VLESS+WS+TLS
- DPI видит: «клиент идёт в Cloudflare, какая-то WebSocket-сессия» — нормально, такое у всех современных сайтов (chat, push, realtime)
- Cloudflare видит твой трафик (decrypts TLS на их стороне) — не подходит для high-privacy
- На бесплатном плане лимит ~100 ГБ/мес, потом throttling
- Cloudflare банит «массовый VPN traffic» — нужно не превышать разумного объёма
- Latency +30-80 мс (через ближайший edge-узел CF)
7. XTLS-Vision — как починили TLS-in-TLS
XTLS-Vision (RPRX, 2022) — главное достижение XTLS-команды до Reality. Идея: после внешнего TLS-handshake мы переключаемся в «raw mode» — никакого второго шифрования, просто проксируем пакеты как есть. Это:
- Убирает CPU-расходы на двойное шифрование (важно на телефонах)
- Убирает «всплеск handshake-пакетов» внутри TLS-канала (TLS-in-TLS detect не работает)
- Маскирует длины пакетов под обычный HTTPS-стрим
splice() и трюк с padding
Когда клиент после handshake шлёт настоящий HTTPS-запрос (внутри туннеля идёт второй TLS), Vision добавляет паддинг и переключает пакеты в режим, неотличимый от обычного TLS application data. Сервер делает то же самое на ответ. На каждом этапе паттерн «длины + тайминги» совпадает с настоящим HTTPS.
Vision — это flow у клиента. В конфиге VLESS:
{
"protocol": "vless",
"settings": {
"vnext": [{
"address": "vpn.example.com",
"port": 443,
"users": [{
"id": "12345678-1234-1234-1234-123456789012",
"encryption": "none",
"flow": "xtls-rprx-vision"
}]
}]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"serverName": "vpn.example.com",
"fingerprint": "chrome"
}
}
}
8. uTLS — притворяемся Chrome'ом
uTLS (refraction-networking) — Go-библиотека, которая позволяет проводить TLS-handshake с побайтово точным fingerprint реального браузера. Это убивает JA3-детект.
Обычный Go использует свою crypto/tls — fingerprint специфический. С uTLS можно сказать:
«представляйся как Chrome 120 Windows» — и все поля ClientHello (cipher_suites, extensions, key_share,
supported_versions) будут идентичны настоящему Chrome. JA3 совпадёт с миллионами реальных пользователей.
В Xray-конфиге это указывается через fingerprint:
chrome— самый рекомендуемый (как у 65% интернет-пользователей)firefoxsafariios— Safari iOSandroid— Chrome Androidedgerandom,randomized
9. Mux.cool — мультиплексирование
Если клиент делает 100 параллельных соединений (открыл сайт с кучей ресурсов) — каждое — отдельный TCP-стрим к серверу. Это много handshake'ов, заметный паттерн, плюс race на ACK.
Mux.cool склеивает все клиентские соединения в один TCP-стрим к серверу с мультиплексированием на уровне Xray. Один туннель — много логических каналов внутри.
- Меньше handshake — меньше детектируемых событий
- Меньше CPU на сервере (один TLS вместо 100)
- Лучше работает через CDN (CDN-лимиты на connections per IP)
Минус: на потерях один pause влияет на все логические каналы (head-of-line blocking). Mux лучше включать на стабильных каналах.
10. Практический пример: VLESS + WS + TLS + Cloudflare
Самая популярная связка 2024-2025 для обхода в РФ. Полный конфиг сервера:
{
"log": { "loglevel": "warning" },
"inbounds": [{
"port": 8443,
"listen": "127.0.0.1", // только localhost, наружу — nginx
"protocol": "vless",
"settings": {
"clients": [{
"id": "UUID-уникальный-для-пользователя",
"level": 0,
"email": "user1@vpn"
}],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"wsSettings": {
"path": "/secure-tunnel-path-random-string"
}
}
}],
"outbounds": [{
"protocol": "freedom",
"settings": {}
}]
}
Перед Xray стоит nginx с настоящим сайтом + проксированием WS на 127.0.0.1:8443:
server {
listen 443 ssl http2;
server_name vpn.example.com;
ssl_certificate /etc/letsencrypt/live/vpn.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vpn.example.com/privkey.pem;
# настоящий сайт — для fallback (если кто-то зайдёт без правильного path)
root /var/www/html;
index index.html;
location /secure-tunnel-path-random-string {
proxy_pass http://127.0.0.1:8443;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_read_timeout 86400s;
}
}
В Cloudflare включаешь Proxy (оранжевая туча) и WebSockets. Trafic идёт:
Клиент → CF edge (TLS-handshake виден провайдеру как «обычный CF») → CF backbone →
твой VPS → nginx → Xray → freedom-outbound → реальный интернет
11. Что дальше
Xray-стек хорош, но всё ещё требует домена + сертификата. Reality — следующий шаг: не нужно ничего. Никакого домена, никакого сертификата, никакого CDN. Клиент маскируется под визит к настоящему чужому сайту (apple.com, gov.cn, microsoft.com — что угодно), и DPI принципиально не может отличить.
Это — урок 07, главная техническая жемчужина курса.