homeproxy-hiddify/wiki/Supported-Protocols-ru.md

🇬🇧 English | 🇷🇺 Русский

Поддерживаемые протоколы

Re:HomeProxy работает на выбор ядра: hiddify-core (по умолчанию) или sing-box-extended — оба форки sing-box с дополнительными протоколами и функциями, недоступными в upstream. Отображаемые в редакторе узлов протоколы зависят от того, какое ядро вы установили и с какими флагами оно собрано на вашем устройстве. Ядро выбирается и устанавливается в разделе Управление ядром (Сервисы → Re:HomeProxy → Ядро и службы).

---

Заполнение полей в редакторе узлов

Когда вы добавляете узел вручную, редактор открывает базовые опции outbound-а sing-box — TLS (включая Reality, отпечатки uTLS, ECH), транспорт (gRPC / WebSocket / HTTP / HTTPUpgrade / XHTTP) и мультиплекс. Чтобы не дублировать справочник sing-box, сверяйте каждое поле со своим сервером по официальной документации:

• Справочник outbound-ов — все типы outbound-ов и их поля
• TLS (общее) — Reality, uTLS, ECH, ALPN
• Транспорты V2Ray — gRPC / WS / HTTP / HTTPUpgrade
• Мультиплекс

Большинству пользователей не нужно заполнять это вручную — импорт share-ссылки или подписки делает это за вас (см. Подписки и импорт узлов).

---

Возможности расширенных ядер (отсутствуют в upstream sing-box)

Оба ядра — форки sing-box, добавляющие функции, которых нет в upstream. Часть из них только в hiddify-core, часть — в обоих ядрах (hiddify-core и sing-box-extended), отмечено по каждому пункту:

Фрагментация TLS (tls_fragment) (только hiddify-core)

Разбивает TLS ClientHello на несколько TCP-пакетов так, чтобы поле SNI (Server Name Indication) — раскрывающее доменное имя назначения — передавалось в отдельных фрагментах. Системы DPI, анализирующие только целые пакеты для идентификации и блокировки доменов, не успевают собрать SNI воедино, и соединение проходит незамеченным.

Режимы фрагментации:

• SNI/Domain — разбивает пакеты на два фрагмента; просто и эффективно в большинстве случаев
• Random — делит на множество очень мелких фрагментов для максимальной обфускации; используйте, если режима SNI недостаточно

Ключевые параметры:

• Размер фрагмента — рекомендуется 100–200 байт; в идеале на один байт меньше длины доменного имени
• Интервал фрагментации — задержка между фрагментами; настраивайте под конкретного провайдера
• Mixed SNI case — рандомизирует регистр символов SNI (например, wWw.ExAmPlE.cOm) для обхода блокировок, зависящих от регистра
• Padding — добавляет случайные данные к полю домена

Важно: Не включайте фрагментацию и padding одновременно — они взаимно нейтрализуют друг друга. Эффективность зависит от провайдера и может потребовать подбора параметров.

Применяется к любому протоколу, использующему TLS (VLESS, VMess, Trojan и др.).

Источник: How the TLS Trick works and its usage — hiddify.com

Транспорт XHTTP (оба ядра)

Современный HTTP-транспорт для VLESS, разработанный для совместимости с CDN и мультиплексирования. Отсутствует в upstream sing-box, но доступен в обоих ядрах — hiddify-core и sing-box-extended. Подробнее — в разделе VLESS ниже.

Дополнительные протоколы (оба ядра)

MieruTCP / MieruUDP и расширенные варианты NaïveProxy — доступны в обоих ядрах (см. ниже).

---

Всегда доступны

Direct

Прямое подключение без проксирования. Используется в правилах маршрутизации для локальных или доверенных адресов.

AnyTLS

TLS-протокол с мультиплексированием, разработанный командой hiddify. Простой, эффективный и сложно поддающийся отпечатыванию. Хороший выбор, когда другие TLS-протоколы блокируются.

HTTP

Обычный HTTP-прокси (метод CONNECT по RFC 7231). Поддерживает аутентификацию по имени пользователя и паролю. Не шифруется — используйте только в доверенных сетях или в сочетании с TLS-обёрткой.

Shadowsocks

Один из наиболее распространённых антицензурных протоколов. Шифрует трафик с помощью общего ключа и шифра (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305 и др.). Прост в настройке. Не использует TLS — трафик обфусцирован, но не выглядит как HTTPS.

Shadowsocks 2022 (2022-blake3-aes-128-gcm, 2022-blake3-aes-256-gcm, 2022-blake3-chacha20-poly1305) также поддерживается. Улучшенная версия с более стойким аутентифицированным шифрованием, защитой от повторного воспроизведения и лучшей производительностью. Если сервер поддерживает — используйте варианты 2022. ShadowTLS (см. ниже) рассчитан на работу именно с Shadowsocks 2022.

ShadowTLS

TLS-обёртка, разработанная для использования с Shadowsocks 2022 (не с оригинальным Shadowsocks). Оборачивает соединение в TLS-рукопожатие, имитирующее настоящий HTTPS-сервер — трафик неотличим от легитимного TLS для пассивного наблюдателя. TLS-рукопожатие настоящее: оно завершается с реальным сервером, поэтому блокировки по SNI и отпечатку TLS не работают. Требует сервер с поддержкой ShadowTLS и бэкенд на Shadowsocks 2022.

Socks

Прокси SOCKS4 и SOCKS5. Поддерживает опциональную аутентификацию (SOCKS5). Без шифрования — подходит для использования внутри доверенной сети или как локальный outbound.

SSH

Туннелирует трафик через SSH-соединение с использованием проброса портов. Полезен, когда доступен только SSH, а другие порты заблокированы. Требует SSH-сервер с учётной записью. Медленнее специализированных протоколов из-за накладных расходов SSH.

Trojan

Маскирует прокси-трафик под обычный HTTPS, используя TLS с действующим сертификатом. Сервер с Trojan выглядит снаружи идентично HTTPS-сайту. Для не-Trojan соединений отдаёт настоящую веб-страницу, что делает его крайне сложным для обнаружения.

Поддерживаемые транспорты:

Транспорт	CDN-совместим	Примечания
TCP (raw TLS)	Нет	По умолчанию; минимальные накладные расходы
WebSocket	Да	Работает за Cloudflare и другими CDN
gRPC	Да	Работает за Cloudflare (требует поддержки gRPC на CDN)
HTTP/2	Нет	Мультиплексирование; не CDN-совместим без WS/gRPC

WebSocket + TLS — наиболее распространённая схема для CDN (Cloudflare): CDN завершает TLS и проксирует WebSocket-трафик на origin-сервер.

VLESS

Лёгкий преемник VMess без дополнительного слоя шифрования (безопасность обеспечивается транспортом, обычно TLS). Широко используется с серверами на основе Xray.

Поддерживаемые транспорты:

Транспорт	CDN-совместим	Примечания
TCP (raw TLS)	Нет	Стандартная схема
WebSocket	Да	CDN-совместим; широко поддерживается
gRPC	Да	CDN-совместим
HTTP/2	Нет	Мультиплексированные соединения
HTTPUpgrade	Да	Лёгкое HTTP upgrade рукопожатие
XHTTP	Да	Нет в upstream sing-box; есть в обоих ядрах — см. ниже

XHTTP — расширенный транспорт для VLESS, доступный в обоих ядрах (hiddify-core и sing-box-extended), но не в upstream sing-box. Использует chunked HTTP-передачу через одиночное или мультиплексированное соединение, специально разработан для совместимости с CDN и устранения паттернов, характерных для не-браузерного трафика.

VMess

Оригинальный протокол V2Ray. Включает собственное шифрование поверх транспортного слоя. Чуть более высокие накладные расходы по сравнению с VLESS, но очень широко распространён.

Поддерживаемые транспорты:

Транспорт	CDN-совместим	Примечания
TCP	Нет
WebSocket	Да	Наиболее распространённая CDN-схема
gRPC	Да
HTTP/2	Нет
HTTPUpgrade	Да

VMess через WebSocket + TLS — одна из наиболее распространённых конфигураций для Cloudflare CDN, скрывающего реальный IP origin-сервера.

---

Требуют флаг сборки with_quic

Hysteria

Высокопроизводительный прокси-протокол на основе QUIC (версия 1). Использует модифицированный стек QUIC, лучше переносящий потерю пакетов по сравнению с TCP — полезен на нестабильных или высоколатентных соединениях. Версия 1 в основном вытеснена Hysteria2.

Hysteria2

Улучшенная и упрощённая версия Hysteria. Использует обфускацию Salamander и управление перегрузкой BBR. Значительно лучше по производительности, чем v1, и сложнее обнаруживается. Рекомендуется вместо Hysteria v1 для новых установок.

TUIC

Протокол на основе QUIC со встроенным мультиплексированием и установкой соединения 0-RTT. Низкая задержка и высокая эффективность. Требует TUIC-сервер (протокол v5).

---

Требует флаг сборки with_naive_outbound

NaïveProxy

Использует настоящий сетевой стек Chrome, делая трафик прокси неотличимым от реального HTTPS-трафика браузера Chrome. Чрезвычайно устойчив к анализу трафика и отпечатыванию — реализация TLS, выбор шифров и поведение идентичны реальному браузеру.

Два варианта транспорта:

Вариант	Протокол	Примечания
NaiveTLS	HTTPS (TLS 1.3 over TCP)	Имитирует HTTPS в Chrome; наиболее распространён
NaiveQUIC	HTTP/3 (QUIC)	Имитирует HTTP/3 в Chrome; сложнее заблокировать, но требует UDP

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

NaïveProxy требует совместимый сервер (например, Caddy с плагином forwardproxy).

---

Требует флаги with_wireguard + with_gvisor

WireGuard

Современный VPN-протокол с минимальной кодовой базой и стойкой криптографией (Curve25519, ChaCha20-Poly1305). Очень быстрый и энергоэффективный. Может использоваться как outbound для туннелирования всего прокси-трафика через WireGuard-эндпоинт (VPS или сервисы вроде Cloudflare WARP).

---

Требуется ядро sing-box-extended

Эти типы узлов доступны, если вместо hiddify-core установить sing-box-extended (ядро выбирается на странице Управление ядром). hiddify-core их не поддерживает.

AmneziaWG

Маскирующийся вариант WireGuard. Он добавляет мусорные пакеты и рандомизированные заголовки рукопожатия (параметры Jc, Jmin, Jmax, S1, S2, H1–H4, I1–I5), благодаря чему DPI-системы, которые обнаруживают и блокируют обычный WireGuard, перестают распознавать трафик. Задайте параметры маскировки в соответствии с вашим сервером AmneziaWG (или эндпоинтом Cloudflare WARP на AmneziaWG). Та же быстрая криптография Curve25519 / ChaCha20-Poly1305, что и в WireGuard, но пакеты больше не выглядят как WireGuard.

---

Mieru — требует with_quic

MieruTCP / MieruUDP

Антицензурный протокол, разработанный независимо от sing-box и добавленный расширенными ядрами (hiddify-core и sing-box-extended). Использует полностью случайные паттерны трафика без идентифицируемых заголовков или рукопожатий — крайне сложен для обнаружения и классификации системами DPI.

• MieruTCP — TCP-вариант транспорта
• MieruUDP — UDP-вариант; более высокая пропускная способность, требует доступ к UDP

Требует сервер Mieru. Настройка сервера — в документации проекта Mieru.

---

Ожидается в будущих версиях hiddify-core

DNSTT (планируется)

Протокол DNS-туннелирования — передаёт прокси-трафик внутри DNS-запросов и ответов. Крайне полезен в жёстко ограниченных средах, где разрешён только DNS-трафик (например, captive portal, некоторые корпоративные сети). Значительно меньшая пропускная способность по сравнению с другими протоколами из-за ограничений размера DNS-пакетов, но работает там, где ничто другое не работает.

---

Как проверить возможности вашей сборки

Выполните команду версии для того ядра, которое установлено:

hiddify-core version    # если установлен hiddify-core
sing-box version        # если установлен sing-box-extended

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

Пример вывода:

Tags: with_quic,with_wireguard,with_gvisor,with_naive_outbound,...

---

Примечание о NaïveProxy

Доступность NaïveProxy определяется флагом сборки with_naive_outbound — это не зависит от архитектуры устройства. Некоторые сборки не включают его для уменьшения размера бинарника. Проверьте установленную версию, как описано выше, прежде чем считать протокол недоступным.