SmartRoute находит мёртвые серверы в пулах VLESS и Trojan

36 из первых 80 серверов подписки не прошли проверку. Для VPN-провайдера это уже не случайный сбой одного узла, а измеримая деградация всего пула.

27 августа на Хабре вышел разбор SmartRoute - открытого модуля поверх xkeen и Xray-core для OpenWrt и KeeneticOS. Модуль проверяет VLESS- и Trojan-серверы из подписки, отбрасывает недоступные узлы и выбирает рабочий маршрут прямо на роутере.

Пинг отвечает, а VPN всё равно не работает

Обычный ping показывает только одно: устройство может достучаться до IP-адреса. Он не подтверждает, что пройдут TCP и TLS, установится защищённый хендшейк Xray и ответит конечный сервис. Сервер может выглядеть доступным на сетевом уровне, но не подключать пользователя.

SmartRoute использует два последовательных сигнала. Сначала выполняется быстрый TCP-пинг. Затем Xray Observatory проводит полный защищённый хендшейк и обращается к probe-URL. Именно второй тест ближе к реальному подключению: узел признаётся рабочим после проверки фактического соединения, а не только доступности порта.

На рабочем роутере автор получил 45 успешно опрошенных серверов. Задержка составила от 373 до 4833 мс, среднее значение оказалось около 1050 мс. Из примерно 80 первых узлов 36 проверку не прошли.

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

Почему SmartRoute не использует штатный balancer Xray

Автор проверил встроенную балансировку Xray через routing.balancers со стратегией leastPing, но столкнулся с ошибкой маршрутизации. Согласно описанию проблемы, наличие любого правила с balancerTag прекращает сопоставление остальных правил. Ошибка зарегистрирована в апстриме как XTLS/Xray-core#6642.

В SmartRoute применён собственный рейтинг из четырёх уровней. Он учитывает доступность узла и результаты нескольких последовательных проверок.

Последовательность здесь важнее скорости. Если одновременно запустить десятки полноценных хендшейков, маломощный роутер может упереться в память и завершить работу с ошибкой OOM. Параллельная проверка быстрее, но в момент выбора маршрута способна перегрузить само устройство.

История серверов сохраняется после обновления подписки

SmartRoute записывает состояние узлов в персистентный кеш. После обновления подписки серверы сопоставляются через match_key, поэтому история не исчезает из-за изменения порядка записей или состава выдачи.

Модуль различает узлы, которые уже проверялись, недавно появились или начали деградировать. Это превращает подписку из статического списка адресов в пул с накопленной статистикой и понятным состоянием каждого сервера.

Для VPN-бизнеса такой подход меняет продуктовую модель. Клиент получает доступ не к одному фиксированному серверу, а к пулу, который сам исключает мёртвые узлы и выбирает пригодный маршрут.

Импорт подписки тоже может стать точкой отказа

В SmartRoute предусмотрен импорт подписки с обходом anti-bot-проверок провайдера. Для запроса перебираются 17 профилей клиента.

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

Если импорт не работает, дальнейшая проверка серверов уже невозможна. Поэтому надёжность VPN-пула начинается ещё до первого хендшейка Xray.

Kill-switch и DNS не оставлены на усмотрение пользователя

В SmartRoute постоянно включён kill-switch на nftables. Порт 53 принудительно перенаправляется, чтобы DNS-запросы не уходили мимо туннеля. UDP 80 и 443 блокируются для отсечения QUIC и HTTP/3.

Это закрывает распространённый сценарий: прокси перестал отвечать, но часть трафика продолжила идти напрямую, а DNS-запросы раскрыли домены внешнему провайдеру.

Для домашнего пользователя речь идёт о приватности. Для VPN-сервиса последствия шире: один заметный DNS-leak способен подорвать доверие к заявленной защите соединения.

36 мёртвых узлов из 80 важнее рекламного числа серверов

Показатель 36 недоступных серверов из 80 выглядит жёстко, но именно поэтому он полезен. Он переводит оценку VPN из рекламного «у нас много локаций» в измеримые параметры: сколько узлов проходит полный хендшейк, какова задержка и как быстро пул восстанавливается после блокировки.

Августовские блокировки ускоряют переход от схемы «купить сервер и раздать ссылку» к управляемой ротации узлов. В такой модели балансировка по одному пингу проигрывает проверке реального соединения.

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

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

P.S. Больше свободы в сети - заходите в бот

По разработке ботов - пишите в личные сообщения