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

Главная сила Xray — матрица: каждый протокол можно завернуть в любой транспорт. «VMess поверх WebSocket поверх TLS» — нормально. «VLESS поверх gRPC поверх TLS» — нормально. «Trojan поверх XHTTP» — тоже. Эта гибкость и убила конкурентов.

3. VMess — старый, но всё ещё живой

VMess (V2Ray Message) — оригинальный протокол V2Ray, 2015 год. Идея — собственный формат шифрования с встроенной аутентификацией и обфускацией. Без HTTPS-обёртки выглядит как случайный шум.

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.

6. Транспорты: TCP, WS, gRPC, HTTPUpgrade, XHTTP

CDN-фронтинг через Cloudflare

Самая популярная техника 2023-2025: VLESS+WS+TLS, домен проксируется через Cloudflare. DPI видит TLS-handshake с серверами Cloudflare (104.x, 172.67.x). Заблокировать Cloudflare целиком — значит положить миллионы сайтов. Это редко делают (хотя в Иране иногда — да).

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-стрим

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% интернет-пользователей)
• firefox
• safari
• ios — Safari iOS
• android — Chrome Android
• edge
• random, randomized

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. Мини-лаба: попробуй прямо сейчас

Полный сервер требует VPS и домена, но саму матрицу и uTLS можно потрогать локально — установи xray (одним бинарником с GitHub) или загляни в готовый конфиг:

# 1. Сгенерируй UUID — «логин» пользователя в VLESS/VMess
xray uuid
# или без xray: cat /proc/sys/kernel/random/uuid

# 2. Посмотри, из каких слоёв собран конфиг (протокол × транспорт × security)
# в inbounds.protocol → "vless"; streamSettings.network → "ws"/"grpc";
#   streamSettings.security → "tls"/"reality" — это и есть матрица из урока

# 3. Проверь, что WebSocket-транспорт действительно выглядит как обычный HTTP-upgrade
curl -sI -H "Connection: Upgrade" -H "Upgrade: websocket" https://ваш-домен/путь
# снаружи это неотличимо от любого веб-сокета (чат, биржа, игра)

# 4. Сравни свой JA3 в браузере (uTLS имитирует именно его):
# https://tls.browserleaks.com/tls — вот «маска Chrome», которую надевает клиент

12. Задачи самопроверки — реши, потом раскрой ответ

13. Словарик урока

14. Что дальше

Xray-стек хорош, но всё ещё требует домена + сертификата. Reality — следующий шаг: не нужно ничего. Никакого домена, никакого сертификата, никакого CDN. Клиент маскируется под визит к настоящему чужому сайту (apple.com, gov.cn, microsoft.com — что угодно), и DPI принципиально не может отличить.

Это — урок 07, главная техническая жемчужина курса.