VPN и обход DPI · 15 мин чтения

VLESS Reality на Xray: настройка сервера в 2026 году

VLESS Reality на Xray: настройка сервера в 2026 году

Reality — это протокол, который научился прятать VPN-трафик внутри настоящего HTTPS-сеанса к чужому сайту. Ни своего домена, ни сертификата — и при этом лучшая на сегодня устойчивость к глубокой инспекции пакетов. Разберём настройку от голого VPS до рабочего клиента.

Привет! Я Семёнов Евгений Сергеевич, директор АйТи Фреш. Мы обслуживаем ИТ-инфраструктуру компаний в Москве, и за последние два года запрос номер один сместился с «поднимите нам VPN» на «поднимите нам VPN, который не отвалится через неделю». Классические протоколы вроде Shadowsocks и WireGuard системы DPI научились узнавать по сигнатуре и подрезать. VLESS + XTLS-Reality на Xray-core решает эту задачу элегантно: сервер маскирует корпоративную связность под обычное соединение с реальным крупным сайтом. В этом гайде я по шагам покажу, как собрать такой сервер для доступа сотрудников к рабочим ресурсам — с реальными командами, полным config.json и разбором граблей, на которые мы сами наступали.

Что такое Reality и почему это лучший обход DPI

Чтобы оценить Reality, нужно понять боль классического VLESS+TLS. Там вы поднимаете свой домен, получаете сертификат Let's Encrypt, а DPI смотрит на SNI в TLS-хендшейке и видит ваш никому не известный домен — подозрительно. Reality переворачивает схему: сервер при рукопожатии предъявляет клиенту сертификат чужого реального сайта (например, www.microsoft.com), а трафик, пришедший с «неправильным» SNI или от постороннего сканера, молча проксирует на этот же настоящий сайт. Для наблюдателя со стороны это неотличимо от того, что кто-то просто зашёл на microsoft.com.

На нашей практике связки Reality пережили несколько волн ограничений там, где Shadowsocks и обычный WireGuard приходилось экстренно переносить. Про то, как выбирать протокол под конкретную сеть, у нас есть отдельный разбор — обход DPI: сравнение корпоративных протоколов 2026.

Что понадобится: сервер и версия Xray

Reality крайне экономичен. Для офиса на 50–100 человек хватает младшего VPS с белым IPv4. Локацию берём там, где провайдер лоялен и канал широкий — Нидерланды, Германия, Финляндия.

СотрудниковvCPURAMКанал
до 301512 МБ – 1 ГБ100–200 Мбит/с
30–1501–21–2 ГБот 500 Мбит/с
150–5002–42–4 ГБ1 Гбит/с

Актуальное ядро — Xray-core версии v26.x (проект перешёл на календарную нумерацию CalVer вида vГГ.М.Д; на момент написания свежий релиз — v26.6.27). Обновляется ядро часто, поэтому мы ставим его официальным скриптом, который сам подтягивает последнюю стабильную сборку с GitHub. Систему берём Debian 12 или Ubuntu 22.04/24.04.

Шаг 1. Установка Xray-core

Официальный установщик XTLS/Xray-install кладёт бинарник в /usr/local/bin/xray, конфиги в /usr/local/etc/xray/ и создаёт готовые systemd-юниты xray.service и xray@.service. Не собираем из исходников вручную — скрипт делает всё правильно и по FHS.

# Обновляемся и ставим Xray официальным скриптом
apt update && apt install -y curl
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

# Проверяем, что бинарник встал и видит свою версию
xray version

Скрипт выведет «info: Start the Xray service» — сервис уже запущен, но пока с пустым дефолтным конфигом. Сейчас мы его заменим на боевой.

Шаг 2. Ключи x25519, UUID и shortId

Reality работает на паре ключей X25519. Приватный ключ живёт на сервере, публичный — раздаётся клиентам. Генерируем всё нужное встроенными средствами Xray и системы:

# Пара ключей Reality: первая строка — приватный (на сервер), вторая — публичный (клиентам)
xray x25519

# UUID для клиента (идентификатор пользователя VLESS)
xray uuid

# shortId — короткий hex-идентификатор, до 16 символов (8 байт)
openssl rand -hex 8

Команда xray x25519 печатает две строки — приватный и публичный ключ. Запомните, какой из них какой: приватный (Private key) пойдёт в privateKey серверного конфига, публичный (Public key) — в настройки клиента как publicKey. Это классическая грабля: перепутали местами — handshake проходит, а трафик не идёт.

Шаг 3. Выбор dest и serverNames (маскировка)

Это сердце маскировки. dest — реальный сайт, под который мы прячемся, а serverNames — список SNI, которые клиент будет предъявлять. Требования к сайту-маске:

Проверить поддержку TLS 1.3 у кандидата можно заранее:

openssl s_client -connect www.microsoft.com:443 -tls1_3 </dev/null 2>/dev/null | grep -i "TLSv1.3"

Важно: значение в serverNames и SNI на клиенте должны совпадать точь-в-точь, а dest указывать на тот же хост на порту 443.

Шаг 4. Рабочий config.json для VLESS-Reality

Теперь собираем всё в конфиг. Открываем /usr/local/etc/xray/config.json и приводим к следующему виду (подставьте свои UUID, приватный ключ и shortId):

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "ВАШ-UUID-ИЗ-xray-uuid",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.microsoft.com:443",
          "xver": 0,
          "serverNames": [
            "www.microsoft.com"
          ],
          "privateKey": "ПРИВАТНЫЙ-КЛЮЧ-ИЗ-xray-x25519",
          "shortIds": [
            "",
            "0123456789abcdef"
          ]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [ "http", "tls", "quic" ]
      }
    }
  ],
  "outbounds": [
    { "protocol": "freedom", "tag": "direct" },
    { "protocol": "blackhole", "tag": "block" }
  ]
}

Разберём ключевые поля, чтобы вы понимали, что правите, а не копировали вслепую:

Проверяем синтаксис перед запуском — это спасает от опечаток в JSON:

xray run -test -config /usr/local/etc/xray/config.json

Шаг 5. Запуск через systemd

Юнит уже создан установщиком, поэтому нам остаётся перечитать конфиг и включить автозапуск. systemd сам поднимет сервис при перезагрузке и перезапустит его при сбое.

# Применяем конфиг и включаем автозапуск
systemctl restart xray
systemctl enable xray
systemctl status xray

# Смотрим, что Xray слушает 443
ss -tlnp | grep 443

# Логи в реальном времени, если что-то не так
journalctl -u xray -f

На фаерволе открываем наружу только 443/tcp, а SSH переносим на нестандартный порт и закрываем по ключу. Меньше открытых портов — меньше поводов для внимания сканеров.

Шаг 6. Подключаем клиентов

Клиенту нужен минимальный набор параметров: address (IP сервера), port 443, id (UUID), flow xtls-rprx-vision, publicKey, serverName (он же SNI = ваш dest) и shortId. Все популярные клиенты понимают Reality из коробки:

Проще всего раздать сотрудникам одну ссылку формата vless://UUID@IP:443?...&security=reality&pbk=PUBLIC_KEY&sni=www.microsoft.com&sid=SHORTID&flow=xtls-rprx-vision&type=tcp#Office. Клиент импортирует её одним нажатием и настраивается сам. Для парка из десятков устройств удобнее централизованная панель с подписками — про клиентскую сторону и связанные с ней риски мы отдельно писали в аудите VLESS-клиентов и их CVE для корпоративного применения.

Частые ошибки

Настроим устойчивый доступ к рабочим ресурсам под ключ

Если нужна не разовая инструкция, а работающая корпоративная связность с резервированием, мониторингом и поддержкой — поможем подобрать VPS, развернуть VLESS-Reality, раздать клиентов сотрудникам и держать сервис в тонусе. Работаем с юрлицами в Москве и МО.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss · info@itfresh.ru
Семёнов Евгений Сергеевич, директор АйТи Фреш

Своими силами или на аутсорсе

Поднять один сервер Reality по этому гайду — вечер работы. Но в компании появляется вопрос эксплуатации: кто следит за обновлениями ядра, кто меняет ключи при уходе сотрудника, кто резервирует локацию, если провайдер начнёт «фильтровать». Это уже не установка, а сопровождение, и здесь стоит взвесить, держать ли компетенцию внутри или отдать наружу. Мы разбирали эту развилку подробно в материале штатный сисадмин против ИТ-аутсорсинга в 2026 году — рекомендую, если решаете, кому доверить инфраструктуру.

Частые вопросы

Нужен ли для Reality собственный домен и TLS-сертификат?
Нет. В этом главное преимущество Reality перед классическим VLESS+TLS: сервер заимствует TLS-сертификат чужого реального сайта (dest), например www.microsoft.com. Свой домен, Let's Encrypt и продление сертификатов не нужны — достаточно голого VPS с белым IP.
Какой dest и serverNames выбрать для маскировки?
Берите крупный сайт на TLS 1.3 и HTTP/2, географически близкий к серверу и не заблокированный. Хорошо работают www.microsoft.com, www.nvidia.com, dl.google.com. serverNames должен точно совпадать с SNI, который клиент отправляет при подключении, а dest указывает на тот же хост на порту 443.
Чем VLESS-Reality отличается от Shadowsocks и обычного VPN?
Reality не просто шифрует трафик, а маскирует его под живой HTTPS-сеанс к реальному сайту с настоящим сертификатом. Для системы глубокой инспекции пакетов соединение неотличимо от обычного посещения microsoft.com, тогда как Shadowsocks и WireGuard имеют узнаваемые сигнатуры и чаще попадают под ограничения.
Что такое shortIds и flow xtls-rprx-vision?
shortIds — список коротких hex-идентификаторов (до 16 символов), по которым сервер различает клиентов; пустая строка в списке разрешает подключения без shortId. Flow xtls-rprx-vision — фирменный режим XTLS-Vision, который снижает накладные расходы двойного шифрования и защищает от анализа по длине пакетов.
Один сервер Reality — сколько сотрудников выдержит?
VLESS+Reality очень экономичен по ресурсам. VPS с 1 vCPU и 1 ГБ RAM спокойно держит 100–300 активных подключений. Для сотни сотрудников офиса этого достаточно; упор идёт в пропускную способность канала, а не в процессор.
Почему подключение обрывается сразу после handshake?
Самые частые причины: время на сервере ушло больше чем на 90 секунд (Reality чувствителен к рассинхрону — включите NTP), publicKey у клиента не соответствует privateKey сервера, либо выбранный dest не поддерживает TLS 1.3. Проверьте journalctl -u xray и синхронизацию часов.

Заключение

VLESS + XTLS-Reality на Xray-core — это про надёжность и незаметность. Вы получаете корпоративную связность, которая не требует своего домена, устойчива к активному зондированию и внешне неотличима от обычного визита на крупный сайт. Ключевые моменты: ставьте ядро официальным скриптом, не путайте приватный и публичный ключи, синхронизируйте время, подбирайте dest с TLS 1.3 и держите открытым один порт. Соберите такой сервер по шагам выше — и доступ сотрудников к рабочим ресурсам перестанет быть головной болью. А если нужна эксплуатация под ключ с резервом и мониторингом — вы знаете, где нас найти.

Похожие статьи