Организация нескольких подписок

Сначала о вводных: в списке профилей может лежать десять карточек, но в любой момент выполняется только активная. Переключение профиля — не то же самое, что смена узла: меняется всё целиком — узлы, группы, правила, секция DNS. Как только это уложилось, цена обоих подходов ниже считается легко.

Путь А: переключать карточки руками

Самый прямой вариант, и YAML он не трогает. Днём профиль провайдера А, вечером под видео профиль провайдера Б, один щелчок по карточке. Путь годится, когда назначения профилей и так разведены, особенно если в одном из них лежит чужой набор правил, который трогать не хочется.

• Переключение пересобирает соединения. Идущие закачки рвутся, видео замирает, мессенджеры с долгими соединениями переподключаются. Не делайте этого посреди передачи.
• Правила у двух профилей обычно разные. Сайт, который под А идёт через прокси, а под Б уходит напрямую по правилу, воспринимается как сайт, работающий через день, хотя на деле под ним сменилась конфигурация.
• После возврата узел, выбранный в ручной группе, может оказаться не тем, который вы там оставили. Выбор в группах, как правило, запоминается отдельно для каждого профиля.

Путь Б: свести их через proxy-providers

Разверните мысль наоборот: перестаньте считать подписку конфигурацией и считайте её источником узлов. Ровно для этого и существует proxy-providers. Каждая подписка регистрируется как provider, клиент забирает и кеширует их по отдельности, а узлы стекаются в группы, написанные вами. Приходят только узлы — правила и группы остаются вашими, и ничего из чужого набора правил вслед за узлами не проникает.

proxy-providers:
  vendor-a:
    type: http
    url: "https://a.example.com/link?token=AAA"
    path: ./providers/vendor-a.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
  vendor-b:
    type: http
    url: "https://b.example.com/link?token=BBB"
    path: ./providers/vendor-b.yaml
    interval: 86400
    filter: "HK|SG|JP"
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
proxy-groups:
  - name: PROXY
    type: select
    use:
      - vendor-a
      - vendor-b

url — это ссылка подписки того провайдера, ровно та строка, которую вы иначе вставили бы на странице профилей. path — локальный файл кеша, и у двух источников имена файлов совпадать не должны, иначе они перезапишут друг друга; симптом — количество узлов, которое всё время скачет. interval задаётся в секундах, так что 86400 — это сутки. health-check — собственная проверка задержки для этого набора, отдельная от общей кнопки теста. Группы подтягивают провайдеров ключом use, который спокойно соседствует с proxies, так что вручную прописанные постоянные узлы остаются в том же списке. Нужен автоматический выбор самого быстрого — поставьте в type значение url-test.

После слияния имена сталкиваются

• У нескольких провайдеров есть узел с именем HK 01, и в общем списке уже не разобрать, чей он. Самое дешёвое решение — filter на каждом провайдере: регулярное выражение по именам узлов, оставляющее только нужную часть, например одни японские маршруты у провайдера Б.
• Неверный filter проявляется так: источник не даёт вообще ни одного узла, а группа теряет половину содержимого. После правки сначала убедитесь, что в группе что-то осталось, и только потом идите мерить задержку.
• Свежие сборки mihomo умеют переписывать имена на уровне провайдера и вешать на источник общий префикс. Какая версия ядра зашита в конкретный клиент — вопрос открытый, поэтому при сомнениях просто уберите дубликаты через filter: практический итог почти тот же.

Чем приходится платить за слияние

• Цифры трафика и срока пропадают. Они приходят из ответа подписки, а после слияния ваша конфигурация сама подпиской не является, так что остаток придётся смотреть в кабинете каждого провайдера.
• Один мёртвый источник тормозит всех. Если provider не скачивается или вся его пачка узлов уходит в таймаут, каждый круг health-check ждёт эти таймауты, и группа url-test заметно замедляется. Всё, что сломано давно, закомментируйте.
• Локализовать сбой становится труднее. Называйте провайдеров узнаваемо, иначе лог не подскажет, который из них падает.
• Конфигурацию отныне поддерживаете вы. Новые правила и группы, которые провайдер добавит позже, до вас уже не дойдут.

Пожалейте себя будущего

Имена стоят больше, чем кажется. Не держите стопку карточек, каждая из которых называется Subscription: напишите то, что читается с одного взгляда, например сокращение провайдера плюс месяц окончания, чтобы беглый просмотр списка сразу показывал, что вот-вот истечёт. Те, за которые вы больше не платите, удаляйте, а не оставляйте про запас: клиент продолжит ходить к ним по расписанию, продолжит получать отказ и накопит слой красных строк, сквозь который вам придётся продираться, когда вы будете разбираться с чем-то другим. Пробные подписки держите отдельно и подчищайте по окончании срока.