Hysteria2 и QUIC: плюсы и подвохи

Hysteria2 — второй транспорт, который я держу почти на каждой ноде. Он про другое, чем Reality: не про маскировку, а про то, чтобы канал жил на потерях и на мобильных, где TCP задыхается. Разбираю, за счёт чего он быстрый и где подвохи. Поднять и подцепить к панели — в парной практике.

Зачем вообще второй транспорт на UDP

Reality на TCP — отличный основной канал, но у TCP есть врождённая слабость: на плохих сетях он деградирует. Стоит появиться потерям пакетов (мобильный интернет, перегруженный канал в прайм-тайм, слабый Wi-Fi), как TCP начинает притормаживать — его алгоритм считает потерю сигналом перегрузки и сбрасывает скорость. Плюс в некоторых сетях именно TCP-профиль душат целенаправленно, а UDP при этом ещё летит.

Hysteria2 — ответ на обе беды. Это протокол поверх QUIC (транспорт на базе UDP), заточенный ровно под то, чтобы держать скорость там, где TCP сдаётся. Я держу его вторым транспортом на ноде именно как «кнопку на крайний случай»: вечер, мобайл, TCP затупил — переключаешься на Hysteria, и часто оно ещё едет.

За счёт чего он быстрый

Ключевое слово — агрессивный конгешн-контроль (BBR). Обычный TCP при потере пакета паникует и режет скорость, предполагая, что канал забит. BBR устроен иначе: он измеряет реальную пропускную способность и задержку канала и держит скорость исходя из них, а не пугается каждой потери. На каналах с потерями это даёт огромную разницу — там, где TCP просел бы вдвое, Hysteria продолжает качать почти на полной.

Плюс сам QUIC поверх UDP не страдает от «head-of-line blocking», которым мучается TCP: потеря одного пакета не тормозит весь поток. В сумме получается протокол, который на плохих сетях выигрывает у TCP заметно, а на хороших идёт вровень. Отсюда его ниша: мобильные сети, потери, перегруженные каналы, прайм-тайм.

По маскировке он средний: снаружи это TLS-over-QUIC (ALPN h3), то есть выглядит как HTTP/3-трафик. Это не стелс уровня Reality, но и не голый прокси — под большинство сетей проходит.

Подвох первый: UDP режут

Главная засада, о которой надо знать сразу. Hysteria — это UDP, а UDP в некоторых сетях режут целиком или частично. Провайдер может душить UDP на 443-м порту, файрвол может его не пропускать, мобильный оператор может ограничивать. Поэтому Hysteria — не замена TCP-Reality, а дополнение: там, где UDP проходит, она спасает; там, где UDP закрыт, работает основной TCP-канал. Держать нужно оба, и клиенту отдавать подписку, где есть и то и другое, чтобы был авто-фейловер.

Практический момент: под Hysteria нужно явно открыть UDP/443 в файрволе и убедиться, что провайдер ноды его не режет. Забыл открыть UDP — протокол просто не заведётся, и будешь искать причину не там.

Подвох второй: панель может не считать трафик

Это грабли, на которых легко потерять день, если не знать. В связке с панелью Remnawave есть тонкость с версией Xray-ядра. На старых сборках ядра панель не видит Hysteria-юзера онлайн и не считает его трафик — то есть протокол работает, клиент подключён и качает, а в панели по нему ноль: ни онлайна, ни расхода. Для платного сервиса это критично — ты не видишь потребление и не можешь применить лимиты.

Причина — баг в конкретных версиях ядра, поправленный в более свежих. Лечится подменой Xray-ядра на ноде на достаточно новую версию. Это не «настройка Hysteria», а обязательный сопутствующий шаг, без которого учёт по Hysteria не работает. В практике я показываю, как именно подменить ядро.

Подвох третий: клиент должен получить конфиг правильно

Ещё одна тонкость доставки. Hysteria — не Xray-протокол в привычном смысле, и некоторые клиенты показывают его в подписке только если подписка отдаётся в формате JSON, а не в base64-списке ссылок. Если этого не сделать, клиент увидит VLESS-хосты, а Hysteria в списке не окажется — при том что на сервере всё поднято корректно. То есть протокол может быть настроен идеально, но не долететь до клиента из-за формата подписки. Об этом тоже в практике — там конкретный переключатель в настройках панели.

Как принять решение

Сведу к операторскому чек-листу:

• Ставь Hysteria2 вторым транспортом почти на каждую ноду — это дешёвая страховка на случай плохих сетей и душения TCP.
• Не делай её единственной — UDP режут, нужен TCP-Reality как основа.
• Проверь версию ядра на ноде, иначе трафик не посчитается.
• Отдавай подписку JSON-ом, иначе клиент Hysteria не увидит.

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