todo/Clash/08-vs-sing-box.md

date	tags	aliases	link
2026-07-25	clash mihomo sing-box xray сравнение	mihomo против sing-box Сравнение ядер прокси Какое ядро выбрать mihomo vs Xray	https://github.com/MetaCubeX/mihomo

⚖️ mihomo против sing-box, Xray и других ядер

[!info] О чём заметка Сравнение Clash/02-mihomo с двумя другими универсальными ядрами — sing-box/sing-box-extended и xray/project-x — и с узкоспециализированными решениями вроде Hysteria/00-overview. Разбор идёт по осям, которые реально влияют на выбор: формат конфига, роль в сети, маршрутизация, экосистема клиентов, серверная часть. Что такое сам mihomo и что он умеет — в заметках Clash/02-mihomo и 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, XTLS Vision, VLESS encryption) появляются здесь первыми.
• Ядра совместимы по проводу, а не по конфигу: сервер на Xray и клиент на mihomo прекрасно работают вместе, потому что говорят на одном протоколе — но конфиги друг друга они не читают.
• Если в VLESS появляется новый режим (как постквантовое шифрование mlkem768x25519plus), старые связки продолжают работать, а новые — нет: пока ядро не обновится, подключиться к серверу с новым режимом не выйдет. Разбор — в разделе «Что будет, если VLESS изменит протокол или шифрование».
• Практический ориентир: сервер — Xray или sing-box, клиент со сложной маршрутизацией и множеством подписок — mihomo, один аккуратный клиент на всех устройствах — sing-box.

Список протоколов решает — но на краю, а не в середине

Первое, что делает человек при выборе, — сравнивает таблички поддержки протоколов. Мысль «это всё равно, у всех одно и то же» здесь неверна, и вот почему. В середине списка ядра действительно неразличимы: VLESS с xray/reality, Hysteria/00-overview, WireGuard, Shadowsocks, Trojan, VMess есть у всех трёх, и по этим позициям выбирать не из чего. Даже Hysteria 2, которой в Xray-core долго не было, появилась там в январе 2026 (релиз v26.1.23) — и это хорошая иллюстрация того, что «край списка» со временем переезжает в середину.

А на краю списка расхождения жёсткие, и обойти их нечем. Самый наглядный пример — protocols/naiveproxy: он реализован в sing-box (и как входящий, и как исходящий, со свежими доработками вроде QUIC и ECH), а в Xray-core и mihomo его нет вовсе. Если сервер выдаёт вам naive, то вопрос «какое ядро удобнее» просто не стоит: подойдёт только то, где протокол реализован. Точно так же работают и обратные примеры: Snell и ShadowTLS есть в mihomo, но не в Xray-core; xray/xhttp и VLESS encryption рождаются в Xray и доезжают до соседей позже; OpenVPN, Tailscale и MTProxy встречаются лишь в отдельных ядрах и форках (см. sing-box/sing-box-extended).

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

[!note] Список поддержки — вещь скоропортящаяся Позиции из «края списка» регулярно переезжают в середину: то, чего в ядре нет сегодня, вполне может появиться в релизе через месяц (mihomo, например, так получил OpenVPN и Tailscale летом 2026). Поэтому проверяйте поддержку по документации и changelog той версии, которая у вас стоит, а не по статьям — включая эту.

Отдельно стоит понимать, откуда вообще берётся совместимость там, где она есть. Ядра совместимы не общим кодом, а общими спецификациями: VLESS в mihomo и VLESS в Xray-core — это разные реализации, дающие одинаковые байты на проводе. Механизм подробно разобран в заметке sing-box/protocols-origin, а сама идея «двух независимых реализаций одного протокола» — в sing-box/wire-protocol-explained.

Отсюда следует приятное: клиент и сервер не обязаны быть на одном ядре. Сервер на 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.

Как это выглядит на практике. Симптом обычно не «нет интернета вообще», а «конкретный узел не подключается, остальные работают»: в логе — ошибка рукопожатия, расшифровки или неизвестного параметра. Виноват при этом не клиент «сломался», а рассинхрон версий: администратор включил на сервере то, чего ваша сборка ещё не умеет.

Отсюда три практических вывода:

• Обновляйте ядро, а не только оболочку. Графический клиент может обновляться сам по себе, а бинарник ядра внутри — оставаться прошлогодним (подробнее — в 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	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/sing-box-extended.

Берите Xray-core, если поднимаете сервер и хотите самую свежую линию развития VLESS: xray/reality, xray/xtls-vision, xray/xhttp появляются здесь первыми, а вокруг ядра выросла экосистема панелей с учётом пользователей и выдачей подписок. Клиентская маршрутизация у него тоже есть (см. xray/routing), но она заметно менее «продуктовая», чем у mihomo.

Берите специализированное решение, если задача узкая. Hysteria/00-overview — один протокол, но со своим сервером, ACL, статистикой и port hopping; на плохих каналах он часто выигрывает у универсальных ядер именно потому, что вся программа заточена под один сценарий. Обратная сторона очевидна: если UDP в вашей сети режется, запасной TCP-вариант придётся держать отдельно.

[!tip] Комбинация вместо выбора Ядра не конкурируют внутри одной инсталляции — их можно совмещать. Типовая рабочая схема: сервер на Xray или sing-box, потому что там панели и свежие протоколы; клиент на mihomo, потому что там удобная маршрутизация и живой интерфейс. Никакой платы за такое смешение нет: связь между ними держится на протоколе, а не на общем коде.

Что ещё есть рядом

• v2ray-core (v2fly) — прародитель Xray, до сих пор развивается отдельным сообществом. Историю раскола и различия двух проектов разбирает заметка xray/v2fly-vs-xray.
• Ядро оригинального Clash — не развивается с ноября 2023 года (см. Clash/01-clash-core). Использовать его сегодня незачем: mihomo совместим с его конфигами и умеет кратно больше.
• Экспериментальные переписывания — например, реализация ядра mihomo на Rust (meow-rs). Такие проекты интересны как эксперимент, но для повседневной работы у них нет ни объёма ревью, ни истории эксплуатации, ни экосистемы клиентов.
• Форки с серверными надстройками — sing-box/sing-box-extended добавляет к sing-box панель администратора, лимитеры и десяток дополнительных протоколов. Это пример того, как недостающие возможности закрываются форком, а не сменой ядра.

[!warning] Универсального «лучшего ядра» нет Любой рейтинг вида «X лучше Y» держится ровно до следующего релиза: набор функций у всех трёх проектов меняется каждые несколько недель, и то, чего сегодня нет в одном ядре, завтра появляется. Сравнение выше — срез на 25 июля 2026 и по устойчивым свойствам (формат конфига, экосистема, роль в сети), а не по перечню галочек. Проверяйте актуальные списки функций в документации проектов.

📚 См. также

• Clash/00-overview — оглавление раздела.
• Clash/02-mihomo и Clash/06-features-protocols — подробности по одной из сравниваемых сторон.
• sing-box/sing-box-extended — обзор соседней платформы и её расширенного форка.
• sing-box/protocols-origin — почему ядра совместимы, не разделяя кода.
• xray/project-x — история и экосистема третьего ядра.
• Hysteria/00-overview — пример специализированного решения под один протокол.
• protocols/00-overview — полная таблица поддержки протоколов по ядрам и разборы каждого протокола.
• subscriptions/hwid-client-lock — ограничение, которое отнимает выбор ядра на уровне подписки, а не протокола.

---

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.