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).
Упомянутые темы
Похожие материалы
Разделы по теме
Источники
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — обращение 28 сентября 2026
- Документация Happ: ошибки приложения — обращение 28 сентября 2026
- Документация Happ: Hysteria2 — обращение 28 сентября 2026