Hysteria 2: протокол, который притворяется HTTP/3 и почти не врёт / Habr

Разбор архитектуры, Brutal-алгоритма, Salamander-обфускации и честный ответ — почему это работает в 2026-м и при каких условиях падает.

Большинство статей про Hysteria 2 написаны по одному шаблону: «быстро, просто, ставится за 5 минут, вот конфиг». Это не такая статья.

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

Если тебе нужен гайд «скопируй конфиг и запусти» — закрывай вкладку. Если интересно почему это работает — читай дальше.

Фундамент: почему QUIC, а не TCP

Hysteria 2 построена поверх QUIC. Это не случайный выбор и не дань моде — это инженерное решение с конкретными последствиями.

QUIC (RFC 9000) — протокол транспортного уровня, разработанный Google и стандартизированный в 2021-м. Работает поверх UDP. Внутри реализует всё то, что раньше было в TCP + TLS: мультиплексирование потоков, контроль перегрузки, надёжная доставка, шифрование. HTTP/3 — это HTTP поверх QUIC.

Зачем это нужно для обхода блокировок?

TCP-соединение блокируется легко. Цензор видит SYN-пакет, решает что соединение подозрительное, посылает RST в обе стороны — всё, соединение разорвано. Дёшево, надёжно, работает годами.

С UDP история другая. UDP stateless: нет рукопожатия, нет установки соединения, нет очевидного «момента начала». Послать RST некуда. Чтобы заблокировать UDP-поток, надо либо заблокировать весь UDP на порту (грубо, с коллатеральными потерями), либо анализировать содержимое каждого пакета (дорого, с задержкой). Hysteria 2 эксплуатирует именно эту разницу в стоимости блокировки.

Но есть нюанс, к которому мы вернёмся.

Brutal: когда потери пакетов работают на тебя

Стандартные алгоритмы контроля перегрузки — BBR, CUBIC, Reno — при обнаружении потерь пакетов снижают скорость отправки. Логика: потери значат перегрузку сети, надо уступить.

Hysteria использует собственный алгоритм — Brutal.

Brutal работает наоборот. При обнаружении потерь он увеличивает скорость отправки, компенсируя потери избыточным количеством пакетов. Клиент объявляет серверу желаемую скорость получения (rx rate) при аутентификации. Сервер пытается её обеспечить любой ценой — в том числе через избыточную отправку с расчётом на то, что часть пакетов доберётся.

Это полезно в двух сценариях:

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

Искусственные потери — некоторые провайдеры в Китае и России применяют rate limiting через намеренные потери пакетов вместо прямой блокировки. Brutal это ломает: провайдер дропает 30% пакетов, Hysteria просто отправляет в 1.4x больше.

Звучит агрессивно — потому что так и есть. На стороне сервера Brutal легко создаёт нагрузку на аплинк, которая заметна. При неправильной настройке bandwidth параметра сервер будет флудить канал независимо от реальной ситуации с сетью.

# Без этого Brutal не включается — используется BBR
bandwidth:
  up: 20 mbps
  down: 100 mbps

Маскировка: два режима с разной философией

Здесь начинается самое интересное — и самое часто неправильно понимаемое.

У Hysteria 2 два принципиально разных подхода к маскировке трафика. Они несовместимы между собой. И выбор между ними — это выбор между разными моделями угроз.

Режим 1: Masquerade (без obfs)

Сервер работает как настоящий HTTP/3 сервер. Если к нему подключиться браузером или curl — он отвечает. По умолчанию возвращает 404, но можно настроить реверс-прокси на реальный сайт.

masquerade:
  type: proxy
  proxy:
    url: https://www.bing.com
    rewriteHost: true

В этом режиме сервер буквально отдаёт страницы HackerNews любому, кто зайдёт на него браузером. DPI-система делает активное зондирование — получает валидный HTTP/3-ответ. Подозрений нет.

Слабое место: стандартный QUIC-трафик с правильными сертификатами и fingerprint всё равно имеет статистические отличия от трафика реального браузера. Межпакетные интервалы другие. Паттерн запросов другой. ML-классификатор это замечает — не сейчас, но в перспективе.

Режим 2: Salamander obfuscation

Salamander оборачивает QUIC-пакеты в дополнительный слой, который инжектирует рандомные «шумовые» пакеты рядом с легитимными данными (меняет структуру начала соединения) . Классификатор трафика не может построить надёжную статистическую моде��ь — данные слишком зашумлены.

textobfs:
  type: salamander
  salamander:
    password: your_obfs_password

Но есть критический момент из документации:
https://github.com/apernet/hysteria/discussions/1115

Enabling obfuscation will make your server incompatible with standard QUIC connections and it will no longer function as a valid HTTP/3 server.

С включённой Salamander сервер не отвечает на стандартные QUIC-запросы. Активное зондирование — молчание. Это само по себе подозрительно для продвинутых DPI-систем: сервер не говорит ни на одном известном протоколе.

Дилемма: masquerade без obfs — хорошая маскировка, но уязвим к статистическому анализу. Salamander с obfs — хаотичный трафик, но нет легенды при зондировании.

Правильный выбор зависит от того, против чего именно ты защищаешься. На большинстве российских провайдеров в 2026-м Salamander даёт лучший результат — ТСПУ активно детектирует QUIC-паттерны, и obfs на уровне Initial пакетов ломает эту детекцию раньше, чем она случается.

Port hopping: изящное решение, которое требует рук

Разработчики Hysteria заметили специфику китайского GFW: при детектировании подозрительного протокола блокируется не IP-адрес целиком, а пара IP+порт. Это даёт лазейку.

Port hopping — клиент прыгает между портами при неудачных соединениях. Важно понять архитектуру: сервер не слушает на диапазоне портов самостоятельно. Он слушает на одном порту (например 443), а диапазон настраивается через перенаправление на уровне iptables/nftables:

# nftables на сервере — обязате��ьно, без этого port hopping не работает
define INGRESS_INTERFACE = "eth0"
define PORT_RANGE = 20000-50000
define HYSTERIA_PORT = 443

table inet hysteria_porthopping {
  chain prerouting {
    typtexte nat hook prerouting priority dstnat; policy accept;
    iifname $INGRESS_INTERFACE udp dport $PORT_RANGE \
    counter redirect to :$HYSTERIA_PORT
  }
}

На клиенте нужна секция transport с hopInterval:

transport:
  udp:
    hopInterval: 30s  # минимум 5s, дефолт 30s

server: your.server.com:20000-50000

Важный практический момент: sing-box как клиент port hopping для Hysteria2 не поддерживает и поддерживать не планирует. Если используешь sing-box — эта фича недоступна. Нужен нативный hysteria2 клиент.

В российском контексте port hopping менее эффективен чем в Китае: ТСПУ блокирует по паттерну трафика, а не по IP+порт. Но против провайдеров, которые режут конкретные порты — работает.

Где Hysteria 2 ломается в 2026-м

Честная часть, которую обычно не пишут.

Проблема 1: QUIC-блокировки

Ряд российских провайдеров режет UDP трафик на 443 порту или замедляет QUIC в целом. Hysteria 2 в базовой конфигурации на таких провайдерах работает хуже TCP-based протоколов или не работает вообще. Это не баг — это фундаментальное ограничение UDP-based архитектуры. FakeTCP режим (когда UDP-пакеты маскируются под TCP-заголовки) теоретически решает эту проблему — но поддерживается только на Linux и требует root. На практике это не «включил и забыл» опция.

Проблема 2: аномальный bandwidth

Brutal генерирует трафик-паттерн, который статистически нетипичен для браузерного HTTPS. Постоянный высокий throughput без пауз, характерных для рендеринга страниц — это подпись. ML-классификатор, обученный на реальном HTTP/3 трафике браузеров, отличит Hysteria 2 от Chrome с хорошей точностью.

Проблема 3: obfs несовместимость

При включённом Salamander сервер не отвечает на стандартные запросы. Активное зондирование возвращает тишину. ТСПУ умеет интерпретировать молчание как подозрение — именно так детектируется часть Shadowsocks-серверов. Это не решённая проблема.

Неудобный вопрос без ответа

Hysteria 2 с Brutal работает отлично в нестабильных сетях с реальными потерями. Но в стабильной московской или питерской сети с низкими потерями — Brutal избыточен и создаёт аномальный трафик-паттерн.

Получается: сильнейшая фича протокола одновременно является его главной детектируемой сигнатурой при хорошем канале.

Я не знаю, как это правильно решить в рамках текущей архитектуры. Возможно, никак — это фундаментальный компромисс.

Когда использовать Hysteria 2, а когда нет

Сценарий	Hysteria 2	Альтернатива
Нестабильный канал, потери >5%	Отлично	VLESS деградирует
Провайдер режет UDP/QUIC	Плохо	VLESS + XHTTP
Нужна максимальная скрытность	Средне	VLESS + Reality
Скорость важнее стелса	Отлично	—
Мобильный интернет	Хорошо	—
Корпоративный файрвол без UDP	Не работает	Любой TCP-based

Конфиг, который реально работает в 2026-м

# Сервер
listen: :443

tls:
  cert: /path/to/cert.pem
  key: /path/to/key.pem

auth:
  type: password
  password: strong_password_here

masquerade:
  type: proxy
  proxy:
    url: https://www.bing.com
    rewriteHost: true

quic:
  initStreamReceiveWindow: 26843545
  maxStreamReceiveWindow: 26843545
  initConnReceiveWindow: 67108864
  maxConnReceiveWindow: 67108864

# Клиент — с port hopping
server: your.server.com:20000-50000

auth: strong_password_here

tls:
  sni: your.server.com
  insecure: false

bandwidth:
  up: 20 mbps
  down: 100 mbps

transport:
  udp:
    hopInterval: 30s

socks5:
  listen: 127.0.0.1:1080

Что дальше

Hysteria 2 — это не замена VLESS+Reality для максимального стелса. Это другой инструмент с другими компромиссами: скорость и устойчивость к потерям в обмен на более заметный трафик-паттерн.

В арсенале имеет смысл держать оба. Hysteria 2 на хорошем UDP-канале даёт скорости, которые TCP-based протоколы просто не могут обеспечить физически. VLESS+Reality — когда нужна маскировка.

Код открытый: github.com/apernet/hysteria.
Документация честная — слабые места там признаются, что само по себе редкость в этой экосистеме :)

Если есть идеи для разбора, нашёл ошибку в конфиге
или хочешь предложить тему — пиши на
aleksandr@murzin.digital. Отвечаю.