REALITY serverName и SNI: как выбрать и проверить значение

Что такое serverName и SNI в REALITY

При работе с REALITY параметр serverName — это доменное имя, которое указывается в клиентской конфигурации в блоке reality и выполняет роль SNI (Server Name Indication) при TLS-соединении. SNI — это расширение протокола TLS, которое позволяет клиенту заранее сообщить серверу, какое имя он хочет получить в сертификате. REALITY использует это для подмены цепочки сертификатов и имитации легитимного TLS-сервера: сервер, настроенный с REALITY, не хранит свой валидный сертификат, а «проксирует» рукопожатие к выбранному serverName, получая и подсовывая клиенту чужой сертификат. Таким образом, весь трафик выглядит как обычное зашифрованное подключение к известному сайту, а не к вашему прокси.

Поле serverName используется и на стороне сервера (в inbound REALITY), и на стороне клиента (в outbound). От его правильного выбора напрямую зависит, будет ли соединение стабильным и заметным для DPI-фильтров.

Почему выбор serverName влияет на стабильность и обход блокировок

Если выбранный домен недоступен с вашего сервера или клиента, TLS-рукопожатие не сможет завершиться, и подключение упадёт. Кроме того, если домен заблокирован на территории пользователя, соединение может быть прервано DPI. Чтобы REALITY работал эффективно, выбранный serverName должен:

• быть доступным по HTTPS (порт 443) из сети вашего сервера;
• поддерживать TLS 1.3 и HTTP/2 (желательно, чтобы соответствовать современным требованиям);
• не находиться под блокировкой у провайдера клиента;
• иметь валидный сертификат, выданный публичным доверенным центром (CA);
• быть «нейтральным»: не слишком популярным, но и не редким, чтобы не привлекать внимание.

Выбор правильного значения помогает маскировать ваш трафик под обычное посещение сайта, а неправильный — наоборот, может выдать вас.

Как выбрать подходящее значение serverName: критерии и проверенные домены

Не существует официального списка «лучших» serverName для REALITY. Однако практика выработала несколько критериев, которым должен соответствовать домен.

Критерии выбора

1. Поддержка TLS 1.3 и HTTP/2. Современный TLS-стек сокращает число отличий от легитимного трафика. Проверить можно командой openssl s_client -connect host:443 -alpn h2.
2. Не за CDN. Домены за Cloudflare и другими CDN могут отдавать нестабильный сертификат или менять IP. Лучше выбирать сайты, хостящиеся на конкретных серверах.
3. Доступность на протяжении 24/7. Крупные сайты почти всегда доступны, поэтому их удобно использовать.
4. Отсутствие HSTS-предзагрузки с префиксом *. Это редко мешает, но лучше, чтобы домен не требовал обязательного redirect.
5. Резолвится в ваш IP? Необязательно. REALITY использует домен только для получения сертификата, но сервер должен иметь сетевой доступ к этому домену.

В качестве примеров часто упоминают www.microsoft.com, www.apple.com, swdist.apple.com, www.cloudflare.com, learn.microsoft.com. Но мы не гарантируем их работу в вашем регионе — проверяйте индивидуально.

Как проверить serverName на сервере: openssl, curl и Xray-подключение

Перед боевым использованием обязательно проверьте выбранный домен. Начнём с проверки на сервере, где будет работать ваш inbound REALITY.

openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3 2>/dev/null | grep -E "Protocol|Server certificate"

Если команда выводит Protocol : TLSv1.3 и данные сертификата — домен поддерживает TLS 1.3. Также проверьте HTTP/2:

curl -I --http2 https://www.example.com

При ответе HTTP/2 200 всё в порядке. Если домен находится за CDN, вы увидите заголовки CDN-провайдера — тогда лучше искать другой вариант.

Далее проверьте, может ли ваш сервер соединиться с этим доменом. Это особенно важно, если вы используете фаервол или блокировку по IP:

curl -sv --connect-timeout 5 https://www.example.com -o /dev/null

Если подключение успешно, сервер сможет «занять» TLS-параметры у этого сайта.

После установки Xray или sing-box проверьте логи. На сервере в inbound REALITY доступен параметр serverName. Попробуйте подключиться с клиента. Если в логах появился REALITY: fallback или ошибка сертификата — значит, сервер не смог получить сертификат от указанного домена.

Как проверить SNI на клиенте: логи, v2rayNG, sing-box, Shadowrocket

Настройка клиента должна совпадать с сервером. В конфигурации VLESS или Trojan для REALITY клиента обычно указывают:

"reality": {
  "serverName": "www.example.com",
  "publicKey": "...",
  "shortId": "..."
}

В v2rayNG (Android) поле называется SNI или serverName. В Shadowrocket — serverName в разделе REALITY. В sing-box — в блоке tls.servername.

Чтобы проверить, какой SNI реально отправляется, можно временно включить логи TLS-рукопожатия на сервере (например, loglevel: debug в Xray) и посмотреть, с каким serverName приходят запросы. Для этого на сервере в разделе log установите loglevel: "debug" и перезапустите Xray. В логах будет виден SNI каждого входящего TLS-соединения.

На клиенте также можно посмотреть, какие запросы отправляются, с помощью tcpdump на роутере или локальной машине:

sudo tcpdump -i any -n -s 0 port 443 -A | grep -i "server_name"

Убедитесь, что SNI равен выбранному домену.

Типичные ошибки: несоответствие SNI и serverName, недоступность домена, CDN

Ошибка №1 — указать в клиенте домен, отличающийся от серверного: например, на клиенте стоит microsoft.com, а на сервере — apple.com. Немедленно приведёт к сбою рукопожатия.

Ошибка №2 — использовать домен, который не поддерживает TLS 1.3 (старые сайты). При обычном TLS REALITY может работать, но снижается имитация.

Ошибка №3 — выбирать домен за Cloudflare. Cloudflare часто отдаёт сертификат с несколькими именами, и сервер может не получить правильную цепочку. Кроме того, CDN может добавить лишние round-trip.

Ошибка №4 — непроверенная доступность домена на сервере. Если ваш сервер географически заблокирован к этому домену, REALITY не подключится.

Ошибка №5 — игнорировать обновления DNS. Если домен начинает резолвиться в заблокированный IP, сервер не сможет получить сертификат. Рекомендуется использовать домены с проверенной стабильной инфраструктурой.

Пошаговая диагностика при неработающем serverName

Если после настройки соединение не устанавливается, выполните следующие шаги.

Шаг 1. Проверьте конфигурацию на сервере

• Убедитесь, что в inbound верно указан serverName, dest (обычно :443), privateKey и shortId. Список параметров deprecated? — смотрите актуальный документацию.

Шаг 2. Проверьте конфигурацию на клиенте

• Сравните serverName, shortId, publicKey с сервером. Ошибка в одной букве недопустима.

Шаг 3. Проверьте сеть и DNS

• На сервере выполните ping www.example.com и curl -v https://www.example.com. Если сервер не резолвит домен или не может установить TLS-соединение, REALITY не заработает.

Шаг 4. Смотрите логи Xray

• Запустите Xray с loglevel: debug и повторите попытку подключения. Ищите строки вида tls:, REALITY, handshake.

Шаг 5. Проверьте SNI на клиенте

• Используйте tcpdump или Wireshark, чтобы увидеть реальный SNI. Если он не совпадает, исправьте настройки клиента.

Заключение

Выбор и проверка serverName — фундамент стабильной работы REALITY. Потратьте 10 минут на диагностику, чтобы избежать недели проблем. Актуальные параметры всегда сверяйте с официальной документацией вашего клиента и ядра (Xray, sing-box).