Xray Reality: настройка сервера и клиента, выбор SNI-донора

Что такое Xray Reality и за счёт чего он обходит DPI

Reality — транспорт-обёртка Xray поверх VLESS, доступная в Xray-core начиная с 1.8.0 (проверьте xray version). Она снимает главную боль обычного VLESS + TLS: собственный домен и сертификат, которые легко вычислить активным пробингом и отрезать по SNI.

При подключении клиент инициирует настоящий TLS 1.3 handshake, где в SNI стоит чужой авторитетный сайт (например, www.microsoft.com). Ваш сервер проксирует этот хендшейк на реальный сайт-донор, и для ТСПУ/DPI соединение неотличимо от визита на популярный ресурс: валидный сертификат донора, корректная цепочка, реальный ClientHello. Доступ к VLESS-туннелю получает только клиент, знающий публичный ключ (pbk) и короткий shortId; все остальные, включая активный пробинг, видят настоящий сайт-донор.

Чем xray vless reality отличается от VLESS + TLS:

• не нужен свой домен и сертификат — заимствуется TLS-личность донора, нет продления Let's Encrypt;
• устойчивость к активному пробингу — «постучавшись» на порт, цензор получает ответ реального сайта, а не подозрительную заглушку;
• нет утечки своего SNI — в трафике светится только домен донора.

Граница, которую надо держать в голове с самого начала: Reality маскирует что вы делаете (факт VPN), но не меняет откуда — IP вашего сервера остаётся вашим. Отсюда следует, против каких блокировок он работает, а против каких бесполезен (разбор — в последнем разделе).

Честная оговорка: Reality — не абсолют. В академических работах описаны методы детекта TLS-in-TLS по таймингам и размерам пакетов; Reality их усложняет, но не отменяет. На практике в РФ такие методы массово пока не применяются, и по наблюдениям Reality остаётся одним из самых живучих транспортов при DPI-фильтрации.

Настройка сервера: inbound Reality

Сгенерируйте пару ключей X25519 прямо в Xray:

xray x25519
# Private key: <PRIVATE_KEY> -> в конфиг сервера (privateKey)
# Public key: <PUBLIC_KEY> -> клиенту как pbk

Добавьте UUID (xray uuid) и shortId — hex-строку чётной длины от 0 до 16 символов (0–8 байт), например openssl rand -hex 8. Минимальный рабочий inbound:

{
 "inbounds": [{
 "listen": "0.0.0.0",
 "port": 443,
 "protocol": "vless",
 "settings": {
 "clients": [{
 "id": "<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": "<PRIVATE_KEY>",
 "shortIds": ["", "0123456789abcdef"]
 }
 }
 }]
}

Что критично:

• dest — куда сервер реально проксирует хендшейк, тот самый сайт-донор. Должен быть доступен с сервера по 443 и говорить TLS 1.3.
• serverNames — список разрешённых SNI. Должен содержать имя донора и совпадать с тем, что укажет клиент.
• network: tcp + flow: xtls-rprx-vision — стандартная связка Reality. Vision работает поверх TCP и обязателен на обеих сторонах; варианты через h2/gRPC существуют, но vision+tcp — рабочая база.
• порт 443 и на inbound, и у донора — визит «на microsoft.com:443» так выглядит естественнее, чем на нестандартный порт.
• shortIds — пустая строка "" разрешает клиентов без sid; для строгости оставьте только явные значения. Можно перечислить несколько.
• xver: 0 — PROXY protocol выключен (нужен только если перед Xray стоит свой прокси).

Применение: systemctl restart xray, лог — journalctl -u xray -f. На панелях (Remnawave, 3x-ui, Marzban) те же поля заполняются через UI — панель просто генерирует этот JSON.

Выбор SNI-донора — самый важный шаг

Большая часть проблем с xray reality настройка — неправильный донор. Он должен выдержать проверку так, будто вы реально на него ходите. Критерии:

1. TLS 1.3 + X25519. Обязательно. Быстрая проверка:

openssl s_client -connect www.microsoft.com:443 -tls1_3 -alpn h2 </dev/null 2>/dev/null | grep -E "Protocol|ALPN"

В выводе должно быть Protocol: TLSv1.3 и ALPN protocol: h2. Если TLS 1.3 не поднимается — донор не подходит.

1. HTTP/2 (h2) в ALPN. Vision-flow ожидает h2; сайт только с http/1.1 даёт повод для аномалии.
2. Не за общим CDN и не за вашим хостером. Донор за Cloudflare/крупным CDN — плохо: цензор видит один IP-пул на миллионы сайтов, и «поездка на microsoft.com» с IP немецкого VPS выглядит странно. Идеален домен на собственной автономной системе (AS).
3. Правдоподобие для вашего IP. Крупные международные сервисы (Microsoft, Apple-поддомены, облачные вендоры) нейтральны; локальный банк РФ на немецком сервере — нет.
4. Неприметность без экзотики. Не берите домен, который сам рискует попасть под блокировку, но и не настолько редкий, что «один клиент = один донор» бросается в глаза. Здоровая середина — популярный, но не рекламируемый сервис.
5. Низкая задержка. Донор географически рядом с сервером — меньше latency хендшейка.

Практика: держите 2–3 проверенных донора и умейте быстро переключить dest/serverNames. Честно: универсального «вечного» донора нет — то, что работает у одного оператора, у другого может отвалиться из-за особенностей IP-диапазона, поэтому донора проверяют периодически, а не один раз при установке.

Настройка клиента и диагностика

Клиенту нужен набор параметров, жёстко связанный с сервером. По ссылке vless:// они кодируются в query; вручную (v2rayN, Nekobox, Streisand, Happ, sing-box) вводятся так:

• address / port — IP сервера и 443;
• id — тот же UUID;
• flow — xtls-rprx-vision;
• security — reality;
• sni — домен донора, совпадает с одним из serverNames;
• pbk (publicKey) — публичный ключ из xray x25519;
• sid (shortId) — одно из значений shortIds сервера;
• fp (fingerprint) — отпечаток TLS-клиента (uTLS): chrome, firefox, safari, ios, edge, random. Обычно chrome; пустой fp — частая причина детекта;
• spx (spiderX) — путь, обычно /.

Пример ссылки:

vless://<UUID>@<SERVER_IP>:443?security=reality&encryption=none&flow=xtls-rprx-vision&type=tcp&sni=www.microsoft.com&fp=chrome&pbk=<PUBLIC_KEY>&sid=0123456789abcdef&spx=%2F#BRAID-Reality

Почему «не коннектится» — чек-лист по частоте:

1. sni не входит в serverNames сервера;
2. sid не из списка shortIds (или лишний символ/нечётная длина);
3. flow: xtls-rprx-vision прописан только на одной стороне;
4. пустой или неверный fp;
5. перепутаны pbk (публичный) и privateKey — клиенту идёт публичный;
6. донор перестал отвечать TLS 1.3 (проверьте openssl s_client заново).

Для отладки временно включите "show": true в realitySettings и смотрите хендшейки в journalctl -u xray -f. После диагностики верните false, чтобы не засорять лог.

Граница применимости: Reality или CDN-фронт

Reality и фронт через CDN часто путают — это инструменты против разных блокировок.

Reality (TCP, прямое соединение на IP ноды):

• прячет факт VPN за TLS-личностью донора — силён против DPI, SNI-фильтрации и активного пробинга;
• клиент ходит напрямую на IP вашего сервера;
• бесполезен при блокировке по IP. Если дата-центровый IP попал под ТСПУ-блок или не входит в белый список (режим «разрешено только доверенное»), маскировать нечего: хендшейк уходит на уже недоступный адрес.

XHTTP через whitelisted-CDN (фронт перед нодой):

• клиент соединяется с IP CDN-фронта, а не вашей ноды;
• если CDN сидит на IP-диапазонах из белых списков операторов, доступ переживает даже периоды тотальных whitelist-блокировок, когда прямые коннекты к зарубежным VPS вырублены;
• цена — сложнее настройка, накладные расходы на трафик и специфика транспорта. Детали — в отдельных материалах про XHTTP и «панели за CDN», здесь не повторяем.

Как выбирать:

• DPI/SNI-фильтрация, IP ещё доступен → Reality: просто, быстро, без накладных расходов;
• активный пробинг → Reality, он ровно под это и создан;
• белые списки / блок по IP дата-центров → XHTTP через whitelisted-CDN, Reality тут не поможет;
• максимальная устойчивость → оба профиля: Reality основной, CDN-фронт резервный. Happ, sing-box и подобные клиенты держат несколько конфигов и переключаются.

Честная оговорка: точные пороги и момент перехода региона в whitelist-режим публично не документированы и меняются; по наблюдениям ряда операторов такие периоды локальны и временны — поэтому CDN-канал держат «на всякий», а Reality остаётся рабочей лошадкой в обычное время. Ключевой тезис: сервер в дата-центре легко блокируется именно при белых списках, и устойчивость там даёт не красивый хендшейк, а фронт на «белом» IP.