Hysteria2: частые ошибки и решения

MAATRIX

Hysteria2 настроен по инструкции, но клиент либо не подключается вовсе, либо соединение то работает, то обрывается каждые пару минут. Протокол построен на QUIC поверх UDP, и это одновременно его сила — трафик быстрый и хорошо переживает потери пакетов — и источник специфичных проблем, которых не бывает у TCP-протоколов. Разберём частые ошибки Hysteria2 по порядку: от сертификата до расхождения версий клиент-сервер.

С чего начать диагностику

Прежде чем разбирать конкретные симптомы, проверьте базовые вещи на сервере. Убедитесь, что служба запущена:

systemctl status hysteria-server.service

Если сервис в состоянии failed или постоянно перезапускается, причина почти всегда в конфиге — смотрите последние строки лога:

journalctl -u hysteria-server -n 80 --no-pager

Hysteria2 при старте пишет в лог конкретную причину падения: неверный YAML, недоступный порт, проблема с сертификатом. У бинарника нет отдельного режима проверки конфига как у Xray, поэтому проще всего временно остановить службу и запустить сервер вручную в терминале:

hysteria server -c /etc/hysteria/config.yaml

Так вы сразу увидите ошибку в реальном времени, не копаясь в journalctl. Проверьте и то, что порт действительно слушается — но помните: Hysteria2 работает по UDP, а не TCP, поэтому ss -tlnp тут бесполезен:

ss -ulnp | grep hysteria

Если процесс не слушает нужный UDP-порт — дело в конфиге или в правах на bind (порты ниже 1024 требуют root или setcap). Если слушает — переходите к следующим разделам, там разобраны конкретные симптомы.

Проблемы с сертификатом

Самая частая причина, по которой сервер вообще не стартует или клиент получает ошибку TLS — сертификат. У Hysteria2 два сценария: автоматический ACME (Let's Encrypt) и собственный сертификат.

ACME не выпускается. Если в конфиге указан блок acme с доменом, для выпуска сертификата серверу нужен доступ к порту 80 (или настроенный DNS-01) и корректная A-запись домена на IP сервера. Типичные причины отказа:

• Порт 80 занят другим веб-сервером или закрыт firewall — ACME HTTP-01 challenge не проходит.
• Домен не резолвится на IP сервера, либо DNS ещё не обновился (проверьте dig +short ваш-домен).
• Превышен rate limit Let's Encrypt — при частых пересозданиях сертификата для одного домена (лимит около 5 попыток в неделю на домен) сервер получит отказ и продолжит пытаться при каждом рестарте.

Логи ACME видно в том же journalctl -u hysteria-server. Если лимит исчерпан — либо ждите, либо временно переключитесь на собственный сертификат.

Свой сертификат не принимается клиентом. Если вы используете самоподписанный сертификат вместо ACME, клиент по умолчанию его отклонит. Нужно явно указать в конфиге клиента insecure: true (для тестов) либо, правильнее, зафиксировать отпечаток через pinSHA256:

tls:
  sni: example.com
  pinSHA256: "AA:BB:CC:..."

Отпечаток сертификата сервера можно получить командой openssl x509 -in cert.pem -noout -fingerprint -sha256. Если после смены сертификата на сервере (например, после обновления Let's Encrypt) клиент вдруг перестал подключаться — сверьте, не устарел ли зафиксированный pinSHA256. Подробнее о типовых граблях самого Let's Encrypt — в статье Let's Encrypt SSL на сервере: частые ошибки и решения, логика применима и здесь.

Провайдер блокирует или душит UDP

Это отдельный класс проблем, характерный именно для Hysteria2 и любых QUIC-протоколов: соединение работает дома, но не работает в офисе, в мобильной сети или у части пользователей — при абсолютно рабочем сервере.

Причина в том, что UDP-трафик на нестандартных портах многие сети режут или сильно ограничивают по скорости (throttling), особенно:

• Корпоративные и учебные сети с жёсткими firewall-политиками — там часто разрешён только TCP 80/443.
• Мобильные операторы в некоторых регионах намеренно приоритизируют TCP над UDP или режут UDP на нестандартных портах.
• Домашние роутеры с включённым QoS иногда занижают приоритет UDP-пакетов, из-за чего Hysteria2 работает, но с большими задержками.

Как проверить, что дело именно в этом: попробуйте подключиться с другой сети (мобильный интернет через другого оператора, другой Wi-Fi). Если там всё работает — проблема на стороне конкретной сети клиента, а не сервера. Проверить доступность UDP-порта снаружи можно так:

nc -u -zv IP_СЕРВЕРА 443

Способы обойти блокировку или троттлинг UDP:

• Порт 443. Если Hysteria2 у вас слушает нестандартный UDP-порт, переключите на 443/udp — многие фильтры пропускают UDP именно на этом порту охотнее, ассоциируя его с QUIC от HTTP/3-сайтов.
• Обфускация Salamander. Встроенный obfs маскирует характерную сигнатуру QUIC-пакетов Hysteria2, из-за которой некоторые DPI-системы отличают протокол от обычного HTTP/3-трафика:

obfs:
  type: salamander
  salamander:
    password: ваш_пароль

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

• Полная блокировка UDP. Если сеть режет UDP целиком (бывает в некоторых мобильных и корпоративных сетях), Hysteria2 в принципе не пройдёт — протокол не имеет TCP-режима. В этом случае разумнее держать запасной сервер с TCP-протоколом вроде VLESS Reality или WireGuard через TCP-обвязку. Как проверить, какие порты вообще открыты на сервере и не режет ли что-то ваш собственный firewall — в статье открытые порты на сервере: как проверить и закрыть.

Обрывы соединения и нестабильность

Канал подключается, но рвётся каждые несколько минут или скорость плавает. Здесь чаще всего виноваты параметры пропускной способности и качество маршрута, а не сам протокол.

Неверно указанная полоса пропускания. Hysteria2 использует congestion control BBR/Brutal, и ему для расчётов нужны реалистичные значения up/down в конфиге клиента:

bandwidth:
  up: 50 mbps
  down: 100 mbps

Если указать значения сильно завышенные относительно реального канала, протокол будет слать больше данных, чем канал способен пропустить, получит массовые потери пакетов и начнёт агрессивно ретрансмитить — со стороны это выглядит как рваная скорость и разрывы. Указывайте реальную полосу канала (можно с небольшим запасом), а не «сколько хотелось бы».

MTU и фрагментация. QUIC чувствителен к MTU по пути: если где-то на маршруте (VPN-провайдер, туннель, мобильная сеть) MTU меньше стандартных 1500 байт, крупные пакеты фрагментируются или теряются. Проверить путь можно так:

ping -M do -s 1472 IP_СЕРВЕРА

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

Ресурсы сервера. При большом числе одновременных клиентов на слабом VPS шифрование и обработка QUIC съедают CPU. Посмотрите нагрузку через top или htop — если процессор постоянно упирается в потолок, точечных настроек протокола уже не хватит, нужен более производительный тариф.

Несовпадение версий клиента и сервера

Hysteria2 развивается быстро, и протокол между мажорными версиями иногда меняется не полностью совместимо. Если сервер обновили, а клиент остался старым (или наоборот), можно получить самые разные симптомы: от «visible auth failed» без пояснений до просто зависающего подключения без единой ошибки в логах.

Проверьте версии на обеих сторонах:

hysteria version

На клиенте команда та же (или пункт «О программе» в GUI-клиентах вроде NekoBox, v2rayN, Hiddify). Если версии разошлись на несколько релизов — сначала попробуйте обновить обе стороны до актуальных, а если старая версия критична (например, зависит от старого клиента на слабом устройстве), проверьте changelog проекта на предмет breaking changes именно в протокольной части, а не только в CLI-флагах.

Отдельно стоит проверять после автообновлений: если на сервере настроен автоматический апдейт пакета, а клиенты у пользователей обновляются вручную, расхождение версий — частая причина внезапных «все отвалились одновременно» жалоб, которые на первый взгляд выглядят как проблема сети.

Ошибка авторизации и masquerade

Если сервер запущен, порт слушается, сертификат в порядке, а клиент получает явную ошибку авторизации — проверяйте пароль в блоке auth. В отличие от UUID у Xray, здесь обычно используется простая строка, и опечатка в одном символе даёт чёткий отказ, а не тихое зависание:

auth:
  type: password
  password: ваш_пароль

Сверяйте значение посимвольно, лучше копированием, чем набором вручную. Второй момент, который часто путают с ошибкой авторизации — неправильно настроенный masquerade. Этот блок отвечает за то, что видит посторонний, если зайдёт на ваш сервер обычным браузером напрямую по HTTPS — Hysteria2 в этом случае должен отдать содержимое обычного сайта, а не ошибку:

masquerade:
  type: proxy
  proxy:
    url: https://example.com
    rewriteHost: true

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

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