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

VLESS + Reality: конфиг, который не палится

Reality — это то, что держит твою ноду живой под DPI в 2026. Не «ещё один протокол», а способ выглядеть как чужой популярный сайт. Ниже — рабочий конфиг и разбор каждого поля. Впиши свои ключи в конструктор сверху (или сгенерируй кнопкой 🎲), дальше просто копируй.

Читать теорию

Зачем Reality, если есть обычный TLS

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

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

Генерируем ключи

Reality держится на паре x25519 и коротком идентификаторе. Генерятся они за секунду:

bash
# пара ключей x25519 (privateKey → на сервер, publicKey → клиенту)
xray x25519

# shortId — короткий hex чётной длины
openssl rand -hex 8

# UUID клиента
xray uuid

privateKey остаётся на ноде, publicKey и shortId уходят в подписку клиенту. Перепутаешь — хендшейк не соберётся, и будешь час втыкать в «почему не коннектится».

Серверный конфиг

Вот inbound, который я ставлю по умолчанию. Впиши свои значения в конструктор — они подставятся сюда и в клиентскую часть одновременно:

config.json
{
  "inbounds": [
    {
      "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"]
        }
      }
    }
  ]
}

Разбор по полям:

  • flow: xtls-rprx-vision — режим Vision, он убирает двойное шифрование TLS-в-TLS и заодно ломает статистический анализ длин пакетов. На TCP это обязательный минимум.
  • dest и serverNames — тот самый донор. Должны совпадать. Бери сайт, который заведомо жив и держит TLS 1.3.
  • privateKey — приватная часть пары, которую ты сгенерил выше.
  • shortIds — можно несколько, удобно раздавать разным клиентам разные.

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

Клиенту нужен зеркальный набор, но вместо privateKeypublicKey:

vless-ссылка
vless://CLIENT_UUID@your-domain.com:443?security=reality&encryption=none&pbk=REALITY_PUBLIC_KEY&fp=chrome&sni=www.cloudflare.com&sid=REALITY_SHORT_ID&flow=xtls-rprx-vision&type=tcp#my-node

fp=chrome — это отпечаток TLS-клиента (uTLS). Если из твоего региона Chrome-фингерпринт начинают душить — переключай на firefox, часто помогает переждать волну.

Проверка

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

bash
# 1. выход через ноду
curl -s https://api.ipify.org

# 2. со стороны — сервер должен отвечать как донор
curl -sI https://your-domain.com | head -1

Второй запрос на твой домен должен вести себя так, будто это обычный сайт, а не «что-то подозрительное на 443». Если Reality собран правильно — снаружи ты неотличим от миллиона HTTPS-соединений. Ровно этого мы и добивались.

Следующий гайд Vision (xtls-rprx-vision): зачем нужен flow → Не понравилась статья или что-то непонятно? Напишите мне — помогу или поправлю. @notrealvpn →
Материал носит образовательный характер и посвящён инженерии сетевой инфраструктуры. Вы отвечаете за соблюдение законов своей юрисдикции.