VLESS + Reality: как работает и как настроить

Reality часто настраивают копипастой из чата: подставили чужой serverNames, сгенерировали ключ, заработало. Через месяц SNI попадает под раздачу, и никто не помнит, какое поле за что отвечало. Ниже то, что написано в официальной документации Xray и README REALITY, плюс что происходило с этим рецептом в России.

#Как работает Reality

По README XTLS/REALITY Reality заменяет TLS на стороне сервера. Сертификат покупать не нужно: сервер указывает на чужой сайт (target) и для наблюдателя выглядит как настоящий TLS с этим SNI. Серверный TLS-отпечаток, характерный для прокси, пропадает.

Что происходит при подключении:

1. Клиент отправляет Client Hello с SNI из serverNames и спрятанными в нём данными для проверки: ключ x25519 и shortId.
2. Если проверка прошла, сервер выдаёт клиенту «временный доверенный сертификат», и внутри идёт VLESS.
3. Если нет (сканер, браузер, чужой клиент), Xray напрямую пересылает соединение на target. Проверяющий получает настоящий сертификат и настоящую страницу сайта.

Клиент Reality различает три случая: временный сертификат (работаем), настоящий сертификат сайта (включается «режим паука» spiderX, клиент ведёт себя как обычный посетитель) и невалидный сертификат (TLS alert, разрыв).

#Ключи и идентификаторы

Все команды встроены в Xray. На ноде в Docker запускай через docker exec <контейнер> xray ....

xray uuid                        # случайный UUID для клиента
xray uuid -i "любая строка"      # UUIDv5 из строки, одинаковый при каждом запуске
xray x25519                      # пара ключей для Reality
openssl rand -hex 8              # shortId: 16 hex-символов

xray x25519 печатает три строки: PrivateKey (в конфиг сервера), Password (PublicKey) (клиенту) и Hash32. Публичный ключ можно получить заново из приватного: xray x25519 -i "ПРИВАТНЫЙ_КЛЮЧ".

Требования к shortId: до 16 символов 0–f, количество символов чётное. Короткое значение ядро дополняет нулями справа: aa1234 превращается в aa12340000000000, а aaa1234 даст ошибку.

#Серверный inbound

Минимальный конфиг ноды с одним клиентом:

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "tag": "VLESS_REALITY",
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "ВСТАВЬ_UUID", "flow": "xtls-rprx-vision", "email": "user1" }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "target": "ВСТАВЬ_САЙТ:443",
          "xver": 0,
          "serverNames": ["ВСТАВЬ_САЙТ"],
          "privateKey": "ВСТАВЬ_PRIVATE_KEY",
          "shortIds": ["ВСТАВЬ_SHORT_ID"]
        }
      }
    }
  ],
  "outbounds": [
    { "tag": "direct", "protocol": "freedom" }
  ]
}

Что здесь что:

• settings.clients[].id: UUID или любая строка до 30 байт. В свежей документации массив называется users, но исходник ядра принимает оба имени.
• flow: "xtls-rprx-vision": режим XTLS Vision. Работает только в связке RAW (TCP) + TLS/Reality. Если на сервере он задан, клиент обязан его включить.
• decryption: "none": пустым оставлять нельзя, для обычного VLESS пишется явно "none".
• network: "raw": бывший tcp, переименован. В документации для 26.7+ поле называется method. Ядро принимает network и method, raw и tcp, поэтому пример выше работает и на стабильной 26.3.27.
• target: куда уходят непроверенные соединения. Формат как у dest в fallbacks: адрес:порт или путь к unix-сокету. Старое имя поля dest, сейчас это синонимы. Не указывай target в конфиге клиента: по нему ядро решает, серверный это конфиг или клиентский.
• xver: отправлять ли на target PROXY protocol (0: нет, 1 или 2: да). Для чужого сайта всегда 0. Пригодится с selfsteal, см. XHTTP и selfsteal.
• serverNames: какие SNI сервер примет. Без *. Обычно совпадает с именами в сертификате target.
• privateKey: из xray x25519.
• shortIds: список допустимых shortId. Пустая строка в списке разрешает клиенту пустой shortId.

#Клиентская сторона

Клиенты вроде Happ и INCY собирают это из ссылки подписки, но полезно понимать, какие поля за этим стоят. Outbound в формате текущей документации:

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "address": "ВСТАВЬ_IP_НОДЫ",
        "port": 443,
        "id": "ВСТАВЬ_UUID",
        "encryption": "none",
        "flow": "xtls-rprx-vision"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "serverName": "ВСТАВЬ_САЙТ",
          "fingerprint": "chrome",
          "password": "ВСТАВЬ_PUBLIC_KEY",
          "shortId": "ВСТАВЬ_SHORT_ID",
          "spiderX": "/"
        }
      }
    }
  ]
}

• serverName: один из серверных serverNames.
• password: публичный ключ сервера. Раньше поле называлось publicKey, ядро понимает оба имени. Документация переименовала его, чтобы подчеркнуть: ключ держат у себя клиенты, публиковать его не стоит.
• shortId: один из серверных shortIds.
• fingerprint: какой браузер изображает Client Hello через uTLS. Варианты: chrome (по умолчанию), firefox, safari, ios, android, edge, 360, qq, random, randomized. Значение unsafe в Reality не поддерживается.
• spiderX: начальный путь для «режима паука». Документация советует разный для каждого клиента.

#Как выбрать сайт-маскировку

Минимальные требования из README REALITY:

• сайт поддерживает TLS 1.3 и HTTP/2;
• домен не используется для редиректа (редирект основного домена на www допустим; в примере README в serverNames указаны оба имени);
• сайт находится «вне GFW». README писали для Китая, по смыслу это сайт, который цензор не блокирует.

Плюсом README называет близость IP сайта к IP ноды и OCSP stapling. Документация Xray говорит прямо: лучшая практика: «одалживать» сертификат у сайта из той же ASN, что и нода. Отдельное предупреждение про сайты за Cloudflare: непроверенный трафик уходит на target, и после сканирования твоя нода превращается в бесплатный порт-форвардер к Cloudflare.

Проверка кандидата:

xray tls ping example.com          # версия TLS, сертификат, пост-квантовый обмен
curl -sI --http2 -o /dev/null -w '%{http_version} %{http_code}\n' https://example.com/

Нужно увидеть TLS 1.3 в первом выводе и 2 200 во втором. Код 301 или 302 означает, что домен отдаёт редирект, и для target он не годится.

Что ставили в target в сообществе: www.amd.com:443 (30.03.2026), st.ozone.ru:443 (04.06.2026), ads.x5.ru:443 с fingerprint firefox на российской ноде-мосте (15.06.2026). Все примеры в базе. Это снимок на дату, а не рекомендация.

#Что горело в РФ

Сжато по хронологии, детекту отпечатков и SNI и fingerprint:

Спуфинг 04.06 соответствует второму случаю из README: посредник отправил Client Hello на настоящий сайт, клиент получил его сертификат и не стал отправлять данные. Защита отработала как задумано, только соединения от этого нет.

#Reality в Remnawave

В Remnawave серверная часть (inbound выше) живёт в профиле конфигурации ноды. В шаблонах из сообщества clients пустой: пользователей подставляет панель. Клиентские параметры вроде fingerprint задаются в хостах, меняются в Хосты → расширенные настройки ( база). Как завести ноду и привязать к ней профиль, описано в гайде Нода Remnawave, установка самой панели в Remnawave с нуля. Перед обновлением ядра на ноде прочитай Обновления без поломок: в 2026 году поля XHTTP меняли несовместимо, подробности в гайде XHTTP и selfsteal.

#Источники

• README XTLS/REALITY: github.com/XTLS/REALITY
• Документация Xray: REALITY, VLESS inbound, VLESS outbound, RAW, TLS (fingerprint), fallbacks; исходники infra/conf/transport_internet.go, infra/conf/vless.go, main/commands/all/curve25519.go, main/commands/all/tls/ping.go в XTLS/Xray-core, тег v26.3.27 и ветка main
• База host.pink: VLESS + Reality, SNI и fingerprint, Ошибки → фиксы, Детект и fingerprint, Хронология блокировок, Итог на 23.08.2026