Отказоустойчивость sing-box строится на исходящем urltest: он проверяет каждый выход и направляет новые соединения через лучший работоспособный, а в Mihomo есть группа fallback, которая всегда предпочитает первый доступный выход из вашего списка. В инструкции обе схемы настраиваются для двух выходов, которыми вы владеете, а затем показано, как измерить время переключения, возврат и поведение открытых соединений, DNS и UDP.

Ключевые выводы

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

urltest в sing-box выбирает по измеренной задержке с допуском, а не по порядку в списке.

fallback в Mihomo берёт первый доступный прокси по порядку и после восстановления возвращается к предпочтительному выходу.

Переключение занимает примерно до одного интервала проверки плюс тайм-аут, поэтому его нужно измерять, а не предполагать.

HTTP-проверка может проходить, даже когда UDP на этом же выходе не работает.

Инструкция подготовлена по официальным источникам ниже; полный сквозной тест не выполнялся. Предполагаются sing-box 1.14.3 или Mihomo v1.19.32 на клиенте Linux и два рабочих прокси-выхода, которыми вы управляете или на которые у вас есть разрешение. Сначала спланируйте владение и восстановление по чек-листу собственного сервера.

Чем отказоустойчивость sing-box отличается от балансировки нагрузки?

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

Инструмент и тип	Как выбирается выход	После восстановления предпочтительного выхода
`urltest` в sing-box	Наименьшая измеренная задержка с допуском против частых переключений	Возвращается, только если восстановленный выход быстрее больше чем на допуск
`selector` в sing-box	Ручной выбор через Clash API	Остаётся там, где вы его установили
`fallback` в Mihomo	Первый доступный прокси по порядку списка	Возвращается к первому прокси, как только тот снова проходит проверку
`url-test` в Mihomo	Наименьшая измеренная задержка с допуском	Как `urltest` в sing-box

Исходящий urltest в sing-box проверяет список исходящих по URL — по умолчанию каждые 3m с допуском 50 мс.［1］ Исходящий selector переключается только через Clash API.［2］ Группа fallback в Mihomo, когда текущий узел перестаёт отвечать, выбирает первый доступный узел в порядке proxies.［3］ Два выхода удваивают объём обслуживания, поэтому, если цель — только бесперебойность, сравните собственные серверы и управляемый VPN.

Шаг 1: подготовьте два выхода и эндпоинт для проверок

Нужны два независимых выхода, здесь — серверы Shadowsocks 2022 по адресам 203.0.113.10 (выход A) и 198.51.100.20 (выход B), у каждого свой ключ. Размещайте их в разных дата-центрах или у разных провайдеров, иначе один сбой выведет из строя оба. Убедитесь, что каждый работает по отдельности, прежде чем объединять их в группу.

Оба инструмента проверяют URL через каждый выход. Если url пуст, sing-box использует адрес Google generate_204.［1］ Вместо него используйте эндпоинт под своим контролем, например https://check.example.net/generate_204, и добавьте второй путь, например /ip, который возвращает адрес обратившегося. Ежеминутные проверки стороннего сервиса с нескольких выходов должны соответствовать его условиям, а собственный эндпоинт даёт журналы, по которым видно, какой выход выполнил каждую проверку.

Шаг 2: настройте urltest в sing-box для резервирования

Если sing-box ещё не установлен, руководство по клиенту sing-box в Linux описывает установку закреплённой сборки и запуск локального слушателя. Сохраните закрытый файл failover.json:

{
  "log": {"level": "warn"},
  "inbounds": [{"type": "mixed", "tag": "local", "listen": "127.0.0.1", "listen_port": 1084}],
  "outbounds": [
    {
      "type": "urltest",
      "tag": "auto-exit",
      "outbounds": ["exit-a", "exit-b"],
      "url": "https://check.example.net/generate_204",
      "interval": "1m",
      "tolerance": 300,
      "interrupt_exist_connections": true
    },
    {"type": "shadowsocks", "tag": "exit-a", "server": "203.0.113.10", "server_port": 8388,
     "method": "2022-blake3-aes-128-gcm", "password": "REPLACE_KEY_A"},
    {"type": "shadowsocks", "tag": "exit-b", "server": "198.51.100.20", "server_port": 8388,
     "method": "2022-blake3-aes-128-gcm", "password": "REPLACE_KEY_B"}
  ],
  "route": {"final": "auto-exit"}
}

Более короткий interval раньше замечает сбой ценой большего числа проверок. Больший tolerance — главное, что меняет настройка sing-box urltest: он не даёт переключаться между двумя работающими выходами с близкими задержками, что важно, когда сессии плохо переносят смену адреса. interrupt_exist_connections закрывает входящие соединения при смене выбранного исходящего; внутренние соединения прерываются всегда.［1］ Оставьте false, если предпочитаете, чтобы старые соединения обрывались сами.

Проверьте файл командой sing-box check -c failover.json с закреплённым бинарным файлом. Успешная проверка подтверждает синтаксис, а не работоспособность выходов.

Шаг 3: настройте группу fallback в Mihomo

Для Mihomo сохраните закрытый config.yaml в отдельном каталоге:

mixed-port: 7891
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: warning
external-controller: 127.0.0.1:9090
secret: "REPLACE_LONG_RANDOM_SECRET"
proxies:
  - {name: exit-a, type: ss, server: 203.0.113.10, port: 8388, cipher: 2022-blake3-aes-128-gcm, password: "REPLACE_KEY_A", udp: true}
  - {name: exit-b, type: ss, server: 198.51.100.20, port: 8388, cipher: 2022-blake3-aes-128-gcm, password: "REPLACE_KEY_B", udp: true}
proxy-groups:
  - name: failover
    type: fallback
    proxies: [exit-a, exit-b]
    url: https://check.example.net/generate_204
    interval: 60
    timeout: 5000
    lazy: false
rules:
  - MATCH,failover

Группа fallback в Mihomo проверяет только прокси из своего поля proxies; interval задаётся в секундах, timeout — в миллисекундах, а lazy по умолчанию равен true и пропускает проверки для невыбранной группы.［4］ С lazy: false группа проверяется и в простое, поэтому к началу трафика у неё уже есть актуальный ответ. max-failed-times (по умолчанию 5) запускает внеочередную проверку после серии сбоев.［4］ Названия шифров 2022 взяты из справочника Mihomo по Shadowsocks.［5］

Оставьте allow-lan: false и bind-address: 127.0.0.1, чтобы другие устройства не могли пользоваться портом.［6］ Контроллер позволяет читать состояние группы; защитите его, как описано в руководстве по защите API контроллера Mihomo.

Шаг 4: запустите клиента и следите за выбранным выходом

Запускайте по одному инструменту в интерактивном режиме и направьте тестовый терминал на его локальный порт (1084 для sing-box, 7891 для Mihomo). В Mihomo текущий выбор группы читается через API, который принимает секрет в заголовке Bearer:［7］

curl -s -H "Authorization: Bearer $MIHOMO_SECRET" http://127.0.0.1:9090/proxies/failover

В ответе указан прокси, который группа использует сейчас. Для sing-box сравните адрес, который возвращает ваш эндпоинт /ip, с известными адресами выхода каждого сервера. В браузере, настроенном на тот же локальный порт, инструмент проверки IP-адреса должен показывать выход A или выход B, но никогда не ваше собственное подключение.

Как измерить время переключения и возврата?

Запустите цикл проверок с отметками времени через локальный порт, затем в окно обслуживания остановите прокси-службу на выходе A. Не отключайте общий сервер, от которого зависят другие люди.

while true; do
  printf '%s ' "$(date +%T)"
  curl -s -m 5 --proxy socks5h://127.0.0.1:1084 https://check.example.net/ip || printf 'FAIL'
  echo; sleep 2
done

Способ проверки	Ожидаемое поведение	Если результат другой
Оба выхода работают	Цикл стабильно показывает адрес одного выхода	Адрес скачет между выходами — увеличьте допуск в sing-box
Остановите прокси-службу на выходе A	Строки `FAIL`, затем адрес выхода B примерно в пределах интервала плюс тайм-аут	Группа не переключается — проверьте, что URL доступен через выход B
Восстановите выход A, Mihomo `fallback`	Возврат к выходу A после следующей успешной проверки	Остаётся на B — проверьте порядок списка и `lazy: false`
Восстановите выход A, sing-box `urltest`	Остаётся на B, если A не быстрее больше чем на допуск	Постоянные переключения — допуск слишком мал для разброса задержек
Остановите оба выхода	Все запросы не проходят	Запросы проходят — трафик идёт в обход группы

Запишите время от остановки выхода A до первой успешной строки через выход B. Реальная задержка переключения — именно этот промежуток, а не заданный интервал. Повторите тест несколько раз, потому что таймер проверок не синхронизирован с моментом остановки службы.

Что происходит с DNS, UDP и открытыми соединениями?

Открытые TCP-соединения остаются на том выходе, где начались. Они обрываются, если выход отказал, или закрываются раньше, когда в sing-box включён interrupt_exist_connections; в обоих случаях приложения должны переподключиться. Новые соединения идут через тот выход, который группа выбрала в этот момент.

Проверки здоровья — это HTTP-запросы, то есть они проверяют TCP через каждый выход. Выход может проходить проверку, хотя его UDP-ретрансляция заблокирована или сломана, и тогда приложения на UDP перестают работать без всякого переключения. Проверяйте UDP-нагрузку через каждый выход отдельно, а в Mihomo используйте параметр группы disable-udp, если лучше заблокировать UDP, чем отправлять его ненадёжным путём.［4］

Поведение DNS зависит от режима. В FakeIP клиент выдаёт приложениям синтетические адреса, а настоящий запрос выполняется позже через выбранный выход; сравнение FakeIP и redir-host объясняет, почему после переключения могут остаться кешированные сопоставления, похожие на устаревшие. Очистите кеш приложения или перезапустите его, если сайт продолжает не открываться после переключения.

Как откатить настройки?

Сохраните отдельный профиль для каждого выхода. Для отката остановите клиента с резервированием, верните прежние настройки прокси в приложении и проверьте новый запрос через один выход. Удаляйте журналы проверок на тестовом эндпоинте по своему расписанию и смените любой ключ, который во время тестов вставляли в общий терминал.

Итоги

Используйте urltest в sing-box, когда нужен самый быстрый работающий выход, и fallback в Mihomo, когда нужен фиксированный порядок предпочтения.
Задавайте интервалы, тайм-ауты и допуск осознанно и проверяйте эндпоинт под своим контролем.
Измеряйте реальный промежуток переключения и поведение при восстановлении, а не полагайтесь на значения в конфигурации.
Проверяйте UDP и DNS отдельно, потому что HTTP-проверки их не охватывают.

Часто задаваемые вопросы (FAQ)

Есть ли в sing-box упорядоченный fallback, как в Mihomo?

Документированный исходящий urltest выбирает по измеренной задержке с допуском, а не по порядку списка. Для фиксированного предпочтения используйте группу fallback в Mihomo или переключайте selector вручную.

Сколько времени занимает переключение в sing-box?

Ожидайте примерно до одного интервала проверки плюс время самой проверки, в зависимости от того, когда начался сбой. Измерьте это циклом с отметками времени, а не доверяйте одной настройке.

Сохранит ли резервирование мой видеозвонок или загрузку?

Обычно нет. Существующие соединения остаются на отказавшем выходе или закрываются, и приложению нужно переподключиться через новый выход, чтобы продолжить сессию.

Почему UDP не работает, хотя проверка здоровья прошла?

Проверка — это HTTP-запрос по TCP. Она подтверждает, что через выход работает пересылка TCP, но не то, что разрешены UDP-ретрансляция или трафик QUIC.

Стоит ли использовать публичный URL для проверок?

Можно, но собственный эндпоинт избавляет от зависимости от чужого сервиса и его условий, а его журналы показывают, какой выход выполнил каждую проверку.

Не лучше ли балансировка нагрузки, чем резервирование, для двух выходов?

Зависит от цели. Балансировка распределяет соединения по выходам, но не ускоряет отдельный поток и может сбивать с толку сервисы, которые ожидают один адрес.

Почему Mihomo возвращается к первому выходу после восстановления?

Тип fallback всегда предпочитает первый доступный прокси в своём списке. Как только первый выход снова проходит проверку, новые соединения возвращаются к нему.

Отказ от ответственности: Данная статья носит исключительно информационный характер и не является юридической, технической или иной профессиональной консультацией. Мы не гарантируем точность, полноту или актуальность содержания.

Источники:

sing-box: URLTest outbound — https://sing-box.sagernet.org/configuration/outbound/urltest/
sing-box: Selector outbound — https://sing-box.sagernet.org/configuration/outbound/selector/
Mihomo wiki: Fallback proxy group — https://wiki.metacubex.one/en/config/proxy-groups/fallback/
Mihomo wiki: Proxy groups — https://wiki.metacubex.one/en/config/proxy-groups/
Mihomo wiki: Shadowsocks proxy — https://wiki.metacubex.one/en/config/proxies/ss/
Mihomo wiki: General configuration — https://wiki.metacubex.one/en/config/general/
Mihomo wiki: API — https://wiki.metacubex.one/en/api/

Sources checked 14 октября 2026 г.

Рекомендуемые статьи:

Отказоустойчивость sing-box и fallback в Mihomo