Happ VPN

TLS-рукопожатие: что это

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

Коротко

TLS-рукопожатие — начальный обмен сообщениями между клиентом и сервером, во время которого стороны проверяют друг друга и договариваются о ключах шифрования, прежде чем пойдут первые данные. В Happ оно происходит перед тем, как Xray-core начнёт передавать трафик VLESS или Trojan через защищённый TLS-канал.

Рукопожатие — это несколько сообщений в самом начале TLS-соединения: клиент предлагает параметры и называет домен сервера, сервер отвечает выбранными параметрами и своим сертификатом, а затем обе стороны подтверждают, что готовы шифровать данные общим ключом. В современной версии TLS 1.3 это укладывается в один обмен сообщениями, тогда как более старая TLS 1.2 требовала на один обмен больше. Если на любом из шагов параметры клиента и сервера не совпали или сертификат не прошёл проверку, рукопожатие обрывается и соединение не устанавливается — именно на этом этапе Happ показывает ошибку TLS-рукопожатия.

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

Суть процесса

Прежде чем клиент и сервер начнут обмениваться зашифрованными данными по TLS, им нужно договориться о нескольких вещах: какую версию протокола использовать, каким набором алгоритмов шифровать данные и — самое важное — каким общим ключом. Этот предварительный обмен сообщениями и называется TLS-рукопожатием.

Кроме согласования ключей, рукопожатие решает вторую задачу — проверку подлинности сервера. Сервер предъявляет сертификат, а клиент сверяет его с доменным именем, которое сам же назвал в начале рукопожатия через параметр SNI. Если сертификат просрочен, выдан на другой домен или подписан неизвестным центром, рукопожатие прерывается.

Пока рукопожатие не завершено, никакие полезные данные — будь то содержимое сайта или трафик VLESS внутри TLS-туннеля — не передаются. Это защищает от ситуации, когда данные уходят на сервер, чья подлинность ещё не подтверждена.

Шаги рукопожатия

В действующей версии протокола, TLS 1.3, рукопожатие укладывается в короткую последовательность сообщений:

ШагЧто происходит
ClientHelloКлиент называет поддерживаемые версии TLS, наборы шифров, домен сервера (SNI) и сразу предлагает материал для будущего ключа
ServerHello + сертификатСервер выбирает параметры, присылает сертификат и подтверждает владение закрытым ключом
Проверка и FinishedКлиент проверяет сертификат, обе стороны вычисляют общий ключ и обмениваются короткими сообщениями о готовности
ДанныеНачинается передача уже зашифрованного трафика поверх согласованного канала

Более ранняя версия, TLS 1.2, устроена похоже, но требует дополнительного обмена сообщениями для согласования шифронабора отдельно от обмена ключами — поэтому рукопожатие в целом занимает на один раунд больше.

Как это происходит в Happ

Когда Happ подключается к серверу с TLS или Reality в качестве защиты канала, Xray-core сначала устанавливает обычное TCP-соединение, а затем — прежде чем передать хоть один байт протокола VLESS, VMess или Trojan — проводит TLS-рукопожатие с сервером.

Параметры ссылки Happ напрямую влияют на то, как выглядит это рукопожатие: sni задаёт домен, который клиент называет на первом шаге, а fp определяет набор технических деталей самого сообщения ClientHello, повторяющий поведение конкретного браузера. Для Reality проверка на этом же этапе идёт не по сертификату, а по публичному ключу и короткому идентификатору из настроек сервера.

Если что-то не совпало — домен, время на устройстве, сертификат или вмешательство программы на пути трафика, — рукопожатие обрывается, и приложение показывает ошибку TLS-рукопожатия. Разбор конкретных причин этой ошибки и порядок диагностики собраны на отдельной странице — здесь описан сам процесс, который не удалось завершить.

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

TLS-рукопожатие — лишь один из этапов внутри более широкого понятия TLS, и его стоит отличать от соседних терминов.

ТерминЧто этоОтличие от рукопожатия
TLSПротокол защиты соединения целикомРукопожатие — только его начальный этап, а не весь протокол
SNIДомен сервера в первом сообщенииОдин из параметров, которые передаются во время рукопожатия
Рукопожатие QUIC (Hysteria2)Согласование транспорта и TLS 1.3 одним обменомУ Hysteria2 нет отдельного TLS-рукопожатия поверх TCP — оно встроено в само рукопожатие QUIC
Ошибка TLS-рукопожатияСообщение Happ о незавершённом рукопожатииСледствие проблемы на этом этапе, а не сам процесс

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

Главное

  • TLS-рукопожатие — обмен сообщениями до передачи данных: клиент и сервер проверяют друг друга и договариваются об общем ключе шифрования.
  • В TLS 1.3 рукопожатие короче, чем в более старой TLS 1.2: меньше обменов сообщениями нужно, чтобы начать передачу данных.
  • Сертификат сервера и совпадение домена в параметрах SNI и sni проверяются именно во время рукопожатия, до появления первых байт полезных данных.
  • У Hysteria2 отдельного TLS-рукопожатия нет: протокол построен на QUIC, где проверка сертификата и согласование транспорта происходят одним объединённым обменом.
  • Если рукопожатие не завершилось — из-за сертификата, времени на устройстве или вмешательства сети, — Happ показывает отдельную ошибку TLS-рукопожатия ещё до попытки передать данные.

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

Что именно происходит во время TLS-рукопожатия?

Клиент отправляет сообщение ClientHello: какие версии TLS и наборы шифров он поддерживает, домен сервера в параметре SNI и случайное число для будущих ключей. Сервер отвечает выбранными параметрами, своим сертификатом и доказательством того, что владеет соответствующим закрытым ключом. Клиент проверяет сертификат, обе стороны вычисляют общий ключ шифрования, и после короткого подтверждения начинается передача уже зашифрованных данных.

Почему TLS-рукопожатие в TLS 1.3 проходит быстрее, чем в TLS 1.2?

TLS 1.3 убрал часть промежуточных сообщений: клиент сразу предлагает материал для ключа вместе с первым сообщением, и сервер может ответить с готовым набором данных за один обмен. TLS 1.2 требовал дополнительного раунда согласования шифронабора перед обменом ключами. На практике разница в одно-два сетевых обращения, что особенно заметно на медленных или дальних соединениях.

Чем рукопожатие Reality отличается от обычного TLS-рукопожатия?

На уровне сети сообщения выглядят как обычное TLS-рукопожатие к постороннему настоящему сайту. Разница — в проверке: вместо сверки сертификата, подписанного удостоверяющим центром, сервер и клиент используют собственный публичный ключ и короткий идентификатор, заданные в настройках Reality. Подробнее о том, как это устроено, — на странице [Reality](/glossary/reality).

Где в цепочке подключения Happ происходит TLS-рукопожатие?

Оно идёт сразу после того, как установлено TCP-соединение с сервером, и до того, как Xray-core начнёт передавать данные VLESS, VMess или Trojan через защищённый канал. Если рукопожатие успешно, дальше идёт уже сам протокол прокси поверх зашифрованного соединения; если нет — до протокола дело не доходит вовсе.

Есть ли отдельное TLS-рукопожатие у Hysteria2?

Отдельного, растянутого во времени TLS-рукопожатия у Hysteria2 нет: протокол построен на QUIC, где транспортное согласование и проверка TLS 1.3 объединены в один обмен, а не идут друг за другом, как при TLS поверх TCP. Это одна из причин, почему Hysteria2 быстрее устанавливает соединение на сетях с высокой задержкой.

Что происходит, если TLS-рукопожатие не завершилось?

Соединение обрывается на этом этапе, и до передачи данных дело не доходит вообще — сервер и клиент не успели согласовать общий ключ шифрования. В Happ это показывается как отдельная ошибка TLS-рукопожатия. Разбор конкретных причин — сертификат, время на устройстве, вмешательство сети — и порядок действий собраны на странице [этой ошибки](/errors/tls-handshake).

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

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

Источники

  1. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — обращение 28 сентября 2026
  2. Документация Happ: ошибки приложения — обращение 28 сентября 2026
  3. Документация Happ: Hysteria2 — обращение 28 сентября 2026