XRay core: движок за анти-цензурными VPN

XRay постоянно называют VPN-протоколом. Это не так. XRay — прокси-платформа. Думай о ней как о nginx, но вместо маршрутизации HTTP-запросов к backend-серверам она маршрутизирует целые сетевые соединения через зашифрованные туннели любым нужным протоколом.

VLESS — протокол. Reality — слой аутентификации. WireGuard — протокол. XRay — то, что запускает VLESS и Reality на стороне сервера. Понять это различие важно, если хочешь понять, почему экосистема устойчивости к цензуре работает так, как работает.

Откуда XRay пришёл

История начинается с V2Ray, проекта около 2015 от человека под псевдонимом «Victoria Raymond». V2Ray ввёл протокол VMess и модульную архитектуру, где можно менять транспорты (TCP, WebSocket, gRPC) независимо от прокси-протокола. Хорошая идея, быстро набравшая популярность, особенно в Китае, где нужны были инструменты, выживающие Great Firewall.

К 2020 оригинальный создатель V2Ray затих. Сообщество V2Fly держало форк v2fly-core. Разработчик RPRX контрибьютил XTLS — performance-оптимизацию, позволяющую прокси-трафику пропускать избыточные слои TLS-шифрования. Значимый технический вклад.

Потом стало мутно.

В ноябре 2020 код XTLS RPRX был удалён из v2ray-core из-за лицензионного спора. Детали сложные и отчасти политические, но результат чистый: RPRX форкнул v2fly-core (с коммита 9a03cc5) и создал xray-core. Чистый разрыв.

XRay двигался быстрее после раскола. RPRX выпустил XTLS Vision, потом Reality, потом XHTTP. Проект сейчас на 35,900+ звёзд GitHub против ~22,000 у V2Ray. Сообщество проголосовало коммитами. Большая часть активного развития анти-цензурного прокси-пространства теперь в xray-core или проектах поверх него.

Что XRay реально делает

XRay — Go-бинарник. Скармливаешь JSON-конфиг, определяющий inbound'ы (слушатели) и outbound'ы (назначения), и он проксирует трафик между ними. Это вся модель.

Сила в том, что можно комбинировать. XRay поддерживает несколько прокси-протоколов:

• VLESS — лёгкий без overhead шифрования (полагается на transport-layer)
• VMess — оригинальный протокол V2Ray с AES-128-GCM шифрованием (MD5 auth недавно убран)
• Trojan — имитирует HTTPS-трафик через password-based auth
• Shadowsocks-2022 — современный rewrite с AEAD-2022 шифрами

Каждый может работать на любом транспорте XRay:

• Raw TCP
• mKCP (UDP-based, как KCP но модифицирован)
• WebSocket
• HTTP/2 (h2)
• gRPC
• QUIC
• XHTTP (собственный мультиплексированный HTTP-транспорт XRay, добавлен в 2025)

Так можно запустить VLESS over WebSocket за CDN, Trojan over gRPC через Cloudflare, или VLESS over raw TCP с Reality-аутентификацией. Протокол и транспорт независимы. Микшируй под условия сети.

У XRay также routing-движок. Можно писать правила, отправляющие трафик определённых доменов через один outbound, блокирующие рекламу через другой, и направляющие всё остальное через прокси. Ближе к программируемому сетевому стеку, чем к простому туннелю.

XTLS и почему производительность важна

У стандартных прокси-сетапов проблема. Когда заходишь на https://example.com через прокси, TLS-шифрование происходит дважды: между браузером и example.com (внутренний TLS) и между клиентом и прокси-сервером (внешний TLS). Шифруешь уже зашифрованные данные. Это потраченный CPU и добавленная задержка.

XTLS Vision это чинит. Когда XRay детектит, что внутреннее соединение уже TLS 1.3, он перестаёт шифровать payload на прокси-слое после завершения handshake. Внутренний TLS даёт confidentiality. Внешний слой обрабатывает только начальное согласование.

XTLS splice идёт дальше на Linux. Использует kernel syscall splice() для прямого форвардинга TCP-данных между файловыми дескрипторами без копирования через userspace-память. Данные двигаются с сетевого сокета на туннельный сокет полностью в kernel space. Go-процесс XRay едва их касается.

Результат: пропускная способность прокси в нескольких процентах от прямого соединения. На сервере с 1 Гбит/с линком XTLS splice может его насытить. Традиционные дважды-шифрованные прокси упираются сильно ниже.

Поэтому VLESS с Reality так лучше работает, чем старые инструменты обхода. Протокол лёгкий, транспорт эффективный, а XTLS убирает избыточный налог шифрования.

Экосистема вокруг XRay

XRay — движок. Вокруг него выросла целая экосистема.

Server management панели вроде 3X-UI дают веб-интерфейс для конфига XRay-inbound'ов, управления юзер-аккаунтами и мониторинга bandwidth. Популярны для личных прокси-серверов, потому что убирают необходимость править JSON руками.

Десктопные клиенты вроде V2RayN (Windows) и V2RayA (Linux) оборачивают xray-core в GUI. Читают subscription-ссылки, управляют списками серверов, обрабатывают routing-правила. Большинство юзеров в цензурированных странах взаимодействует с XRay через один из этих клиентов, не raw-бинарник.

sing-box — интересный. Новая прокси-платформа, написанная с нуля разработчиком SagerNet. Поддерживает все протоколы XRay (VLESS, VMess, Trojan, Shadowsocks) плюс Hysteria2, TUIC и другие. Главное — компилируется в мобильную библиотеку через gomobile. Это и делает VLESS Reality возможным на телефонах. Запустить xray-core на iOS или Android разумно нельзя, а libbox sing-box можно встроить в нативное приложение.

Экосистема разделяется примерно по линиям: xray-core доминирует на серверах, V2RayN/V2RayA на десктопах, sing-box на мобильном. Все говорят на тех же протоколах.

Как Fexyn использует XRay

Запускаем xray-core на VPN-серверах. У каждого сервера VLESS Reality inbound на порту 443 (TCP с Reality-аутентификацией) и XHTTP-inbound на порту 8444 (для сред, где raw TCP к 443 фильтруется, но HTTP-based транспорты проходят).

На сервере наш Fexyn Agent управляет процессом xray-core, обрабатывает ротацию ключей и provisioning per-user UUID. Когда подключаешься с VLESS, агент генерирует креды, и клиент получает конфиг, указывающий на нужный сервер с нужными Reality-ключами.

Клиентская сторона интереснее. На Windows xray-core не используем вообще. Вместо этого создаём Wintun TUN-адаптер и запускаем tun2socks для маршрутизации всего системного трафика в SOCKS5-прокси, который предоставляет xray-core. Запускаем урезанный xray-core в SOCKS-прокси режиме, и tun2socks захватывает пакеты с TUN-интерфейса, реконструирует TCP/UDP-сессии и форвардит через этот SOCKS-прокси. ОС видит обычный сетевой адаптер. Весь трафик идёт через него. Конфиг прокси на уровне приложений не нужен.

На Android и iOS используем sing-box, скомпилированный как нативная библиотека. Обрабатывает тот же VLESS Reality, но запускается внутри VPN-фреймворка ОС (Android VpnService, iOS NEPacketTunnelProvider). sing-box был правильным выбором здесь, потому что xray-core не собирается чисто под мобильные платформы, а libbox sing-box спроектирована именно для этого сценария.

Результат одинаков на всех платформах: твой трафик выглядит как чьё-то браузенье microsoft.com (или того SNI, на который таргетит Reality). DPI-системы видят TLS 1.3 соединение к легитимному домену. Active probes против нашего сервера перенаправляются на настоящий сайт.

XRay в сравнении с другими инструментами

Анти-цензурное пространство имеет много проектов. Вот где XRay сидит.

Shadowsocks был оригиналом. Простой, быстрый, single-purpose шифрованный прокси. Rewrite 2022 (Shadowsocks-2022) починил старые криптослабости, но у Shadowsocks проблема детекта: GFW идентифицирует паттерны через статистический анализ длин пакетов и таймингов. Всё ещё работает в некоторых регионах. Менее надёжен, чем VLESS Reality в сильно цензурированных.

V2Ray (v2fly-core) — предок XRay. Всё ещё поддерживается, всё ещё работает. Но без XTLS Vision, Reality, XHTTP. Если нужны эти фичи, а в 2026 почти точно нужны, нужен xray-core.

Trojan-GFW был умным при запуске. Маскирует прокси-трафик как HTTPS, запуская реальный веб-сервер рядом. Reality пошёл дальше, убрав необходимость владеть TLS-сертификатом target-домена.

Hysteria 2 использует QUIC (UDP-based) с обфускацией. Отличная пропускная, но QUIC-протоколы получают больше внимания цензоров. Некоторые сети сейчас блокируют или троттлят QUIC целиком. TCP-инструменты как VLESS Reality сложнее блокировать одним ударом, потому что пришлось бы блокировать сам HTTPS.

NaiveProxy использует сетевой стек Chrome для генерации трафика, статистически идентичного реальному Chrome-браузеру. Очень сложно детектить, но клиентская настройка сложнее, и нет той же экосистемы панелей и клиентов.

Преимущество XRay не в том, что он делает что-то лучше каждой альтернативы. Преимущество — что это платформа. Запускает много протоколов, поддерживает много транспортов, имеет зрелый routing-движок и крупнейшее активное сообщество. Когда GFW разрабатывает новый метод детекта, xray-core получает контрмеру за недели. Это выгода 35,000+ звёзд и активного мейнтейнера, относящегося к этому как к гонке вооружений.

Куда движется

Развитие XRay не замедлилось. Свежие релизы убрали legacy-код: VMess MD5 auth ушла, поддержка MTProto убрана. Кодовая база становится стройнее.

Две предстоящие фичи выделяются. XDRIVE — транспорт, маскирующий прокси-трафик как операции с облачным хранилищем. XICMP использует ICMP-пакеты как transport-layer. Обе экспериментальные, но представляют тот же паттерн, определяющий эволюцию XRay: найти тип трафика, разрешённый цензорами, и построить транспорт вокруг.

Схема версий говорит о темпе. XRay использует формат vYY.M.DD. Версия v26.2.6 значит 6 февраля 2026. Релизы частые. Проект двигается быстро, потому что должен. Great Firewall не ждёт квартальные циклы релизов.

Если строишь что-то, что должно выжить в цензурированной сети, XRay — движок, который ты, скорее всего, хочешь крутить на серверной стороне. Не единственная опция. Но та, у которой больше всего momentum, шире всего поддержка протоколов и быстрее реакция на новые техники цензуры. Поэтому мы выбрали его для Fexyn.