Hysteria2 или TUIC: что выбрать для обхода DPI

MAATRIX

Оба протокола работают поверх QUIC — того же транспорта, что и HTTP/3 у половины крупных сайтов, и оба заточены под одну задачу: пробить DPI там, где WireGuard уже режут по сигнатуре. Разница в деталях — как каждый маскируется, как ведёт себя на нестабильном канале и насколько просто его поднять и обслуживать. Ниже — честное сравнение Hysteria2 и TUIC без общих слов, чтобы выбор был по вашему сценарию, а не по хайпу вокруг протокола.

Коротко: что выбрать

Если нужна максимальная устойчивость к активному зондированию портов и минимум телодвижений при настройке — берите Hysteria2. У него из коробки есть маскировка под реальный сайт (masquerade) и собственный congestion control Brutal, заточенный под жёсткие потери пакетов.

Если важнее гибкость UDP-релея (игры, голос, WebRTC поверх туннеля) и вы готовы сами закрыть вопрос с маскировкой TLS через нормальный домен — TUIC даёт более лёгкий протокол с быстрым переподключением и явным выбором алгоритма борьбы с перегрузкой (BBR, cubic, new_reno). Он менее раскручен, а значит и менее изучен со стороны систем блокировки — это может быть как плюсом, так и временным окном, которое рано или поздно закроется.

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

Сравнительная таблица

Таблица показывает главное: Hysteria2 закрывает вопрос маскировки и обфускации сам, TUIC делает ставку на минимализм протокола и гибкость сетевых настроек. Дальше — почему это так и что из этого следует на практике.

Как оба протокола обходят DPI

Базовый принцип у обоих один: спрятаться внутри QUIC-трафика, который DPI не может просто заблокировать оптом — иначе отвалится половина современного веба на HTTP/3. Дальше начинаются различия.

Hysteria2 умеет отвечать на обычный HTTP-запрос без валидных учётных данных как настоящий сайт-прокси (параметр masquerade в конфиге сервера) — если DPI или живой человек зайдёт на порт браузером, получит чужую страницу, а не признак VPN-сервера. Плюс встроенная обфускация Salamander усложняет активное зондирование, когда система сама стучится в порт и по паттерну ответа определяет протокол.

TUIC такой встроенной маскировки не имеет. Его защита — обычный TLS-хендшейк с настоящим сертификатом на реальном домене: снаружи это выглядит как HTTPS/QUIC-сессия к легитимному серверу, но при активном зондировании (не HTTP-запрос, а попытка достучаться по протоколу TUIC на порт) сервер либо отвечает специфично для TUIC, либо не отвечает вовсе — второе тоже может быть подозрительным сигналом для продвинутых систем анализа. На практике это означает: для TUIC домен и валидный сертификат — не опция, а фактическая необходимость для нормальной маскировки, тогда как у Hysteria2 можно закрыть вопрос и без домена, через self-signed сертификат под чужой SNI.

Оговорка, которая касается обоих: DPI-технологии не стоят на месте, и нет протокола с гарантией «навсегда неубиваем». Если провайдер блокирует не по сигнатуре протокола, а по диапазону IP дата-центров, ни Hysteria2, ни TUIC не помогут — тут нужна смена сервера или локации, а не смена протокола. Если вы ещё не определились в принципе, посмотрите гид по выбору протокола VPN по сценариям — там оба варианта разложены рядом с WireGuard и VLESS Reality.

Скорость и congestion control

Здесь протоколы расходятся по философии. Hysteria2 использует Brutal — алгоритм, который не снижает скорость агрессивно при первых потерях пакетов, а держит темп исходя из заявленной в конфиге полосы (bandwidth.up/bandwidth.down). Это удобно на линиях с шейпингом или искусственной деградацией QUIC у части провайдеров: Brutal просто «прёт» с заданной скоростью, не откатываясь панически при единичных потерях.

TUIC не навязывает свой алгоритм, а даёт выбрать: BBR обычно ведёт себя похоже на Brutal по агрессивности на нестабильных каналах, cubic и new_reno — более классическое, консервативное поведение, знакомое по обычному TCP. Разница в том, что TUIC перекладывает настройку на вас — можно подобрать алгоритм под конкретный канал, но по умолчанию решение придётся принять самому, а не полагаться на готовую пресет-стратегию.

Отдельно у TUIC заметно быстрое переподключение за счёт архитектуры на базе QUIC-библиотеки quinn — 0-RTT resumption сокращает время повторного хендшейка при обрыве и восстановлении сети. Для мобильных сценариев (переключение Wi-Fi на мобильный интернет) это ощутимо на глаз.

Точных цифр по скорости и задержке здесь намеренно не даём — оба протокола сильно зависят от канала, дистанции до сервера, загрузки CPU и настроек congestion control. Любые «X Мбит/с быстрее» без указания конкретного стенда — маркетинг, а не инженерный факт. Если для вас критична сама тема QUIC-транспорта и типичные проблемы с ним на уровне сети, есть отдельный разбор частых ошибок HTTP/3 и QUIC на сервере — многое из него применимо и к Hysteria2, и к TUIC, поскольку оба сидят на одном транспорте.

Настройка и модель аутентификации

Hysteria2 ставится одной командой через официальный скрипт (bash <(curl -fsSL https://get.hy2.sh/)), который сам разворачивает systemd-юнит и определяет архитектуру. Конфиг — один YAML-файл, аутентификация по паролю, встроенный ACME для Let's Encrypt при наличии домена. Мы уже разбирали это пошагово в статье про установку Hysteria2 на Ubuntu 24.04 — если решите остановиться на нём, весь путь от чистого сервера до рабочего клиента там расписан по шагам.

TUIC чаще всего разворачивают либо через официальный tuic-server (тоже бинарник и systemd, но без единого установочного скрипта уровня Hysteria2 — сертификаты и юнит настраиваются вручную), либо через sing-box, который умеет TUIC как один из inbound-протоколов наравне с VLESS, Shadowsocks и другими — это удобно, если вы уже используете sing-box как универсальную точку входа и не хотите держать отдельный процесс под каждый протокол.

Модель аутентификации у TUIC — UUID плюс пароль, а не просто пароль. Пример фрагмента серверного конфига TUIC (в формате, который принимает tuic-server):

{
  "server": "0.0.0.0:443",
  "users": {
    "3aa02ec4-1d38-4b18-9ff0-9f8b0d6e7c1a": "ЗАМЕНИТЕ_НА_ДЛИННЫЙ_ПАРОЛЬ"
  },
  "certificate": "/etc/tuic/cert.pem",
  "private_key": "/etc/tuic/key.pem",
  "congestion_control": "bbr",
  "udp_relay_mode": "native",
  "zero_rtt_handshake": true
}

UUID здесь — не декоративная деталь: он даёт удобное разграничение пользователей без городить отдельный webhook-механизм, как это приходится делать в Hysteria2 для мультипользовательских сценариев (auth.type: http). Если у вас одно устройство — разница не критична, для десятка пользователей с учётом трафика по каждому UUID выигрывает нагляднее.

UDP-relay и нестандартные сценарии

У TUIC есть параметр udp_relay_mode с двумя значениями: native — сырые UDP-пакеты пробрасываются через QUIC как есть, минимальные накладные расходы, но чувствительность к потерям такая же, как у обычного UDP; quic — каждый UDP-пакет заворачивается в надёжный QUIC-поток, расходы выше, зато устойчивость к потерям и переупорядочиванию лучше. Для игр и голосовой связи, где важна низкая задержка больше, чем гарантия доставки каждого пакета, обычно берут native; для приложений, чувствительных к порядку и целостности данных поверх UDP — quic.

У Hysteria2 такого явного переключателя режимов UDP-релея нет — он передаёт UDP через свой протокол с фиксированным поведением, которое неплохо себя чувствует по умолчанию, но не даёт той же тонкой настройки под конкретный тип трафика.

Если ваш сценарий — не просто «браузер и мессенджеры», а что-то чувствительное к джиттеру (потоковые игры, VoIP, RDP через туннель), эта гибкость TUIC может оказаться решающей. Для более общего сценария с RDP через шифрованный канал у нас есть отдельная статья про безопасный доступ по RDP через WireGuard — принципы задержки и джиттера там применимы независимо от конкретного протокола туннеля.

Когда что выбирать на практике

Берите Hysteria2, если: нужен быстрый старт без ручной возни с сертификатами и юнитами, важна встроенная маскировка под сайт без домена (self-signed + SNI-подмена), канал сильно шейпится провайдером и нужен агрессивный Brutal, который не «сдаётся» при первых потерях, или вы просто хотите один готовый скрипт установки и не планируете тонко тюнинговать congestion control.

Берите TUIC, если: у вас уже есть нормальный домен с валидным сертификатом и маскировка через masquerade не критична, важна низкая задержка и быстрое переподключение при смене сети, нужен явный выбор congestion control под конкретный канал (BBR против cubic), или вы обслуживаете несколько пользователей и хотите разграничение через UUID без внешнего webhook.

В обоих случаях фундамент один — сервер с белым выделенным IP и открытым UDP-портом, который не заблокирован на уровне подсети дата-центра. Здесь принципиальной разницы между протоколами нет: у MAATRIX VPS с чистыми IP в локациях RU, US и UK, оплата из России картой или криптой. Для доступа к зарубежным сервисам логичнее брать US или UK, для минимальной задержки внутри России — RU; выбор протокола на выбор локации не влияет, а вот качество и репутация IP-диапазона — влияет на оба протокола одинаково сильно.

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