mirror of
https://github.com/kiddin9/op-packages.git
synced 2026-09-14 12:24:33 +08:00
209 lines
20 KiB
Markdown
209 lines
20 KiB
Markdown
🇬🇧 [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` — это не зависит от архитектуры устройства. Некоторые сборки не включают его для уменьшения размера бинарника. Проверьте установленную версию, как описано выше, прежде чем считать протокол недоступным.
|