--- date: 2026-07-25 tags: - clash - mihomo - sing-box - xray - сравнение aliases: - mihomo против sing-box - Сравнение ядер прокси - Какое ядро выбрать - mihomo vs Xray link: https://github.com/MetaCubeX/mihomo --- # ⚖️ mihomo против sing-box, Xray и других ядер > [!info] О чём заметка > Сравнение [[Clash/02-mihomo|mihomo]] с двумя другими универсальными ядрами — [[sing-box/sing-box-extended|sing-box]] и [[xray/project-x|Xray-core]] — и с узкоспециализированными решениями вроде [[Hysteria/00-overview|Hysteria]]. Разбор идёт по осям, которые реально влияют на выбор: формат конфига, роль в сети, маршрутизация, экосистема клиентов, серверная часть. Что такое сам mihomo и что он умеет — в заметках [[Clash/02-mihomo|mihomo (Clash.Meta)]] и [[Clash/06-features-protocols|Возможности и протоколы]]. ## TL;DR - **Список протоколов проверять обязательно — но смотреть надо на край списка, а не на середину.** Базовый набор (VLESS с REALITY, Hysteria 2, WireGuard, Shadowsocks, Trojan, VMess) есть у всех трёх, и по нему ядра неразличимы. Расходятся они на «редких» позициях, и там расхождение жёсткое: NaiveProxy есть в sing-box, но его нет ни в mihomo, ни в Xray-core; TUIC, Snell и ShadowTLS есть в mihomo и sing-box, но не в Xray; XHTTP и VLESS encryption первыми появляются в Xray. - **mihomo** — сильнее всех в клиентской маршрутизации и в живом интерфейсе: YAML-конфиг, группы политик, готовые подписки, Clash API и десяток графических оболочек поверх. - **sing-box** — строгий JSON, продуманная модель правил и rule-set, аккуратные официальные приложения на всех платформах; консервативнее в добавлении экзотики. - **Xray-core** — центр серверной экосистемы: панели 3x-ui и Marzban, самые свежие возможности VLESS ([[xray/xhttp|XHTTP]], XTLS Vision, VLESS encryption) появляются здесь первыми. - Ядра **совместимы по проводу**, а не по конфигу: сервер на Xray и клиент на mihomo прекрасно работают вместе, потому что говорят на одном протоколе — но конфиги друг друга они не читают. - Если в VLESS появляется новый режим (как постквантовое шифрование `mlkem768x25519plus`), **старые связки продолжают работать, а новые — нет**: пока ядро не обновится, подключиться к серверу с новым режимом не выйдет. Разбор — в разделе «Что будет, если VLESS изменит протокол или шифрование». - Практический ориентир: сервер — Xray или sing-box, клиент со сложной маршрутизацией и множеством подписок — mihomo, один аккуратный клиент на всех устройствах — sing-box. ## Список протоколов решает — но на краю, а не в середине Первое, что делает человек при выборе, — сравнивает таблички поддержки протоколов. Мысль «это всё равно, у всех одно и то же» здесь неверна, и вот почему. **В середине списка ядра действительно неразличимы**: VLESS с [[xray/reality|REALITY]], [[Hysteria/00-overview|Hysteria 2]], WireGuard, Shadowsocks, Trojan, VMess есть у всех трёх, и по этим позициям выбирать не из чего. Даже Hysteria 2, которой в Xray-core долго не было, появилась там в январе 2026 (релиз v26.1.23) — и это хорошая иллюстрация того, что «край списка» со временем переезжает в середину. **А на краю списка расхождения жёсткие, и обойти их нечем.** Самый наглядный пример — **[[protocols/naiveproxy|NaiveProxy]]**: он реализован в sing-box (и как входящий, и как исходящий, со свежими доработками вроде QUIC и ECH), а в Xray-core и mihomo его нет вовсе. Если сервер выдаёт вам naive, то вопрос «какое ядро удобнее» просто не стоит: подойдёт только то, где протокол реализован. Точно так же работают и обратные примеры: Snell и ShadowTLS есть в mihomo, но не в Xray-core; [[xray/xhttp|XHTTP]] и VLESS encryption рождаются в Xray и доезжают до соседей позже; OpenVPN, Tailscale и MTProxy встречаются лишь в отдельных ядрах и форках (см. [[sing-box/sing-box-extended|sing-box-extended]]). Практическое правило поэтому такое: **сначала посмотрите, какой протокол вам нужно поддержать, и только потом сравнивайте удобство**. Если протокол базовый — выбирайте по эргономике и экосистеме, разделы ниже как раз про это. Если протокол редкий — список поддержки становится главным и единственным критерием, и никакая удобная маршрутизация его не компенсирует. > [!note] Список поддержки — вещь скоропортящаяся > Позиции из «края списка» регулярно переезжают в середину: то, чего в ядре нет сегодня, вполне может появиться в релизе через месяц (mihomo, например, так получил OpenVPN и Tailscale летом 2026). Поэтому проверяйте поддержку по документации и changelog **той версии, которая у вас стоит**, а не по статьям — включая эту. Отдельно стоит понимать, откуда вообще берётся совместимость там, где она есть. **Ядра совместимы не общим кодом, а общими спецификациями**: VLESS в mihomo и VLESS в Xray-core — это разные реализации, дающие одинаковые байты на проводе. Механизм подробно разобран в заметке [[sing-box/protocols-origin|Откуда в sing-box код протоколов]], а сама идея «двух независимых реализаций одного протокола» — в [[sing-box/wire-protocol-explained|вводной про wire-протокол]]. Отсюда следует приятное: **клиент и сервер не обязаны быть на одном ядре**. Сервер на Xray с REALITY одинаково обслуживает клиента на mihomo, на sing-box и на самом Xray. И неприятное — о нём следующий раздел. ## Что будет, если VLESS изменит протокол или шифрование Вопрос звучит так: если в VLESS появится новый режим шифрования или изменится формат, перестанет ли работать sing-box (или mihomo) до обновления? **Короткий ответ: сам по себе — нет, но как только эту новинку включат на сервере — да, перестанет, и лечится это только обновлением ядра.** Разберём подробно, потому что путаница здесь стоит дорого. **Старое продолжает работать.** Ваша связка «клиент такой-то версии ↔ сервер такой-то конфигурации» не ломается от того, что где-то вышла новая спецификация. Пока сервер отдаёт то, что клиент умеет, соединение устанавливается ровно как раньше. Выход новой версии Xray не отключает ваши текущие узлы. **Ломается новое.** Раз каждое ядро реализует спецификацию своим кодом (см. предыдущий раздел), новый режим не появляется у всех одновременно. Он выходит в том ядре, где его придумали, а остальные догоняют — недели или месяцы. Всё это время связка «сервер с новым режимом ↔ клиент на другом ядре» не работает: клиент буквально не знает, что отвечать. Живой пример — [[xray/vless-encryption|**VLESS Encryption**]] (`mlkem768x25519plus`, постквантовый обмен ключами с набивкой трафика). Механизм разработали в Xray-core и выпустили в релизе v25.9.5 (5 сентября 2025). Дальше ядра разошлись: mihomo реализовал его даже раньше — в v1.19.13 от 27 августа 2025, взяв код прямо из ветки разработки Xray (сам pull request открыли только на следующий день), — а **sing-box не поддерживает его до сих пор** (проверено на стабильной v1.13.16, август 2026). Симптомы у пользователей при этом разные в зависимости от стороны: старый Xray-клиент, которому подсунули настоящую строку `encryption`, вообще не стартует — конфиг отвергается на разборе с требованием указать `"encryption":"none"`; а если такой клиент подключается к уже мигрировавшему серверу, ошибки расшифровки видит сервер, для пользователя же соединение просто обрывается или зависает. У клиентов на sing-box поведение ещё хуже: разбор идёт с запретом неизвестных полей, поэтому лишнее поле `encryption` ломает **весь** конфиг подписки, а не один узел (это касается подписок в формате конфига sing-box; клиент, сам разбирающий `vless://`-ссылку, лишний параметр отбросит). Точно так же в своё время расходились по ядрам XTLS Vision и [[xray/xhttp|XHTTP]]. **Как это выглядит на практике.** Симптом обычно не «нет интернета вообще», а «конкретный узел не подключается, остальные работают»: в логе — ошибка рукопожатия, расшифровки или неизвестного параметра. Виноват при этом не клиент «сломался», а рассинхрон версий: администратор включил на сервере то, чего ваша сборка ещё не умеет. Отсюда три практических вывода: - **Обновляйте ядро, а не только оболочку.** Графический клиент может обновляться сам по себе, а бинарник ядра внутри — оставаться прошлогодним (подробнее — в [[Clash/07-clients|заметке про клиенты]]). - **Смена параметров на сервере — это ломающее изменение для клиентов.** Если вы админ, включая новый режим шифрования, предупреждайте пользователей или держите отдельный inbound со старыми настройками, пока все не обновятся. - **Не гонитесь за самой новой опцией на клиенте без нужды.** Новый режим полезен, когда его поддерживает и ваш сервер; в остальных случаях он лишь повышает шанс поймать несовместимость. > [!warning] Обновление ядра — не только про новые функции > В прокси-ядрах регулярно чинят и то, что влияет на обнаружение: TLS-отпечатки, поведение при активном зондировании, ошибки реализации протоколов. Клиент годовалой давности может исправно подключаться и при этом выделяться на фоне свежих — то есть работать до первого внимательного взгляда DPI. Это отдельный довод обновляться, помимо совместимости. Есть и обратная сторона: **конфиги между ядрами не переносятся**. YAML от mihomo не скормить sing-box, JSON sing-box не понять Xray. Переезд означает переписывание конфигурации (или использование конвертеров подписок, которые генерируют нужный формат из общего описания узлов). ## Сравнение по осям | Ось | mihomo | sing-box | Xray-core | |---|---|---|---| | Базовый набор протоколов | VLESS/REALITY, Hysteria 2, WireGuard, SS, Trojan, VMess | то же | то же (Hysteria 2 — с января 2026) | | Протоколы «на краю списка» | TUIC, Snell, ShadowTLS, AnyTLS, SSH, OpenVPN, Tailscale, Mieru, GOST-реле; NaiveProxy — нет | NaiveProxy (in/out), TUIC, AnyTLS, ShadowTLS, Snell, SSH, Tailscale и OpenVPN (endpoint); экзотика вроде Mieru — в форке | XHTTP и VLESS encryption раньше всех; TUIC, NaiveProxy, Snell, ShadowTLS, AnyTLS, SSH — нет | | Формат конфига | YAML, читается без документации | JSON со строгой схемой | JSON, унаследованный от v2ray (внутри — protobuf) | | Основная роль | Клиент и шлюз; сервер — как дополнение | Полноценно и клиент, и сервер | Сервер как основной сценарий, клиент — тоже | | Маршрутизация | Группы политик + правила + провайдеры правил | Правила и rule-set в бинарном формате `.srs` | Правила роутинга, ориентированные на серверные сценарии | | Наборы правил | `yaml` / `text` / бинарный `.mrs` | бинарный `.srs`, компилируемый из исходников | geosite/geoip `.dat` | | API управления | Clash API — де-факто стандарт для дашбордов | Собственный API (Clash API поддерживается для совместимости) | gRPC API (статистика и управление), заточен под панели | | Графические клиенты | Больше всего оболочек: Verge Rev, FlClash, Mihomo Party, CMFA | Официальные приложения SFI/SFA/SFM + сторонние | v2rayN, Happ, Hiddify, Streisand и другие | | Серверные панели | Нет своей экосистемы панелей | Управляющая подсистема есть в форке [[sing-box/architecture\|sing-box-extended]] | 3x-ui, Marzban и другие — крупнейшая экосистема | | Темп новых функций | Очень высокий, много экзотики | Умеренный, консервативный отбор | Высокий в части VLESS/XTLS | | Язык, лицензия | Go, GPL-3.0 | Go, GPL-3.0 | Go, MPL-2.0 | Строку про API стоит развернуть: **Clash API оказался тем интерфейсом, который пережил своё ядро**. Именно поэтому вокруг mihomo существует столько независимых дашбордов и оболочек — писать их можно на чём угодно, ядро при этом остаётся неизменным. sing-box поддерживает совместимость с этим API отдельной опцией, что позволяет использовать привычные дашборды и с ним. ## Когда что выбирать **Берите mihomo**, если у вас много узлов из нескольких подписок и нужно, чтобы они автоматически проверялись и переключались; если маршрутизация сложная (десятки категорий доменов, разные правила для разных устройств в доме); если хочется веб-дашборд и один и тот же YAML на ноутбуке, телефоне и роутере. Это самое «клиентское» из трёх ядер, и в удобстве повседневного управления узлами ему пока нет равных. **Берите sing-box**, если цените предсказуемость и порядок: строгая схема конфига, аккуратная модель правил, официальные приложения под все платформы от одной команды, меньше сюрпризов при обновлении. Он же удобен, когда одним бинарником нужно закрыть и сервер, и клиент, и делать это на нескольких платформах одинаково. Разбор внутреннего устройства — в [[sing-box/architecture|архитектуре sing-box-extended]], а обзор расширенного форка — в [[sing-box/sing-box-extended|отдельной заметке]]. **Берите Xray-core**, если поднимаете сервер и хотите самую свежую линию развития VLESS: [[xray/reality|REALITY]], [[xray/xtls-vision|XTLS Vision]], [[xray/xhttp|XHTTP]] появляются здесь первыми, а вокруг ядра выросла экосистема панелей с учётом пользователей и выдачей подписок. Клиентская маршрутизация у него тоже есть (см. [[xray/routing|роутинг Xray]]), но она заметно менее «продуктовая», чем у mihomo. **Берите специализированное решение**, если задача узкая. [[Hysteria/00-overview|Hysteria 2]] — один протокол, но со своим сервером, ACL, статистикой и port hopping; на плохих каналах он часто выигрывает у универсальных ядер именно потому, что вся программа заточена под один сценарий. Обратная сторона очевидна: если UDP в вашей сети режется, запасной TCP-вариант придётся держать отдельно. > [!tip] Комбинация вместо выбора > Ядра не конкурируют внутри одной инсталляции — их можно совмещать. Типовая рабочая схема: **сервер на Xray или sing-box**, потому что там панели и свежие протоколы; **клиент на mihomo**, потому что там удобная маршрутизация и живой интерфейс. Никакой платы за такое смешение нет: связь между ними держится на протоколе, а не на общем коде. ## Что ещё есть рядом - **v2ray-core (v2fly)** — прародитель Xray, до сих пор развивается отдельным сообществом. Историю раскола и различия двух проектов разбирает заметка [[xray/v2fly-vs-xray|v2fly против Xray]]. - **Ядро оригинального Clash** — не развивается с ноября 2023 года (см. [[Clash/01-clash-core|Ядро Clash]]). Использовать его сегодня незачем: mihomo совместим с его конфигами и умеет кратно больше. - **Экспериментальные переписывания** — например, реализация ядра mihomo на Rust (`meow-rs`). Такие проекты интересны как эксперимент, но для повседневной работы у них нет ни объёма ревью, ни истории эксплуатации, ни экосистемы клиентов. - **Форки с серверными надстройками** — [[sing-box/sing-box-extended|sing-box-extended]] добавляет к sing-box панель администратора, лимитеры и десяток дополнительных протоколов. Это пример того, как недостающие возможности закрываются форком, а не сменой ядра. > [!warning] Универсального «лучшего ядра» нет > Любой рейтинг вида «X лучше Y» держится ровно до следующего релиза: набор функций у всех трёх проектов меняется каждые несколько недель, и то, чего сегодня нет в одном ядре, завтра появляется. Сравнение выше — срез на **25 июля 2026** и по устойчивым свойствам (формат конфига, экосистема, роль в сети), а не по перечню галочек. Проверяйте актуальные списки функций в документации проектов. ## 📚 См. также - [[Clash/00-overview|Обзор раздела Clash]] — оглавление раздела. - [[Clash/02-mihomo|mihomo (Clash.Meta)]] и [[Clash/06-features-protocols|его возможности]] — подробности по одной из сравниваемых сторон. - [[sing-box/sing-box-extended|sing-box-extended]] — обзор соседней платформы и её расширенного форка. - [[sing-box/protocols-origin|Откуда в sing-box код протоколов]] — почему ядра совместимы, не разделяя кода. - [[xray/project-x|Project X (Xray-core)]] — история и экосистема третьего ядра. - [[Hysteria/00-overview|Hysteria 2]] — пример специализированного решения под один протокол. - [[protocols/00-overview|Обзор протоколов]] — полная таблица поддержки протоколов по ядрам и разборы каждого протокола. - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — ограничение, которое отнимает выбор ядра на уровне подписки, а не протокола. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/08-vs-sing-box.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).