Xray-core: что это такое, какие протоколы и как настраивается ядро

Что такое Xray-core простыми словами

Xray-core — это программа-ядро, которое ставится на сервер (и в клиент) и делает одно: принимает ваш трафик, оборачивает его в один из протоколов и отдаёт наружу так, чтобы провайдер или ТСПУ не распознали в этом прокси. Это именно движок, а не приложение с кнопкой — собственного интерфейса почти нет, всё поведение задаётся конфигом.

По запросу *«что такое Xray»* сразу снимем путаницу с однофамильцами:

• Это не Lada Xray — кроссовер АвтоВАЗа.
• Это не Xray-мод для Minecraft (рентген-текстуры).
• Это не медицинский рентген.

В контексте VPN и обхода блокировок Xray — это форк проекта V2Ray, который развивает команда XTLS (репозиторий XTLS/Xray-core на GitHub, ~28k звёзд). Написан на Go, кроссплатформенный (Linux/Windows/macOS/Android), под MIT-лицензией, релизится одним статическим бинарником xray. Когда в чатах пишут «поставь иксрей» или «нода на Xray» — речь про это ядро.

Xray против V2Ray: откуда взялся и чем отличается

Историю стоит знать: она объясняет, почему Xray сегодня — фактический стандарт.

Изначально был V2Ray (проект V2Fly) с протоколом VMess. Затем часть разработчиков выделилась в команду XTLS и сделала форк — Xray-core. Форк быстро обогнал оригинал по фичам, критичным именно для обхода DPI:

• XTLS Vision (flow: xtls-rprx-vision) — режим, который отдаёт «настоящий» TLS-хендшейк без двойного шифрования, убирая характерные признаки прокси и заодно снижая нагрузку на CPU.
• VLESS — облегчённый протокол без встроенного шифрования (его берёт на себя TLS/Reality): меньше оверхед и меньше сигнатур.
• Reality — маскировка под чужой валидный сайт без покупки собственного домена и сертификата.

Совместимость с конфигами V2Ray в целом сохраняется (формат config.json общий), но перечисленные фичи живут только в Xray. Практический вывод для оператора: поднимаете сервис сегодня — берёте Xray-core, а не V2Ray, вопрос закрыт.

Какие протоколы и транспорты поддерживает Xray

Важно различать протокол (как оборачивается полезная нагрузка) и транспорт/маскировку (как это выглядит в сети). Xray их комбинирует, и в конфиге это разные поля: protocol и streamSettings.

Протоколы (inbound/outbound):

• VLESS — основной современный выбор. Без своего шифрования, работает в паре с TLS или Reality. Минимальный оверхед и отпечаток.
• VMess — старый протокол V2Ray со встроенным шифрованием и таймстампами. Ещё встречается, но по маскировке проигрывает VLESS+Reality.
• Trojan — прикидывается обычным HTTPS-сайтом, но требует свой домен и валидный сертификат.
• Shadowsocks — простой и быстрый; «голый» SS без плагинов (AEAD 2022 — лучше) сейчас уверенно детектится ТСПУ.

Транспорты и маскировка (streamSettings):

• Reality (security: reality) — маскирует TLS-сессию под легитимный сторонний сайт (SNI чужого домена), свой домен/сертификат не нужен. Де-факто база для устойчивых конфигов в РФ.
• XHTTP (network: xhttp, ранее splithttp) — транспорт поверх HTTP: выглядит как обычные веб-запросы и умеет ходить через CDN. Ключевое, когда нужен фронт перед нодой.
• Классика: TCP, WebSocket (ws), gRPC, HTTPUpgrade.

Про связку VLESS + Reality и про XHTTP через CDN у нас есть отдельные подробные разборы — здесь не повторяемся. Ориентир простой: VLESS для транспорта, Reality для маскировки TLS на «голом» IP, XHTTP — когда перед нодой нужен слой CDN.

Где используется Xray-core: панели Marzban, 3x-ui, Remnawave

В проде почти никто не пишет config.json руками на сотни клиентов. Поверх ядра ставят панель управления: она генерирует конфиг, выдаёт подписки, считает трафик и рулит пользователями. Но движком внутри почти всегда остаётся Xray-core:

• 3x-ui — веб-панель для одиночного сервера, низкий порог входа, вся настройка Xray через UI.
• Marzban — панель посерьёзнее: ноды, подписки, API; Xray как ядро на каждой ноде.
• Remnawave — современная панель с раздельной архитектурой «панель + ноды» и подписочным сервисом; ноды крутят тот же Xray-core.

Логика одна: панель — оркестратор и биллинг, а прикладную работу (приём VLESS, Reality-хендшейк, XHTTP-транспорт) делает Xray. Практическая польза от понимания этого — в отладке: если «протокол не коннектится», причина почти всегда в конфиге ядра или в сети/блокировке IP, а не в самой панели. Первым делом смотрят логи именно Xray (journalctl -u xray -f или логи ноды в панели), а не веб-морду.

Xray core настройка: как устроен config.json

Вся настройка Xray-core сводится к одному JSON-файлу — по умолчанию /usr/local/etc/xray/config.json при установке официальным скриптом:

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

Панели генерируют этот файл сами, но структуру полезно знать для диагностики. Ключевые секции:

• inbounds — что ядро принимает: protocol (vless/vmess/…), port, id (UUID клиента), настройки TLS/Reality и транспорт (streamSettings).
• outbounds — куда отправляет: обычно freedom (напрямую в интернет) и blackhole (сброс).
• routing — правила маршрутизации: кого куда пустить, что заблокировать, разделение по доменам/IP (например, гнать geoip:ru напрямую мимо туннеля).
• log — уровень (warning в проде, debug при отладке).

Минимальный смысловой каркас VLESS + Reality inbound:

{
 "inbounds": [{
 "port": 443,
 "protocol": "vless",
 "settings": {
 "clients": [{ "id": "UUID-КЛИЕНТА", "flow": "xtls-rprx-vision" }],
 "decryption": "none"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "reality",
 "realitySettings": {
 "dest": "www.some-real-site.com:443",
 "serverNames": ["www.some-real-site.com"],
 "privateKey": "ПРИВАТНЫЙ-КЛЮЧ",
 "shortIds": ["", "0123abcd"]
 }
 }
 }],
 "outbounds": [{ "protocol": "freedom" }]
}

Практические заметки:

• id (UUID) на сервере и клиенте должны совпадать — это и есть «логин». Сгенерировать: xray uuid.
• Ключевую пару Reality генерирует само ядро: xray x25519 (даёт privateKey для сервера и publicKey для клиента).
• serverNames/dest должны указывать на реально живой чужой сайт, который отвечает валидным TLS 1.3 с HTTP/2 и не заблокирован в РФ (частая ошибка — взять домен, уже отрезанный ТСПУ).
• Проверить конфиг перед стартом: xray run -test -confdir /usr/local/etc/xray/ (или -config config.json) — синтаксис и логику без реального запуска.
• Применить изменения: systemctl restart xray; смотреть, что живо: systemctl status xray.
• Если стоит панель — правьте параметры в её UI/API, а не в файле напрямую: при следующем действии панель перезапишет config.json и ваши ручные изменения потеряются.

Устойчивость к блокировкам: чего Xray не решает сам

Xray отлично прячет *характер* трафика: Reality убирает сигнатуры TLS, VLESS+Vision минимизируют отпечаток, XHTTP маскирует всё под обычный веб. Но есть предел, который ядро закрыть не в силах — блокировка самого IP ноды.

В регионах с политикой «белых списков» (доступ разрешён только к одобренным подсетям, остальное режется) сервер в обычном дата-центре вычисляется и блокируется по IP. Никакая маскировка протокола тут не помогает: до ноды просто не доходит пакет, обрабатывать нечего. Это вопрос уже не протокола, а того, *откуда* виден фронт.

Практичный ответ — не держать точку входа на «голом» IP ноды, а ставить перед ней фронт через whitelisted-CDN: клиент по XHTTP стучится в адрес CDN из разрешённых подсетей, а CDN проксирует трафик на вашу ноду. Именно под такой сценарий в Xray и сделан XHTTP (в отличие от WebSocket/gRPC, которые через CDN проходят не всегда, а с POST-ограничениями CDN — тем более капризны). Так ядро отвечает за маскировку внутри туннеля, а CDN-слой — за то, чтобы точка входа оставалась доступной даже при белых списках. Детали схемы — в отдельных статьях про Remnawave и панели за CDN.