Когда v2raya зависал: разбор миграции на mihomo

Обновлено 21 сентября 2026 года. Это ретроспектива моего случая на Linux: что именно ломалось, почему собственный watchdog усложнил систему и какие проверки оказались полезны при смене клиента. Здесь нет инструкции по подключению к ограниченным ресурсам или рекомендации конкретного сервиса.

Как выглядел сбой

У меня v2raya работал вместе с Xray-core. Проблема проявлялась как «тихое» зависание: процесс оставался запущенным, локальный порт отвечал, но пользовательские соединения переставали передавать данные. Обычная проверка состояния службы этого не замечала — для неё процесс был жив.

Первой реакцией стал watchdog на Bash. Он периодически проверял соединение через клиент, пытался переключить узел через локальный API и перезапускал службу, когда API не отвечал. Через несколько месяцев в нём было около 350 строк и пять файлов состояния. Сам механизм восстановления превратился в отдельный источник ошибок.

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

Что я мог подтвердить, а что нет

Локально я наблюдал расхождение между состоянием процесса и результатом прикладного запроса. Этого достаточно, чтобы не считать статус службы показателем доступности канала. Но по одним этим наблюдениям нельзя доказать, что виноваты именно v2raya, Xray-core, конкретная сборка или внешняя сеть.

В записях того периода я отметил около 180 МБ памяти у прежней связки в обычной работе и около 48 МБ у mihomo после перехода. Во время одного цикла частых переключений прежний процесс разросся до нескольких гигабайт и завершился из-за нехватки памяти. Это измерения на моей машине при разных нагрузках, а не воспроизводимый бенчмарк двух проектов. Цифру 48 МБ нельзя превращать в обещание потребления памяти для другой системы.

Почему я сменил клиент

Я перешёл на mihomo, чтобы уменьшить число собственных компонентов в цепочке восстановления. Мне были нужны проверки, которые смотрят на результат запроса, а не только на открытый TCP-порт, и предсказуемое поведение при смене активного соединения. После перехода я убрал свой watchdog и связанные с ним файлы состояния.

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

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

Что показали более поздние логи

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

В журнале mihomo за 21 сентября видны повторяющиеся предупреждения о невозможности определить исходящий сетевой интерфейс и ошибки соединений с сообщением no such device. Затем журнал сообщает о смене интерфейса и показывает новые попытки передачи трафика. Это подтверждает кратковременный сбой маршрута, но не устанавливает его причину и не доказывает, что после смены интерфейса все запросы успешно завершились.

Вывод после этих логов уже скромнее: переход позволил убрать мой Bash-watchdog, но не избавил от диагностики DNS, маршрутов и восстановления при смене сети.

Что вынес из случая

• Проверять результат операции. Живой процесс и успешное TCP-соединение не означают, что прикладной запрос завершится.
• Учитывать время установления соединения. Слишком ранняя повторная проверка способна запустить ложное восстановление.
• Ограничивать автоматику. У восстановления должны быть пауза, предел повторных попыток и понятный журнал причин переключения.
• Сравнивать на одной нагрузке. Разовые значения памяти и скорости полезны для расследования, но сами по себе не подтверждают преимущество продукта.
• Сохранять откат. Смена клиента становится менее рискованной, когда предыдущая конфигурация доступна до завершения наблюдения.

Почему статья стала короче

В первой версии были название и цена платной подписки, готовая конфигурация маршрутизации и промпт для автоматической настройки. Я удалил эти части при обновлении. Часть 10.8 статьи 5 закона «О рекламе» запрещает рекламу средств доступа к ресурсам, доступ к которым ограничен в РФ. Пункт «м» части 5 статьи 15.1 закона «Об информации» касается информации о способах такого доступа; критерии Роскомнадзора отдельно учитывают побуждение к использованию этих способов. Само название программы в технической ретроспективе не делает материал автоматически рекламой, но оценка зависит от содержания и контекста публикации.

Здесь остаётся инженерный разбор наблюдавшегося отказа. Он не предназначен для продвижения сервиса или настройки доступа к ограниченным ресурсам.