relay - особый тип группы: трафик проходит каждого участника по порядку, образуя цепочку пересылки. Классический мотив: быстрый «транзитный» узел ретранслирует на «посадочный» с чистым IP - скорость и качество выхода одновременно.

Конфигурация

proxy-groups:
  - name: "Chain"
    type: relay
    proxies:
      - "Transit-Nearby"   # первый хоп: близко к вам
      - "Landing-US"       # последний хоп: определяет выходной IP

rules:
  - DOMAIN-SUFFIX,target-site.com,Chain

Порядок и есть путь: вы → Transit-Nearby → Landing-US → сайт. Сайт видит IP посадочного узла.

Факты для взвешивания

  • Задержки складываются: задержка цепи ≈ сумма хопов. Практический потолок - два хопа.
  • Хрупкость умножается: смерть любого хопа убивает цепь; relay не делает ни health-check, ни failover.
  • Каждый хоп должен уметь пересылать дальше: участники - только конкретные узлы (никаких url-test групп), а UDP требует поддержки UDP на каждом хопе.
  • Узлы провайдеров с пометкой «транзит/туннель» уже ретранслируют внутри - поверх них relay обычно не нужен. Ручной relay - в основном для связок своих серверов.

Типовые сценарии

  1. Защита посадочного сервера: его IP не светится вашей локальной сети - впереди транзитный хоп.
  2. Оптимизация маршрута: когда прямой путь до посадки с потерями, транзит с хорошей линией суммарно быстрее.
  3. Стабильный выход для дел: сервисы, требующие один чистый постоянный IP (коды подтверждения, строгий антифрод) - фронт меняйте, посадку держите.

Проверка цепи

С активной цепью сервис определения IP должен показывать адрес последнего хопа; на Connections в колонке Chains видно Chain. Что средний хоп реально задействован, докажет наблюдение соединений на транзитной машине (в самостоятельном сценарии).

Совет: relay - функция «точно знаю, зачем». Если хочется просто надёжности, группа fallback обходится несравнимо дешевле содержания цепочки.