Hysteria2: ошибка сертификата и SNI — что проверить

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

Почему SNI и сертификат критичны для Hysteria2

Hysteria2 использует TLS для шифрования трафика и маскировки под обычное HTTPS-соединение. SNI (Server Name Indication) — это имя сервера, которое клиент отправляет в начале TLS-рукопожатия. Если SNI не совпадает с сертификатом, рукопожатие обрывается. Поэтому первое, что проверяют при ошибке — соответствие имени в конфигурации и фактического домена сервера.

Протокол Hysteria2, работающий поверх QUIC, ведёт себя так же, как браузер: он проверяет действительность сертификата и его цепочку. Отключение этой проверки снижает безопасность и делает возможным атаку «человек посередине». Но иногда insecure-режим применяют намеренно, например, когда сертификат самоподписанный. Об этом мы поговорим отдельно.

С чего начать диагностику: собираем факты

Перед проверкой зафиксируйте точный текст ошибки. В клиенте Hysteria2 она обычно выглядит как tls: failed to verify certificate: x509: certificate is valid for example.com, not your.domain.com или содержит certificate signed by unknown authority. Сверьте, какой адрес вы указали в конфигурации клиента и какой сертификат выдал сервер. Часто несоответствие в одну букву (поддомен вместо домена) ломает всё.

Если у вас есть доступ к серверу, выполните простую проверку: openssl s_client -connect your.server:443 -servername your.server -showcerts. Эта команда покажет цепочку сертификатов и статус проверки. Обратите внимание, что Hysteria2 по умолчанию использует порт 443, но порт может быть изменён. Подставьте свой порт, если он нестандартный.

Проверяем домен и цепочку сертификата

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

Проверьте, что сертификат не просрочен и что промежуточные сертификаты отданы сервером. Если конфигурация веб-сервера (например, Nginx или Caddy) настроена неправильно, клиент может получить только конечный сертификат без цепочки. В этом случае используйте openssl s_client и посмотрите, полная ли цепочка. В ответе команды должно быть на один сертификат больше, чем конечный, если есть промежуточные.

Также убедитесь, что домен действительно указывает на IP вашего сервера. Если DNS только обновился, подождите немного. Проверить можно с помощью dig your.domain или nslookup.

Системное время: невидимая причина

ТLS-проверка критически зависит от времени на клиенте. Если часы отстают или спешат более чем на пару минут, сертификат может быть признан недействительным. Особенно это распространено на серверах без автоматической синхронизации времени.

На Linux время проверяют командой timedatectl. Если время неправильное, включите синхронизацию: timedatectl set-ntp true. На Windows откройте «Параметры» → «Время и язык» и включите автоматическую синхронизацию. На Android и iOS также используйте автоматическое определение времени.

Self-signed и insecure: когда это допустимо

Если вы используете самоподписанный сертификат, клиент Hysteria2 по умолчанию будет отвергать его. Есть два пути: добавить сертификат в доверенные на устройстве или включить режим insecure: true в конфигурации. Последний вариант удобен для тестов, но небезопасен для постоянного использования.

Внимание: при insecure: true вы полностью отключаете проверку подлинности сервера. Атакующий, контролирующий сеть, может подменить сервер и перехватить трафик. Если вы всё же включаете этот режим, делайте это только на короткий срок, а лучше настройте корректный сертификат через Let's Encrypt.

Также важно правильно указать SNI. Даже в insecure-режиме SNI используется для маршрутизации и маскировки. Если SNI не совпадает с фактическим именем, некоторые firewall могут блокировать соединение. Указывайте реальный домен, даже если проверка отключена.

Частые ошибки при настройке

Среди типичных ошибок:

• Указан IP-адрес вместо домена в поле sni.
• Сертификат выпущен для домена без www, а в конфигурации написан www-поддомен.
• Порт для проверки сертификата указан неверно: если Hysteria2 слушает не на 443, то и SNI-проверка должна быть на этом же порту.
• Копирование конфигурации с примера без замены домена.
• Неверное время на устройстве, из-за чего сертификат считается недействительным.

Если вы используете один сервер для нескольких доменов, убедитесь, что в настройках выбран правильный сертификат на основе SNI. Проверить это можно на стороне сервера, посмотрев конфигурацию вашего прокси-сервера (например, Caddy автоматически делает это, но всё же советуем свериться с документацией вашего релиза).

Что дальше: связанные проблемы и логи

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

Не забывайте: логи клиента и сервера — ваш главный помощник. Включите подробное логирование и ищите строки, содержащие cert или tls. Там будет точная причина отказа.