Почему Xray лучше sing-box (и почему BEAM уходит от sing-box)

BEAM долгое время сидел на sing-box и был верен ему как ядру, считая его быстрым и удобным в разработке. Но нам пришлось уйти на другое ядро по нескольким независящим от нас причинам, которые противоречат нашим ценностям.

Как появился sing-box

Изначально вся китайская антицензура держалась на V2Ray (Project V). Когда оригинальный создатель (Victoria Raymond) отошёл от дел, ядро стагнировало, а в комьюнити назрел кризис: цензура усиливалась, старый код не справлялся, а обновления буксовали.

На этом этапе сформировались два лагеря контрибьюторов с принципиально разным видением будущего.

Лагерь прагматиков (будущий Xray)

Разработчики во главе с rprx хотели сохранить преемственность, спасти миллионы пользователей и быстро внедрять прорывные фичи (так родились XTLS, Reality, а позже XHTTP). Из-за бюрократии в апстриме V2Ray они форкнули проект и создали Xray-core — мощный, совместимый со всей старой инфраструктурой комбайн с открытым сообществом под лицензией MPL 2.0. И начали его дорабатывать под современные реалии производительности и удобства.

Лагерь радикального минимализма (nekohasekai)

Некохасекай считал, что кодовая база V2Ray/Xray безнадёжно устарела, перегружена легаси-кодом, абстракциями и не подходит для мобильных устройств. Сначала он пилил популярный клиент SagerNet (а позже Matsuri / NekoBox), где пытался прикручивать разные ядра. Но постоянная война с зоопарком чужих бинарников и ограничениями архитектуры Xray привела его к мысли: «Вы все пишете кривой спагетти-код, я уйду и перепишу всё с нуля правильно».

Так и произошёл окончательный раскол:

• Некохасекай свернул разработку старых надстроек и в соло начал писать sing-box.
• Чтобы никто не мог просто так взять его архитектурные решения и встроить в Xray или коммерческие закрытые клиенты, он выпустил проект под строжайшей GPLv3.

Почему sing-box — плохое ядро для продакшена

Когда у проекта 38 тысяч звёзд на GitHub, у большинства разработчиков и пользователей отключается критическое мышление: кажется, что перед ними несокрушимый монолит и стандарт индустрии. Но если заглянуть под капот и проследить за реальной разработкой хотя бы пару месяцев, иллюзии рассыпаются в прах.

sing-box страдает фундаментальными системными болезнями, которые делают его токсичным для любого продакшена.

1. Инцидент «reality verification failed»: как сломать миллионы клиентов за один день

Самый наглядный кейс — это недавняя драма с протоколом Reality.

Reality был изначально придуман, написан и стандартизирован командой Xray. Автор sing-box скопировал его реализацию в sing-box. Формально протокол открытый, запретить это никто не может. Но проблема в том, что реализацию утащили без какой-либо координации с авторами оригинала — синхронизации по изменениям протокола не было вообще.

Финал этой истории был предсказуем: разработчики Xray обновили серверную часть, изменив алгоритм проверки ключей и контроль совместимости. И в этот момент вся экосистема sing-box сложилась как карточный домик:

• Массовый отвал. Подавляющее большинство мировых серверов и панелей (Remnawave, 3X-UI, Marzban) крутятся именно на Xray. Клиенты на sing-box моментально начали ловить reality verification failed и намертво терять сеть (клиент тупо не мог установить соединение с сервером, использующим другой алгоритм верификации ключей Reality).
• Месяцы гробовой тишины. Проблема висит в issues месяцами. Пользователи принесли дампы, логи, сценарии воспроизведения и даже готовые Pull Requests — казалось бы, просто нажми кнопку Merge.
• Фикс так и не влили. Автор sing-box даже пальцем не пошевелил. Когда от твоего софта зависят миллионы людей под жёсткой цензурой, а критический баг совместимости с мировым серверным стеком месяцами остаётся без реакции при готовом решении на блюдечке — это уже не «авторское видение», а натуральный пофигизм на собственную аудиторию.

2. Игнорирование XHTTP в угоду личным принципам

Ни для кого не секрет, что цензоры (включая российский ТСПУ и китайский GFW) всё активнее учатся вычислять и душить Reality. Пусть пока у них это получается с переменным успехом, вечно эти кошки-мышки продолжаться не могут: длинные сессии и характерное поведение трафика xtls-rprx-vision рано или поздно начнут резать массово.

Команда Xray предусмотрела этот сценарий заранее и разработала XHTTP (SplitHTTP) — транспорт нового поколения, который дробит трафик на независимые HTTP-запросы и идеально маскирует поток под обычную веб-активность, позволяя без проблем проксировать данные даже через CDN. На сегодняшний день это самый надёжный и перспективный транспорт, который станет спасательным кругом, когда классический Reality с Vision окончательно прижмут к стенке.

Казалось бы: если sing-box в своё время без особых раздумий скопировал Reality ради удержания аудитории, почему бы не внедрить XHTTP хотя бы ради базовой совместимости? Но автор sing-box пошёл на принцип:

• Отрицание проблемы. Автор sing-box публично называет XHTTP «избыточным костылём» и вместо этого продолжает продвигать gRPC и чистый HTTP/2 — протоколы, которые цензура в РФ и других странах давно научилась вычислять без особых проблем (возможно, потому что в Китае, где живёт автор, эта конкретная проблема стоит не так остро — ему виднее).
• Решение за всех. Один разработчик решает за миллионы пользователей под цензурой, какой транспорт им «правильнее» использовать — при том что рабочее решение уже существует и проверено в бою.
• Потеря совместимости как норма. Вместо того чтобы подготовить софт заранее и дать пользователям стабильный инструмент до того, как старые методы умрут окончательно, sing-box просто теряет аудиторию. Разработчикам сторонних клиентов приходится либо сидеть на пороховой бочке, либо городить костыльные форки ядра ради одной фичи.

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

3. Лицензионный капкан GPLv3 и двойные стандарты

Отдельная и крайне показательная глава во всей этой истории — юридическая политика проекта.

Архитектурно sing-box разбит на модули, но куда ни глянь — везде намертво приколочена GPLv3. Само ядро sing-box — GPLv3, сетевой стек sing-tun — GPLv3. Казалось бы, опенсорс и свободный софт, в чём подвох? А подвох — в двойных стандартах:

• «Мне можно всё, вам — ничего». nekohasekai спокойно берёт открытые алгоритмы, архитектурные идеи и готовые протоколы вроде Reality, которые создавались комьюнити под добрыми лицензиями. Он свободно затаскивает чужой труд в свой проект, но на выходе закрывает всё жесточайшим вирусным копилефтом (при этом Xray сидит под свободным MPL с честной политикой и практически ничего не запрещает своим пользователям).
• Юридическая удавка для разработчиков. GPLv3 работает как вирус. Если разработчик клиента решает залинковать sing-box или sing-tun напрямую как Go-библиотеку (чтобы получить максимальную скорость, плавность и не гонять трафик через лишние процессы), GPLv3 юридически принуждает открыть 100% кодовой базы клиента. Нельзя просто сделать удобный инструмент с уникальной внутренней архитектурой — лицензия требует раздеть проект догола.
• Отказ от цивилизованного пути (LGPL/MPL). В здоровом опенсорсе базовые системные библиотеки и сетевые драйверы выпускаются под LGPL, MIT, Apache 2.0 или MPL 2.0, чтобы их можно было использовать как строительные блоки. Некохасекай закрепил даже низкоуровневый sing-tun под чистой GPLv3 — судя по всему, ради контроля, чтобы никто снаружи не мог построить вокруг его стека независимое решение (привет те самые 2 наносекунды скорости).

В итоге экосистема sing-box держится не на принципах открытого интернета и взаимопомощи, а на искусственно созданных юридических кандалах. Ты либо пляшешь под дудку автора, либо обязан отдавать всю свою работу в общее пользование, пока сам автор продолжает выборочно перенимать чужие находки.

4. Постоянные breaking changes: лотерея с каждым обновлением

Для любого разработчика клиентского софта или панели управления стабильность схемы конфигурации — это святое. Но только не в мире sing-box: мейнтейнер проекта полностью игнорирует понятие семантического версионирования и обратной совместимости.

• Рваный синтаксис. В минорном обновлении структура JSON-конфигов может измениться по щелчку пальцев. Автор может молча переименовать ключевые поля, перекроить логику роутинга или снести привычный формат параметров.
• Вечный ад для разработчиков. Тысячи сторонних приложений, панелей управления и генераторов конфигов постоянно сидят на пороховой бочке. Вместо того чтобы пилить новые фичи и улучшать интерфейс, разработчики вынуждены бесконечно переписывать парсеры, потому что ему, видите ли, не понравилось название ключа в JSON. Даже нейросети не могут разобраться, как писать эти sing-box конфиги...
• Непредсказуемость апдейтов. Обновление sing-box до свежей версии в продакшене — всегда русская рулетка: либо всё взлетит и попрёт на гиперскорости, либо у пользователей внезапно ляжет вся маршрутизация, а авторы клиентов будут срочно экстренно патчить свои билды.

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

5. Синтетический перфекционизм в вакууме

Вся разработка sing-box подчинена одной идее — показать красивые цифры в микробенчмарках на чистом энтузиазме. Автор бесконечно оптимизирует аллокации памяти и гонится за наносекундами там, где в реальной жизни эти микроприросты вообще не имеют никакого значения.

Но реальный интернет за пределами синтетических тестов устроен иначе:

• Игнорирование полевых условий. Пользователь сидит не в стерильной лабе с пингом 0 мс. Он перемещается между базовыми станциями LTE, ловит потери пакетов на вай-фае в метро, сталкивается с плавающим MTU и обрывами соединений, к тому же ТСПУ или GFW стоит буквально рядом с пользователем у провайдера.
• Цена микрооптимизаций. Пока автор полирует чистый код в вакууме, софт начинает сыпаться при реальных сетевых штормах. Вместо того чтобы закладывать надёжную обработку сбоев связи и адаптацию под нестабильный трафик, упор делается на сферическую «красоту архитектуры в вакууме», которая трещит по швам при первом же серьёзно заблокированном протоколе. Ему, видите ли, главное, чтоб горутина не сожрала на 1 килобайт больше памяти.
• А недавно он в своем sing-tun и вовсе сломал IPv6, засунув IPv6-over-IPv4 и даже сломав Teredo (устаревший как лет 10 назад). Зачем?

Почему нельзя вынести sing-box как отдельный бинарник?

Когда люди слышат и видят, что половина приложений (Hiddify, Happ, v2rayN) хранят sing-box как отдельный бинарник в условной папке bin или lib и дёргают его из своего основного процесса, они поневоле задумываются: а зачем тогда вообще жаловаться на лицензии, если можно сделать точно так же?

И вот тут кроется фундаментальная разница подходов: стабильность против пофигизма.

1. Кроссплатформенный ад и концепция macOS

Бинарник висит отдельным процессом всегда и везде, его нужно искать и менеджить под каждую систему отдельно. А на той же macOS это вообще гигантская проблема: система на дух не переносит дёрганье сторонних бинарников из рантайма, там такая концепция тупо противоречит архитектуре самой ОС с её изолированными .app-бандлами, песочницами и нотаризацией. Это уже как минимум вызывает вопрос: стоит ли вообще строить архитектуру через костыли, если сама ОС прямо говорит тебе так не делать? Вам на подумать)

2. Проблема мёртвого процесса и IPC

Хорошо, предположим, мы живём в идеальном мире и пользователи macOS нас не волнуют (расизм в мире VPN-клиентов, пхахах, осуждаем такое). Мы берём, тупо дёргаем бинарник и скармливаем ему сгенерированный нашим клиентом конфиг.

И что мы видим? Закрываем наш GUI — каков шанс, что sing-box останется висеть мёртвым процессом в фоне? Примерно 99.9%. И это не просто глупая отмазка, а реальная головная боль: почему разработчик должен вечно ловить этот зомби-процесс, городить костыли для IPC и зачистки хвостов, если можно тупо взять и вызвать нативный core.StartInstance()? Согласитесь, это проще и удобнее? Это на 100% использует лучшую концепцию прямого вызова функций в памяти, минуя никому не нужные абстракции: код чище, пользователям лучше. Минусов нет.

3. Это не решает фундаментальных проблем sing-box

Если вы не дай бог настроите в своём CI/CD подтягивание свежего релиза sing-box в папку, чтобы ваш GUI его дёргал, вы сделаете выстрел себе же в колено. Потому что в один прекрасный день окажется, что в очередном минорном патче переделали вообще весь блок DNS. И sing-box радостно выдаст вашему GUI ошибку в духе: «Ой, ошибка, у вас тут DNS блок неправильный» — обратная совместимость живет 2 патча, а потом выпиливается.

Вынос в отдельный .exe просто прячет проблему лицензий, но не избавляет от мин замедленного действия, заложенных в самой логике и политике разработки sing-box.

---

Наши главные ценности в разработке BEAM

BEAM был создан 21 ноября 2025 года на фоне жесточайшей ненависти к Hiddify и другим клиентам, которые вечно вылетали, лагали, выглядели уродски и неудобно. Мы решили полностью изменить концепцию и представление людей о том, каким должен быть VPN-клиент. Именно поэтому Килдум (я) решил взять всё лучшее от существующих решений и собрать ультимативный продукт, который без мануалов поймут и бабушки, и пожилые гики.

1. Мы ошиблись? Или изначально были неправы?

Сначала нам казалось, что sing-box — лучшее ядро на рынке. Мы держали его ровно так же, как и все остальные: отдельным бинарником в папке, пока в один прекрасный день эта схема не взорвала нам мозг. Один из наших пользователей заметил, что после закрытия BEAM в системе остаются висеть мёртвые процессы sing-box (а если перезапустить клиент несколько раз подряд — их накапливалось по 3–4 штуки, намертво блокируя сеть).

Мы решили не лепить пластыри поверх костылей, а сразу избавиться от порочной концепции «отдельно лежащего бинарника». Наш изначальный промах был лишь в том, что на старте мы не задумывались о юридической стороне вопроса: BEAM создавался для закрытого круга лиц и до мая 2026 года находился в стадии строгого ЗБТ. Поэтому в открытый прод он вышел максимально вылизанным, и рядовые пользователи этих ранних косяков даже не успели заметить.

2. Мы за UX, а не за 1 наносекунду синтетической скорости

Давайте смотреть правде в глаза: процент людей, которые одновременно выкачивают торрент на гигабите, смотрят 4K-видео и играют в соревновательные шутеры с миллисекундным пингом — крайне мал. BEAM всегда уважал и будет уважать потребности пользователей, но мы не собираемся идти на поводу у бессмысленного задротства и этой бессмысленной гонки за 1МБ RAM, мы не в 90-х!

Гораздо важнее дать человеку надёжное, выточенное в реальных боях приложение с предсказуемым поведением, чем хвастаться красивым скриншотом из Speedtest. Именно поэтому BEAM разрабатывался так долго, пережил две полные смены внутренней архитектуры (сейчас у нас DDD) и закалился в полевых условиях, не отступив от первоначального видения ни на шаг (разве что мы отказались от системы аккаунтов в том же ноябре 2025 в угоду независимости).

3. Впрочем, бенчмарк-энтузиастам мы тоже угодили

Ни для кого не секрет, что именно в sing-tun были чудовищные провалы по скорости и стабильности: он регулярно падал, затыкался и вообще не держал серьёзные сетевые штормы. Недавно, кстати, многие проблемы исправили — но обратного пути уже нет, слишком долго тянули.

Когда мы ушли на Xray, перед нами встал выбор: взять абстрактный, медленный tun2socks (на котором до сих пор сидит большинство клиентов) или сделать всё по-человечески. Мы отказались городить лишние прослойки абстракций. Поскольку в самом Xray нет готового из коробки адекватного TUN-стека, мы решили написать свой — beam-tun. Мы отдаём себе отчёт, насколько тяжело вылизать сетевой драйвер до идеала. Но мы осознанно берём на себя 100% ответственности за каждую строчку, каждый буфер и каждый баг. Для нас это в разы честнее и надёжнее, чем годами терпеть капризы чужого мейнтейнера с непредсказуемой политикой.

4. Почему мы принципиально не отдадим код под вирусную GPLv3?

Потому что BEAM — это в первую очередь продукт, а не очередной заброшенный опенсорс-проект на GitHub, который загнётся через полгода после того, как случайные контрибьюторы нагородят туда кривого кода.

Мы принципиально строим независимый клиент, который не пляшет под дудку чужих закрытых экосистем (вроде Happ с их телеметрией и привязками или костыльного Hiddify). Нам безумно важно, чтобы труд нас и наших тестировщиков не могли в один клик украсть: тупо форкнуть репозиторий, наклеить свой логотип, поменять пару строчек в README и продавать под видом «своей разработки», сломав наш выверенный месяцами стиль. У BEAM есть чёткий план по открытию кода, но это будет сделано цивилизованно: для тех, кто реально хочет развивать продукт вместе с нами, а не для паразитирования на чужой работе. Полноценного open-source никогда не будет и не может обсуждаться, мы будем работать так, как это хочет наше верное комьюнити в паре с нами! Поэтому мы за source-available лицензию с открытой возможностью контрибьютить.

---

На этом всё! Спасибо за прочтение :)

With ❤️ by Acelate Development