🇬🇧 [English](Supported-Protocols-en) | 🇷🇺 [Русский](Supported-Protocols-ru) # Поддерживаемые протоколы Re:HomeProxy работает на выбор ядра: [hiddify-core](https://github.com/hiddify/hiddify-core) (по умолчанию) или [sing-box-extended](https://github.com/shtorm-7/sing-box-extended) — оба форки [sing-box](https://sing-box.sagernet.org) с дополнительными протоколами и функциями, недоступными в upstream. Отображаемые в редакторе узлов протоколы зависят от того, **какое ядро вы установили** и с какими флагами оно собрано на вашем устройстве. Ядро выбирается и устанавливается в разделе **Управление ядром** (Сервисы → Re:HomeProxy → Ядро и службы). --- ## Заполнение полей в редакторе узлов Когда вы добавляете узел вручную, редактор открывает базовые опции **outbound-а sing-box** — TLS (включая **Reality**, отпечатки **uTLS**, **ECH**), транспорт (**gRPC / WebSocket / HTTP / HTTPUpgrade / XHTTP**) и **мультиплекс**. Чтобы не дублировать справочник sing-box, сверяйте каждое поле со своим сервером по официальной документации: - [Справочник outbound-ов](https://sing-box.sagernet.org/configuration/outbound/) — все типы outbound-ов и их поля - [TLS (общее)](https://sing-box.sagernet.org/configuration/shared/tls/) — Reality, uTLS, ECH, ALPN - [Транспорты V2Ray](https://sing-box.sagernet.org/configuration/shared/v2ray-transport/) — gRPC / WS / HTTP / HTTPUpgrade - [Мультиплекс](https://sing-box.sagernet.org/configuration/shared/multiplex/) Большинству пользователей не нужно заполнять это вручную — импорт share-ссылки или подписки делает это за вас (см. [Подписки и импорт узлов](Subscriptions-ru)). --- ## Возможности расширенных ядер (отсутствуют в 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](https://hiddify.com/manager/basic-concepts-and-troubleshooting/How-the-TLS-Trick-works-and-its-usage/#tls-fragment)* ### Транспорт 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](https://github.com/enfein/mieru). --- ## Ожидается в будущих версиях hiddify-core ### DNSTT (планируется) Протокол DNS-туннелирования — передаёт прокси-трафик внутри DNS-запросов и ответов. Крайне полезен в жёстко ограниченных средах, где разрешён только DNS-трафик (например, captive portal, некоторые корпоративные сети). Значительно меньшая пропускная способность по сравнению с другими протоколами из-за ограничений размера DNS-пакетов, но работает там, где ничто другое не работает. --- ## Как проверить возможности вашей сборки Выполните команду версии для **того ядра, которое установлено**: ```sh 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` — это не зависит от архитектуры устройства. Некоторые сборки не включают его для уменьшения размера бинарника. Проверьте установленную версию, как описано выше, прежде чем считать протокол недоступным.