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

Все настройки, как и в первой части, выполняем локально на роутере или компьютере и используем крайнюю версию xray-core. Настройки подключений к прокси-серверам у вас могут быть прописаны, как в одном файле outbounds.json:

так и пофайлово (outbounds_1.json, outbounds_2.json, outbounds_3.json, …), в этом случае теги direct и block можете оставить только в одном из файлов, но это не обязательное условие. Так же можно объединить все файлы конфигурации в единый config.json, если вам удобно.

Условимся, что подключениям к прокси-серверам в outbounds присвоены теги proxy1, proxy2, proxy3, …, а прямое подключение имеет тег direct. Добавим в роутинг настройки балансира и заменим направляющий в прокси параметр outboundTag на параметр balancerTag. Для контроля IP-адреса будем использовать ресурс ip.me

routing.json

В параметре selector можно перечислить через запятую все теги прокси-подключений:

а можно, как в примере, указать только префикс proxy согласно документации:

Массив selector

В параметре fallbackTag, как следует из его названия, указано запасное подключение, на случай если ни один прокси недоступен. Разумеется, тут можно использовать не только direct, но и резервное прокси-подключение, а так же можно пустить трафик через wireguard.

В предлагаемом примере используется стратегия leastPing, по которой приоритет получает наиболее быстро ответивший прокси-сервер. Остальные стратегии смотрите в документации xray, я не заостряю на них внимание, чтобы не раздувать статью.

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

observatory.json

В этом конфиге проверяем доступность прокси-серверов из массива subjectSelector, пытаясь каждые 60 секунд подключиться через них к адресу, указанному в параметре probeUrl (в subjectSelector так же можно перечислить все теги серверов, а можно, как и в роутинге, использовать префикс proxy). В отличие конфигурации с одним сервером в конфиг добавлен параметр enableConcurrency, который разрешает проверять прокси не по очереди, а одновременно. Как только один из серверов «оживёт», балансировщик переключит маршрутизацию с запасного direct направления на него.

Кроме режима observatory, можно использовать burstObservatory. Оба режима взаимозаменяемы и какого-либо преимущества перед друг другом не имеют, разница заключается в методе мониторинга подключений. Observatory это фоновый мониторинг подключений, а burstObservatory это мониторинг параллельных подключений. Выберите какой-то один режим и не используйте одновременно оба. Подробности настройки burstObservatory смотрите в официальной документации xray, я не заостряю на ней внимание по выше обозначенной причине.