🚄 TUIC: QUIC-прокси с нулевой задержкой на переподключении

О чём заметка

Разбор протокола TUIC — прокси поверх QUIC, спроектированного вокруг быстрого установления соединения (0-RTT) и честной работы с UDP. Здесь: как он устроен, чем отличается от Hysteria 2, в чём разница версий v4 и v5, какие режимы UDP-релея бывают и в каком состоянии находится проект. Карта протоколов — в обзоре.

TL;DR

• TUIC — прокси поверх QUIC: транспорт работает по UDP, шифрование берётся из TLS 1.3, несколько потоков мультиплексируются в одном соединении.
• Главная особенность — 0-RTT при возобновлении сессии: повторное подключение к знакомому серверу не требует полного рукопожатия, и восстановление занимает доли миллисекунды вместо сотен.
• UDP проксируется по-настоящему, а не эмуляцией поверх TCP: поддерживается Full Cone NAT, что важно для игр, голосовой связи и P2P.
• Два режима UDP-релея: native (через QUIC-датаграммы, быстро, но пакет ограничен размером датаграммы) и quic (через потоки, надёжно, но с накладными расходами).
• В v5 появился отдельный пароль пользователя; конфиги v4 и v5 несовместимы — это частая причина «всё введено верно, но не подключается».
• Оригинальный репозиторий попал в волну архиваций ноября 2023 года; протокол живёт прежде всего в реализациях универсальных ядер — mihomo, sing-box.

Зачем понадобился ещё один QUIC-протокол

К моменту появления TUIC у обхода блокировок уже был набор TCP-протоколов (Trojan, VLESS, Shadowsocks), и у всех них общие врождённые проблемы.

Первая — стоимость установления соединения. TCP-рукопожатие плюс TLS-рукопожатие — это два-три обмена пакетами до того, как пойдут данные. На канале до другого континента с задержкой 200–300 мс каждое новое соединение обходится в заметную паузу, и это ощущается как «интернет думает».

Вторая — проксирование UDP. TCP-протоколы вынуждены упаковывать UDP-пакеты в TCP-поток. Это ломает свойства UDP: появляется лишняя надёжность там, где она не нужна (игре важнее свежий пакет, чем гарантированно доставленный старый), и рушится NAT-поведение, от которого зависят голосовые звонки и P2P.

Третья — потери пакетов. При потере TCP резко снижает скорость. На плохом канале это выглядит как «скорость есть, но её нет».

QUIC решает всё три задачи на уровне транспорта: он несёт TLS 1.3 внутри себя (рукопожатие совмещено), умеет 0-RTT-возобновление, мультиплексирует потоки без блокировки друг друга и передаёт датаграммы. TUIC — это тонкий прокси-протокол поверх этих возможностей: вся криптография и надёжность взяты у QUIC, сверху добавлены только аутентификация и команды релея.

Как это работает

Клиент устанавливает QUIC-соединение с сервером (TLS 1.3, сертификат — обычный или самоподписанный), проходит аутентификацию и дальше отправляет команды: «открой TCP до такого-то адреса» или «перешли этот UDP-пакет туда-то». Каждое проксируемое TCP-соединение живёт в своём QUIC-потоке, поэтому потеря пакета в одном не тормозит остальные.

0-RTT при возобновлении. QUIC умеет сохранять параметры прошлой сессии: при повторном подключении клиент отправляет данные вместе с рукопожатием, не дожидаясь ответа сервера. Практическая разница ощутима — вместо задержки в 200–300 мс на каждое новое соединение восстановление проходит почти мгновенно. Особенно заметно на мобильной сети, где соединения рвутся постоянно (переход между вышками, засыпание экрана).

Режимы UDP-релея. Это единственная настройка TUIC, которую действительно стоит понимать:

• native — UDP-пакеты идут в QUIC-датаграммах. Быстро и семантически честно (пакет либо доехал, либо нет), но датаграмма QUIC ограничена по размеру: большие UDP-пакеты в неё не помещаются, и на практике это приводит к проблемам с некоторыми приложениями.
• quic — UDP-пакеты идут через потоки QUIC. Ограничение размера снимается и доставка гарантирована, но появляются накладные расходы и та самая надёжность, которая UDP-приложениям не всегда нужна.

Проще говоря: native быстрее и «честнее» по смыслу, quic — безопаснее по совместимости. Если UDP-приложение ведёт себя странно, переключение режима — первое, что стоит попробовать.

Full Cone NAT. TUIC проксирует UDP так, что внешние узлы могут отвечать на ваш порт напрямую. Это то, без чего плохо работают голосовые звонки, игровые лобби и P2P-передача.

v4 против v5

Версии несовместимы, и это самая частая практическая проблема. Ключевое отличие на уровне конфига: в v5 у пользователя есть UUID и отдельный пароль, тогда как в v4 пароля нет. Если вы вписали пароль в конфиг узла v4 или, наоборот, не указали его для v5 — соединение не установится, при том что адрес, порт и сертификат верны.

Помимо этого v5 привёл в порядок формат команд и работу с аутентификацией. В документации ядер (mihomo, sing-box) параметры версий описаны раздельно — при настройке сверяйтесь именно с разделом своей версии.

TUIC против Hysteria 2

Оба протокола работают поверх QUIC и решают похожие задачи, поэтому выбор между ними — типичный вопрос.

Свойство	TUIC	Hysteria 2
Основной акцент	Быстрое установление соединения, честный UDP	Скорость на каналах с потерями, маскировка
Контроль перегрузки	Стандартные алгоритмы QUIC (BBR и др.)	Собственный Brutal с заданной скоростью
Маскировка	Обычный QUIC/TLS 1.3	Маскировка под HTTP/3 плюс режим masquerade — сервер отвечает как настоящий сайт
Своя серверная обвязка	Минимальная	Развитая: ACL, API статистики, port hopping
Развитие проекта	Оригинальный репозиторий заархивирован, живёт в ядрах	Активное

Практический ориентир: Hysteria 2 сильнее там, где канал плохой или где нужна серверная обвязка; TUIC привлекателен минимализмом и поведением при частых переподключениях. И у обоих одна общая уязвимость — они целиком зависят от того, пропускает ли сеть UDP.

Всё упирается в UDP

Часть провайдеров и мобильных операторов режет, троттлит или полностью блокирует UDP, особенно длинные сессии и трафик на 443-й порт. Тогда QUIC-протоколы отваливаются там, где TCP-based VLESS продолжает работать. Держите TCP-вариант как запасной: это не перестраховка, а типовая практика.

Состояние проекта

Оригинальный репозиторий TUIC (автор — @EAimTY) попал в волну удалений и архиваций 2–3 ноября 2023 года, описанную в сводке gfw.report и в заметке Ядро Clash. Спецификация и код остались доступны, но отдельная активная разработка протокола фактически остановилась.

Это не означает, что TUIC мёртв: он реализован в mihomo и sing-box (в Xray-core его нет — там из QUIC-протоколов есть только Hysteria 2), там же чинятся ошибки и добавляются мелкие улучшения (в релизах mihomo середины 2026 года, например, дорабатывали UDP-релей). Но рассчитывать на развитие самого протокола — на новые версии, на ответ на новые методы детекта — не стоит. Для сравнения: AnyTLS и Hysteria развиваются активно.

📚 См. также

• Обзор протоколов — карта задач и поддержки в ядрах.
• Hysteria 2 — второй крупный QUIC-протокол и его отличия.
• AnyTLS и NaiveProxy — современные TCP-альтернативы с упором на маскировку.
• Возможности и протоколы mihomo — как TUIC настраивается в YAML-конфиге.
• 🔗 github.com/tuic-protocol/tuic — спецификация и исходники.
• 🔗 Документация TUIC в mihomo — актуальные параметры конфига.

---

🤖 Эти статьи открыты — можно обучать на них ИИ

При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.