TUIC на Android: настройка клиента

MAATRIX

Если вы подняли TUIC v5 на сервере и попытались подключиться с телефона привычным v2rayNG — ничего не выйдет: xray-core, на котором он построен, протокол TUIC не понимает вообще. TUIC — это не вариация VLESS, а отдельный протокол поверх QUIC, и ему нужен клиент с поддержкой именно этого транспорта. Разберём, какие Android-приложения умеют работать с TUIC v5, как собрать профиль из ссылки или вручную, какие параметры реально влияют на поведение туннеля и почему на части мобильных сетей протокол капризничает там, где Wi-Fi работает без проблем.

Что такое TUIC и чем он отличается от привычных протоколов на телефоне

TUIC (автор — EAimTY) работает поверх QUIC — того же транспорта, на котором построен HTTP/3, то есть поверх UDP, а не TCP. Это принципиально меняет поведение туннеля по сравнению с VLESS, Shadowsocks или OpenVPN, которые почти всегда используют TCP:443 или собственный TCP-порт:

• 0-RTT handshake. При повторном подключении (например, после переключения Wi-Fi → LTE) TUIC способен восстановить сессию почти без задержки на рукопожатие — на телефоне, который постоянно скачет между сетями, это заметно на глаз.
• Встроенный congestion control. Протокол сам управляет скоростью отправки при потере пакетов (алгоритмы BBR, Cubic, NewReno), а не полагается на TCP-стек ОС. На нестабильном канале это иногда работает лучше классической связки «TCP-туннель поверх TCP-соединения», где congestion control срабатывает дважды и мешает сам себе.
• Мультиплексирование потоков внутри одного QUIC-соединения — меньше накладных расходов на установку новых потоков при открытии нескольких вкладок или соединений одновременно.

Обратная сторона: TUIC — это UDP, а операторы сотовой связи и некоторые Wi-Fi-роутеры обращаются с UDP иначе, чем с TCP — от QoS-приоритизации ниже, чем у веб-трафика, до полного блокирования нестандартных UDP-портов. Об этом — в разделе про диагностику ниже.

Какие Android-приложения поддерживают TUIC v5

v2rayNG и другие клиенты на чистом xray-core протокол не поддерживают — нужен клиент с отдельным движком под TUIC или с сингбокс-ядром, где TUIC реализован как один из outbound-типов.

Для большинства пользователей разумный выбор — NekoBox или его форк Husi: они принимают готовую ссылку tuic:// одним касанием и не требуют разбираться в синтаксисе конфигов sing-box. Если вы уже используете sing-box на сервере и привыкли к его JSON-формату конфигурации, официальное приложение sing-box for Android даст более предсказуемое поведение, потому что клиент и сервер построены на одном движке.

Установка клиента

Ни один из этих клиентов не публикуется в Google Play — маркет ограничивает VPN-инструменты подобного рода, поэтому ставим APK напрямую с GitHub.

1. Скачайте APK нужной архитектуры (для большинства телефонов — arm64-v8a) со страницы релизов проекта (MatsuriDayo/NekoBoxForAndroid, xchacha20-poly1305/husi или SagerNet/sing-box — в зависимости от выбора).
2. Разрешите установку из неизвестных источников для браузера или файлового менеджера: Настройки → Приложения → Особый доступ → Установка неизвестных приложений.
3. Установите APK, запустите приложение, подтвердите системный запрос на создание VPN-соединения (стандартный диалог Android VpnService).

Перед установкой стоит свериться с контрольной суммой:

sha256sum NekoBoxForAndroid_universal.apk

и сравнить с хэшем на странице релиза — привычка не лишняя, когда APK ставится не из маркета.

Импорт профиля через ссылку tuic://

Панель управления сервером или скрипт установки TUIC обычно выдаёт готовую ссылку вида:

tuic://a1b2c3d4-e5f6-7890-abcd-ef1234567890:mypassword@203.0.113.10:443?congestion_control=bbr&udp_relay_mode=native&alpn=h3&sni=www.example.com&allow_insecure=0#MyTUIC

Разбор параметров:

Порядок импорта в NekoBox или Husi:

1. Скопируйте ссылку tuic://… в буфер обмена.
2. В приложении нажмите + → Импорт из буфера обмена (или отсканируйте QR-код, если панель его выдаёт).
3. Профиль появится в списке — нажмите на него, чтобы сделать активным, затем на кнопку запуска туннеля.

Если ссылки нет и есть только сырые параметры из config.json на сервере, профиль собирается вручную — этим и удобны названные клиенты по сравнению с более узкими решениями вроде v2rayNG.

Ручная настройка через JSON (sing-box-совместимые клиенты)

Для sing-box for Android, а также для ручного добавления outbound в NekoBox/Husi через режим sing-box конфиг выглядит так:

{
  "type": "tuic",
  "server": "203.0.113.10",
  "server_port": 443,
  "uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "password": "mypassword",
  "congestion_control": "bbr",
  "udp_relay_mode": "native",
  "zero_rtt_handshake": false,
  "heartbeat": "10s",
  "tls": {
    "enabled": true,
    "server_name": "www.example.com",
    "alpn": ["h3"]
  }
}

Ключевые поля, которые часто путают:

• heartbeat — интервал keepalive-пакетов. На мобильной сети операторский NAT закрывает «молчащие» UDP-сессии заметно быстрее, чем TCP, поэтому значение по умолчанию (обычно 10 секунд) трогать не стоит без причины — увеличение интервала на LTE может привести к обрывам при простое.
• zero_rtt_handshake — ускоряет переподключение, но теоретически повышает риск replay-атак на уровне протокола. Разработчики TUIC рекомендуют держать его выключенным, если только вы не понимаете, зачем включаете.
• tls.server_name — должен совпадать с тем, что настроено на сервере, иначе TLS-хендшейк не пройдёт вовсе, а не просто ухудшится соединение.

Собранный вручную профиль в NekoBox сохраняется как обычная запись в списке серверов, ничем не отличаясь от импортированного по ссылке.

Congestion control и другие параметры: что реально влияет на поведение

Точных цифр по приросту скорости для вашей сети никто не даст без замера на месте — слишком много переменных: оператор, загрузка соты, расстояние до сервера. Но общие ориентиры такие:

• BBR обычно лучше ведёт себя на каналах с потерями пакетов (типично для мобильной сети в движении), потому что не воспринимает единичную потерю как сигнал к резкому снижению скорости, в отличие от классических алгоритмов на основе потерь.
• Cubic — консервативнее, предсказуемее на стабильном канале (домашний Wi-Fi), но может проседать сильнее при кратковременных всплесках потерь на LTE.
• udp_relay_mode: native vs quic. native даёт меньше накладных расходов, но quic-режим иногда лучше проходит через строгие NAT и некоторые типы файрволов оператора, потому что весь трафик остаётся внутри одного QUIC-потока без дополнительных UDP-сессий наружу.

Практический подход — начать с bbr + native, и переключаться на альтернативы только если видите нестабильность именно в вашей сети, а не по общим советам из интернета.

Почему TUIC может не работать на мобильной сети и что делать

Раз TUIC — это UDP, часть типичных проблем связана именно с этим:

• Оператор режет или сильно ограничивает UDP. Проверьте: если на Wi-Fi всё подключается мгновенно, а на LTE/5G — нет или очень медленно, дело почти наверняка в QoS-политике оператора для UDP-трафика на нестандартный порт. Попробуйте udp_relay_mode=quic вместо native — иногда это помогает пройти через более жёсткую фильтрацию.
• Проблемы с MTU. QUIC чувствителен к фрагментации пакетов, а на мобильных сетях эффективный MTU часто ниже, чем на проводном подключении. Если в клиенте есть настройка MTU для интерфейса, стоит попробовать снизить значение (например, до 1350–1400) при частых обрывах именно на LTE.
• Фоновые ограничения Android. На MIUI, EMUI, ColorOS и подобных оболочках система агрессивно убивает фоновые процессы ради экономии батареи — отдельно разрешите автозапуск и работу в фоне для выбранного клиента в настройках энергосбережения, иначе туннель падает через минуту-две после сворачивания приложения.
• Конфликт с другим активным VPN. Android разрешает только одно активное VpnService-соединение одновременно — если параллельно работает корпоративный клиент или другое VPN-приложение, TUIC не запустится. Этот случай подробно разобран в статье про конфликт двух туннелей на телефоне.
• UDP заблокирован полностью, а не просто ограничен. Такое встречается на некоторых корпоративных или гостевых Wi-Fi. В этом случае TUIC не поможет в принципе — нужен протокол поверх TCP, и стоит свериться с гайдом по выбору протокола под конкретный сценарий.

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

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