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 решения.

Что узнаешь

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

Inbound → Routing → Outbound
Inbound принимает от клиента VLESS + Reality VMess + WebSocket Trojan + TCP/TLS Shadowsocks SOCKS, HTTP, Dokodemo Routing правила маршрутизации geoip:ru → direct (российские сайты мимо туннеля) geosite:openai → proxy (ChatGPT через VPN) port:53 → fakedns Outbound отправляет дальше freedom (direct) VLESS → upstream blackhole (drop) Wireguard DNS, loopback, ...
Любой Xray-конфиг = выбор inbound + правил маршрутизации + outbound. Очень модульно.

Главная сила 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
Проблема VMess

Уязвим к 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 handshake (client → server): 0000 00 version = 0 0001 [16 bytes: uuid] UUID клиента — единственный «пароль» 0011 00 addons length = 0 (для Vision: длина flow id) 0012 01 command = 01 (TCP) / 02 (UDP) / 03 (Mux) 0013 01 BB port = 443 (target) 0015 02 address type: 01=ipv4, 02=domain, 03=ipv6 0016 0B 65 78 61 6d 70 6c 65 2e 63 6f 6d domain length(11), "example.com" 0022 [payload starts here] далее — сам трафик

Видим: всего ~34 байта overhead, нет своего шифрования. Это позволяет «склеить» транспорт с TLS в одно — никакого TLS-in-TLS.

5. Trojan — «выглядим как HTTPS-сервер»

Trojan (2019, неизвестный автор) — другая философия: вместо «делаем шум» — «полностью маскируемся под обычный HTTPS-сервер». Если запрос имеет правильный «пароль» в первых 56 байтах — это Trojan-клиент. Если нет — отдать обычный сайт через fallback.

Trojan request (внутри TLS-канала): 0000 [56 bytes: hex(SHA-224(password))] пароль в hex-строке 0038 0D 0A CRLF 003A 01 [target_address] [port] SOCKS5-like target .... 0D 0A CRLF .... [payload] данные
Контрмера

Fallback на nginx

Если первые 56 байт ≠ ожидаемый хеш — Trojan-сервер проксирует TCP-стрим в локальный nginx, обслуживающий настоящий сайт. Active probe увидит «обычный wordpress» — не подозрительно.

Проблема Trojan

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 целиком — значит положить миллионы сайтов. Это редко делают (хотя в Иране иногда — да).

Под капотом

Как работает

  1. Ты регистрируешь домен vpn.example.com, направляешь его CNAME на Cloudflare
  2. Cloudflare становится для DPI «лицом» твоего домена — TLS-handshake клиент видит с CF
  3. В настройках CF включаешь «WebSockets» (бесплатно) и origin = IP твоего VPS
  4. CF проксирует WS-соединение на твой VPS, где работает Xray + VLESS+WS+TLS
  5. DPI видит: «клиент идёт в Cloudflare, какая-то WebSocket-сессия» — нормально, такое у всех современных сайтов (chat, push, realtime)
Минусы CDN-фронтинга

7. XTLS-Vision — как починили TLS-in-TLS

XTLS-Vision (RPRX, 2022) — главное достижение XTLS-команды до Reality. Идея: после внешнего TLS-handshake мы переключаемся в «raw mode» — никакого второго шифрования, просто проксируем пакеты как есть. Это:

  1. Убирает CPU-расходы на двойное шифрование (важно на телефонах)
  2. Убирает «всплеск handshake-пакетов» внутри TLS-канала (TLS-in-TLS detect не работает)
  3. Маскирует длины пакетов под обычный 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:

9. Mux.cool — мультиплексирование

Если клиент делает 100 параллельных соединений (открыл сайт с кучей ресурсов) — каждое — отдельный TCP-стрим к серверу. Это много handshake'ов, заметный паттерн, плюс race на ACK.

Mux.cool склеивает все клиентские соединения в один TCP-стрим к серверу с мультиплексированием на уровне Xray. Один туннель — много логических каналов внутри.

Эффект

Минус: на потерях один 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, главная техническая жемчужина курса.