Relay-сервер для Hiddify - промежуточный сервер фронт-бэк#

Когда главный VPS за границей блокируют по IP или к нему медленный маршрут, между клиентом и главным сервером ставят промежуточный relay-сервер в стране проживания. Клиент подключается к relay, а тот форвардит трафик на зарубежный бэк. Получается связка "фронт (RU) -> бэк (EU)".

Зачем нужен relay-сервер#

Главный сервер (vpn.example.com, например 203.0.113.10) не виден клиенту напрямую - его IP скрыт за relay.
Если IP бэка попал под блок, его меняют, не трогая клиентские подписки: точка входа остается на relay (relay.example.com).
Локальный relay дает короткий стабильный первый хоп; дальний маршрут за границу прячется в туннеле фронт-бэк.
relay дешевый: хватает слабой VPS (256 МБ RAM), важен лишь "чистый" IP и адекватный канал.

Какие туннели есть у Hiddify#

Hiddify Manager штатно поддерживает несколько способов поднять связку фронт-бэк:

IP-Tables / IP-Forwarding - простой L4-форвард пакетов средствами ядра, без шифрования и без логики.
HA-Proxy - L4/TCP-проксирование портов на стороне relay, тоже простой проброс.
GOST - L4-туннель с шифрованием и работой по домену (а не голому IP), есть свой systemd-сервис.
Dokodemo-Door - проброс на ядре Xray (inbound dokodemo-door -> outbound на бэк).
WST (wstunnel) - туннель поверх WebSocket, удобен для маскировки под web-трафик.

Все они решают одну задачу - дотащить трафик с фронта на бэк, но не умеют маршрутизацию: разруливать, что слать в туннель, а что напрямую, они не могут.

Почему мы используем mihomo-каскад#

Для фронт-бэк мы предпочитаем mihomo-каскад: RU-фронт каскадирует трафик на EU-бэк и при этом применяет правила маршрутизации - часть идет через бэк, часть напрямую, по спискам доменов и IP. Голый L4-форвард такого не дает. Как это раскладывается на узлы - в заметке мультинода и каскад.

Источники#

На основе официальной документации Hiddify Manager: IP-Tables tunnel relay.

Не помогло или есть уточняющий вопрос - заходите в русское сообщество @hiddify_rus.