Коротко — TLS‑handshake означает, что на этапе установления защищённого TLS‑соединения клиент и сервер не договорились о параметрах шифрования и/или не прошла проверка сертификата. Причин для этого много; ниже — наиболее вероятные и как их проверять/исправлять.
Что проверить в первую очередь
1. Сертификат и SNI
- Проверьте, что в настройках сервера используется корректный полный цепной сертификат (fullchain) и приватный ключ.
- Проверьте, что клиент запрашивает тот же домен (SNI), для которого выдали сертификат. Если в профиле указан IP вместо домена — TLS обычно не пройдет.
- Проверьте срок действия сертификата (не просрочен ли).
2. Время на сервере и клиенте
- Сильный сдвиг времени (несинхронизированные часы) ломает проверку сертификата. На сервере: date или timedatectl status.
3. Совместимость TLS/версий/шифров
- Если сервер или клиент жестко настроены на TLS1.3 или на набор шифров, а другая сторона этого не поддерживает — handshake может срываться. Обновите ПО до актуальной версии или скорректируйте конфиг.
4. Неправильный профиль (несовпадение протокола)
- Убедитесь, что тип проксирования (vmess/vless/trojan/ws/grpc и т. п.), путь для WebSocket, host/ALPN и порт в профиле клиента точно соответствуют серверному конфигу. Несовпадение протокола часто ведёт к «TLS» ошибкам (например, настроен VLESS+TLS, а клиент пытается VMess без tls).
5. Сеть / брандмауэр / провайдер
- Переодические сбои могут быть из‑за блокировок/фильтрации (DPI), проблем у провайдера или нестабильной сети. Попробуйте подключиться с другой сети (мобильный интернет) или через VPN другого провайдера.
- Проверьте, не закрыт ли порт на сервере/маршрутизаторе/фаерволе.
6. Нагрузка/лимиты соединений/ресурсы сервера
- При нехватке ресурсов или ограничениях количества одновременных соединений tls рукопожатание может не проходить.
Как локально диагностировать (команды и проверки)
- Проверить сертификат/цепочку:
- openssl s_client -connect example.com:443 -servername example.com
(замените host/port на ваш)
- Посмотрите даты сертификата и цепочку (если openssl говорит о verify error — важная подсказка).
- Проверить резолв/маршрут:
- dig example.com
- ping/traceroute к IP
- Логи сервера (3‑xui / xray):
- Посмотрите журналы xray/3‑xui — там обычно появляется причина отказа TLS или ошибки соединения.
- Включите режим дебага, если нужно.
- На клиенте:
- Включите подробные логи в Happ (или другом клиенте) и приложите текст ошибки.
Типичные быстрые исправления
- Если срок действия сертификата истек — обновите/пересоздайте сертификат (Let's Encrypt и т.п.).
- Если в профиле использован IP — замените на домен и убедитесь, что SNI совпадает.
- Синхронизируйте время (ntpdate/chrony/systemd‑timesyncd).
- Убедитесь, что в серверной конфигурации указан fullchain, а не только сертификат сервера.
- Перезапустите сервис xray/3‑xui и проверьте логи.
- Обновите клиент Happ и серверное ПО до последних версий.
Что пришлите, если нужна помощь
- Точный текст ошибки из клиента (скрин или лог).
- Вывод openssl s_client -connect your_host:port -servername your_domain и результат.
- Логи сервера за время попытки соединения (xray/3‑xui).
- Конфигурацию TLS части сервера (анонсимизируйте ключи/пароли).
- Информацию: используемый протокол (vless/vmess/trojan), transport (tcp/ws/grpc), домен/порт.
Если пришлёте эти данные — помогу точнее определить проблему и подсказать конкретное исправление.