cwx/op-packages
1
0 Fork 0
mirror of https://github.com/kiddin9/op-packages.git synced 2026-10-30 10:05:13 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

🎁 Sync 2026-07-31 00:21:49

Browse Source
This commit is contained in:
github-actions[bot] committed 2026-07-31 00:21:49 +08:00
1 parent 2660b1fce8
commit ae7b9f4d28
204 files changed
+187145 -10038
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

homeproxy-hiddify/wiki/ByeDPI-en.md
+102
View File
@@ -0,0 +1,102 @@
🇬🇧 [English](ByeDPI-en) | 🇷🇺 [Русский](ByeDPI-ru)
# ByeDPI
**ByeDPI** is a built-in DPI-bypass that can un-throttle and unblock sites **without any VPN subscription**. Re:HomeProxy bundles the [ByeDPI](https://github.com/hufrea/byedpi) engine (`ciadpi`) and manages it for you.
---
## What it is — and what it is not
ByeDPI runs a tiny local proxy that **desyncs the TLS handshake** of your connections (splitting, reordering, fake packets, OOB data, etc.) so that your ISP's Deep Packet Inspection can no longer recognise — and therefore can no longer throttle or block — the traffic.
| | |
|---|---|
| ✅ **Un-throttles DPI-filtered sites** | The common case for YouTube and similar services that load slowly or buffer endlessly under DPI throttling. |
| ✅ **No subscription, no server** | It's a local trick — you don't need a VPN node, account, or any remote server. |
| ❌ **Does not encrypt or hide traffic** | Your ISP still sees *which* sites you visit; ByeDPI only changes *how* the first packets look. It is **not a VPN**. |
| ❌ **Cannot reach fully IP-blocked sites** | If a site is blocked by IP/DNS (not just throttled), only a real proxy/VPN node can reach it. |
| ❌ **Not a tunnel** | ByeDPI carries your traffic but does not resolve DNS like a proxy — see *DNS* below. |
Think of ByeDPI as a complement to a VPN node (offload throttled sites like YouTube to ByeDPI to save VPN bandwidth), or as a standalone tool when the only problem is throttling.
---
## Enabling ByeDPI
1. Go to **Services → Re:HomeProxy → Node Settings** and open the **ByeDPI** section.
2. If `ciadpi` is not installed yet, use the **Install** button — Re:HomeProxy fetches the right `byedpi` package for your architecture.
3. Tick **Enable**, pick a strategy (see below), and **Save & Apply**.
That's all that's needed for the engine. Re:HomeProxy starts `ciadpi` for you and prevents it from looping back through the proxy automatically — you do not need to touch the firewall or process settings.
---
## Strategies and presets
A "strategy" is the set of command-line options ByeDPI uses to mangle the handshake. There is no universal best strategy — **what works depends on your ISP's DPI**. Re:HomeProxy ships **47 ready-made presets** grouped by technique (named by group letter, e.g. `C3`, `I1`):
| Group | Examples | Idea |
|-------|----------|------|
| Disorder | `--disorder 1`, `--disorder 1+s` | Reorder the first segments so DPI can't reassemble the SNI |
| Fake TTL | `--fake -1 --ttl 6…15` | Inject a fake packet that dies (low TTL) before reaching the server |
| Fake MD5 | `--fake -1 --md5sig` | Fake packet carrying an invalid TCP MD5 signature |
| TLS record | `--tlsrec 1+s` | Split at the TLS record layer |
| OOB / DisOOB | `--oob 1+s`, `--disoob 1+s` | Out-of-band byte tricks at the SNI |
| Split | `--split 1+s` | Split the ClientHello at the SNI |
| HTTP mix | `--mod-http hcsmix,…` | Case/format mixing for plain-HTTP hosts |
| **Adaptive** | `--auto=ssl_err`, `--auto=torst` | **Self-correcting** — retries per connection on TLS error / reset |
| Fake SNI/TLS | `--fake-sni`, `--fake-tls-mod` | Send a decoy SNI / TLS fingerprint |
| Aggressive combos | split + OOB + disorder together | When single techniques aren't enough |
You can also pick **Custom** and type your own option string.
### Recommended starting point: preset I1 (adaptive)
**Preset I1 — "Auto SSL Error Fallback"** (`--fake -1 --ttl 8 --auto=ssl_err --fake -1 --ttl 5`) is the safest default, **especially for YouTube**.
Why adaptive matters: a **fixed** fake-TTL strategy (the Fake-TTL group, presets C1–C5) works for *far* servers but corrupts the handshake on *near* CDN/edge servers — e.g. some YouTube video segments served from a local Google cache. A fixed strategy that fails on near servers not only stalls the page, it can produce a storm of failed-handshake retries that **fills the router's connection-tracking table and freezes SSH/LuCI**. The adaptive `--auto=ssl_err` strategy retries per-connection when it sees a TLS error, so it self-corrects across near *and* far destinations.
---
## The strategy tester
Because the right strategy is ISP-specific, the ByeDPI section includes a **tester**:
- **Test all strategies** — probes four reference sites in parallel and shows a result per site as dots:
- **YouTube** and **Telegram** — *far* servers
- **Discord** and **Speedtest.net** — *near* servers
- `●●●●` = all four reachable with that strategy; `●●○○` = far sites work but near sites fail (a sign the strategy is destination-sensitive, like a fixed fake-TTL).
- **Test current** — tests only the strategy currently in the command field and shows full site names with ✓ / ✗.
Pick a strategy that scores **all-green (`●●●●`)** for your network. If several do, prefer an adaptive one (I1/I2).
> The tester runs ByeDPI on a separate temporary port, so it does not disturb live traffic.
---
## Routing traffic through ByeDPI
ByeDPI appears as a selectable node (**ByeDPI**) once enabled. Two common setups:
- **Alongside a VPN node (recommended):** in `proxy_banned_ru` mode, open **RU Proxy Rules** and set a *specific list's* node to **ByeDPI** — e.g. route YouTube through ByeDPI (saving VPN bandwidth) while everything else uses your VPN.
- **Standalone (no VPN):** set ByeDPI as the **main node**. All proxied traffic then goes through the local desync.
---
## DNS
ByeDPI is a desync, not a tunnel, so DNS does **not** go through it. When ByeDPI carries traffic, Re:HomeProxy resolves names **directly** (your configured Secure DNS detours direct-out for ByeDPI). Trying to push DoH/DoT or UDP DNS *through* ByeDPI fails — the handshake mangling corrupts the encrypted DNS session. This is handled automatically; there is nothing to configure.
---
## Troubleshooting
| Symptom | Likely cause / fix |
|---------|--------------------|
| A site still loads slowly | The strategy isn't right for your ISP — run **Test all strategies** and pick an all-green one. |
| YouTube buffers on a fixed fake-TTL preset | Switch to an adaptive preset (**I1/I2**); fixed TTL stalls on near Google cache nodes. |
| Router/LuCI/SSH becomes laggy | A destination-sensitive strategy is causing retry storms — switch to an adaptive preset. |
| A site is unreachable, not just slow | It may be IP-blocked, not throttled — ByeDPI can't help; use a proxy/VPN node for it. |
See also: [Zapret](Zapret-en) · [Core Management](Core-Management-en) · [Supported Protocols](Supported-Protocols-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/ByeDPI-ru.md
+102
View File
@@ -0,0 +1,102 @@
🇬🇧 [English](ByeDPI-en) | 🇷🇺 [Русский](ByeDPI-ru)
# ByeDPI
**ByeDPI** — встроенный обход DPI, который позволяет разблокировать сайты и снять троттлинг **без какой-либо VPN-подписки**. Re:HomeProxy включает движок [ByeDPI](https://github.com/hufrea/byedpi) (`ciadpi`) и управляет им за вас.
---
## Что это — и чем оно не является
ByeDPI запускает крошечный локальный прокси, который **рассинхронизирует TLS-рукопожатие** ваших соединений (разбиение, переупорядочивание, фейковые пакеты, OOB-данные и т. п.), чтобы система DPI провайдера больше не распознавала трафик — а значит, не могла его замедлять или блокировать.
| | |
|---|---|
| ✅ **Снимает троттлинг сайтов под DPI** | Типичный случай — YouTube и подобные сервисы, которые медленно грузятся или бесконечно буферизуются из-за DPI-троттлинга. |
| ✅ **Без подписки и сервера** | Это локальный трюк — не нужен VPN-узел, аккаунт или удалённый сервер. |
| ❌ **Не шифрует и не скрывает трафик** | Провайдер по-прежнему видит, *какие* сайты вы посещаете; ByeDPI меняет только то, *как выглядят* первые пакеты. Это **не VPN**. |
| ❌ **Не открывает сайты, заблокированные по IP** | Если сайт блокируется по IP/DNS (а не просто троттлится), достучаться до него может только настоящий прокси/VPN-узел. |
| ❌ **Не туннель** | ByeDPI переносит трафик, но не резолвит DNS как прокси — см. раздел *DNS*. |
Рассматривайте ByeDPI как дополнение к VPN-узлу (перенаправьте троттлящиеся сайты вроде YouTube на ByeDPI, чтобы экономить трафик VPN) либо как самостоятельный инструмент, когда проблема только в троттлинге.
---
## Включение ByeDPI
1. Откройте **Сервисы → Re:HomeProxy → Настройки узлов** и раздел **ByeDPI**.
2. Если `ciadpi` ещё не установлен, нажмите **Установить** — Re:HomeProxy скачает подходящий пакет `byedpi` для вашей архитектуры.
3. Отметьте **Включить**, выберите стратегию (см. ниже) и нажмите **Сохранить и применить**.
Этого достаточно. Re:HomeProxy сам запускает `ciadpi` и автоматически предотвращает зацикливание его трафика через прокси — настраивать межсетевой экран или процесс вручную не нужно.
---
## Стратегии и пресеты
«Стратегия» — это набор параметров командной строки, которыми ByeDPI искажает рукопожатие. Универсально лучшей стратегии нет — **что сработает, зависит от DPI вашего провайдера**. Re:HomeProxy включает **47 готовых пресетов**, сгруппированных по технике (именуются по букве группы, например `C3`, `I1`):
| Группа | Примеры | Идея |
|--------|---------|------|
| Disorder | `--disorder 1`, `--disorder 1+s` | Переупорядочить первые сегменты, чтобы DPI не собрал SNI |
| Fake TTL | `--fake -1 --ttl 6…15` | Вставить фейковый пакет, «умирающий» (низкий TTL) до сервера |
| Fake MD5 | `--fake -1 --md5sig` | Фейковый пакет с неверной TCP MD5-подписью |
| TLS record | `--tlsrec 1+s` | Разбиение на уровне TLS-записи |
| OOB / DisOOB | `--oob 1+s`, `--disoob 1+s` | Трюки с внеполосным байтом у SNI |
| Split | `--split 1+s` | Разбить ClientHello по SNI |
| HTTP mix | `--mod-http hcsmix,…` | Смешивание регистра/формата для обычного HTTP |
| **Адаптивные** | `--auto=ssl_err`, `--auto=torst` | **Самокорректирующиеся** — повторяют попытку на каждом соединении при TLS-ошибке/сбросе |
| Fake SNI/TLS | `--fake-sni`, `--fake-tls-mod` | Отправить ложный SNI / TLS-отпечаток |
| Агрессивные комбо | split + OOB + disorder вместе | Когда одиночных техник недостаточно |
Также можно выбрать **Custom** и ввести свою строку параметров.
### Рекомендуемая отправная точка: пресет I1 (адаптивный)
**Пресет I1 — «Auto SSL Error Fallback»** (`--fake -1 --ttl 8 --auto=ssl_err --fake -1 --ttl 5`) — самый безопасный вариант по умолчанию, **особенно для YouTube**.
Почему важна адаптивность: **фиксированная** стратегия fake-TTL (группа Fake TTL, пресеты C1–C5) работает для *далёких* серверов, но портит рукопожатие на *близких* CDN/edge-серверах — например, на сегментах видео YouTube из локального кэша Google. Фиксированная стратегия, дающая сбой на близких серверах, не только подвешивает страницу, но и может породить шторм повторов неудачных рукопожатий, который **переполняет таблицу отслеживания соединений роутера и подвешивает SSH/LuCI**. Адаптивная `--auto=ssl_err` повторяет попытку на каждом соединении при TLS-ошибке и потому сама подстраивается под близкие *и* далёкие адреса.
---
## Тестер стратегий
Поскольку нужная стратегия зависит от провайдера, в разделе ByeDPI есть **тестер**:
- **Проверить все стратегии** — параллельно опрашивает четыре эталонных сайта и показывает результат по каждому точками:
- **YouTube** и **Telegram** — *далёкие* серверы
- **Discord** и **Speedtest.net** — *близкие* серверы
- `●●●●` = все четыре доступны с этой стратегией; `●●○○` = далёкие работают, близкие — нет (признак того, что стратегия чувствительна к адресу, как фиксированный fake-TTL).
- **Проверить текущую стратегию** — проверяет только стратегию из поля команды и показывает полные имена сайтов с ✓ / ✗.
Выбирайте стратегию с результатом **«всё зелёное» (`●●●●`)** для вашей сети. Если таких несколько — предпочтите адаптивную (I1/I2).
> Тестер запускает ByeDPI на отдельном временном порту, поэтому не мешает «живому» трафику.
---
## Маршрутизация трафика через ByeDPI
После включения ByeDPI появляется как выбираемый узел (**ByeDPI**). Две частые схемы:
- **Вместе с VPN-узлом (рекомендуется):** в режиме `proxy_banned_ru` откройте **RU Proxy Rules** и задайте для *конкретного списка* узел **ByeDPI** — например, направьте YouTube через ByeDPI (экономя трафик VPN), а остальное оставьте на VPN.
- **Самостоятельно (без VPN):** назначьте ByeDPI **основным узлом**. Тогда весь проксируемый трафик идёт через локальную рассинхронизацию.
---
## DNS
ByeDPI — это рассинхронизация, а не туннель, поэтому DNS через него **не** идёт. Когда ByeDPI несёт трафик, Re:HomeProxy резолвит имена **напрямую** (настроенный Secure DNS для ByeDPI идёт через direct-out). Попытка пропустить DoH/DoT или UDP DNS *через* ByeDPI проваливается — искажение рукопожатия ломает зашифрованную DNS-сессию. Это обрабатывается автоматически, настраивать ничего не нужно.
---
## Устранение неполадок
| Симптом | Вероятная причина / решение |
|---------|------------------------------|
| Сайт всё ещё грузится медленно | Стратегия не подходит вашему провайдеру — запустите **Проверить все стратегии** и выберите полностью зелёную. |
| YouTube буферизуется на фиксированном пресете fake-TTL | Переключитесь на адаптивный пресет (**I1/I2**); фиксированный TTL подвешивает близкие узлы кэша Google. |
| Роутер/LuCI/SSH начинают тормозить | Стратегия, чувствительная к адресу, вызывает шторм повторов — переключитесь на адаптивный пресет. |
| Сайт недоступен, а не просто медленный | Возможно, он заблокирован по IP, а не троттлится — ByeDPI не поможет; используйте для него прокси/VPN-узел. |
См. также: [Zapret](Zapret-ru) · [Управление ядром](Core-Management-ru) · [Поддерживаемые протоколы](Supported-Protocols-ru) · [Устранение неполадок](Troubleshooting-ru)
homeproxy-hiddify/wiki/Core-Management-en.md
+79
View File
@@ -0,0 +1,79 @@
🇬🇧 [English](Core-Management-en) | 🇷🇺 [Русский](Core-Management-ru)
# Core Management
Re:HomeProxy is **multi-core**: the LuCI app is the interface, and a separate **core** binary does the actual proxying. You install, update, and switch cores from **Services → Re:HomeProxy → Core & Tools → Core management** — no SSH required.
---
## Choosing a core
| | **hiddify-core** (default) | **sing-box-extended** |
|---|---|---|
| Engine | Fork of sing-box by the Hiddify team | Fork of sing-box with extra build tags |
| Footprint | Lighter; a **compact build** exists for small devices | Larger (~26 MB installed) |
| Protocols | Hiddify-app protocols, TLS fragment, XHTTP, Mieru, etc. | The widest protocol set… |
| **AmneziaWG / WARP** | ❌ **Not supported** | ✅ **Supported** |
**Rule of thumb:** if you need **AmneziaWG/WARP**, or want the broadest protocol coverage and have ~40 MB free, choose **sing-box-extended**. Otherwise **hiddify-core** is the lighter default and is the only one with a compact build for tight-storage routers.
Which protocols appear in the node editor depends on the core you install — see [Supported Protocols](Supported-Protocols-en).
---
## Installing — one smart button
Core Management has a single **Install** button per core. It does **not** ask you to choose between "standard" and "compressed" builds — instead it inspects your device and picks a build that actually fits:
1. It reads the free space on `/overlay` (persistent flash) and your free RAM.
2. For hiddify-core: if the full build fits → it installs the **standard** build. If storage is tight but there's enough RAM → it installs the **compact** build and tells you so.
3. If neither can fit → it stops with a clear message instead of installing something broken.
### Why the guardrail matters
A core binary that is **larger than the free overlay** gets **truncated** as it's written, and then crashes with a **"bus error" (SIGBUS)** the moment it's launched — a confusing failure that looks like a corrupt download. The installer's size check exists specifically to prevent this: it never offers a build the device can't hold.
### The compact build
The compact (UPX-compressed) build of hiddify-core is much smaller on flash, but it **decompresses into RAM each time it launches** — trading flash space for memory. The installer only picks it when there's enough free RAM, and shows a note like *"Limited storage — installing the compact build (decompresses into RAM at launch)."* On most routers this is invisible in day-to-day use.
---
## Storage at a glance
| Free on `/overlay` | What installs |
|--------------------|---------------|
| ~40 MB+ | hiddify-core or sing-box-extended (full build) |
| ~25–40 MB | hiddify-core (compact build, if RAM allows) |
| < ~25 MB | Not enough — free space, or bake the core into a custom firmware image |
> On a **compressing** overlay (jffs2/ubifs) the full build needs less free space than the raw figure, because the filesystem compresses it. The installer accounts for this automatically — trust its check over the table above.
Tight on flash but building your own image? Large cores fit comfortably when **baked into the SquashFS** root at image-build time (the SquashFS root is compressed and read-only), rather than installed into the writable overlay.
---
## Switching cores and updating
- **Update:** press **Install** again — it fetches the latest release and reinstalls.
- **Switch cores:** install the other core; if both are present, Re:HomeProxy uses your **Preferred core** setting (on **Client → Routing Settings**). The config generator and the service honour the same preference, so the generated config always matches the core that will run it.
- **Custom / external core:** instead of the managed install you can point Re:HomeProxy at a **self-provided core binary** (a build you compiled, or a version not in Releases) — it detects and uses it. Advanced setups only.
- **Version / status:** the **Core management** section shows the installed core and version. If it shows all `?`, the backend (rpcd) is stale — restart it (`/etc/init.d/rpcd restart`) and reload the page.
---
## Resources & updates
The **Core & Tools** tab also has a **Resources management** section for the data files routing depends on — the GeoIP / Geosite databases and the RU rule-sets:
- **Check update** fetches the latest rule-set and geo data on demand.
- The RU routing lists also **self-refresh** on a schedule, so in normal use you don't need to touch this.
- **Subscriptions** update separately — on demand from the Subscriptions tab, or automatically on a cron; see [Subscriptions & Node Import](Subscriptions-en).
---
## Kernel modules
The proxy needs `kmod-nft-tproxy` and `kmod-tun` for transparent routing. The installer pulls these in; if routing doesn't work after a fresh install, confirm they're present.
See also: [ByeDPI](ByeDPI-en) · [Zapret](Zapret-en) · [Supported Protocols](Supported-Protocols-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/Core-Management-ru.md
+79
View File
@@ -0,0 +1,79 @@
🇬🇧 [English](Core-Management-en) | 🇷🇺 [Русский](Core-Management-ru)
# Управление ядром
Re:HomeProxy **многоядерный**: приложение LuCI — это интерфейс, а само проксирование выполняет отдельный бинарник-**ядро**. Установка, обновление и переключение ядер выполняются на вкладке **Сервисы → Re:HomeProxy → Ядро и службы → Управление ядром** — без SSH.
---
## Выбор ядра
| | **hiddify-core** (по умолчанию) | **sing-box-extended** |
|---|---|---|
| Движок | Форк sing-box от команды Hiddify | Форк sing-box с доп. флагами сборки |
| Размер | Легче; есть **компактная сборка** для слабых устройств | Крупнее (~26 МБ установленного) |
| Протоколы | Протоколы Hiddify-app, TLS fragment, XHTTP, Mieru и др. | Самый широкий набор протоколов… |
| **AmneziaWG / WARP** | ❌ **Не поддерживается** | ✅ **Поддерживается** |
**Правило:** если нужен **AmneziaWG/WARP** или хочется максимально широкий набор протоколов и есть ~40 МБ свободного места — выбирайте **sing-box-extended**. Иначе **hiddify-core** — более лёгкий вариант по умолчанию и единственный с компактной сборкой для роутеров с малым объёмом памяти.
Какие протоколы появятся в редакторе узлов — зависит от установленного ядра; см. [Поддерживаемые протоколы](Supported-Protocols-ru).
---
## Установка — одна умная кнопка
На странице «Управление ядром» для каждого ядра есть единственная кнопка **Установить**. Она **не** спрашивает, какую сборку — «стандартную» или «сжатую» — выбрать. Вместо этого она проверяет устройство и подбирает сборку, которая действительно поместится:
1. Считывает свободное место на `/overlay` (постоянная флеш-память) и свободную ОЗУ.
2. Для hiddify-core: если полная сборка помещается → ставит **стандартную**. Если места мало, но ОЗУ хватает → ставит **компактную** и сообщает об этом.
3. Если не помещается ни одна → останавливается с понятным сообщением, а не ставит заведомо нерабочее.
### Зачем нужна эта защита
Бинарник ядра, который **больше свободного overlay**, при записи **обрезается** и затем падает с **«bus error» (SIGBUS)** при запуске — сбивающая с толку ошибка, похожая на повреждённую загрузку. Проверка размера в установщике существует именно для этого: он никогда не предложит сборку, которая не помещается на устройстве.
### Компактная сборка
Компактная (сжатая UPX) сборка hiddify-core занимает гораздо меньше места на флеше, но **распаковывается в ОЗУ при каждом запуске** — обмен места на флеше на память. Установщик выбирает её только при достаточном объёме свободной ОЗУ и показывает примечание вроде *«Мало места — устанавливается компактная сборка (распаковывается в ОЗУ при запуске)»*. На большинстве роутеров в повседневной работе это незаметно.
---
## Память — кратко
| Свободно на `/overlay` | Что устанавливается |
|------------------------|---------------------|
| ~40 МБ+ | hiddify-core или sing-box-extended (полная сборка) |
| ~25–40 МБ | hiddify-core (компактная сборка, если хватает ОЗУ) |
| < ~25 МБ | Недостаточно — освободите место или запеките ядро в собственный образ прошивки |
> На **сжимающем** overlay (jffs2/ubifs) полной сборке нужно меньше свободного места, чем сырая цифра, потому что ФС её сжимает. Установщик учитывает это автоматически — доверяйте его проверке, а не таблице выше.
Мало флеша, но собираете свой образ? Крупные ядра свободно помещаются, если **запечь их в SquashFS**-корень на этапе сборки образа (корень SquashFS сжат и доступен только для чтения), а не ставить в записываемый overlay.
---
## Переключение ядер и обновление
- **Обновление:** нажмите **Установить** снова — будет загружен и переустановлен последний релиз.
- **Переключение ядер:** установите другое ядро; если присутствуют оба, Re:HomeProxy использует настройку **Предпочтительное ядро** (на вкладке **Настройки клиента → Настройки маршрутизации**). Генератор конфигурации и служба учитывают ту же настройку, поэтому сгенерированный конфиг всегда соответствует ядру, которое его запустит.
- **Своё / внешнее ядро:** вместо управляемой установки можно указать Re:HomeProxy на **собственный бинарник ядра** (свою сборку или версию, которой нет в Releases) — он его обнаружит и использует. Только для продвинутых сценариев.
- **Версия / статус:** раздел **Управление ядром** показывает установленное ядро и версию. Если везде `?`, значит бэкенд (rpcd) устарел — перезапустите его (`/etc/init.d/rpcd restart`) и перезагрузите страницу.
---
## Ресурсы и обновления
На вкладке **Ядро и службы** также есть раздел **Управление ресурсами** для файлов данных, от которых зависит маршрутизация — баз GeoIP / Geosite и RU-списков:
- **Проверить обновление** скачивает свежие списки и гео-данные по запросу.
- RU-списки маршрутизации к тому же **сами обновляются** по расписанию, так что в обычной работе трогать это не нужно.
- **Подписки** обновляются отдельно — по запросу со вкладки «Подписки» или автоматически по cron; см. [Подписки и импорт узлов](Subscriptions-ru).
---
## Модули ядра
Для прозрачной маршрутизации прокси нужны `kmod-nft-tproxy` и `kmod-tun`. Установщик подтягивает их; если после свежей установки маршрутизация не работает — проверьте, что они присутствуют.
См. также: [ByeDPI](ByeDPI-ru) · [Zapret](Zapret-ru) · [Поддерживаемые протоколы](Supported-Protocols-ru) · [Устранение неполадок](Troubleshooting-ru)
homeproxy-hiddify/wiki/Custom-JSON-Config-en.md
+155
View File
@@ -0,0 +1,155 @@
🇬🇧 [English](Custom-JSON-Config-en) | 🇷🇺 [Русский](Custom-JSON-Config-ru)
# Custom JSON Config
**Custom JSON** is a routing mode that lets you bypass Re:HomeProxy's UCI-based configuration entirely and supply a raw [sing-box](https://sing-box.sagernet.org) / hiddify-core JSON config directly. It is intended for advanced users who need fine-grained control that the web UI does not expose.
To enable it, go to **Re:HomeProxy → Client → Routing Settings** and set **Routing Mode** to **Custom JSON**.
---
## Config Structure
A hiddify-core config is a JSON object. The main top-level sections are:
| Section | Purpose |
|---------|---------|
| `log` | Logging level and output path |
| `dns` | DNS servers, rules, and strategy |
| `inbounds` | How traffic enters the proxy (tproxy, tun, socks, http, etc.) |
| `outbounds` | Where traffic exits (direct, proxy servers, chains) |
| `route` | Rules that map inbound traffic to outbounds |
| `experimental` | Cache database, clash API, and other experimental features |
A minimal working config needs at least one inbound, at least two outbounds (`proxy` + `direct`), and route rules to decide which traffic goes where.
**Full reference:** [sing-box Configuration](https://sing-box.sagernet.org/configuration/)
Specific sections:
- [DNS](https://sing-box.sagernet.org/configuration/dns/)
- [Inbounds](https://sing-box.sagernet.org/configuration/inbound/)
- [Outbounds](https://sing-box.sagernet.org/configuration/outbound/)
- [Route](https://sing-box.sagernet.org/configuration/route/)
---
## hiddify-core vs. sing-box
hiddify-core is a fork of sing-box and is largely config-compatible. The key differences:
- **Additional protocols** — hiddify-core may support protocols not yet upstream in sing-box, or support them earlier. This includes AnyTLS and extended options for some existing protocols. Check [Supported Protocols](Supported-Protocols-en) for what your installed build includes.
- **Hiddify-specific extensions** — some extra fields and options exist for hiddify's own features. These are documented in the [HiddifyCli guide](https://hiddify.com/app/HiddifyCli-guide/#run-config-or-subscription-link-in-hiddifycli-with-hiddifyapp-settings).
- **Version differences** — hiddify-core may be ahead of or behind a specific sing-box release. If a sing-box feature is missing, check the hiddify-core release notes.
When writing configs, start from the sing-box documentation and refer to the hiddify-core guide for anything that does not behave as expected.
---
## Example Skeleton
```json
{
"log": {
"level": "info"
},
"dns": {
"servers": [
{ "tag": "remote", "address": "tls://1.1.1.1" },
{ "tag": "local", "address": "223.5.5.5", "detour": "direct" }
],
"rules": [
{ "geosite": "cn", "server": "local" }
]
},
"inbounds": [
{
"type": "tproxy",
"tag": "tproxy-in",
"listen": "::",
"listen_port": 5332
}
],
"outbounds": [
{
"type": "vless",
"tag": "proxy",
"server": "your.server.example",
"server_port": 443
},
{ "type": "direct", "tag": "direct" },
{ "type": "block", "tag": "block" },
{ "type": "dns", "tag": "dns-out" }
],
"route": {
"rules": [
{ "protocol": "dns", "outbound": "dns-out" },
{ "geosite": "cn", "outbound": "direct" },
{ "geoip": "cn", "outbound": "direct" }
],
"final": "proxy"
}
}
```
This is illustrative only — adjust inbound type/port, outbound settings, and routing rules to match your setup.
---
## Tips
- **Validate before saving.** An invalid JSON config will silently fail to apply. Use a JSON validator before pasting — syntax errors will not be reported in the UI. After saving, check the log (see below) to confirm the config loaded correctly.
- **Logs.** If the config applies but traffic does not work, check the core log in **Re:HomeProxy → Core & Tools** or via SSH: `tail -f /var/run/homeproxy/hiddify-c.log`.
- **Inbound ports.** Re:HomeProxy's firewall rules expect specific ports. If you change inbound ports in a custom config, the nftables redirect rules will not match and traffic will not reach your inbound. The default inbound configuration used by Re:HomeProxy is:
```json
"inbounds": [
{
"type": "direct",
"tag": "dns-in",
"listen": "::",
"listen_port": 5333
},
{
"type": "mixed",
"tag": "mixed-in",
"listen": "::",
"listen_port": 5330,
"udp_timeout": "300s",
"sniff": true,
"sniff_override_destination": true,
"set_system_proxy": false
},
{
"type": "redirect",
"tag": "redirect-in",
"listen": "::",
"listen_port": 5331,
"sniff": true,
"sniff_override_destination": true
},
{
"type": "tproxy",
"tag": "tproxy-in",
"listen": "::",
"listen_port": 5332,
"network": "udp",
"udp_timeout": "300s",
"sniff": true,
"sniff_override_destination": true
}
]
```
If you need to change these ports, update them both in your custom JSON and in `/etc/config/homeproxy` (the `proxy_port`, `redirect_port`, `tproxy_port`, and `dns_port` options) so the firewall rules stay in sync.
- **`default_mark`.** This is **required** in the `route` section to prevent tproxy routing loops. Without it, hiddify-core's own outbound traffic gets intercepted by the nftables tproxy rules and sent back to the proxy, causing a loop. The value must match `self_mark` in `/etc/config/homeproxy` (default: `100`):
```json
"route": {
"default_mark": 100,
...
}
```
If you change this value, update `self_mark` in `/etc/config/homeproxy` to match.
- **Outbound tags.** Route rules reference outbound tags by name — keep them consistent.
homeproxy-hiddify/wiki/Custom-JSON-Config-ru.md
+166
View File
@@ -0,0 +1,166 @@
🇬🇧 [English](Custom-JSON-Config-en) | 🇷🇺 [Русский](Custom-JSON-Config-ru)
# Пользовательский JSON конфиг
**Пользовательский JSON** — режим маршрутизации, позволяющий полностью обойти UCI-конфигурацию Re:HomeProxy и использовать «сырой» JSON-конфиг формата [sing-box](https://sing-box.sagernet.org) / hiddify-core напрямую. Предназначен для опытных пользователей, которым нужен тонкий контроль, недоступный через веб-интерфейс.
Чтобы включить режим: **Re:HomeProxy → Клиент → Настройки маршрутизации** → установить **Режим маршрутизации** в значение **Пользовательский JSON**.
Файл конфигурации размещается по пути `/etc/homeproxy/hiddify-c.json`.
---
## Структура конфига
Конфиг hiddify-core — это JSON-объект. Основные секции верхнего уровня:
| Секция | Назначение |
|--------|-----------|
| `log` | Уровень логирования и путь к файлу лога |
| `dns` | DNS-серверы, правила и стратегия разрешения |
| `inbounds` | Как трафик попадает в прокси (tproxy, tun, socks, http и др.) |
| `outbounds` | Куда трафик выходит (прямо, через прокси-серверы, цепочки) |
| `route` | Правила сопоставления входящего трафика с исходящими |
| `experimental` | Кэш, Clash API и другие экспериментальные возможности |
Минимальный рабочий конфиг требует как минимум одного inbound, двух outbound (`proxy` + `direct`) и правил маршрутизации.
**Полная документация:** [Конфигурация sing-box](https://sing-box.sagernet.org/configuration/)
Отдельные разделы:
- [DNS](https://sing-box.sagernet.org/configuration/dns/)
- [Inbounds](https://sing-box.sagernet.org/configuration/inbound/)
- [Outbounds](https://sing-box.sagernet.org/configuration/outbound/)
- [Route](https://sing-box.sagernet.org/configuration/route/)
---
## hiddify-core и sing-box
hiddify-core — форк sing-box, в целом совместимый по формату конфига. Ключевые отличия:
- **Дополнительные протоколы** — hiddify-core поддерживает протоколы, которых нет в upstream sing-box или которые появились в нём позже. Это AnyTLS, расширенные опции для некоторых существующих протоколов. Полный список — на странице [Поддерживаемые протоколы](Supported-Protocols-ru).
- **Расширения hiddify** — некоторые дополнительные поля и опции специфичны для hiddify. Они задокументированы в [руководстве HiddifyCli](https://hiddify.com/app/HiddifyCli-guide/#run-config-or-subscription-link-in-hiddifycli-with-hiddifyapp-settings).
- **Различия версий** — hiddify-core может опережать или отставать от конкретного релиза sing-box. Если функция sing-box не работает — проверьте release notes hiddify-core.
При написании конфигов отталкивайтесь от документации sing-box, обращаясь к руководству hiddify-core там, где поведение отличается.
---
## Пример скелета конфига
```json
{
"log": {
"disabled": false,
"level": "warn",
"output": "/var/run/homeproxy/hiddify-c.log",
"timestamp": true
},
"dns": {
"servers": [
{ "tag": "remote", "address": "tls://1.1.1.1" },
{ "tag": "local", "address": "223.5.5.5", "detour": "direct" }
],
"rules": [
{ "geosite": "cn", "server": "local" }
]
},
"inbounds": [
{
"type": "tproxy",
"tag": "tproxy-in",
"listen": "::",
"listen_port": 5332,
"network": "udp",
"sniff": true
}
],
"outbounds": [
{
"type": "vless",
"tag": "proxy",
"server": "your.server.example",
"server_port": 443
},
{ "type": "direct", "tag": "direct" },
{ "type": "block", "tag": "block" },
{ "type": "dns", "tag": "dns-out" }
],
"route": {
"default_mark": 100,
"rules": [
{ "protocol": "dns", "outbound": "dns-out" },
{ "geosite": "cn", "outbound": "direct" },
{ "geoip": "cn", "outbound": "direct" }
],
"final": "proxy"
}
}
```
Это только иллюстрация — адаптируйте тип/порт inbound, настройки outbound и правила маршрутизации под свою конфигурацию.
---
## Советы
- **Проверяйте перед сохранением.** Некорректный JSON будет молча проигнорирован. Используйте JSON-валидатор перед вставкой — ошибки синтаксиса не отображаются в интерфейсе. После сохранения проверьте лог (см. ниже), чтобы убедиться, что конфиг загрузился корректно.
- **Логи.** Если конфиг применился, но трафик не работает — проверьте лог ядра в **Re:HomeProxy → Ядро и службы** или через SSH: `tail -f /var/run/homeproxy/hiddify-c.log`.
- **Порты входящих соединений.** Правила файрвола Re:HomeProxy ожидают конкретные порты. Если вы меняете порты inbound в пользовательском JSON, правила nftables перестанут совпадать и трафик не достигнет inbound. Стандартная конфигурация inbounds, используемая Re:HomeProxy:
```json
"inbounds": [
{
"type": "direct",
"tag": "dns-in",
"listen": "::",
"listen_port": 5333
},
{
"type": "mixed",
"tag": "mixed-in",
"listen": "::",
"listen_port": 5330,
"udp_timeout": "300s",
"sniff": true,
"sniff_override_destination": true,
"set_system_proxy": false
},
{
"type": "redirect",
"tag": "redirect-in",
"listen": "::",
"listen_port": 5331,
"sniff": true,
"sniff_override_destination": true
},
{
"type": "tproxy",
"tag": "tproxy-in",
"listen": "::",
"listen_port": 5332,
"network": "udp",
"udp_timeout": "300s",
"sniff": true,
"sniff_override_destination": true
}
]
```
Если нужно изменить порты — обновите их и в пользовательском JSON, и в `/etc/config/homeproxy` (опции `mixed_port`, `redirect_port`, `tproxy_port`, `dns_port`), чтобы правила файрвола оставались согласованными.
- **`default_mark`.** **Обязательное** поле в секции `route` для предотвращения петель маршрутизации tproxy. Без него собственный исходящий трафик hiddify-core перехватывается правилами nftables и снова направляется в прокси. Значение должно совпадать с `self_mark` в `/etc/config/homeproxy` (по умолчанию: `100`):
```json
"route": {
"default_mark": 100,
...
}
```
Если вы меняете это значение — обновите `self_mark` в `/etc/config/homeproxy` соответственно.
- **Теги outbound.** Правила маршрутизации ссылаются на outbound по имени тега — следите за их согласованностью.
homeproxy-hiddify/wiki/Custom-Routing-en.md
+66
View File
@@ -0,0 +1,66 @@
🇬🇧 [English](Custom-Routing-en) | 🇷🇺 [Русский](Custom-Routing-ru)
# Custom Routing
**Custom routing** is the manual middle ground between the ready-made [routing modes](Routing-and-Access-Control-en) and a hand-written [Custom JSON](Custom-JSON-Config-en) config. You build your own **routing nodes** (where traffic can exit) and **routing rules** (which traffic goes where) in the LuCI UI, without writing JSON.
Set it on **Client → Routing Settings → Routing mode → Custom routing**. Two extra tabs appear: **Routing Nodes** and **Routing Rules**.
> You don't have to switch the whole router to Custom routing: in **Russia (Proxy Banned)** mode, ticking **Advanced custom rules** 👨‍💻 reveals these same two tabs so you can layer custom rules *on top of* the RU presets. See [Routing & Access Control](Routing-and-Access-Control-en).
---
## Routing Nodes
A **routing node** is a named outbound that rules can target. Each can be:
- a specific **node**, or **URLTest** (auto-pick the fastest from a pool),
- a **chain** — via the **Outbound** field, send this node's traffic *through* another routing node,
- with its own **Domain resolver** (including the Russia 🔓 / Secure 🔒 servers in RU mode) and **Domain strategy** (IPv4-only, prefer IPv6, etc.).
This is what lets you do things like "this rule → node A, but resolve its domains with the secure DNS" or build a multi-hop chain.
---
## Routing Rules
Each **routing rule** matches some traffic and sends it to a routing node (or **Direct**). The editor groups the match fields into tabs:
| Tab | Matches on |
|-----|-----------|
| **Other fields** | **Protocol** (sniffed — BitTorrent, DNS, QUIC, TLS, HTTP, STUN, SSH, RDP, DTLS…), **IP version**, network, rule-sets |
| **Host/IP fields** | `domain` / `domain_suffix` / `domain_keyword` / `domain_regex`, destination & source **IP CIDR** |
| **Port fields** | destination / source **port** and port ranges |
| **Process fields** | **process name / path** (for traffic originating on the router itself) |
The **Mode** field shows the matching logic — within a category the entries are OR-ed, and the categories are AND-ed together:
```
(domain || domain_suffix || domain_keyword || domain_regex || ip_cidr || ip_is_private) &&
(port || port_range) &&
(source_ip_cidr || source_ip_is_private) &&
(source_port || source_port_range) &&
(other fields)
```
Rules are evaluated top to bottom (the list is sortable) and the first match wins. The fields map one-to-one to sing-box's route rule — for exactly what each accepts, see the upstream reference:
- [Route](https://sing-box.sagernet.org/configuration/route/) — how routing is structured
- [Route Rule](https://sing-box.sagernet.org/configuration/route/rule/) — every match field
- [Sniff](https://sing-box.sagernet.org/configuration/route/sniff/) — **Protocol** matching needs sniffing enabled (it is, by default)
> **Protocol matching needs sniffing.** Matching by `quic`, `tls`, `bittorrent`, etc. relies on the inbound sniffing the first packets — Re:HomeProxy enables this on its inbounds, so it works out of the box.
---
## Custom routing vs Custom JSON
| | **Custom routing** | **[Custom JSON](Custom-JSON-Config-en)** |
|---|---|---|
| How | UI: Routing Nodes + Routing Rules | Raw sing-box / hiddify-core JSON |
| Good for | Per-app/site/IP rules without writing JSON | Full control, fields the UI doesn't expose |
| Validation | UI-guided | You must validate the JSON yourself |
Start with Custom routing; drop to Custom JSON only when you need something the rule editor can't express.
See also: [Routing & Access Control](Routing-and-Access-Control-en) · [Custom JSON Config](Custom-JSON-Config-en) · [Supported Protocols](Supported-Protocols-en) · [DNS & Diagnostics](DNS-and-Diagnostics-en)
homeproxy-hiddify/wiki/Custom-Routing-ru.md
+66
View File
@@ -0,0 +1,66 @@
🇬🇧 [English](Custom-Routing-en) | 🇷🇺 [Русский](Custom-Routing-ru)
# Пользовательская маршрутизация
**Пользовательская маршрутизация** — это ручная золотая середина между готовыми [режимами маршрутизации](Routing-and-Access-Control-ru) и конфигом [Пользовательский JSON](Custom-JSON-Config-ru), написанным руками. Вы сами собираете **узлы маршрутизации** (откуда может выходить трафик) и **правила маршрутизации** (какой трафик куда идёт) в интерфейсе LuCI, не написав ни строчки JSON.
Включается в **Настройки клиента → Настройки маршрутизации → Режим маршрутизации → Пользовательская маршрутизация**. Появляются две вкладки: **Правила узлов** и **Расширенные правила**.
> Переключать на пользовательскую маршрутизацию весь роутер необязательно: в режиме **Россия (Обход Блокировок)** галочка **Расширенные правила** 👨‍💻 открывает те же две вкладки, чтобы добавлять свои правила *поверх* RU-пресетов. См. [Маршрутизация и контроль доступа](Routing-and-Access-Control-ru).
---
## Правила узлов
**Узел маршрутизации** — это именованный outbound, на который могут указывать правила. Каждый может быть:
- конкретным **узлом** или **URLTest** (авто-выбор самого быстрого из пула),
- **цепочкой** — через поле **outbound** направить трафик этого узла *через* другой узел маршрутизации,
- со своим **Резолвером доменов** (включая серверы Россия 🔓 / Защищённый 🔒 в режиме РФ) и **Стратегией доменов** (только IPv4, предпочитать IPv6 и т. п.).
Именно это позволяет делать вещи вроде «это правило → узел A, но домены резолвить защищённым DNS» или строить многошаговую цепочку.
---
## Расширенные правила
Каждое **правило маршрутизации** сопоставляет какой-то трафик и отправляет его на узел маршрутизации (или **Напрямую**). Поля сопоставления в редакторе сгруппированы по вкладкам:
| Вкладка | Сопоставление по |
|---------|------------------|
| **Прочие поля** | **Протокол** (по сниффингу — BitTorrent, DNS, QUIC, TLS, HTTP, STUN, SSH, RDP, DTLS…), **Версия IP**, сеть, rule-set-ы |
| **Поля хоста/IP** | `domain` / `domain_suffix` / `domain_keyword` / `domain_regex`, **IP CIDR** назначения и источника |
| **Поля портов** | **порт** и диапазоны портов назначения / источника |
| **Поля процесса** | **имя / путь процесса** (для трафика, исходящего с самого роутера) |
Поле **Режим** показывает логику сопоставления — внутри категории записи объединяются по ИЛИ, а категории — по И:
```
(domain || domain_suffix || domain_keyword || domain_regex || ip_cidr || ip_is_private) &&
(port || port_range) &&
(source_ip_cidr || source_ip_is_private) &&
(source_port || source_port_range) &&
(прочие поля)
```
Правила проверяются сверху вниз (список сортируемый), срабатывает первое совпавшее. Поля один-в-один соответствуют route-правилу sing-box — что именно принимает каждое поле, см. в официальном справочнике:
- [Route](https://sing-box.sagernet.org/configuration/route/) — как устроена маршрутизация
- [Route Rule](https://sing-box.sagernet.org/configuration/route/rule/) — все поля сопоставления
- [Sniff](https://sing-box.sagernet.org/configuration/route/sniff/) — сопоставление по **Протоколу** требует включённого сниффинга (он включён по умолчанию)
> **Сопоставление по протоколу требует сниффинга.** Матч по `quic`, `tls`, `bittorrent` и т. п. опирается на анализ первых пакетов на inbound-е — Re:HomeProxy включает это на своих inbound-ах, так что работает из коробки.
---
## Пользовательская маршрутизация vs Пользовательский JSON
| | **Пользовательская маршрутизация** | **[Пользовательский JSON](Custom-JSON-Config-ru)** |
|---|---|---|
| Как | Интерфейс: Правила узлов + Расширенные правила | «Сырой» JSON sing-box / hiddify-core |
| Для чего | Правила по приложению/сайту/IP без написания JSON | Полный контроль, поля, которых нет в интерфейсе |
| Проверка | С подсказками интерфейса | JSON нужно валидировать самому |
Начинайте с пользовательской маршрутизации; переходите на Пользовательский JSON, только когда нужно что-то, что редактор правил выразить не может.
См. также: [Маршрутизация и контроль доступа](Routing-and-Access-Control-ru) · [Пользовательский JSON конфиг](Custom-JSON-Config-ru) · [Поддерживаемые протоколы](Supported-Protocols-ru) · [DNS и диагностика](DNS-and-Diagnostics-ru)
homeproxy-hiddify/wiki/DNS-and-Diagnostics-en.md
+61
View File
@@ -0,0 +1,61 @@
🇬🇧 [English](DNS-and-Diagnostics-en) | 🇷🇺 [Русский](DNS-and-Diagnostics-ru)
# DNS & Diagnostics
Two related topics: how Re:HomeProxy resolves names (and why that matters for leaks), and how to verify everything works.
---
## DNS
DNS is configured on **Client → Routing**. Which fields appear depends on the routing mode.
### Russia mode (`proxy_banned_ru`) — two resolvers
Russia mode splits DNS into a **clean** resolver and a **secure** resolver so that lookups go to the right place:
| Field | Purpose | Default |
|-------|---------|---------|
| **Russia DNS server 🔓** | Resolves **Russian** domains **directly**, without the proxy. Plain UDP DNS. | Yandex `77.88.8.8` (also SkyDNS, Comss.one, Cloudflare, Google) |
| **Secure DNS server 🔒** | Resolves **blocked** domains **through the proxy** using encrypted DNS (DoH/DoT), so your ISP can't see which blocked sites you look up. | Cloudflare DoH `https://cloudflare-dns.com/dns-query` (also Quad9, AdGuard, Google; DoT variants) |
This split matters: resolving a blocked domain over plain ISP DNS would either fail or leak the lookup, so blocked domains use encrypted DNS via the proxy, while ordinary Russian domains resolve fast and direct.
> **ByeDPI note:** when a node is ByeDPI, secure DNS is automatically detoured **direct** (not through ByeDPI), because the desync corrupts DoH/DoT. This is handled for you — see [ByeDPI](ByeDPI-en).
### Other modes
- **DNS server** — the general resolver (supports UDP/TCP/DoH/DoQ/DoT). Default `8.8.8.8`. Or `WAN DNS` to read it from the interface.
- **China DNS server** — used in *Bypass mainland China* mode for Chinese domains (default Aliyun `223.5.5.5`).
### Advanced: DNS Servers & DNS Rules
The **DNS Settings**, **DNS Servers**, and **DNS Rules** tabs (under Node Settings) let you define custom resolvers and per-domain DNS routing, including the **domain strategy** (IPv4-only, prefer IPv6, etc.). Most users never need these.
### IPv6 and leaks
In Russia mode, **IPv6 support is off by default on purpose**: the RU routing lists contain **no IPv6 CIDRs**, so any IPv6 traffic would bypass *both* the proxy and the rules — a silent leak. If your WAN has IPv6 and you want everything controlled, the safe choice is to **leave IPv6 disabled** rather than enabling `ipv6_support`.
---
## Diagnostics
The **Diagnostics** page (Services → Re:HomeProxy → Diagnostics) runs live checks. Each card has its own **Check** button.
| Card | What it shows |
|------|---------------|
| **Connectivity** | Reachability of test sites. On **hiddify-core** it also shows your **Direct IP** vs **Proxy IP** (the two should differ when traffic is actually proxied); on **sing-box-extended** it shows the live **Active Node** instead, because sing-box can't report the exit IP. |
| **Core & System** | Whether the core (hiddify-core / sing-box-extended) and ByeDPI are installed, the active binary, version, whether they're running (with PID), and listening ports. Includes a **Restart Service** button. |
| **Configuration** | Whether the generated core config is **valid**, its size, and counts of inbounds / outbounds / rules. |
| **DNS Tests** | Checks that DNS resolution works through the configured resolvers. |
| **Network Intercept** | The nft/firewall interception state — UCI firewall settings and, when Zapret is on, the **Zapret NFQUEUE counters** (mark 110 → queue) so you can confirm packets are reaching nfqws2. |
| **Diagnostics Report** | **Generate** a shareable plain-text report bundling the above — paste it when asking for help. |
### Reading the results
- **Direct IP == Proxy IP** (hiddify-core) → traffic isn't being proxied (check main node / routing mode / access control). On sing-box-extended, confirm the **Active Node** row shows your chosen node instead.
- **Core not running** → use **Restart Service**; if status shows all `?`, the rpcd backend is stale (`/etc/init.d/rpcd restart`, wait ~2 s).
- **Config invalid** → a node or rule is malformed; the report names the error.
- **Zapret counters not incrementing** → the strategy/queue isn't catching traffic — see [Zapret](Zapret-en).
See also: [Getting Started](Getting-Started-en) · [Routing & Access Control](Routing-and-Access-Control-en) · [ByeDPI](ByeDPI-en) · [Zapret](Zapret-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/DNS-and-Diagnostics-ru.md
+61
View File
@@ -0,0 +1,61 @@
🇬🇧 [English](DNS-and-Diagnostics-en) | 🇷🇺 [Русский](DNS-and-Diagnostics-ru)
# DNS и диагностика
Две связанные темы: как Re:HomeProxy резолвит имена (и почему это важно для утечек) и как проверить, что всё работает.
---
## DNS
DNS настраивается в **Настройки клиента → Настройки маршрутизации**. Какие поля видны, зависит от режима маршрутизации.
### Режим России (`proxy_banned_ru`) — два резолвера
Режим России разделяет DNS на **чистый** и **защищённый** резолверы, чтобы запросы уходили туда, куда нужно:
| Поле | Назначение | По умолчанию |
|------|------------|--------------|
| **DNS-сервер России 🔓** | Резолвит **российские** домены **напрямую**, без прокси. Обычный UDP DNS. | Yandex `77.88.8.8` (также SkyDNS, Comss.one, Cloudflare, Google) |
| **Защищённый DNS-сервер 🔒** | Резолвит **заблокированные** домены **через прокси** по шифрованному DNS (DoH/DoT), чтобы провайдер не видел, какие заблокированные сайты вы ищете. | Cloudflare DoH `https://cloudflare-dns.com/dns-query` (также Quad9, AdGuard, Google; варианты DoT) |
Это разделение важно: резолв заблокированного домена через обычный DNS провайдера либо не сработает, либо приведёт к утечке запроса, поэтому заблокированные домены идут по шифрованному DNS через прокси, а обычные российские — быстро и напрямую.
> **Про ByeDPI:** когда узел — ByeDPI, защищённый DNS автоматически уводится **напрямую** (не через ByeDPI), так как рассинхрон ломает DoH/DoT. Это делается за вас — см. [ByeDPI](ByeDPI-ru).
### Другие режимы
- **DNS-сервер** — общий резолвер (поддерживает UDP/TCP/DoH/DoQ/DoT). По умолчанию `8.8.8.8`. Или `WAN DNS`, чтобы взять его с интерфейса.
- **DNS-сервер для Китая** — используется в режиме *Китай - Direct* для китайских доменов (по умолчанию Aliyun `223.5.5.5`).
### Продвинутое: DNS-серверы и DNS-правила
Вкладки **Настройки DNS**, **DNS-серверы** и **DNS-правила** (в Настройках узлов) позволяют задать свои резолверы и пер-доменную маршрутизацию DNS, включая **стратегию доменов** (только IPv4, предпочитать IPv6 и т. п.). Большинству пользователей это не нужно.
### IPv6 и утечки
В режиме России **поддержка IPv6 по умолчанию выключена намеренно**: RU-списки маршрутизации **не содержат IPv6-подсетей**, поэтому любой IPv6-трафик обошёл бы *и* прокси, *и* правила — тихая утечка. Если на WAN есть IPv6 и вы хотите всё контролировать, безопаснее **оставить IPv6 выключенным**, а не включать `ipv6_support`.
---
## Диагностика
Страница **Диагностика** (Сервисы → Re:HomeProxy → Диагностика) запускает живые проверки. У каждой карточки своя кнопка **Проверить**.
| Карточка | Что показывает |
|----------|----------------|
| **Проверка соединения** | Доступность тестовых сайтов. На **hiddify-core** также показывает ваш **IP провайдера** против **IP прокси** (при реальном проксировании они должны различаться); на **sing-box-extended** вместо этого показывает **Активный узел**, так как sing-box не может сообщить исходящий IP. |
| **Ядро и система** | Установлены ли ядро (hiddify-core / sing-box-extended) и ByeDPI, активный бинарник, версия, запущены ли они (с PID) и слушаемые порты. Есть кнопка **Перезапустить службу**. |
| **Конфигурация** | Валиден ли сгенерированный конфиг ядра, его размер и счётчики inbound / outbound / правил. |
| **Тест DNS** | Проверяет, что резолв DNS работает через настроенные резолверы. |
| **Перехват трафика** | Состояние перехвата nft/firewall — настройки firewall в UCI и, при включённом Zapret, **счётчики Zapret NFQUEUE** (метка 110 → очередь), чтобы убедиться, что пакеты доходят до nfqws2. |
| **Отчёт диагностики** | **Сгенерировать** текстовый отчёт, объединяющий всё выше — приложите его при обращении за помощью. |
### Как читать результаты
- **IP провайдера == IP прокси** (hiddify-core) → трафик не проксируется (проверьте основной узел / режим маршрутизации / контроль доступа). На sing-box-extended убедитесь, что в строке **Активный узел** показан выбранный узел.
- **Ядро не запущено** → нажмите **Перезапустить службу**; если статус весь в `?`, бэкенд rpcd устарел (`/etc/init.d/rpcd restart`, подождите ~2 с).
- **Конфиг невалиден** → узел или правило некорректны; отчёт назовёт ошибку.
- **Счётчики Zapret не растут** → стратегия/очередь не ловит трафик — см. [Zapret](Zapret-ru).
См. также: [Первая настройка](Getting-Started-ru) · [Маршрутизация и контроль доступа](Routing-and-Access-Control-ru) · [ByeDPI](ByeDPI-ru) · [Zapret](Zapret-ru) · [Устранение неполадок](Troubleshooting-ru)
homeproxy-hiddify/wiki/Getting-Started-en.md
+96
View File
@@ -0,0 +1,96 @@
🇬🇧 [English](Getting-Started-en) | 🇷🇺 [Русский](Getting-Started-ru)
# Getting Started
This page walks you from a fresh install to a working connection. It assumes Re:HomeProxy is already installed (see the [README](../../blob/master/README.md) for package installation).
> Everything below is done in the LuCI web UI: **Services → Re:HomeProxy**.
---
## Step 1 — Install a core
The LuCI app is only the interface; a separate **core** binary does the proxying. Open **Core & Tools → Core management** and install one:
- **hiddify-core** (default) — lighter, has a compact build for small routers.
- **sing-box-extended** — needed for AmneziaWG/WARP and the widest protocol set.
The installer auto-picks a build that fits your storage. Full details: **[Core Management](Core-Management-en)**.
---
## Step 2 — Add at least one node
Open **Node Settings → Nodes**. A "node" is a proxy server you connect through. Add one by:
- **Import share links** — paste `vless://`, `vmess://`, `ss://`, `trojan://`, `vpn://` (Amnezia), Hysteria, etc.
- **Import .conf** — a WireGuard / AmneziaWG config file.
- **Subscription URL** — let the router pull and refresh a list of nodes automatically.
- **Manual** — fill the fields by hand.
All import methods and formats: **[Subscriptions & Node Import](Subscriptions-en)**.
---
## Step 3 — Select the main node
Back on the **Client** page, set **Main node** to the node you added — or choose **URLTest** to let Re:HomeProxy automatically pick and fail over to the fastest reachable node.
---
## Step 4 — Choose a routing mode
On the **Client → Routing** tab, pick **Routing mode**. The default depends on your LuCI language:
- **Russia (Proxy Banned)** — `proxy_banned_ru`, the default for Russian installs: everything goes **direct** except the destinations you add to **RU Proxy Rules** (blocked/throttled sites), which go through the proxy.
- **Global** — everything through the proxy.
- **GFWList / Bypass mainland China / Only proxy mainland China** — China-oriented presets.
- **Custom routing / Custom JSON** — full manual control.
For Russia, leave it on **Russia (Proxy Banned)** and open the **RU Proxy Rules** tab to enable the lists you need (Russia Inside, Re:Filter, YouTube, Discord…). Full reference: **[Routing & Access Control](Routing-and-Access-Control-en)**.
---
## Step 5 — Check the basic transport settings
Still on the **Routing** tab, the defaults are sensible:
- **Proxy mode** — `Redirect TCP + TProxy UDP` by default (TUN options appear if `kmod-tun` is installed).
- **IPv6 support** — **off** by default in Russia mode on purpose: the RU lists have no IPv6 CIDRs, so v6 traffic would bypass both the proxy and the rules. Leave it off unless you know you need it. See **[DNS & Diagnostics](DNS-and-Diagnostics-en)**.
---
## Step 6 — Save, apply, start
Press **Save & Apply**. Then start the service (it also auto-starts on boot):
```sh
/etc/init.d/homeproxy start
```
Watch the log at **Core & Tools**.
---
## Step 7 — Verify it works
Open the **Diagnostics** page and run the checks:
- **Connectivity** — confirms reachability of test sites. On **hiddify-core** it shows your **Direct IP** vs **Proxy IP** (they should differ when traffic is proxied); on **sing-box-extended** it shows the live **Active Node** instead (sing-box can't report the exit IP).
- **Core & System** — confirms the core is installed and running.
- **Configuration** — confirms the generated config is valid.
If something is off, see **[Troubleshooting](Troubleshooting-en)** and **[DNS & Diagnostics](DNS-and-Diagnostics-en)**.
---
## Optional — un-throttle sites without a VPN node
If a site (e.g. YouTube, Discord) is merely *throttled* rather than IP-blocked, you can offload it to a built-in DPI-bypass instead of spending VPN bandwidth:
- **[ByeDPI](ByeDPI-en)** — a SOCKS-level desync.
- **[Zapret](Zapret-en)** — a packet-level (nfqws2) desync.
Both can be selected per RU Proxy Rule (e.g. route only YouTube through ByeDPI/Zapret while the rest uses your VPN).
See also: [Core Management](Core-Management-en) · [Routing & Access Control](Routing-and-Access-Control-en) · [Subscriptions & Node Import](Subscriptions-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/Getting-Started-ru.md
+96
View File
@@ -0,0 +1,96 @@
🇬🇧 [English](Getting-Started-en) | 🇷🇺 [Русский](Getting-Started-ru)
# Первая настройка
Эта страница проведёт вас от свежей установки до рабочего соединения. Предполагается, что Re:HomeProxy уже установлен (установку пакетов см. в [README](../../blob/master/README_ru.md)).
> Всё ниже делается в веб-интерфейсе LuCI: **Сервисы → Re:HomeProxy**.
---
## Шаг 1 — Установите ядро
Приложение LuCI — это только интерфейс; проксированием занимается отдельный бинарник **ядра**. Откройте **Ядро и службы → Управление ядром** и установите одно из них:
- **hiddify-core** (по умолчанию) — легче, есть компактная сборка для маленьких роутеров.
- **sing-box-extended** — нужно для AmneziaWG/WARP и самого широкого набора протоколов.
Установщик сам подберёт сборку под ваше хранилище. Подробно: **[Управление ядром](Core-Management-ru)**.
---
## Шаг 2 — Добавьте хотя бы один узел
Откройте **Настройки узлов → Узлы**. «Узел» — это прокси-сервер, через который вы подключаетесь. Добавить можно:
- **Импорт share-ссылок** — вставьте `vless://`, `vmess://`, `ss://`, `trojan://`, `vpn://` (Amnezia), Hysteria и т. п.
- **Импорт .conf** — файл конфигурации WireGuard / AmneziaWG.
- **Ссылка подписки** — роутер сам скачает и будет обновлять список узлов.
- **Вручную** — заполнить поля самостоятельно.
Все способы и форматы импорта: **[Подписки и импорт узлов](Subscriptions-ru)**.
---
## Шаг 3 — Выберите основной узел
На странице **Настройки клиента** задайте **Основной узел** = добавленный узел — или выберите **URLTest**, чтобы Re:HomeProxy автоматически выбирал самый быстрый доступный узел и переключался при сбоях.
---
## Шаг 4 — Выберите режим маршрутизации
На вкладке **Настройки клиента → Настройки маршрутизации** выберите **Режим маршрутизации**. Значение по умолчанию зависит от языка LuCI:
- **Россия (Обход Блокировок)** — `proxy_banned_ru`, по умолчанию для русских установок: всё идёт **напрямую**, кроме адресов, добавленных в **Правила прокси (РФ)** (заблокированные/троттлящиеся сайты) — они идут через прокси.
- **Глобальный** — весь трафик через прокси.
- **Китай - GFWList / Китай - Direct / Китай - Proxy** — пресеты для Китая.
- **Пользовательская маршрутизация / Пользовательский JSON** — полный ручной контроль.
Для России оставьте **Россия (Обход Блокировок)** и откройте вкладку **Правила прокси (РФ)**, чтобы включить нужные списки (Russia Inside, Re:Filter, YouTube, Discord…). Полный справочник: **[Маршрутизация и контроль доступа](Routing-and-Access-Control-ru)**.
---
## Шаг 5 — Проверьте базовые настройки транспорта
На той же вкладке **Настройки маршрутизации** значения по умолчанию разумны:
- **Режим прокси** — по умолчанию `Redirect TCP + TProxy UDP` (опции TUN появляются при установленном `kmod-tun`).
- **Поддержка IPv6** — **выключена** по умолчанию в режиме России намеренно: в RU-списках нет IPv6-подсетей, поэтому v6-трафик обошёл бы и прокси, и правила. Оставьте выключенной, если не уверены, что она нужна. См. **[DNS и диагностика](DNS-and-Diagnostics-ru)**.
---
## Шаг 6 — Сохраните, примените, запустите
Нажмите **Сохранить и применить**. Затем запустите службу (она также стартует при загрузке):
```sh
/etc/init.d/homeproxy start
```
Логи — в разделе **Ядро и службы**.
---
## Шаг 7 — Проверьте, что всё работает
Откройте страницу **Диагностика** и запустите проверки:
- **Проверка соединения** — проверяет доступность тестовых сайтов. На **hiddify-core** показывает ваш **IP провайдера** против **IP прокси** (при проксировании они должны различаться); на **sing-box-extended** вместо этого показывает **Активный узел** (sing-box не может сообщить исходящий IP).
- **Ядро и система** — подтверждает, что ядро установлено и запущено.
- **Конфигурация** — подтверждает, что сгенерированный конфиг валиден.
Если что-то не так — см. **[Устранение неполадок](Troubleshooting-ru)** и **[DNS и диагностика](DNS-and-Diagnostics-ru)**.
---
## По желанию — обойти замедление без VPN
Если сайт (например, YouTube, Discord) просто *замедляется*, а не заблокирован по IP, его можно отдать встроенному обходу DPI вместо расхода трафика VPN:
- **[ByeDPI](ByeDPI-ru)** — рассинхронизация на уровне SOCKS.
- **[Zapret](Zapret-ru)** — рассинхронизация на уровне пакетов (nfqws2).
Оба выбираются для конкретного правила Правила прокси (РФ) (например, направить через ByeDPI/Zapret только YouTube, а остальное — через VPN).
См. также: [Управление ядром](Core-Management-ru) · [Маршрутизация и контроль доступа](Routing-and-Access-Control-ru) · [Подписки и импорт узлов](Subscriptions-ru) · [Устранение неполадок](Troubleshooting-ru)
homeproxy-hiddify/wiki/Home.md
+39
View File
@@ -0,0 +1,39 @@
# Re:HomeProxy Wiki
---
## 🇬🇧 English
| Page | Description |
|------|-------------|
| [Getting Started](Getting-Started-en) | From a fresh install to a working connection, step by step |
| [Core Management](Core-Management-en) | Choosing hiddify-core vs sing-box-extended, the smart installer, storage and the compact build |
| [Supported Protocols](Supported-Protocols-en) | All supported proxy protocols, build requirements, transport options |
| [Subscriptions & Node Import](Subscriptions-en) | Share links, .conf, Amnezia vpn:// (AmneziaWG/Xray), subscriptions, base64 |
| [Routing & Access Control](Routing-and-Access-Control-en) | Routing modes, RU Proxy Rules, per-device access control |
| [Server Settings](Server-Settings-en) | Run the router as a proxy server — inbounds, types, TLS/ACME |
| [DNS & Diagnostics](DNS-and-Diagnostics-en) | Clean vs secure DNS, IPv6 leaks, and the Diagnostics page |
| [ByeDPI](ByeDPI-en) | SOCKS-level DPI-bypass — un-throttle sites without a VPN, strategy presets and the tester |
| [Zapret](Zapret-en) | Packet-level (nfqws2) DPI-bypass — per-rule desync, presets, Discord voice and the tester |
| [Custom Routing](Custom-Routing-en) | UI routing nodes + rules — match by domain/IP/port/protocol/process |
| [Custom JSON Config](Custom-JSON-Config-en) | Using the Custom JSON routing mode with raw hiddify-core config |
| [Troubleshooting](Troubleshooting-en) | Common errors and how to fix them |
---
## 🇷🇺 Русский
| Страница | Описание |
|----------|----------|
| [Первая настройка](Getting-Started-ru) | От свежей установки до рабочего соединения, по шагам |
| [Управление ядром](Core-Management-ru) | Выбор hiddify-core или sing-box-extended, умный установщик, память и компактная сборка |
| [Поддерживаемые протоколы](Supported-Protocols-ru) | Все поддерживаемые протоколы, требования к сборке, варианты транспорта |
| [Подписки и импорт узлов](Subscriptions-ru) | Share-ссылки, .conf, Amnezia vpn:// (AmneziaWG/Xray), подписки, base64 |
| [Маршрутизация и контроль доступа](Routing-and-Access-Control-ru) | Режимы маршрутизации, RU Proxy Rules, пер-девайс контроль доступа |
| [Настройки сервера](Server-Settings-ru) | Роутер как прокси-сервер — inbound-ы, типы, TLS/ACME |
| [DNS и диагностика](DNS-and-Diagnostics-ru) | Чистый и защищённый DNS, утечки IPv6 и страница диагностики |
| [ByeDPI](ByeDPI-ru) | Обход DPI на уровне SOCKS — разблокировка сайтов без VPN, пресеты стратегий и тестер |
| [Zapret](Zapret-ru) | Обход DPI на уровне пакетов (nfqws2) — рассинхронизация по правилам, пресеты, голос Discord и тестер |
| [Пользовательская маршрутизация](Custom-Routing-ru) | Узлы и правила маршрутизации в UI — матч по домену/IP/порту/протоколу/процессу |
| [Пользовательский JSON конфиг](Custom-JSON-Config-ru) | Использование режима «Пользовательский JSON» с конфигом hiddify-core |
| [Устранение неполадок](Troubleshooting-ru) | Типичные ошибки и способы их устранения |
homeproxy-hiddify/wiki/Routing-and-Access-Control-en.md
+110
View File
@@ -0,0 +1,110 @@
🇬🇧 [English](Routing-and-Access-Control-en) | 🇷🇺 [Русский](Routing-and-Access-Control-ru)
# Routing & Access Control
Re:HomeProxy decides **what** traffic is proxied (routing mode + rules) and **which devices** are affected (access control). This page covers both.
---
## Routing modes
Set on **Client → Routing → Routing mode**:
| Mode | What it does |
|------|--------------|
| **Russia (Proxy Banned)** (`proxy_banned_ru`) | Default for RU. Everything is **direct** except destinations added to **RU Proxy Rules**, which go through the proxy. |
| **Global** | All traffic through the proxy. |
| **GFWList** | Proxies a built-in list of commonly blocked (GFW) domains. |
| **Bypass mainland China** | Everything proxied except mainland-China destinations (direct). |
| **Only proxy mainland China** | Only mainland-China destinations proxied. |
| **Custom routing** | Manual routing nodes + rules (advanced). |
| **Custom JSON** | Hand-written hiddify-core config — see [Custom JSON Config](Custom-JSON-Config-en). |
**Routing ports** — restrict which destination ports are proxied (e.g. *Common ports only* to keep P2P traffic direct).
**Proxy mode** — how traffic is intercepted: `Redirect TCP`, `Redirect TCP + TProxy UDP` (default), `Redirect TCP + Tun UDP`, or full `Tun TCP/UDP` (TUN modes need `kmod-tun`).
### Main node and a separate UDP node
On the **Routing Settings** tab, **Main node** sets where traffic exits (a specific node, or **URLTest** to auto-pick the fastest with its own pool, test interval and tolerance).
By default UDP follows the main node. Set **Main UDP node** to send **UDP/QUIC out a different node** than TCP — useful when your main node handles UDP poorly (or not at all), or when you want QUIC/voice on a node that's better at it. It has its own URLTest pool too. Leave it on *Same as main node* if you don't need the split.
---
## Russia (Proxy Banned) — the full UI
`proxy_banned_ru` is the default RU mode: **everything is direct except what you explicitly proxy.** When it is selected, the **Routing** tab gains the fields below and an extra **RU Proxy Rules** tab appears.
### Routing tab (in this mode)
| Field | What it does |
|-------|--------------|
| **Russia DNS server** 🔓 | Resolves Russian/normal domains **directly** (not through the proxy). Default *Yandex (77.88.8.8)*; also SkyDNS, Comss.one, and plain-UDP Cloudflare/Google. |
| **Secure DNS server** 🔒 | Resolves **blocked** domains **through the proxy** over encrypted DNS (DoH/DoT), so your ISP can't see those lookups. Default *Cloudflare DoH*; also Quad9 / AdGuard / Google (DoH and DoT). See [DNS & Diagnostics](DNS-and-Diagnostics-en). |
| **Proxy calls** 📞 | Route VoIP call ports (WhatsApp, Telegram, FaceTime…) through the proxy. Off by default. |
| **Do not proxify torrents** 🧲 | Force BitTorrent traffic (protocol + common ports) direct. Off by default. |
| **Advanced custom rules** 👨‍💻 | Reveal the **Routing Nodes** and **Routing Rules** tabs (see below). Off by default. |
| **Routing ports** | Limit which destination ports are proxied (e.g. *Common ports only* keeps P2P direct). |
| **Proxy mode** | How traffic is intercepted — see [Routing modes](#routing-modes) above. |
### RU Proxy Rules tab
This is where you choose *what* to proxy. **The default route is Direct** — only the rules you add here are proxied. Each rule = a **Source list** ⤵️ + a **Node** 🔗 to send it through, applied with automatic priority:
1. **Smaller service lists** first — YouTube, Twitter/X, TikTok, Telegram, Discord, Roblox, Meta (Facebook/Instagram), Google AI, Google Play, anime, HDRezka, international news, adult, GeoBlock, HODCA, and cloud/CDN ranges (Cloudflare, CloudFront, OVH, Hetzner, DigitalOcean).
2. **Russia Inside** (1000+ domains, by itdoginfo) — the in-Russia must-have set.
3. **Re:Filter** (60000+ domains + 25000+ IPs) — the Roskomnadzor blocklist.
The lists are community-maintained and **self-refresh** on the router; you only pick which to enable. (Adding the same source twice is flagged — only the first rule takes effect.)
**Per-rule Node** 🔗 can be:
- **Same as main node** — use your main proxy.
- **Separate URLTest** — auto-select among a chosen set of nodes, with its own **URLTest nodes**, **Test interval** (default 180 s) and **Test tolerance** (default 150 ms).
- **A specific node**.
- **ByeDPI** or **Zapret** — send that list through a DPI-bypass instead of a VPN node (e.g. YouTube via [ByeDPI](ByeDPI-en) / [Zapret](Zapret-en) to save VPN bandwidth).
### Advanced custom rules (optional)
Enabling **Advanced custom rules** 👨‍💻 layers two extra tabs on top of the RU presets:
- **Routing Nodes** — define named outbounds (a node, a URLTest group, or a chained **Outbound**), each with its own **Domain resolver** (including the Russia 🔓 / Secure 🔒 servers) and **Domain strategy**.
- **Routing Rules** — match traffic by domain / IP / port / protocol and send it to one of those routing nodes.
Full reference for both tabs (and the standalone **Custom routing** mode): **[Custom Routing](Custom-Routing-en)**.
---
## Access Control — which devices are affected
**Client → Access Control** controls *which LAN devices* the proxy applies to. There are several **independent** controls — they combine, they are not one dropdown:
### LAN IP Policy
- **Proxy mode for devices** — the global gate:
- **Disable** — no per-device restriction (all LAN devices follow the routing rules).
- **Proxy listed only** — only the listed IPs/MACs are proxied.
- **Proxy all except listed** — everyone is proxied except the listed IPs/MACs (which go direct).
- **Gaming mode** *(independent list)* — for the selected devices, **only TCP** is proxied (UDP/game traffic stays direct for lower latency).
- **Global proxy** *(independent list)* — for the selected devices, **all** traffic goes through the proxy regardless of the routing rules.
Each of these is its own IP/MAC list, so you can mix them per device.
### WAN IP Policy
Force specific **destination** IPs/CIDRs to be proxied or direct, regardless of mode.
### Proxy / Direct Domain Lists
Free-form domain lists that are always proxied or always direct — useful for one-off destinations not covered by the RU lists.
---
## Tips
- In Russia mode, start with **Russia Inside + Re:Filter** enabled; add per-service lists only if a specific site still misbehaves.
- If a site is *throttled* (slow) rather than *blocked* (unreachable), route it through [ByeDPI](ByeDPI-en) or [Zapret](Zapret-en) instead of the VPN.
- Use the [Diagnostics](DNS-and-Diagnostics-en) page to confirm traffic is actually being proxied — **Direct IP vs Proxy IP** on hiddify-core, or the **Active Node** row on sing-box-extended.
See also: [Getting Started](Getting-Started-en) · [Subscriptions & Node Import](Subscriptions-en) · [DNS & Diagnostics](DNS-and-Diagnostics-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/Routing-and-Access-Control-ru.md
+110
View File
@@ -0,0 +1,110 @@
🇬🇧 [English](Routing-and-Access-Control-en) | 🇷🇺 [Русский](Routing-and-Access-Control-ru)
# Маршрутизация и контроль доступа
Re:HomeProxy решает, **какой** трафик проксировать (режим маршрутизации + правила) и **каких устройств** это касается (контроль доступа). Эта страница — про оба аспекта.
---
## Режимы маршрутизации
Задаётся в **Настройки клиента → Настройки маршрутизации → Режим маршрутизации**:
| Режим | Что делает |
|-------|------------|
| **Россия (Обход Блокировок)** (`proxy_banned_ru`) | По умолчанию для РФ. Всё идёт **напрямую**, кроме адресов в **Правила прокси (РФ)** — они через прокси. |
| **Глобальный** | Весь трафик через прокси. |
| **Китай - GFWList** | Проксирует встроенный список часто блокируемых (GFW) доменов. |
| **Китай - Direct** | Всё через прокси, кроме адресов материкового Китая (напрямую). |
| **Китай - Proxy** | Через прокси только адреса материкового Китая. |
| **Пользовательская маршрутизация** | Ручные узлы и правила маршрутизации (для продвинутых). |
| **Пользовательский JSON** | Конфиг hiddify-core вручную — см. [Пользовательский JSON конфиг](Custom-JSON-Config-ru). |
**Порты маршрутизации** — ограничить, какие порты назначения проксируются (например, *Только обычные порты*, чтобы P2P-трафик шёл напрямую).
**Режим прокси** — как перехватывается трафик: `Redirect TCP`, `Redirect TCP + TProxy UDP` (по умолчанию), `Redirect TCP + Tun UDP` или полный `Tun TCP/UDP` (режимы TUN требуют `kmod-tun`).
### Основной узел и отдельный UDP-узел
На вкладке **Настройки маршрутизации** поле **Основной узел** задаёт, через какой узел уходит трафик (конкретный узел или **URLTest** для авто-выбора самого быстрого, со своим пулом, интервалом и допуском теста).
По умолчанию UDP идёт через основной узел. Поле **Основной UDP-узел** позволяет отправлять **UDP/QUIC через другой узел**, чем TCP — полезно, если основной узел плохо (или вообще не) работает с UDP, или если хочется отдать QUIC/голос узлу, который с этим справляется лучше. У него тоже свой пул URLTest. Оставьте *Как основной узел*, если разделение не нужно.
---
## Россия (Обход Блокировок) — полный интерфейс
`proxy_banned_ru` — режим РФ по умолчанию: **весь трафик идёт напрямую, кроме того, что вы явно проксируете.** При его выборе на вкладке **Маршрутизация** появляются поля ниже, а также отдельная вкладка **Правила прокси (РФ)**.
### Вкладка «Маршрутизация» (в этом режиме)
| Поле | Что делает |
|------|------------|
| **DNS-сервер России** 🔓 | Разрешает российские/обычные домены **напрямую** (не через прокси). По умолчанию *Yandex (77.88.8.8)*; также SkyDNS, Comss.one и обычный UDP Cloudflare/Google. |
| **Защищённый DNS-сервер** 🔒 | Разрешает **заблокированные** домены **через прокси** по шифрованному DNS (DoH/DoT), чтобы провайдер не видел эти запросы. По умолчанию *Cloudflare DoH*; также Quad9 / AdGuard / Google (DoH и DoT). См. [DNS и диагностика](DNS-and-Diagnostics-ru). |
| **Проксировать звонки** 📞 | Направить порты VoIP-звонков (WhatsApp, Telegram, FaceTime…) через прокси. По умолчанию выключено. |
| **Не проксировать торренты** 🧲 | Заставить трафик BitTorrent (протокол + типичные порты) идти напрямую. По умолчанию выключено. |
| **Расширенные правила** 👨‍💻 | Открывает вкладки **Правила узлов** и **Расширенные правила** (см. ниже). По умолчанию выключено. |
| **Порты маршрутизации** | Ограничить, какие порты назначения проксируются (например, *только типичные порты* оставляет P2P напрямую). |
| **Режим прокси** | Как перехватывается трафик — см. [Режимы маршрутизации](#режимы-маршрутизации) выше. |
### Вкладка «Правила прокси (РФ)»
Здесь выбирается, *что* проксировать. **Маршрут по умолчанию — Напрямую**, проксируется только то, что вы добавите. Каждое правило = **список-источник** ⤵️ + **узел** 🔗, через который его отправлять. Правила применяются с автоматическим приоритетом:
1. Сначала **небольшие сервисные списки** — YouTube, Twitter/X, TikTok, Telegram, Discord, Roblox, Meta (Facebook/Instagram), Google AI, Google Play, аниме, HDRezka, международные новости, 18+, GeoBlock, HODCA и облачные/CDN-диапазоны (Cloudflare, CloudFront, OVH, Hetzner, DigitalOcean).
2. **Russia Inside** (1000+ доменов, от itdoginfo) — обязательный набор для РФ.
3. **Re:Filter** (60000+ доменов + 25000+ IP) — список блокировок Роскомнадзора.
Сами списки поддерживаются сообществом и **автообновляются** на роутере; вы только выбираете, какие включить. (Повторное добавление того же источника отмечается — сработает только первое правило.)
**Узел** 🔗 для каждого правила может быть:
- **Как основной узел** — ваш основной прокси.
- **Отдельный URLTest** — автовыбор среди заданного набора узлов, со своими **узлами URLTest**, **интервалом тестирования** (по умолчанию 180 с) и **допуском теста** (по умолчанию 150 мс).
- **Конкретный узел**.
- **ByeDPI** или **Zapret** — отправить список через обход DPI вместо VPN-узла (например, YouTube через [ByeDPI](ByeDPI-ru) / [Zapret](Zapret-ru), чтобы экономить трафик VPN).
### Расширенные правила (опционально)
Включение **Расширенных правил** 👨‍💻 добавляет две вкладки поверх RU-пресетов:
- **Правила узлов** — задают именованные исходящие (узел, группа URLTest или цепочка через **Исходящий**), у каждого свой **Резолвер доменов** (включая серверы Россия 🔓 / Защищённый 🔒) и **Стратегия доменов**.
- **Расширенные правила** — сопоставляют трафик по домену / IP / порту / протоколу и направляют его на один из этих узлов.
Полный справочник по обеим вкладкам (и по самостоятельному режиму **Пользовательская маршрутизация**): **[Пользовательская маршрутизация](Custom-Routing-ru)**.
---
## Контроль доступа — каких устройств это касается
**Настройки клиента → Контроль доступа** определяет, *к каким устройствам LAN* применяется прокси. Здесь несколько **независимых** механизмов — они комбинируются, это не один список:
### Политика IP для LAN
- **Режим проксирования устройств** — глобальный вентиль:
- **Отключить** — без пер-девайс ограничений (все устройства следуют правилам маршрутизации).
- **Проксировать только указанные** — проксируются только перечисленные IP/MAC.
- **Проксировать всё кроме указанных** — проксируются все, кроме перечисленных IP/MAC (те идут напрямую).
- **Игровой режим** *(независимый список)* — для выбранных устройств проксируется **только TCP** (UDP/игровой трафик идёт напрямую для меньшей задержки).
- **Глобальный прокси** *(независимый список)* — для выбранных устройств **весь** трафик идёт через прокси, независимо от правил маршрутизации.
Каждый из этих механизмов — свой список IP/MAC, так что их можно комбинировать по устройствам.
### Политика WAN IP
Принудительно проксировать или направлять напрямую конкретные **IP/подсети назначения**, независимо от режима.
### Списки доменов (прокси / напрямую)
Свободные списки доменов, которые всегда проксируются или всегда идут напрямую — удобно для разовых адресов, не покрытых RU-списками.
---
## Советы
- В режиме России начните с включённых **Russia Inside + Re:Filter**; добавляйте сервисные списки, только если конкретный сайт всё ещё работает плохо.
- Если сайт *троттлится* (медленный), а не *заблокирован* (недоступен), направьте его через [ByeDPI](ByeDPI-ru) или [Zapret](Zapret-ru) вместо VPN.
- Используйте страницу [Диагностика](DNS-and-Diagnostics-ru), чтобы убедиться, что трафик реально проксируется — **IP провайдера против IP прокси** на hiddify-core или строка **Активный узел** на sing-box-extended.
См. также: [Первая настройка](Getting-Started-ru) · [Подписки и импорт узлов](Subscriptions-ru) · [DNS и диагностика](DNS-and-Diagnostics-ru) · [Устранение неполадок](Troubleshooting-ru)
homeproxy-hiddify/wiki/Server-Settings-en.md
+51
View File
@@ -0,0 +1,51 @@
🇬🇧 [English](Server-Settings-en) | 🇷🇺 [Русский](Server-Settings-ru)
# Server Settings
Most of Re:HomeProxy is a **client** — the router dials *out* to proxy nodes. **Server Settings** is the reverse: it runs **inbounds** on the router so other devices can connect *in*. Use it to turn the router into your own endpoint (e.g. a home server you reach from a phone while away), or to expose a local SOCKS/HTTP proxy to the LAN.
Open it at **Services → Re:HomeProxy → Server Settings**. It is independent of client mode — run either, both, or neither. A fresh install has **no inbounds**; you add them here.
> ⚠️ An inbound opens a listening port. Turn on **Firewall** (below) only for inbounds you want reachable from the Internet, and always protect them with a strong password and/or TLS.
---
## Global
A single **Enable** switch turns the server subsystem on or off. Each inbound below also has its own enable toggle.
## Inbounds (Server settings)
Add one row per listener. The common fields:
| Field | Meaning |
|-------|---------|
| **Label** | A unique name for the inbound |
| **Enable** | Turn this inbound on/off |
| **Firewall** | *Allow access from the Internet* — off = reachable from LAN only, on = the port is opened on WAN |
| **Type** | The inbound protocol (see below) |
| **Listen address / Listen port** | Bind address (default `::`) and a unique port |
| **Username / Password** | Where the protocol uses credentials |
Per-protocol fields (encryption method, TLS, transport, multiplex…) appear in the edit dialog **after you pick a Type**. They mirror sing-box's inbound options one-to-one — rather than repeat them here, see the **[sing-box inbound reference](https://sing-box.sagernet.org/configuration/inbound/)** for each field, and the per-type pages (e.g. [VLESS](https://sing-box.sagernet.org/configuration/inbound/vless/), [Trojan](https://sing-box.sagernet.org/configuration/inbound/trojan/), [Hysteria2](https://sing-box.sagernet.org/configuration/inbound/hysteria2/)).
### Inbound types
**Always available:** AnyTLS, HTTP, **Mixed** (HTTP + SOCKS on one port), Shadowsocks, SOCKS, Trojan, VLESS, VMess.
Core/build-dependent (the dropdown only shows them if your core supports them — check tags as in [Supported Protocols](Supported-Protocols-en)):
- **Hysteria, Hysteria2, NaïveProxy, TUIC** — require a `with_quic` build.
- **MTProxy** — sing-box-extended only.
## TLS & certificates
TLS-capable inbounds expose the usual controls (min/max version, cipher suites) plus either **your own certificate** or, on a `with_acme` build, **ACME** auto-issuance (Let's Encrypt / ZeroSSL, via HTTP-01 or DNS-01 challenge). These follow sing-box field-for-field — see **[sing-box TLS](https://sing-box.sagernet.org/configuration/shared/tls/)** and its [ACME section](https://sing-box.sagernet.org/configuration/shared/tls/#acme).
## Tips
- Quickest personal endpoint: **Mixed** + a strong password — point a client's SOCKS/HTTP proxy at the router's IP and port.
- Public, blocking-resistant endpoint: a TLS type (VLESS / Trojan / Hysteria2) with ACME **DNS-01**, so you don't have to expose port 80.
- Leave **Firewall** off for an inbound you only use from inside the LAN.
See also: [Supported Protocols](Supported-Protocols-en) · [Core Management](Core-Management-en) · [Getting Started](Getting-Started-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/Server-Settings-ru.md
+51
View File
@@ -0,0 +1,51 @@
🇬🇧 [English](Server-Settings-en) | 🇷🇺 [Русский](Server-Settings-ru)
# Настройки сервера
Бо́льшая часть Re:HomeProxy — это **клиент**: роутер сам подключается *наружу* к прокси-узлам. **Настройки сервера** — наоборот: роутер поднимает **входящие соединения (inbounds)**, чтобы другие устройства подключались *к нему*. Пригодится, чтобы сделать из роутера собственную точку входа (например, домашний сервер, к которому вы подключаетесь с телефона в поездке) или открыть локальный SOCKS/HTTP-прокси в LAN.
Открывается в **Сервисы → Re:HomeProxy → Настройки сервера**. Не зависит от клиентского режима — можно использовать любой из них, оба или ни одного. На свежей установке inbound-ов **нет** — вы добавляете их здесь.
> ⚠️ Inbound открывает слушающий порт. Включайте **Брандмауэр** (ниже) только для тех inbound-ов, которые должны быть доступны из интернета, и всегда защищайте их надёжным паролем и/или TLS.
---
## Глобально
Один переключатель **Включить** включает или выключает серверную подсистему. У каждого inbound-а ниже есть свой собственный переключатель.
## Inbound-ы (Настройки сервера)
Добавьте по одной строке на каждый слушатель. Общие поля:
| Поле | Что значит |
|------|------------|
| **Метка** | Уникальное имя inbound-а |
| **Включить** | Включить/выключить этот inbound |
| **Брандмауэр** | *Разрешить доступ из интернета* — выкл = доступен только из LAN, вкл = порт открывается на WAN |
| **Тип** | Протокол inbound-а (см. ниже) |
| **Адрес прослушивания / Порт прослушивания** | Адрес привязки (по умолчанию `::`) и уникальный порт |
| **Имя пользователя / Пароль** | Где протокол использует учётные данные |
Поля конкретного протокола (метод шифрования, TLS, транспорт, мультиплекс…) появляются в окне редактирования **после выбора Типа**. Они один-в-один повторяют опции inbound-ов sing-box — поэтому здесь они не дублируются, см. **[справочник inbound-ов sing-box](https://sing-box.sagernet.org/configuration/inbound/)** по каждому полю и страницы по типам (например, [VLESS](https://sing-box.sagernet.org/configuration/inbound/vless/), [Trojan](https://sing-box.sagernet.org/configuration/inbound/trojan/), [Hysteria2](https://sing-box.sagernet.org/configuration/inbound/hysteria2/)).
### Типы inbound-ов
**Всегда доступны:** AnyTLS, HTTP, **Смешанный** (HTTP + SOCKS на одном порту), Shadowsocks, SOCKS, Trojan, VLESS, VMess.
Зависят от ядра/сборки (в списке появляются только если ядро их поддерживает — проверьте теги, как в [Поддерживаемых протоколах](Supported-Protocols-ru)):
- **Hysteria, Hysteria2, NaïveProxy, TUIC** — требуют сборку `with_quic`.
- **MTProxy** — только sing-box-extended.
## TLS и сертификаты
Inbound-ы с TLS дают обычные настройки (мин./макс. версия, наборы шифров) плюс либо **ваш собственный сертификат**, либо, на сборке `with_acme`, авто-выпуск через **ACME** (Let's Encrypt / ZeroSSL, через HTTP-01 или DNS-01). Они повторяют sing-box поле-в-поле — см. **[TLS в sing-box](https://sing-box.sagernet.org/configuration/shared/tls/)** и его [раздел ACME](https://sing-box.sagernet.org/configuration/shared/tls/#acme).
## Советы
- Самая быстрая личная точка входа: **Смешанный** + надёжный пароль — направьте SOCKS/HTTP-прокси клиента на IP и порт роутера.
- Публичная, устойчивая к блокировкам точка входа: TLS-тип (VLESS / Trojan / Hysteria2) с ACME **DNS-01**, чтобы не открывать порт 80.
- Оставляйте **Брандмауэр** выключенным для inbound-а, которым пользуетесь только из LAN.
См. также: [Поддерживаемые протоколы](Supported-Protocols-ru) · [Управление ядром](Core-Management-ru) · [Первая настройка](Getting-Started-ru) · [Устранение неполадок](Troubleshooting-ru)
homeproxy-hiddify/wiki/Subscriptions-en.md
+94
View File
@@ -0,0 +1,94 @@
🇬🇧 [English](Subscriptions-en) | 🇷🇺 [Русский](Subscriptions-ru)
# Subscriptions & Node Import
There are four ways to get nodes into Re:HomeProxy. All live on **Node Settings → Nodes** (import buttons) and **Node Settings → Subscriptions**.
---
## 1. Import share links
The **Import share links** button accepts one link per line. Supported schemes:
| Scheme | Protocol |
|--------|----------|
| `vless://` | VLESS (incl. Reality, XHTTP) |
| `vmess://` | VMess (v2rayN format) |
| `ss://` | Shadowsocks / Shadowsocks 2022 |
| `trojan://` | Trojan |
| `hysteria://`, `hysteria2://`, `hy2://` | Hysteria / Hysteria2 |
| `tuic://` | TUIC |
| `naive://` | NaïveProxy |
| `mieru://` | Mieru |
| `ssh://` | SSH |
| `wireguard://` | WireGuard |
| `vpn://` | **AmneziaVPN** share link — see below |
### AmneziaVPN `vpn://` links
Re:HomeProxy fully decodes Amnezia's `vpn://` share format (`base64url(qCompress(zlib JSON))`) right in the browser — no helper tool needed. It reads the container inside and recognises **both** Amnezia config types automatically:
- **AmneziaWG** (`amnezia-awg` / `amnezia-awg2`) → an **AmneziaWG** node, with the full obfuscation parameter set (`Jc`, `Jmin`, `Jmax`, `S1`–`S4`, `H1`–`H4`, `I1`–`I5`), MTU, keepalive and keys. *Requires the sing-box-extended core* — see [Supported Protocols](Supported-Protocols-en).
- **Xray** (`amnezia-xray`) → the Xray outbound inside is parsed into a node, including **VLESS + Reality/TLS** and the transport (`ws`, `grpc`, `xhttp`/`splithttp`, HTTPUpgrade) with their settings.
So an Amnezia link works whether it carries an AmneziaWG or an Xray profile.
### Base64
Subscription and share-link payloads are very often **base64**-encoded — this is the norm, not an edge case. Re:HomeProxy decodes base64 transparently:
- A pasted block that is one big base64 blob is decoded into its list of links.
- Individual `ss://` / `vmess://` links carry their own base64 (userinfo, VMess JSON) — handled automatically.
- Subscription URLs that return a base64 list (the classic format) are decoded on fetch.
You normally don't need to decode anything yourself — just paste the link or the blob.
Two options apply during import:
- **Allow insecure** — marks imported TLS nodes as `tls_insecure` (skip cert verification). Use only if you trust the server.
- **Packet encoding** — applied to imported VLESS/VMess nodes.
---
## 2. Import a .conf file
The **Import .conf** button reads a **WireGuard** or **AmneziaWG** `.conf` file and creates a node from it — handy for WARP/AmneziaWG configs you already have. (AmneziaWG nodes require the **sing-box-extended** core — see [Supported Protocols](Supported-Protocols-en).)
---
## 3. Subscription URLs (auto-updating)
On the **Subscriptions** tab, add one or more **Subscription URL-s**. The router fetches them and keeps the node list in sync. Re:HomeProxy understands several response formats automatically:
- **Base64 / plain share-link lists** — the classic subscription format (one encoded link per line).
- **sing-box JSON / Hiddify** — when the subscription is served as a sing-box/Hiddify JSON config. The correct format is requested via the **User-Agent**, so the same URL can return different formats to different clients.
- **Xray / V2Ray JSON** — config-array JSON (e.g. *connliberty*-style) is parsed into nodes; this path is User-Agent gated as well.
### Update settings
- **Auto update** — enable periodic refresh; pick the **Update time** (hour of day, default 02:00).
- **Update via proxy** — fetch the subscription through the proxy (useful when the subscription host itself is blocked). Off by default to avoid a startup chicken-and-egg.
- Nodes can also be refreshed on demand from the UI.
### Filtering subscription nodes
- **Filter nodes** — `Disable`, `Blacklist mode` (drop matching), or `Whitelist mode` (keep only matching).
- **Filter keywords** — the match list; **regex** is supported.
This is useful to drop dead/region-locked nodes or to keep only a curated subset (e.g. only certain countries/protocols for URLTest).
---
## Which protocols can I import?
That depends on the **core** you installed — a node type only works if the core supports it (e.g. AmneziaWG needs sing-box-extended; some QUIC/Naive protocols need specific build tags). See **[Supported Protocols](Supported-Protocols-en)** for the full matrix and how to check your build's tags.
---
## Notes
- Imported subscription nodes are grouped by their subscription; manual nodes stay separate.
- If an import reports "no valid link found", check the scheme is one of the above and that the link isn't truncated.
- For URLTest selection across many subscription nodes, combine **Filter nodes** here with a per-rule **URLTest** target in [RU Proxy Rules](Routing-and-Access-Control-en).
See also: [Getting Started](Getting-Started-en) · [Supported Protocols](Supported-Protocols-en) · [Routing & Access Control](Routing-and-Access-Control-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/Subscriptions-ru.md
+94
View File
@@ -0,0 +1,94 @@
🇬🇧 [English](Subscriptions-en) | 🇷🇺 [Русский](Subscriptions-ru)
# Подписки и импорт узлов
Есть четыре способа добавить узлы в Re:HomeProxy. Все они — на **Настройки узлов → Узлы** (кнопки импорта) и **Настройки узлов → Подписки**.
---
## 1. Импорт share-ссылок
Кнопка **Импортировать ссылку-конфигурацию для подключения** (на вкладке **Узлы**) принимает по одной ссылке на строку. Поддерживаемые схемы:
| Схема | Протокол |
|-------|----------|
| `vless://` | VLESS (в т. ч. Reality, XHTTP) |
| `vmess://` | VMess (формат v2rayN) |
| `ss://` | Shadowsocks / Shadowsocks 2022 |
| `trojan://` | Trojan |
| `hysteria://`, `hysteria2://`, `hy2://` | Hysteria / Hysteria2 |
| `tuic://` | TUIC |
| `naive://` | NaïveProxy |
| `mieru://` | Mieru |
| `ssh://` | SSH |
| `wireguard://` | WireGuard |
| `vpn://` | **AmneziaVPN** share-ссылка — см. ниже |
### Ссылки AmneziaVPN `vpn://`
Re:HomeProxy полностью декодирует share-формат Amnezia `vpn://` (`base64url(qCompress(zlib JSON))`) прямо в браузере — без вспомогательных утилит. Он читает контейнер внутри и автоматически распознаёт **оба** типа конфигов Amnezia:
- **AmneziaWG** (`amnezia-awg` / `amnezia-awg2`) → узел **AmneziaWG** с полным набором параметров обфускации (`Jc`, `Jmin`, `Jmax`, `S1`–`S4`, `H1`–`H4`, `I1`–`I5`), MTU, keepalive и ключами. *Требует ядро sing-box-extended* — см. [Поддерживаемые протоколы](Supported-Protocols-ru).
- **Xray** (`amnezia-xray`) → вложенный outbound Xray разбирается в узел, включая **VLESS + Reality/TLS** и транспорт (`ws`, `grpc`, `xhttp`/`splithttp`, HTTPUpgrade) с их настройками.
Так что ссылка Amnezia работает, несёт ли она профиль AmneziaWG или Xray.
### Base64
Содержимое подписок и share-ссылок очень часто закодировано в **base64** — это норма, а не редкий случай. Re:HomeProxy декодирует base64 прозрачно:
- Вставленный блок, представляющий собой один большой base64-блоб, разворачивается в список ссылок.
- Отдельные ссылки `ss://` / `vmess://` несут собственный base64 (userinfo, JSON VMess) — обрабатывается автоматически.
- Ссылки подписок, возвращающие base64-список (классический формат), декодируются при скачивании.
Обычно ничего декодировать вручную не нужно — просто вставьте ссылку или блоб.
При импорте действуют две опции:
- **Разрешить небезопасные** — помечает импортируемые TLS-узлы как `tls_insecure` (пропуск проверки сертификата). Используйте, только если доверяете серверу.
- **Кодирование пакетов (packet encoding)** — применяется к импортируемым узлам VLESS/VMess.
---
## 2. Импорт файла .conf
Кнопка **Импорт WG (.conf) файла** читает файл конфигурации **WireGuard** или **AmneziaWG** `.conf` и создаёт из него узел — удобно для готовых конфигов WARP/AmneziaWG. (Узлы AmneziaWG требуют ядро **sing-box-extended** — см. [Поддерживаемые протоколы](Supported-Protocols-ru).)
---
## 3. Ссылки подписок (с автообновлением)
На вкладке **Подписки** добавьте одну или несколько **ссылок подписок**. Роутер скачивает их и поддерживает список узлов в актуальном состоянии. Re:HomeProxy автоматически распознаёт несколько форматов ответа:
- **Base64 / обычные списки share-ссылок** — классический формат подписки (по одной кодированной ссылке на строку).
- **sing-box JSON / Hiddify** — когда подписка отдаётся как JSON-конфиг sing-box/Hiddify. Нужный формат запрашивается через **User-Agent**, поэтому один и тот же URL может возвращать разным клиентам разные форматы.
- **Xray / V2Ray JSON** — JSON с массивом конфигов (например, в стиле *connliberty*) разбирается в узлы; этот путь также завязан на User-Agent.
### Настройки обновления
- **Автообновление** — включить периодическое обновление; выберите **Время обновления** (час суток, по умолчанию 02:00).
- **Обновлять через прокси** — скачивать подписку через прокси (полезно, если сам хост подписки заблокирован). По умолчанию выключено, чтобы избежать проблемы «курицы и яйца» при старте.
- Узлы также можно обновить вручную из интерфейса.
### Фильтрация узлов подписки
- **Фильтр узлов** — `Отключено`, `Режим чёрного списка` (отбрасывать совпадения) или `Режим белого списка` (оставлять только совпадения).
- **Ключевые слова фильтра** — список совпадений; поддерживается **регулярное выражение**.
Удобно, чтобы отбросить мёртвые/региональные узлы или оставить только нужный набор (например, только определённые страны/протоколы для URLTest).
---
## Какие протоколы можно импортировать?
Зависит от установленного **ядра** — тип узла работает, только если ядро его поддерживает (например, AmneziaWG требует sing-box-extended; некоторым протоколам QUIC/Naive нужны определённые build-теги). Полную матрицу и проверку тегов сборки см. в **[Поддерживаемые протоколы](Supported-Protocols-ru)**.
---
## Примечания
- Импортированные узлы подписки группируются по своей подписке; узлы, добавленные вручную, остаются отдельно.
- Если импорт сообщает «не найдено валидных ссылок», проверьте, что схема — одна из перечисленных выше и ссылка не обрезана.
- Для выбора через URLTest среди множества узлов подписки сочетайте **Фильтр узлов** здесь с целью **URLTest** для конкретного правила в [RU Proxy Rules](Routing-and-Access-Control-ru).
См. также: [Первая настройка](Getting-Started-ru) · [Поддерживаемые протоколы](Supported-Protocols-ru) · [Маршрутизация и контроль доступа](Routing-and-Access-Control-ru) · [Устранение неполадок](Troubleshooting-ru)
homeproxy-hiddify/wiki/Supported-Protocols-en.md
+208
View File
@@ -0,0 +1,208 @@
🇬🇧 [English](Supported-Protocols-en) | 🇷🇺 [Русский](Supported-Protocols-ru)
# Supported Protocols
Re:HomeProxy runs on a choice of cores: [hiddify-core](https://github.com/hiddify/hiddify-core) (default) or [sing-box-extended](https://github.com/shtorm-7/sing-box-extended) — both forks of [sing-box](https://sing-box.sagernet.org) with additional protocols and features not available upstream. The protocols shown in the node editor depend on **which core you installed** and how it was compiled on your device. You choose and install the core on the **Core management** section (Services → Re:HomeProxy → Core & Tools).
---
## Filling in the node editor
When you add a node by hand, the editor exposes the underlying **sing-box outbound** options — TLS (including **Reality**, **uTLS** fingerprints, **ECH**), the transport (**gRPC / WebSocket / HTTP / HTTPUpgrade / XHTTP**), and **multiplex**. Rather than duplicate sing-box's reference here, match each field to your server using the upstream docs:
- [Outbound reference](https://sing-box.sagernet.org/configuration/outbound/) — every outbound type and its fields
- [TLS (shared)](https://sing-box.sagernet.org/configuration/shared/tls/) — Reality, uTLS, ECH, ALPN
- [V2Ray transports](https://sing-box.sagernet.org/configuration/shared/v2ray-transport/) — gRPC / WS / HTTP / HTTPUpgrade
- [Multiplex](https://sing-box.sagernet.org/configuration/shared/multiplex/)
Most users never fill these by hand — importing a share link or subscription sets them for you (see [Subscriptions & Node Import](Subscriptions-en)).
---
## Extended-core features (not in upstream sing-box)
Both cores are sing-box forks that add features missing from upstream. Some are **hiddify-core only**; others are in **both** hiddify-core and sing-box-extended (noted per item):
### TLS Fragmentation (`tls_fragment`) *(hiddify-core only)*
Splits the TLS ClientHello handshake across multiple TCP packets so that the SNI (Server Name Indication) field — which reveals the destination domain — arrives in separate fragments. DPI systems that inspect only whole packets to identify and block domains cannot reassemble the SNI in time, so the connection passes through undetected.
**Fragment modes:**
- **SNI/Domain** — splits packets into two pieces; simple and effective in most cases
- **Random** — divides into many very small pieces for maximum obfuscation; use when SNI mode alone is insufficient
**Key parameters:**
- **Fragment size** — recommended 100–200 bytes; ideally one byte less than the domain name length
- **Fragment interval** — timing between fragments; tune per ISP if needed
- **Mixed SNI case** — randomises capitalisation of the SNI (e.g. `wWw.ExAmPlE.cOm`) to defeat case-sensitive matching
- **Padding** — appends random data to the domain field
> **Note:** Do not enable fragment and padding at the same time — they cancel each other out. Effectiveness varies by ISP and may require parameter tuning.
Can be applied to any protocol that uses TLS (VLESS, VMess, Trojan, etc.).
*Source: [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 Transport *(both cores)*
A modern HTTP-based transport for VLESS designed for CDN compatibility and multiplexing. Not in upstream sing-box, but available on **both** hiddify-core and sing-box-extended. See the VLESS section below.
### Additional Protocols *(both cores)*
MieruTCP / MieruUDP and extended NaïveProxy variants — available on **both** cores (see below).
---
## Always Available
### Direct
Bypasses the proxy — traffic goes to the destination without any tunneling. Used in route rules for local or trusted destinations.
### AnyTLS
A TLS-based multiplexing protocol developed by the hiddify team. Designed to be simple, efficient, and hard to fingerprint. Good choice when other TLS-based protocols are being blocked.
### HTTP
Plain HTTP proxy (RFC 7231 CONNECT method). Supports username/password authentication. Not encrypted — use only on trusted networks or wrapped in TLS via another layer.
### Shadowsocks
One of the most widely used anti-censorship protocols. Encrypts traffic with a pre-shared key and cipher (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, etc.). Simple to set up. Does not use TLS — traffic is obfuscated but does not look like HTTPS.
**Shadowsocks 2022** (`2022-blake3-aes-128-gcm`, `2022-blake3-aes-256-gcm`, `2022-blake3-chacha20-poly1305`) is also supported. It improves on the original with stronger authenticated encryption, replay protection, and better performance. If your server supports it, prefer the 2022 variants. ShadowTLS (see below) is designed to work with Shadowsocks 2022.
### ShadowTLS
A TLS camouflage wrapper designed for use with **Shadowsocks 2022** (not the original Shadowsocks). Wraps the underlying connection in a TLS handshake that impersonates a real HTTPS server, making traffic indistinguishable from legitimate TLS to passive observers. The TLS handshake is genuine — it completes with a real server — so SNI-based blocking and TLS fingerprinting are defeated. Requires a ShadowTLS-aware server alongside a Shadowsocks 2022 backend.
### Socks
SOCKS4 and SOCKS5 proxy. Supports optional username/password authentication (SOCKS5). No encryption — suitable for use within a trusted network or as a local outbound.
### SSH
Tunnels traffic over an SSH connection using port forwarding. Useful when only SSH is accessible and other ports are blocked. Requires an SSH server with a valid account. Slower than dedicated proxy protocols due to SSH overhead.
### Trojan
Disguises proxy traffic as regular HTTPS by using TLS with a valid certificate. A server hosting Trojan looks identical to an HTTPS web server to outside observers. Falls back to serving a real web page for non-Trojan connections, making it very hard to detect.
**Supported transports:**
| Transport | CDN Compatible | Notes |
|-----------|:--------------:|-------|
| TCP (raw TLS) | No | Default; lowest overhead |
| WebSocket | **Yes** | Works behind Cloudflare and other CDNs |
| gRPC | **Yes** | Works behind Cloudflare (requires gRPC support on CDN) |
| HTTP/2 | No | Multiplexed; not CDN-friendly without WebSocket/gRPC |
WebSocket + TLS is the most common setup for CDN (Cloudflare) deployment — the CDN terminates TLS and forwards WebSocket traffic to the origin server.
### VLESS
A lightweight successor to VMess without the extra encryption layer (relies on the transport for security, typically TLS). Widely used with Xray-based servers.
**Supported transports:**
| Transport | CDN Compatible | Notes |
|-----------|:--------------:|-------|
| TCP (raw TLS) | No | Standard setup |
| WebSocket | **Yes** | CDN-friendly; widely supported |
| gRPC | **Yes** | CDN-friendly |
| HTTP/2 | No | Multiplexed connections |
| HTTPUpgrade | **Yes** | Lightweight HTTP upgrade handshake |
| **XHTTP** | **Yes** | Not in upstream sing-box; on both cores — see below |
**XHTTP** is an extended transport for VLESS, available on **both** hiddify-core and sing-box-extended (but not upstream sing-box). It uses chunked HTTP transfers over a single or multiplexed connection, designed specifically for CDN compatibility and to avoid patterns detectable as non-browser traffic.
### VMess
The original V2Ray protocol. Includes its own encryption on top of the transport layer. Slightly more overhead than VLESS but very widely deployed.
**Supported transports:**
| Transport | CDN Compatible | Notes |
|-----------|:--------------:|-------|
| TCP | No | |
| WebSocket | **Yes** | Most common CDN setup |
| gRPC | **Yes** | |
| HTTP/2 | No | |
| HTTPUpgrade | **Yes** | |
VMess over WebSocket + TLS is one of the most common configurations for Cloudflare CDN deployment — the CDN hides the origin server's real IP.
---
## Requires `with_quic` Build Tag
### Hysteria
QUIC-based high-throughput proxy protocol (version 1). Uses a modified QUIC stack that tolerates packet loss better than TCP-based protocols — useful on lossy or high-latency connections. Version 1 is largely superseded by Hysteria2.
### Hysteria2
Improved and simplified version of Hysteria. Uses the Salamander obfuscation protocol and BBR congestion control. Significantly better performance than v1 and harder to detect. Recommended over Hysteria v1 for new setups.
### TUIC
QUIC-based protocol with built-in multiplexing and 0-RTT connection establishment. Low latency and efficient. Requires a TUIC server (v5 protocol).
---
## Requires `with_naive_outbound` Build Tag
### NaïveProxy
Uses the **actual Chrome network stack** to make proxy traffic indistinguishable from real Chrome browser HTTPS traffic. Extremely resistant to traffic analysis and fingerprinting because the TLS implementation, cipher choices, and behavior are identical to a real browser.
Two transport variants:
| Variant | Protocol | Notes |
|---------|----------|-------|
| **NaiveTLS** | HTTPS (TLS 1.3 over TCP) | Mimics Chrome HTTPS; most common |
| **NaiveQUIC** | HTTP/3 (QUIC) | Mimics Chrome HTTP/3; harder to block but requires UDP |
NaiveTLS is the standard choice. NaiveQUIC offers better performance where UDP is available but may be blocked in some environments that drop unknown UDP traffic.
NaïveProxy requires a compatible server (e.g., Caddy with the `forwardproxy` plugin).
---
## Requires `with_wireguard` + `with_gvisor` Build Tags
### WireGuard
Modern VPN protocol with a minimal codebase and strong cryptography (Curve25519, ChaCha20-Poly1305). Very fast and battery-efficient. Can be used as an outbound to tunnel all proxy traffic through a WireGuard VPN endpoint (e.g., a VPS or a service like Cloudflare WARP).
---
## Requires the sing-box-extended core
These node types are available when you install **sing-box-extended** instead of hiddify-core (pick your core on the **Core Management** page). hiddify-core does **not** support them.
### AmneziaWG
An obfuscated variant of WireGuard. It adds junk packets and randomised handshake headers (the `Jc`, `Jmin`, `Jmax`, `S1`, `S2`, `H1`–`H4`, `I1`–`I5` parameters) so that DPI systems which detect and block plain WireGuard no longer recognise the traffic. Set the obfuscation parameters to match your AmneziaWG server (or a Cloudflare WARP endpoint running AmneziaWG). Same fast Curve25519 / ChaCha20-Poly1305 cryptography as WireGuard, but the packets no longer look like WireGuard on the wire.
---
## Mieru — requires `with_quic`
### MieruTCP / MieruUDP
Anti-censorship protocol developed independently of sing-box, added by the extended cores (hiddify-core **and** sing-box-extended). Uses fully randomized traffic patterns with no identifiable headers or handshakes, making it very difficult to detect or classify by DPI.
- **MieruTCP** — TCP transport variant
- **MieruUDP** — UDP transport variant; higher throughput, requires UDP access
Requires a Mieru server. See the [Mieru project](https://github.com/enfein/mieru) for server setup.
---
## Coming in Future hiddify-core Versions
### DNSTT (planned)
DNS tunneling protocol — tunnels proxy traffic inside DNS queries and responses. Extremely useful in heavily restricted environments where only DNS traffic is allowed (e.g., captive portals, some corporate networks). Significantly lower throughput than other protocols due to DNS packet size limits, but works where nothing else does.
---
## How to Check What Your Build Supports
Run the version command for **whichever core you installed**:
```sh
hiddify-core version # if you run hiddify-core
sing-box version # if you run sing-box-extended
```
Look at the `Tags:` line. Protocols that require a specific tag will only appear in the node editor if that tag is present.
Example:
```
Tags: with_quic,with_wireguard,with_gvisor,with_naive_outbound,...
```
---
## Note on NaïveProxy
NaïveProxy availability is controlled by the `with_naive_outbound` build tag — it is not architecture-specific. Some builds omit it to reduce binary size. Check your installed version as shown above before assuming it is unavailable.
homeproxy-hiddify/wiki/Supported-Protocols-ru.md
+208
View File
@@ -0,0 +1,208 @@
🇬🇧 [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` — это не зависит от архитектуры устройства. Некоторые сборки не включают его для уменьшения размера бинарника. Проверьте установленную версию, как описано выше, прежде чем считать протокол недоступным.
homeproxy-hiddify/wiki/Troubleshooting-en.md
+123
View File
@@ -0,0 +1,123 @@
🇬🇧 [English](Troubleshooting-en) | 🇷🇺 [Русский](Troubleshooting-ru)
# Troubleshooting
---
## "Object not found" Error When Saving
**Symptom:** Saving any form (client settings, access control lists, etc.) shows:
```
RPC call to luci.homeproxy/[method] failed with error -32000: Object not found
```
**Cause:** rpcd has not loaded the `luci.homeproxy` module. This commonly happens right after installing or upgrading the package if the post-install script sent a reload signal while rpcd was not yet running.
**Fix:**
```sh
/etc/init.d/rpcd restart
```
Then **log out and log back in** to the web UI. An existing session does not pick up the new permissions without a fresh login.
---
## Proxy Modes Missing (No TProxy, No Tun)
**Symptom:** The Proxy Mode selector on the Client page only shows "Redirect TCP". TProxy and Tun options are absent even though the required kernel modules are installed.
**Cause:** Same as above — `luci.homeproxy` not loaded. The feature detection call (`singbox_get_features`) returns empty, so all capability flags are false and the options are hidden.
**Fix:** Same as above — restart rpcd and re-login.
---
## TypeError on the Client Page
**Symptom:** Opening `/cgi-bin/luci/admin/services/homeproxy/client` shows:
```
TypeError: Cannot read properties of undefined (reading 'content')
```
**Cause:** The domain list RPC call failed (module not loaded or first boot), and an older version of the package did not handle this gracefully.
**Fix:** Restart rpcd and re-login as above. If you are running an older build, update to the latest release which includes the fix.
---
## All Three Issues Share the Same Root Fix
If you just installed or upgraded the package and see any of the above:
```sh
/etc/init.d/rpcd restart
```
Log out of the web UI and log back in. Both steps are required.
---
## Cannot Download Package via wget (HTTPS Fails)
**Symptom:**
```
Failed to send request: Operation not permitted
Failed to allocate uclient context
```
**Cause:** OpenWRT's built-in `wget` (uclient-fetch) has no SSL library installed, so HTTPS requests fail.
**Fix:**
```sh
opkg update && opkg install libustream-openssl ca-certificates
```
If `opkg` itself cannot reach the internet, download the `.ipk` or `.apk` file on a PC from the [Releases page](https://github.com/1andrevich/homeproxy-hiddify/releases) and transfer it to the router with `scp`.
---
## No Internet Access When Re:HomeProxy Is Enabled (mwan3 Conflict)
**Symptom:** Ping and DNS work, but HTTP/HTTPS traffic fails when Re:HomeProxy is enabled. Stopping mwan3 restores connectivity.
**Cause:** mwan3 uses fwmarks and policy routing to steer traffic between WAN interfaces. When the proxy core makes outbound connections, mwan3 can intercept and misroute them.
**Fix:** Tell the OS to skip mwan3's routing logic for traffic already handled by Re:HomeProxy (marked `0x64`).
Add the following rule as a persistent firewall include:
```sh
uci add firewall include
uci set firewall.@include[-1].path='/etc/firewall.d/homeproxy-mwan3'
uci set firewall.@include[-1].type='script'
uci set firewall.@include[-1].reload='1'
uci commit firewall
mkdir -p /etc/firewall.d
cat > /etc/firewall.d/homeproxy-mwan3 << 'EOF'
#!/bin/sh
iptables -t mangle -I OUTPUT 1 -m mark --mark 0x64/0x64 -j RETURN
EOF
chmod +x /etc/firewall.d/homeproxy-mwan3
/etc/init.d/firewall reload
```
To verify the rule is active:
```sh
iptables -t mangle -L OUTPUT -n --line-numbers | head -5
```
The `0x64` mark rule should appear as line 1.
> This fix deliberately uses `iptables` because **mwan3** operates at the iptables layer. On a fw4 / nftables system it still applies through the iptables-nft compatibility shim — it does not conflict with Re:HomeProxy's nft chains.
---
## Subscription Update Button Does Nothing
**Symptom:** Clicking "Update subscriptions" shows a spinner but node count stays at zero after the page reloads.
**Fix:** Update to the latest release. Earlier builds used a background execution method that did not work correctly from the rpcd context. The current version uses the correct execution path.
If you are on the latest release and still see this, run manually over SSH to check for errors:
```sh
ucode /etc/homeproxy/scripts/update_subscriptions.uc
```
homeproxy-hiddify/wiki/Troubleshooting-ru.md
+123
View File
@@ -0,0 +1,123 @@
🇬🇧 [English](Troubleshooting-en) | 🇷🇺 [Русский](Troubleshooting-ru)
# Устранение неполадок
---
## Ошибка «Object not found» при сохранении
**Симптом:** При сохранении любой формы (настройки клиента, списки контроля доступа и др.) появляется:
```
RPC call to luci.homeproxy/[method] failed with error -32000: Object not found
```
**Причина:** rpcd не загрузил модуль `luci.homeproxy`. Чаще всего это происходит сразу после установки или обновления пакета, если скрипт post-install отправил сигнал перезагрузки, когда rpcd ещё не был запущен.
**Решение:**
```sh
/etc/init.d/rpcd restart
```
Затем **выйдите из веб-интерфейса и войдите снова**. Существующая сессия не подхватывает новые разрешения без повторного входа.
---
## Недоступны режимы прокси (нет TProxy, нет Tun)
**Симптом:** Селектор режима прокси на странице «Клиент» показывает только «Redirect TCP». Опции TProxy и Tun отсутствуют, хотя необходимые модули ядра установлены.
**Причина:** Та же, что выше — `luci.homeproxy` не загружен. Вызов определения возможностей (`singbox_get_features`) возвращает пустой объект, все флаги оказываются ложными и опции скрываются.
**Решение:** То же — перезапустить rpcd и войти заново.
---
## TypeError на странице «Клиент»
**Симптом:** При открытии `/cgi-bin/luci/admin/services/homeproxy/client` появляется:
```
TypeError: Cannot read properties of undefined (reading 'content')
```
**Причина:** Вызов RPC для загрузки списков доменов завершился неудачей (модуль не загружен или первая загрузка системы), а старая версия пакета не обрабатывала это корректно.
**Решение:** Перезапустите rpcd и войдите снова, как описано выше. Если вы используете старую сборку — обновитесь до последнего релиза, в котором это исправлено.
---
## Все три проблемы — одно решение
Если вы только что установили или обновили пакет и наблюдаете любую из перечисленных ошибок:
```sh
/etc/init.d/rpcd restart
```
Выйдите из веб-интерфейса и войдите снова. Нужны оба шага.
---
## Не удаётся скачать пакет через wget (HTTPS не работает)
**Симптом:**
```
Failed to send request: Operation not permitted
Failed to allocate uclient context
```
**Причина:** Встроенный `wget` в OpenWRT (uclient-fetch) не имеет установленной SSL-библиотеки и не умеет работать с HTTPS.
**Решение:**
```sh
opkg update && opkg install libustream-openssl ca-certificates
```
Если сам `opkg` не имеет доступа к интернету — скачайте файл `.ipk` или `.apk` на компьютере со [страницы релизов](https://github.com/1andrevich/homeproxy-hiddify/releases) и передайте на роутер через `scp`.
---
## Нет интернета при включённом Re:HomeProxy (конфликт с mwan3)
**Симптом:** Ping и DNS работают, но HTTP/HTTPS-трафик не проходит при включённом Re:HomeProxy. Остановка mwan3 восстанавливает связь.
**Причина:** mwan3 использует fwmark и policy routing для распределения трафика между WAN-интерфейсами. Когда ядро прокси устанавливает исходящие соединения, mwan3 может перехватить их и направить не туда.
**Решение:** Сообщить ОС пропускать логику маршрутизации mwan3 для трафика, уже обработанного Re:HomeProxy (помечен `0x64`).
Добавьте правило в виде постоянного include файрвола:
```sh
uci add firewall include
uci set firewall.@include[-1].path='/etc/firewall.d/homeproxy-mwan3'
uci set firewall.@include[-1].type='script'
uci set firewall.@include[-1].reload='1'
uci commit firewall
mkdir -p /etc/firewall.d
cat > /etc/firewall.d/homeproxy-mwan3 << 'EOF'
#!/bin/sh
iptables -t mangle -I OUTPUT 1 -m mark --mark 0x64/0x64 -j RETURN
EOF
chmod +x /etc/firewall.d/homeproxy-mwan3
/etc/init.d/firewall reload
```
Для проверки, что правило применилось:
```sh
iptables -t mangle -L OUTPUT -n --line-numbers | head -5
```
Правило с меткой `0x64` должно быть первым в списке.
> Здесь намеренно используется `iptables`, потому что **mwan3** работает на уровне iptables. На системе с fw4 / nftables правило всё равно применяется через слой совместимости iptables-nft и не конфликтует с nft-цепочками Re:HomeProxy.
---
## Кнопка обновления подписок не работает
**Симптом:** После нажатия кнопки «Обновить подписки» появляется спиннер, но количество узлов остаётся нулевым после перезагрузки страницы.
**Решение:** Обновитесь до последнего релиза. В более ранних сборках использовался метод фонового выполнения, который некорректно работал в контексте rpcd. В текущей версии используется правильный механизм.
Если вы уже используете последний релиз и проблема сохраняется — запустите вручную через SSH, чтобы увидеть возможные ошибки:
```sh
ucode /etc/homeproxy/scripts/update_subscriptions.uc
```
homeproxy-hiddify/wiki/Zapret-en.md
+116
View File
@@ -0,0 +1,116 @@
🇬🇧 [English](Zapret-en) | 🇷🇺 [Русский](Zapret-ru)
# Zapret
**Zapret 2** is a second, packet-level DPI-bypass built into Re:HomeProxy. It un-throttles and unblocks sites **without any VPN subscription** by desyncing the handshake of selected flows directly on the wire. Re:HomeProxy bundles the [bol-van/zapret2](https://github.com/bol-van/zapret2) engine (`nfqws2`) and manages it for you.
It complements [ByeDPI](ByeDPI-en): same goal, different layer. See [ByeDPI vs Zapret](#byedpi-vs-zapret) below.
---
## What it is — and what it is not
Zapret runs the **`nfqws2`** packet processor. The selected traffic is tagged in the firewall and handed to an **NFQUEUE**, where `nfqws2` rewrites the first few packets of each connection (fake packets, splitting, disorder, TCP-MD5/seq tricks, TLS-record manipulation) so your ISP's Deep Packet Inspection can no longer recognise — and therefore can no longer throttle or block — the traffic.
| | |
|---|---|
| ✅ **Un-throttles DPI-filtered sites** | The common case for YouTube, Discord and similar services slowed or blocked by DPI. |
| ✅ **No subscription, no server** | A local packet trick — no VPN node, account or remote server. |
| ✅ **Works on both cores** | Implemented as a marked direct outbound; works identically on hiddify-core and sing-box-extended. |
| ✅ **Handles TCP *and* UDP/QUIC** | Unlike ByeDPI, the NFQUEUE path also desyncs UDP flows (used for Discord voice). |
| ❌ **Does not encrypt or hide traffic** | Your ISP still sees *which* sites you visit; Zapret only changes *how* the first packets look. It is **not a VPN**. |
| ❌ **Cannot reach fully IP-blocked sites** | If a site is blocked by IP/DNS (not just throttled), only a real proxy/VPN node can reach it. |
---
## How it works
Zapret is wired as a routing **target**, not a SOCKS node:
1. The config generator adds a `direct` outbound called **`zapret-out`** stamped with a `routing_mark` (default mark `110`).
2. When a routing rule selects `zapret-out`, the core egresses that flow **directly**, but tagged with the mark.
3. An nft chain (`homeproxy_zapret_queue`) catches the marked packets and sends the first 1–12 packets of each TCP/UDP connection to an **NFQUEUE**.
4. `nfqws2` reads the queue and desyncs the handshake, then lets the connection continue normally.
Because it is a marked *direct* outbound (not a tunnel), `zapret-out` falls back to plain `direct-out` automatically when Zapret is disabled, so the generated config always stays valid. Loop-avoidance returns for the Zapret mark and `nfqws2`'s own reinjected (DESYNC_MARK) packets are added to the firewall automatically — you don't touch nft.
---
## Enabling Zapret
1. Go to **Services → Re:HomeProxy → Node Settings** and open the **Zapret** tab.
2. If `nfqws2` is not installed yet, use the **Install** button — Re:HomeProxy fetches the right [zapret2-openwrt](https://github.com/1andrevich/zapret2-openwrt) package for your architecture.
3. Tick **Enable**, pick a strategy preset (see below), and **Save & Apply**.
That's all for the engine. The `--qnum` / `--user` / `--fwmark` / `--lua-init` arguments are added automatically — you only edit the desync strategy itself.
---
## Strategies and presets
A "strategy" is the set of `nfqws2` options applied to every flow routed to Zapret. There are **no hostlists** — the routing rules already decide *what* is sent here, so the strategy only decides *how* to desync it. As with ByeDPI, **there is no universal best strategy** — what works depends on your ISP's DPI.
The **Strategy preset** picker fills the strategy field for you and is grouped into two sets:
| Group | What it is |
|-------|------------|
| **Recommended** | A small curated set, purpose-named (e.g. *Default (fake + multidisorder)*, *Multisplit*, *Fake only*). Start here. |
| **Full-test pool** | The larger technique-named pool used by the full tester. |
Presets are shipped read-only in `/etc/homeproxy/zapret_candidates.json` and are based on [bol-van/zapret2](https://github.com/bol-van/zapret2) (nfqws2/blockcheck2) with some adapted from [flowseal/zapret-discord-youtube](https://github.com/flowseal/zapret-discord-youtube) (MIT). You can also leave the preset on *custom* and type your own option string in the **Desync strategy** field.
---
## The strategy tester
Because the right strategy is ISP-specific, the Zapret tab includes a **tester** that never touches your live traffic — it spins up a **temporary NFQUEUE scoped to four test sites** and checks whether each TLS handshake completes:
- **Test current strategy** — runs whatever is in the strategy field against **YouTube**, **Telegram**, **Discord** and **Speedtest.net**, showing each site as ✓ / ✗ with the handshake time, plus an `ok/total` count.
- **Full strategy test** — sweeps the whole preset pool and reports which candidates pass, so you can apply the best one.
Pick a strategy that passes all four sites. If several do, prefer one from the **Recommended** group.
---
## Discord voice (opt-in)
Enabling **Zapret voice** routes Discord's voice-server UDP ranges (and call/voice UDP ports) to `zapret-out` **before** the normal proxy/call rules, so Discord voice is desynced via Zapret instead of being proxied. The UDP port ranges come from [flowseal/zapret-discord-youtube](https://github.com/flowseal/zapret-discord-youtube). This option is honoured only when Zapret is enabled.
---
## Routing traffic through Zapret
Once enabled, **Zapret** becomes a selectable routing target. The typical setup mirrors ByeDPI:
- **Alongside a VPN node (recommended):** in `proxy_banned_ru` mode, open **RU Proxy Rules** and set a *specific list's* target to **Zapret** — e.g. route YouTube and Discord through Zapret (no VPN bandwidth used) while everything else uses your VPN.
- **Per service:** because Zapret is selected per rule, you can mix it freely with the proxy and ByeDPI across different lists.
---
## ByeDPI vs Zapret
Both bypass DPI without a VPN; they operate at different layers, so the right one depends on your ISP.
| | **ByeDPI** | **Zapret 2** |
|---|---|---|
| Layer | Local SOCKS proxy (`ciadpi`) | Kernel NFQUEUE packet mangler (`nfqws2`) |
| Appears as | Selectable in routing rules ("ByeDPI") | Selectable in routing rules ("Zapret") |
| TCP | ✅ | ✅ |
| UDP / QUIC | Carried, but not desynced | ✅ desynced (used for Discord voice) |
| DNS | Forced direct, bypassing ByeDPI (routing it through ByeDPI corrupts DoH/DoT) | Not in the DNS path — Zapret only touches flows routed to it |
| Try when | YouTube throttling, simple per-site offload | ByeDPI doesn't beat your DPI, or you need UDP/voice desync |
There's no harm in installing both and using the tester on each — keep whichever scores all-green on your network.
---
## Troubleshooting
| Symptom | Likely cause / fix |
|---------|--------------------|
| A site still loads slowly or won't open | The strategy isn't right for your ISP — run the **Full strategy test** and apply a passing one. |
| Tester shows everything failing | `nfqws2` may not be installed/running — check the **Zapret** tab and the [Diagnostics](Troubleshooting-en) page (it reports install / running / queue status). |
| Discord voice still drops | Enable **Zapret voice**, then re-test. |
| A site is unreachable, not just slow | It may be IP-blocked, not throttled — Zapret can't help; route it through a proxy/VPN node. |
See also: [ByeDPI](ByeDPI-en) · [Core Management](Core-Management-en) · [Supported Protocols](Supported-Protocols-en) · [Troubleshooting](Troubleshooting-en)
homeproxy-hiddify/wiki/Zapret-ru.md
+116
View File
@@ -0,0 +1,116 @@
🇬🇧 [English](Zapret-en) | 🇷🇺 [Русский](Zapret-ru)
# Zapret
**Zapret 2** — второй, пакетный обход DPI, встроенный в Re:HomeProxy. Он снимает троттлинг и разблокирует сайты **без какой-либо VPN-подписки**, рассинхронизируя рукопожатие выбранных потоков прямо на сетевом уровне. Re:HomeProxy включает движок [bol-van/zapret2](https://github.com/bol-van/zapret2) (`nfqws2`) и управляет им за вас.
Он дополняет [ByeDPI](ByeDPI-ru): цель та же, уровень разный. См. [ByeDPI или Zapret](#byedpi-или-zapret) ниже.
---
## Что это — и чем оно не является
Zapret запускает пакетный обработчик **`nfqws2`**. Выбранный трафик помечается в межсетевом экране и передаётся в **NFQUEUE**, где `nfqws2` переписывает первые несколько пакетов каждого соединения (фейковые пакеты, разбиение, переупорядочивание, трюки с TCP-MD5/seq, манипуляции с TLS-record), чтобы система DPI провайдера больше не распознавала трафик — а значит, не могла его замедлять или блокировать.
| | |
|---|---|
| ✅ **Снимает троттлинг сайтов под DPI** | Типичный случай — YouTube, Discord и подобные сервисы, замедленные или заблокированные DPI. |
| ✅ **Без подписки и сервера** | Локальный пакетный трюк — не нужен VPN-узел, аккаунт или удалённый сервер. |
| ✅ **Работает на обоих ядрах** | Реализован как помеченный direct-outbound; одинаково работает на hiddify-core и sing-box-extended. |
| ✅ **Обрабатывает TCP *и* UDP/QUIC** | В отличие от ByeDPI, путь через NFQUEUE рассинхронизирует и UDP-потоки (используется для голоса Discord). |
| ❌ **Не шифрует и не скрывает трафик** | Провайдер по-прежнему видит, *какие* сайты вы посещаете; Zapret меняет только то, *как выглядят* первые пакеты. Это **не VPN**. |
| ❌ **Не открывает сайты, заблокированные по IP** | Если сайт блокируется по IP/DNS (а не просто троттлится), достучаться до него может только настоящий прокси/VPN-узел. |
---
## Как это работает
Zapret подключён как **цель** маршрутизации, а не как SOCKS-узел:
1. Генератор конфига добавляет direct-outbound с именем **`zapret-out`**, помеченный `routing_mark` (метка по умолчанию `110`).
2. Когда правило маршрутизации выбирает `zapret-out`, ядро выпускает поток **напрямую**, но с этой меткой.
3. Цепочка nft (`homeproxy_zapret_queue`) ловит помеченные пакеты и отправляет первые 1–12 пакетов каждого TCP/UDP-соединения в **NFQUEUE**.
4. `nfqws2` читает очередь и рассинхронизирует рукопожатие, после чего соединение продолжается как обычно.
Поскольку это помеченный *direct*-outbound (а не туннель), при выключенном Zapret `zapret-out` автоматически откатывается к обычному `direct-out`, так что генерируемый конфиг всегда остаётся валидным. Правила-исключения для метки Zapret и для собственных переинжектированных пакетов `nfqws2` (DESYNC_MARK) добавляются в межсетевой экран автоматически — править nft вручную не нужно.
---
## Включение Zapret
1. Откройте **Сервисы → Re:HomeProxy → Настройки узлов** и вкладку **Zapret**.
2. Если `nfqws2` ещё не установлен, нажмите **Установить** — Re:HomeProxy скачает подходящий пакет [zapret2-openwrt](https://github.com/1andrevich/zapret2-openwrt) для вашей архитектуры.
3. Отметьте **Включить**, выберите пресет стратегии (см. ниже) и нажмите **Сохранить и применить**.
Этого достаточно. Аргументы `--qnum` / `--user` / `--fwmark` / `--lua-init` добавляются автоматически — вы редактируете только саму стратегию рассинхронизации.
---
## Стратегии и пресеты
«Стратегия» — это набор опций `nfqws2`, применяемых к каждому потоку, направленному в Zapret. **Списков хостов нет** — правила маршрутизации уже решают, *что* сюда отправлять, поэтому стратегия определяет только то, *как* это рассинхронизировать. Как и с ByeDPI, **универсально лучшей стратегии не существует** — что работает, зависит от DPI вашего провайдера.
Выбор **Пресет стратегии** заполняет поле стратегии за вас и сгруппирован на два набора:
| Группа | Что это |
|--------|---------|
| **Рекомендуемые** | Небольшой подобранный набор с понятными названиями (например, *Default (fake + multidisorder)*, *Multisplit*, *Fake only*). Начните отсюда. |
| **Полный пул тестирования** | Более крупный пул с техническими названиями, используемый полным тестером. |
Пресеты поставляются только для чтения в `/etc/homeproxy/zapret_candidates.json` и основаны на [bol-van/zapret2](https://github.com/bol-van/zapret2) (nfqws2/blockcheck2), часть адаптирована из [flowseal/zapret-discord-youtube](https://github.com/flowseal/zapret-discord-youtube) (MIT). Можно оставить пресет в режиме *custom* и ввести свою строку опций в поле **Стратегия рассинхронизации**.
---
## Тестер стратегий
Поскольку нужная стратегия зависит от провайдера, на вкладке Zapret есть **тестер**, который не трогает ваш живой трафик — он поднимает **временную NFQUEUE, ограниченную четырьмя тестовыми сайтами**, и проверяет, завершается ли каждое TLS-рукопожатие:
- **Проверить текущую стратегию** — запускает то, что в поле стратегии, против **YouTube**, **Telegram**, **Discord** и **Speedtest.net**, показывая каждый сайт как ✓ / ✗ со временем рукопожатия и счётчиком `ok/total`.
- **Полная проверка стратегий** — перебирает весь пул пресетов и сообщает, какие кандидаты проходят, чтобы применить лучший.
Выберите стратегию, проходящую все четыре сайта. Если подходит несколько — предпочтите вариант из группы **Рекомендуемые**.
---
## Голос Discord (по желанию)
Включение **Zapret voice** направляет UDP-диапазоны голосовых серверов Discord (и UDP-порты звонков/голоса) в `zapret-out` **до** обычных правил прокси/звонков, так что голос Discord рассинхронизируется через Zapret, а не проксируется. Диапазоны UDP-портов взяты из [flowseal/zapret-discord-youtube](https://github.com/flowseal/zapret-discord-youtube). Опция учитывается только при включённом Zapret.
---
## Маршрутизация трафика через Zapret
После включения **Zapret** становится доступной целью маршрутизации. Типичная схема повторяет ByeDPI:
- **Вместе с VPN-узлом (рекомендуется):** в режиме `proxy_banned_ru` откройте **RU Proxy Rules** и задайте цель *конкретного списка* как **Zapret** — например, направьте YouTube и Discord через Zapret (без расхода трафика VPN), а всё остальное — через VPN.
- **По сервисам:** поскольку Zapret выбирается в каждом правиле, его можно свободно смешивать с прокси и ByeDPI по разным спискам.
---
## ByeDPI или Zapret
Оба обходят DPI без VPN; работают на разных уровнях, поэтому выбор зависит от вашего провайдера.
| | **ByeDPI** | **Zapret 2** |
|---|---|---|
| Уровень | Локальный SOCKS-прокси (`ciadpi`) | Пакетный обработчик NFQUEUE в ядре (`nfqws2`) |
| Отображается как | Выбирается в правилах маршрутизации («ByeDPI») | Выбирается в правилах маршрутизации («Zapret») |
| TCP | ✅ | ✅ |
| UDP / QUIC | Переносится, но не рассинхронизируется | ✅ рассинхронизируется (используется для голоса Discord) |
| DNS | Принудительно резолвится напрямую в обход ByeDPI (через него рассинхрон ломает DoH/DoT) | Не в пути DNS — Zapret трогает только потоки, направленные на него |
| Когда пробовать | Троттлинг YouTube, простой обход по сайтам | Если ByeDPI не справляется с вашим DPI или нужен рассинхрон UDP/голоса |
Ничто не мешает установить оба и прогнать тестер на каждом — оставьте тот, что даёт «всё зелёное» в вашей сети.
---
## Устранение неполадок
| Симптом | Вероятная причина / решение |
|---------|------------------------------|
| Сайт по-прежнему медленно грузится или не открывается | Стратегия не подходит вашему провайдеру — запустите **Полную проверку стратегий** и примените проходящую. |
| Тестер показывает, что всё падает | Возможно, `nfqws2` не установлен/не запущен — проверьте вкладку **Zapret** и страницу [Диагностики](Troubleshooting-ru) (она показывает статус установки / запуска / очереди). |
| Голос Discord по-прежнему рвётся | Включите **Zapret voice** и протестируйте заново. |
| Сайт недоступен, а не просто медленный | Возможно, он заблокирован по IP, а не троттлится — Zapret тут не поможет; направьте его через прокси/VPN-узел. |
См. также: [ByeDPI](ByeDPI-ru) · [Управление ядром](Core-Management-ru) · [Поддерживаемые протоколы](Supported-Protocols-ru) · [Устранение неполадок](Troubleshooting-ru)