SNI: что это

Автор: Екатерина Лебедева, редактор раздела knowledge base
Проверил:: Артём Волков
Проверено:: 28 сентября 2026
Опубликовано:: 27 сентября 2026, обновлено 28 сентября 2026
Версия гайда:: 1.0

Коротко

SNI (Server Name Indication) — расширение TLS (RFC 6066), в котором клиент называет домен назначения в начале рукопожатия, ещё до шифрования. В ссылках Happ параметр sni указывает, какой домен сервер сверит с сертификатом или со списком Reality.

TLS появился, когда один IP-адрес с одним портом обычно обслуживал один сайт с одним сертификатом. SNI решил проблему нескольких доменов на одном адресе: клиент называет нужный домен прямо в первом сообщении рукопожатия, ClientHello, и сервер подбирает подходящий сертификат. В протоколах Xray-core параметр sni работает похоже: у VLESS, Trojan и VMess с TLS он должен совпадать с доменом сертификата, а в Reality — с одним из доменов из списка serverNames на сервере. У Hysteria2 sni нужен по той же причине, потому что TLS 1.3 встроен в его транспорт QUIC.

SNI — расширение протокола TLS (RFC 6066), в котором клиент называет домен назначения в самом начале рукопожатия, до того как соединение зашифровано. В ссылках Happ параметр sni задаёт, какое имя сервер сверит с сертификатом или списком доменов.

Суть термина

TLS изначально проектировался в расчёте на то, что один IP-адрес с одним портом обслуживает один сайт с одним сертификатом. Когда несколько доменов стали делить общий адрес — например, за одним балансировщиком или CDN, — понадобился способ сказать серверу, к какому именно домену обращается клиент, ещё до того, как выбран сертификат.

Для этого в TLS добавили расширение SNI (Server Name Indication), описанное в RFC 6066. Клиент передаёт нужный домен открытым текстом в самом первом сообщении рукопожатия — ClientHello, до того как стороны договорились о шифровании. Сервер читает это имя и подбирает подходящий сертификат или направляет соединение нужному обработчику.

В протоколах, которые поддерживает Xray-core, параметр sni используется для той же цели, но с разными последствиями при несовпадении. У VLESS, Trojan и VMess с обычным TLS он должен точно совпадать с доменом сертификата сервера — иначе рукопожатие не пройдёт. В Reality роль немного другая: значение sni сверяется со списком serverNames, который администратор задал на сервере, а не с настоящим сертификатом.

sni в разных протоколах Happ

Протокол	Что проверяется через sni
VLESS, Trojan, VMess с TLS	совпадение с доменом сертификата сервера
VLESS с Reality	совпадение с одним из значений в списке serverNames сервера
Hysteria2	совпадение с сертификатом сервера через встроенный в QUIC TLS 1.3
Shadowsocks, SOCKS5	не используется — TLS в этих протоколах нет

Параметр fp из uTLS fingerprint работает рядом с sni в том же TLS-рукопожатии, но отвечает за другую часть — форму самого ClientHello, а не за домен назначения.

Как это выглядит в Happ

Параметр sni приходит в составе ссылки или подписки как часть настройки протокола с TLS.

Ссылка

trojan://password@example.com:443?security=tls&sni=example.com&type=tcp#Example

При ручном вводе поле sni находится среди параметров TLS: кнопка «+» вверху справа → «Ручной ввод» → протокол с TLS → заполнение полей → «Готово». Если значение не совпадает с сертификатом сервера или списком Reality, Happ, скорее всего, покажет ошибку TLS-рукопожатия — она же возникает при просроченном сертификате или неверном времени на устройстве.

Чем sni отличается от похожих терминов

TLS-рукопожатие — весь процесс установления защищённого соединения; sni — только одно поле внутри его первого сообщения.
Host (заголовок HTTP) — похожая по смыслу вещь, но уровнем выше: Host передаётся уже внутри зашифрованного HTTP-запроса, а sni — до шифрования.
Reality — использует sni не для поиска настоящего сертификата, а для сверки со списком доменов на сервере.
serverDescription — текст, который Happ показывает рядом с именем сервера в списке; к TLS и sni отношения не имеет.

Главное

SNI — часть TLS-рукопожатия, описанная в RFC 6066: клиент называет домен назначения до того, как соединение зашифровано.
В ссылках VLESS, Trojan, VMess с TLS и Hysteria2 параметр sni должен совпадать с доменом сертификата сервера.
В Reality sni — это одно из имён списка serverNames на сервере, а не домен настоящего сертификата.
Несовпадение sni с сертификатом или списком сервера приводит к ошибке TLS-рукопожатия, а не к тихому сбою без объяснений.
SNI работает на уровне TLS до расшифровки, а заголовок Host в HTTP — уже внутри зашифрованного запроса; это разные, хотя и похожие по смыслу поля.

Частые вопросы

Что произойдёт, если указать в sni случайный домен?

Сервер с обычным TLS попытается подобрать сертификат под названный домен и, скорее всего, не найдёт подходящего — рукопожатие завершится ошибкой. В Reality результат похож: если домена нет в списке serverNames сервера, аутентификация клиента не пройдёт. В обоих случаях Happ покажет обычный сбой соединения или ошибку TLS-рукопожатия, а не отдельное сообщение про sni.

Почему sni важен для Hysteria2, если это протокол на UDP?

Hysteria2 работает поверх QUIC, а TLS 1.3 встроен в QUIC как обязательная часть транспорта, а не отдельная надстройка. Поэтому клиенту всё равно нужно указать sni, совпадающий с сертификатом сервера, точно так же, как для TCP-протоколов с TLS. Разница только в транспорте снаружи — сам механизм проверки домена внутри рукопожатия остаётся тем же.

Обязательно ли значение sni совпадает с адресом сервера в ссылке?

Нет, и это не одно и то же поле. Адрес в ссылке — то, куда клиент физически подключается, например IP-адрес или домен через CDN, а sni — имя, которое проверяется в TLS-рукопожатии. Их специально разводят, когда сервер стоит за обратным прокси или CDN: подключение идёт на один адрес, а sni называет домен, на который выдан сертификат.

Чем sni отличается от serverNames в настройках Reality?

serverNames — список допустимых значений, который администратор задаёт на самом сервере Reality. sni — конкретное значение, которое клиент присылает в ссылке и которое должно входить в этот список. Формально это два разных поля на двух разных сторонах соединения, а не синонимы одного и того же.

Виден ли sni кому-то на пути соединения?

Да, по стандарту TLS расширение SNI передаётся в открытом виде в первом сообщении рукопожатия, ещё до того, как соединение зашифровано. Так работает, например, обычное разделение доменов на одном IP-адресе у CDN и хостингов. Это особенность самого протокола TLS, а не какая-то настройка Happ или Xray-core.

Нужен ли sni для протоколов без TLS, например Shadowsocks?

Нет, sni — параметр именно TLS-рукопожатия, а Shadowsocks и обычный SOCKS5 работают без TLS вовсе, поэтому такого параметра у них нет и в документации Happ он для этих протоколов не упоминается. Он актуален только там, где Xray-core сам устанавливает TLS-соединение: у VLESS, Trojan, VMess с TLS, в Reality и у Hysteria2 через встроенный в QUIC TLS 1.3.

Что делать, если Happ показывает ошибку TLS-рукопожатия и подозрение падает на sni?

Сверьте значение sni из ссылки с доменом сертификата сервера или со списком serverNames, если используется Reality, — опечатка здесь одна из частых причин ошибки. Также проверьте дату и время на устройстве: неверные часы делают любой сертификат недействительным независимо от sni. Подробный разбор возможных причин — на странице ошибки TLS-рукопожатия.

Упомянутые темы

Разделы по теме

Источники

RFC 6066: TLS Extensions — Server Name Indication — обращение 28 сентября 2026
Документация Happ: примеры ссылок и параметры — обращение 28 сентября 2026
Документация Xray: транспортная безопасность TLS — обращение 28 сентября 2026