Группы прокси в mihomo: select, url-test и fallback

Группа прокси — это именованный набор серверов с описанием того, как из него выбирается один. Правила маршрутизации почти никогда не указывают конкретный сервер: они ссылаются на группу, а группа уже решает, куда отправить соединение прямо сейчас. Такая развязка позволяет менять узлы, не переписывая ни одного правила.

В секции proxy-groups у mihomo несколько типов групп, и различаются они именно логикой выбора: ручной, по задержке, по порядку отказоустойчивости или с распределением нагрузки. Разберём каждый тип и то, как из них складываются многоуровневые конфигурации, которые приходят в подписках.

Зачем группы вообще нужны

Представьте конфигурацию с полусотней серверов. Без групп каждое правило пришлось бы привязывать к конкретному имени, а при смене сервера — править десятки строк. Группы решают сразу три задачи: дают правилам стабильную точку назначения, собирают серверы в осмысленные наборы (по регионам, по назначению) и предоставляют пользователю удобный переключатель в интерфейсе клиента. То, что вы видите в клиенте как список для выбора, — это и есть группы из вашего профиля.

select: ручное переключение

Самый простой и самый распространённый тип. Группа хранит список вариантов, а активный выбирает пользователь — через интерфейс клиента или через API.

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "Auto"
      - "Japan"
      - "server-01"
      - DIRECT

Обратите внимание: в списке допустимы не только серверы, но и другие группы, а также встроенные адресаты DIRECT и REJECT. Добавить DIRECT в группу выбора удобно для отладки: одним переключением проверяете, связана ли проблема с прокси или существует и без него.

url-test: автоматический выбор по задержке

Группа периодически проверяет доступность серверов и оставляет активным тот, который отвечает быстрее остальных.

  - name: "Auto"
    type: url-test
    interval: 300
    tolerance: 50
    proxies:
      - "server-01"
      - "server-02"
      - "server-03"

Параметр interval задаёт период проверки в секундах, tolerance — допуск в миллисекундах: новый сервер станет активным только если он быстрее текущего на эту величину. Без допуска группа начала бы дёргаться при каждом колебании сети, обрывая соединения. Значение tolerance порядка нескольких десятков миллисекунд обычно даёт спокойное поведение. Адрес, по которому идёт проверка, задаётся полем url — в профилях провайдеров оно, как правило, уже прописано.

fallback и load-balance

Группа fallback работает по порядку списка: активен первый доступный сервер, и только если он перестал отвечать, группа переходит к следующему. Это сценарий «основной сервер и резервный», а не «самый быстрый».

  - name: "Backup"
    type: fallback
    interval: 300
    proxies:
      - "server-main"
      - "server-reserve"

Группа load-balance не выбирает один сервер, а распределяет между ними соединения — новые запросы уходят на разные узлы. Поле strategy определяет способ распределения: например, привязку по домену, чтобы все соединения одного сайта шли через один и тот же сервер. Такой режим полезен при большом количестве параллельных соединений, но усложняет отладку: одинаковые запросы могут уходить разными путями.

Вложенные группы: структура типичного профиля

Группы можно вкладывать друг в друга, и именно на этом построены конфигурации, которые приходят в подписках. Схема обычно двухуровневая. Внизу — региональные группы (Japan, Singapore, Germany), каждая типа url-test, чтобы внутри региона автоматически выбирался живой сервер. Наверху — функциональные группы (PROXY, Streaming, Telegram) типа select, в списке которых перечислены региональные группы.

Правила ссылаются на функциональные группы, пользователь переключает регион одним движением, а внутри региона автоматика сама справляется с падением отдельных серверов. Как правила выбирают группу для конкретного соединения, разобрано в статье о правилах маршрутизации.

Какой тип выбрать под задачу

• Один сервер на всё и полный контроль — select. Понятно, предсказуемо, легко отлаживать.
• Не хочется следить за узлами — url-test с разумным interval.
• Нужен резерв на случай отказа — fallback с явным порядком приоритета.
• Много параллельных соединений — load-balance, если готовы мириться с усложнением диагностики.

На практике удобнее комбинировать: автоматическая группа внутри и ручной выбор снаружи. Общая структура файла, в который вписываются эти секции, разобрана во введении в конфигурацию mihomo, а готовый набор групп проще всего получить вместе с профилем — см. импорт подписки.