← К библиотеке
Протоколы Практика

3x-ui: VLESS + Reality пошагово

Reality — то, что держит твой инбаунд живым под DPI в 2026. В 3x-ui его собирать приятно: панель сама генерит ключи и умеет искать живого донора. Ниже — пошагово по форме создания подключения, с разбором каждого поля и одним предупреждением, которое сэкономит тебе вечер. Свои значения впиши в конструктор сверху.

Зачем Reality, а не обычный TLS

Классический VLESS+TLS палится на раз: свежий Let's Encrypt на непонятном домене, DPI видит редкий SNI и рвёт хендшейк. Reality решает это иначе — он не поднимает свой TLS вообще. Он представляется чужим большим сайтом (донором) и переиспользует его настоящий сертификат. Снаружи это неотличимо от того, как ты зашёл на крупный HTTPS-сайт.

Ключевая мысль: донор — это чужой живой ресурс с TLS 1.3, к которому не придерётся никто. Не твой домен. Твой домен тут вообще не участвует. Хорошая новость: в 3x-ui почти всё это панель делает за тебя.

Шаг 1 — создаём подключение

Форма «Создать подключение» в 3x-ui — вкладка «Основное»

Открываешь Входящие → «Создать подключение». Форма разбита на вкладки: Основное / Протокол / Поток / Безопасность / Сниффинг / Расширенный шаблон. Пройдём по тем, что нужны для Reality.

На вкладке Основное:

  • Примечание (Remark) — метка инбаунда, например DE-01 · Reality.
  • Порт443. Это важно: 443 — самый неприметный порт, там и живёт весь HTTPS-мир.
  • Протоколvless.

Шаг 2 — вкладка Безопасность и авто-ключи

Вкладка «Безопасность» → Reality: панель сама сгенерировала пару ключей и Short IDs

Публичный и приватный ключ + кнопка «Получить новый сертификат»

Переходишь на вкладку Безопасность. Тут переключатель: Нет / TLS / Reality. Выбираешь Reality — и панель тут же сама генерит пару ключей: поля «Публичный ключ» и «Приватный ключ» уже заполнены. Ничего в терминале генерить не надо.

  • Кнопка «Получить новый сертификат» — если хочешь новую пару ключей, жми её.
  • Приватный ключ остаётся на сервере (в конфиге инбаунда).
  • Публичный ключ уйдёт клиенту в подписку — панель подставит его сама.
  • Short IDs панель заполняет автоматически, трогать не нужно.
  • Поля mldsa65 Seed / Verify (новое в Xray 26.x) — можно не трогать, для базового Reality они не нужны.

Шаг 3 — донор (Цель + SNI), и главное предупреждение

Тут же на вкладке Безопасность задаётся донор — два связанных поля:

  • «Цель» (dest/target) — куда Reality проксирует «фасад». Формат домен:443.
  • SNI — имя, под которое ты маскируешься; это домен донора без порта.

Панель помогает: кнопки «Сканировать» / «Найти цели» сами подбирают живой dest, который держит TLS 1.3, и подставляют его. Но подбирать вслепую не надо — вот критичное:

Проверено вживую e2e: на Xray 26.x донор www.microsoft.com ЛОМАЕТ Reality. Инбаунд создаётся, но тоннель не поднимается. Бери www.cloudflare.com — с ним Reality встаёт стабильно. Это первое, что надо проверить, если «всё настроил, а не коннектится».

Итого по донору:

донор
Цель (dest) : www.cloudflare.com:443
SNI         : www.cloudflare.com
uTLS        : chrome
Short IDs   : (авто — не трогаем)
  • uTLS оставь chrome — это отпечаток TLS-клиента. Если из твоего региона именно chrome-фингерпринт начнут душить — переключишь на firefox, часто помогает переждать волну.
  • Цель и SNI должны указывать на одного и того же донора (www.cloudflare.com).

Шаг 4 — flow Vision на вкладке Поток

Reality на TCP просит режим Vision. Идёшь на вкладку Поток, где network = tcp, и в клиентском flow ставишь:

поток
network : tcp
flow    : xtls-rprx-vision

xtls-rprx-vision убирает двойное шифрование TLS-в-TLS и ломает статистический анализ длин пакетов. На TCP-Reality это обязательный минимум. Flow задаётся у клиента — когда будешь добавлять пользователя к этому инбаунду, у него в flow тоже должно стоять xtls-rprx-vision.

Вкладку Сниффинг оставь включённой (destOverride на http/tls/quic) — это стандарт. Расширенный шаблон для базового Reality не трогаешь.

Сохраняешь подключение. Панель собирает конфиг Xray и перезапускает ядро сама.

Шаг 5 — как это выглядит в конфиге

Панель под капотом собирает вот такой инбаунд. Смотреть его руками не обязательно (и править напрямую не надо — панель перезапишет), но полезно понимать, что происходит:

config.json
{
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [
      { "id": "CLIENT_UUID", "flow": "xtls-rprx-vision" }
    ],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "show": false,
      "dest": "www.cloudflare.com:443",
      "serverNames": ["www.cloudflare.com"],
      "privateKey": "PRIVATE_KEY_X25519",
      "shortIds": ["REALITY_SHORT_ID"]
    }
  }
}

Видно, что dest и serverNames — тот самый донор и совпадают, privateKey — из авто-пары панели, а publicKey (которого тут нет) панель отдаёт клиенту в подписку.

Проверка

Открой порт и подключись клиентом:

bash
ufw allow 443/tcp

# с устройства под VPN — должен показать IP сервера
curl -s https://api.ipify.org

Вернулся IP сервера — Reality собрался, цепочка живая. Если висит и не коннектится — проверь по порядку: (1) донор не www.microsoft.com, а www.cloudflare.com; (2) на клиенте flow = xtls-rprx-vision; (3) 443 открыт в фаерволе; (4) публичный ключ у клиента совпадает с приватным на сервере (если менял пару кнопкой — переотдай подписку).

Reality — база. Дальше можно навесить XHTTP поверх Reality или gRPC как скрытый резерв — это в соседних разборах ветки «протоколы».

Следующий гайд 3x-ui: XHTTP поверх Reality → Не понравилась статья или что-то непонятно? Напишите мне — помогу или поправлю. @notrealvpn →
Материал носит образовательный характер и посвящён инженерии сетевой инфраструктуры. Вы отвечаете за соблюдение законов своей юрисдикции.