Технологии

21 сентября 2026 г.

Разоблачение на «Почему Xray лучше sing-box»

Статья Acelate начинается как технический разбор, быстро превращается в обвинительное заключение, а заканчивается рекламой собственного закрытого продукта. Всё это подаётся с таким напором, будто автор лично провёл вскрытие двух ядер, отладил TLS на уровне…

Ответ на статью Acelate: «Почему Xray лучше sing-box (и почему BEAM уходит от sing-box)»(внешняя ссылка, откроется в новой вкладке)

Дата фактчека: 21 сентября 2026 года
Проверенные версии: Xray-core 26.9.9, sing-box 1.15.0-alpha.6, TodayCore 1.15.0-alpha6.7-beta

Спойлер: не принёс.

Есть реальный баг REALITY. Есть агрессивные миграции конфигов sing-box. Есть неудобная для закрытого BEAM лицензия GPLv3. Но между этими фактами в статью аккуратно напиханы выдуманные сроки, неподтверждённые масштабы, неверные утверждения о macOS, страшилки про процессы и личные догадки о мотивах разработчика.

Давайте сделаем то, чего не сделал оригинал: разнесём всё по исходникам, датам, лицензиям и реальному коду.

Коротко: что в статье правда, а что — художественный свист

Тезис Acelate	Вердикт	Что на самом деле
Новый Xray сломал совместимость REALITY с sing-box	✅ Правда	Xray начал требовать `X25519MLKEM768` в ClientHello
Баг «месяцами висел без реакции»	❌ Ложь	Между изменением Xray и публикацией статьи прошло 13 дней
Пострадали «миллионы клиентов»	❓ Не доказано	Ни статистики, ни телеметрии, ни оценки установок не приведено
В sing-box нет upstream-поддержки XHTTP	✅ Правда	Большой PR был закрыт без принятия
XHTTP невозможно нормально реализовать в sing-box	❌ Ложь	Клиентский порт уже существует в TodayCore
GPL автоматически требует открыть 100% GUI	⚠️ Манипуляция	Для in-process linking риск реален; отдельный процесс обычно является отдельной программой
macOS «не переносит» внешние бинарники	❌ Ложь	Apple официально документирует embedded helper tools
Отдельный core останется висеть с вероятностью 99,9%	❌ Выдумка	Процент взят с потолка; lifecycle штатно управляется ОС и приложением
sing-box молча ломает конфиги каждым патчем	⚠️ Преувеличение	Миграций много, но они документируются и обычно имеют deprecation window
Xray доказанно быстрее и надёжнее	❌ Не доказано	В статье нет сравнительного benchmark suite
sing-tun сломал IPv6 и Teredo	❌ Не доказано	Нет ссылки на commit, issue или воспроизводимый сценарий
BEAM уходит от sing-box	⚠️ Заявлено	В тот же день официальный сайт всё ещё называет BEAM клиентом на базе sing-box

1. REALITY действительно сломался. А теперь посмотрим, кто врёт про сроки

Начнём с самого сильного аргумента статьи — reality verification failed.

8 сентября 2026 года в XTLS/REALITY появился commit, который начал отклонять ClientHello без гибридного key share X25519MLKEM768, расположенного перед обычным X25519.Источник(внешняя ссылка, откроется в новой вкладке)

11 сентября был открыт воспроизводимый issue в sing-box: клиенты 1.12.25, 1.14.x, 1.15 alpha и testing не подключались к Xray 26.9.8/26.9.9.Источник(внешняя ссылка, откроется в новой вкладке)

Статья Acelate опубликована 21 сентября.

Считаем на пальцах:

8 сентября — изменение REALITY;
11 сентября — публичный issue;
21 сентября — публикация Acelate.

Тринадцать дней от commit. Десять дней от issue.

Но нам рассказывают про «месяцы гробовой тишины».

Это уже не эмоциональная оценка. Это просто фактически невозможная хронология. Машину времени в репозитории sing-box пока не нашли.

Что именно сломалось

Проблема была не в магическом «другом алгоритме проверки ключей Reality», как пересказывает статья. Цепочка конкретная:

Xray-сервер потребовал X25519MLKEM768 перед X25519.
ClientHello sing-box не содержал подходящий гибридный key share.
Сервер классифицировал такой ClientHello как неподходящий.
REALITY молча уходил в fallback на сайт-донор.
Клиент получал настоящий сертификат донора вместо ожидаемой REALITY-подписи.
На клиенте появлялось reality verification failed.

Есть и второй слой совместимости: REALITY упаковывает версию клиента в первые три байта session_id. Старый клиент sing-box сообщал 1.8.1; сервер с minClientVer мог отвергнуть его даже при правильно сформированном криптографическом материале.

В TodayCore обе части исправлены:

ClientHello собирается через UTLSIdToSpec → HelloCustom → ApplyPreset;
X25519MLKEM768 вставляется строго перед X25519;
обычный X25519 сохраняется, поскольку REALITY использует соответствующий ECDHE-ключ для authKey;
версия клиента в session_id обновлена до 26.9.9.

То есть перед нами конкретный compatibility gap, исправляемый локальным патчем. Не доказательство того, что вся архитектура sing-box «токсична для любого продакшена».

А где миллионы пострадавших?

3X-UI, Marzban и Remnawave действительно построены вокруг Xray-core.Источник(внешняя ссылка, откроется в новой вкладке)Источник(внешняя ссылка, откроется в новой вкладке)Источник(внешняя ссылка, откроется в новой вкладке)

Но из этого не следует, что:

все их серверы мгновенно обновились до 26.9.8+;
все клиенты на этих серверах использовали sing-box;
все использовали REALITY с затронутым fingerprint;
число реально пострадавших измерялось миллионами.

Фраза «сломали миллионы клиентов» звучит мощно. Осталось приложить какую-нибудь статистику, кроме внутреннего ощущения автора.

2. XHTTP: отсутствие в upstream — факт. «Невозможность» — уже сказка

Да, upstream sing-box не принял XHTTP.

PR #4326 добавлял:

packet-up;
stream-up;
stream-one;
XMUX;
padding и placement;
downloadSettings;
HTTP/3;
REALITY interoperability tests.

CI прошёл, но PR был закрыт 13 сентября без публичного технического объяснения мейнтейнера.Источник(внешняя ссылка, откроется в новой вкладке)Источник(внешняя ссылка, откроется в новой вкладке)

Это нормальная претензия к upstream: пользователям нужна совместимость, готовая реализация существовала, а понятной публичной позиции не появилось.

Но дальше статья совершает любимый трюк: превращает «upstream не принял реализацию» в «sing-box технически не способен иметь XHTTP».

Что показал реальный порт

Контракт V2Ray-транспорта в sing-box узкий:

клиент должен вернуть net.Conn;
сервер должен принять логическое соединение и передать его handler-у.

XHTTP ровно этим и занимается: собирает логический net.Conn поверх независимых HTTP-запросов. Никакого фундаментального конфликта архитектур здесь нет.

В TodayCore поверх sing-box 1.15.0-alpha.6 добавлен клиентский XHTTP-порт:

transport/v2rayxhttp/
├── client.go       — packet-up / stream-up / stream-one
├── client_http.go  — H1/H2, dial и reuse
├── config.go       — совместимые с Xray опции и дефолты
├── conn.go         — splitConn
├── h1conn.go       — H1 keep-alive
├── headers.go      — браузерные заголовки
├── pipe.go         — upload queue
├── placement.go    — path/query/header/cookie/body
├── util.go         — ranges и session ID
├── xmux.go         — XMUX
└── xpadding.go     — padding и obfs mode

Реализованы:

все три клиентских режима;
HTTP/1.1 и HTTP/2;
XMUX с maxConcurrency, maxConnections, cMaxReuseTimes, hMaxRequestTimes, hMaxReusableSecs;
X-Padding;
размещение session ID, sequence и uplink data;
отдельный downlink через downloadSettings;
работа поверх TLS и REALITY;
конфигурационные имена, совместимые с Xray.

Сознательно не реализованы:

XHTTP inbound/server;
HTTP/3 из-за несовместимых форков quic-go;
Browser Dialer.

Для desktop VPN-клиента, который подключается к Xray-серверу, это означает практически нужный набор: полная клиентская поддержка XHTTP для H1/H2, а не «невозможный костыль».

XHTTP остаётся технологией Xray, и его документация действительно описывает полезные свойства: раздельные направления, packet-up, streaming-down, H2/H3, CDN и XMUX.Источник(внешняя ссылка, откроется в новой вкладке)

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

3. Пока Acelate хоронил sing-box, в него портировали ещё и VLESS Encryption

В статье рисуется мир, где Xray в одиночку изобретает будущее, а sing-box способен только «тащить чужое» и ломаться.

Реальность немного неудобнее для этого нарратива.

В TodayCore уже добавляется клиентская реализация mlkem768x25519plus — нового VLESS Encryption из Xray 26.9.9.

Это не переименование поля в JSON. Это полноценный криптографический слой перед обычным VLESS:

долговременная аутентификация через X25519 или ML-KEM-768;
гибридный эфемерный PFS-обмен ML-KEM-768 + X25519;
UnitedKey = PfsKey || NfsKey;
AEAD record layer на AES-256-GCM или ChaCha20-Poly1305;
TLS-подобные записи 17 03 03 <len> <ciphertext>;
режимы native, xorpub, random;
1-RTT и 0-RTT tickets;
padding DSL;
цепочки NFS-ключей.

Клиентский parser принимает тот же формат, что Xray:

mlkem768x25519plus.<native|xorpub|random>.<1rtt|0rtt>[.<padding>].<key>...

Интеграция выполнена до отправки внутреннего VLESS-заголовка: сначала создаётся защищённый record layer, затем поверх него работает обычный VLESS/Vision.

Это ещё не upstream sing-box и не серверная реализация. Но как инженерный контрпример этого достаточно: архитектура sing-box расширяется и принимает новые слои Xray без капитальной перестройки ядра.

4. GPLv3: когда бизнес-ограничение BEAM выдают за технический дефект

Здесь статья наконец касается реальной причины перехода.

sing-box и sing-tun лицензированы под GPLv3-or-later.Источник(внешняя ссылка, откроется в новой вкладке)Источник(внешняя ссылка, откроется в новой вкладке)

Xray-core — под MPL 2.0.Источник(внешняя ссылка, откроется в новой вкладке)

Если закрытый BEAM напрямую линкует GPL-код в один процесс и распространяет получившийся продукт, лицензионный риск действительно серьёзный. MPL для такой модели гораздо удобнее: copyleft применяется на уровне файлов, а собственные файлы larger work могут оставаться закрытыми.Источник(внешняя ссылка, откроется в новой вкладке)

Вот только это означает не «sing-box плох», а:

BEAM хочет закрытый in-process core, а условия GPL мешают бизнес-модели BEAM.

Совершенно нормальная причина. Зачем было обмазывать её рассказами про «вирус», «удавку» и моральную неполноценность автора — вопрос к драматургии.

GPL не означает автоматическое раскрытие любого GUI

FSF проводит важное различие:

общий executable/shared address space и linking обычно указывают на одну комбинированную программу;
exec, pipes, sockets и command-line arguments обычно используются между отдельными программами;
окончательная граница зависит и от характера передаваемых данных.Источник(внешняя ссылка, откроется в новой вкладке)

Следовательно, отдельный GPL-бинарник — не «грязный способ спрятать проблему», а юридически значимая архитектурная граница.

И кто здесь на самом деле хочет больше контроля?

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

А затем гордо сообщает:

полноценного open source у BEAM не будет;
свободный форк нежелателен;
перепродажа производных продуктов нежелательна;
будет source-available на условиях владельца.

То есть GPL разрешает изучать, изменять, форкать и продавать код — при условии сохранения тех же свобод для следующих пользователей.

BEAM хочет оставить за собой право запретить свободный форк и повторное распространение.

Можно выбрать любую модель. Но называть вторую модель «цивилизованной свободой», а первую — «юридическими кандалами» немного охуенно даже по меркам рекламного текста.

5. macOS якобы «на дух не переносит» helper binaries

Это один из самых легко проверяемых фейлов статьи.

Apple имеет официальную документацию Embedding a command-line tool in a sandboxed app. В ней прямо объясняется, как:

добавить helper tool в проект;
положить его в .app/Contents/MacOS;
подписать;
включить Code Sign On Copy;
запускать из sandboxed-приложения.Источник(внешняя ссылка, откроется в новой вкладке)

Раздел App Sandbox сам ссылается на этот механизм.Источник(внешняя ссылка, откроется в новой вкладке)

Да, macOS требует:

корректные entitlements;
code signing;
notarization;
правильное размещение helper-а;
аккуратное управление Network/System Extension.

Но фраза «сама ОС прямо говорит тебе так не делать» — противоположность реальности. Сама ОС даёт инструкцию, как именно это делать.

Сложно? Иногда. Запрещено архитектурой? Нет.

6. «99,9% мёртвых процессов»: статистика из института внутреннего ощущения

BEAM запускал sing-box отдельным процессом. После закрытия GUI процесс иногда оставался работать. Значит ли это, что отдельный core фундаментально непригоден?

Нет. Это значит, что BEAM плохо управлял дочерним процессом.

На Windows для групп процессов существуют Job Objects. Флаг JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE завершает связанные процессы при закрытии последнего handle.Источник(внешняя ссылка, откроется в новой вкладке)Источник(внешняя ссылка, откроется в новой вкладке)

Дополнительно применяются:

graceful shutdown через IPC;
watchdog/heartbeat;
service manager;
PID/lock file;
аварийная очистка при следующем запуске;
явный TerminateJobObject для дерева процессов.Источник(внешняя ссылка, откроется в новой вкладке)

Никаких данных, подтверждающих «99,9%», статья не содержит.

Причём sidecar-архитектура имеет свои плюсы:

падение core не валит GUI;
core можно перезапустить отдельно;
проще ограничить права;
легче собирать логи и crash dump;
появляется лицензионная граница;
обновление core не требует перелинковки всего приложения.

In-process тоже имеет преимущества: меньше IPC, проще lifecycle, потенциально меньше копирований. Но «прямой вызов всегда лучше, минусов нет» — это не инженерная аргументация. Это фраза человека, который только что выбрал архитектуру и теперь объясняет, почему альтернативы якобы не существует.

7. Breaking changes: здесь у Acelate есть основание, но снова отказали тормоза

sing-box действительно агрессивно меняет конфигурационный API:

DNS server format;
DNS rules;
sniffing;
special outbounds;
WireGuard;
TUN stack;
route actions.

После 1.0 строгий SemVer требует major bump для несовместимых изменений.Источник(внешняя ссылка, откроется в новой вкладке) В этом смысле претензия справедлива: 1.12 → 1.14 не должна ощущаться как миграция между разными поколениями продукта.

Но изменения не происходят «молча в каждом патче».

Официальные страницы migration, deprecated features и changelog показывают предупреждения и окна совместимости. Например:

legacy DNS объявлен deprecated в 1.12 и удалён в 1.14;
новый TUN stack появился в 1.15;
опция stack должна быть удалена только в 1.17.Источник(внешняя ссылка, откроется в новой вкладке)Источник(внешняя ссылка, откроется в новой вкладке)Источник(внешняя ссылка, откроется в новой вкладке)

Правильная формулировка:

sing-box быстро эволюционирует, не соблюдает ожидаемую строгость SemVer и перекладывает заметную стоимость миграций на клиентов и генераторы конфигов.

Неправильная:

в случайном patch-релизе автор молча переписывает весь DNS, и каждый апдейт — русская рулетка.

И да: автоматически скачивать «самый свежий core» прямо в production — плохая идея независимо от логотипа. Версия должна быть pinned, конфиги — versioned, обновление — проходить integration tests.

Xray тоже способен ломать окружающую экосистему. Собственно, весь инцидент REALITY начался именно с серверного изменения Xray, введённого без заранее согласованного межъядерного процесса совместимости.

8. «Синтетический перфекционизм» без единого нормального benchmark

Статья много говорит о наносекундах, сетевых штормах, LTE, MTU, метро и реальной жизни.

Чего в ней нет:

test harness;
одинакового железа;
версий Go;
размера буферов;
CPU/RAM profiles;
throughput по TCP и UDP;
p50/p95/p99 latency;
packet loss 0/1/3/5%;
roaming между интерфейсами;
долгого soak test;
crash rate;
сравнения старого sing-tun, нового стека 1.15, Xray+tun2socks и beam-tun.

Ноль таблиц. Ноль сырых результатов. Зато «сыпется при сетевых штормах».

Отдельные issues с падениями существуют у любого активно используемого сетевого проекта. Например, crash sing-box 1.11.4 в HTTPUpgrade действительно зарегистрирован.Источник(внешняя ссылка, откроется в новой вкладке) Есть и issue о stall под connection churn.Источник(внешняя ссылка, откроется в новой вкладке)

Но issue — это повод написать regression test, а не лицензия объявить всю архитектуру «синтетической».

Тем более статья сравнивает старые проблемы с sing-tun с переходным 1.15, где появился собственный TCP/IP stack. Upstream заявляет улучшения peak performance, energy efficiency и memory usage.Источник(внешняя ссылка, откроется в новой вкладке) Эти заявления тоже нужно независимо измерять — но Acelate не измеряет ни их, ни собственный beam-tun.

9. IPv6 и Teredo: предложение есть, доказательства забыли

Фраза про то, что разработчик «засунул IPv6-over-IPv4 и сломал Teredo», не сопровождается:

номером issue;
ссылкой на commit;
версией;
конфигом;
pcap;
способом воспроизведения.

Найденный публичный issue об IPv6 TUN в sing-box 1.13.12 завершился тем, что автор включил auto_redirect, после чего IPv6 пошёл через туннель и утечка исчезла.Источник(внешняя ссылка, откроется в новой вкладке)

А Teredo вообще по определению переносит IPv6 через UDP/IPv4/NAT.Источник(внешняя ссылка, откроется в новой вкладке)

Поэтому сам факт наличия IPv6-over-IPv4 не доказывает ни баг, ни архитектурное безумие.

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

10. Что статья на самом деле доказывает про BEAM

Не то, что Xray универсально лучше sing-box.

Она доказывает следующее:

BEAM хочет оставаться закрытым.
BEAM хочет вызывать core в своём процессе.
GPL мешает такой комбинации.
Xray под MPL для неё удобнее.
XHTTP уже есть в Xray upstream.
Разработчики BEAM не хотят постоянно сопровождать fork sing-box.

Это честное продуктовое решение.

Но затем начинаются попытки превратить удобство конкретной proprietary-модели в универсальный технический закон.

Ирония напоследок

В день публикации статьи официальный сайт BEAM всё ещё говорит:

«BEAM — бесплатный прокси-клиент на базе sing-box»;
«BEAM работает на базе sing-box».Источник(внешняя ссылка, откроется в новой вкладке)

То есть статья уже объясняет, почему sing-box настолько ужасен, что от него пришлось срочно уйти, а продуктовая страница всё ещё продаёт sing-box как преимущество.

Очень предсказуемый production-процесс. Никаких breaking changes. Всё по ценностям.

11. Xray против sing-box без фан-клубов

Где Xray объективно удобнее

MPL 2.0 проще для закрытого in-process приложения.
XHTTP и новые технологии XTLS появляются здесь первыми.
Высокая совместимость с популярными серверными панелями.
Сильная экосистема VLESS/REALITY/Vision.
Для Xray-сервера Xray-клиент обычно получает изменения протокола первым.

Где sing-box объективно силён

широкий набор протоколов и endpoints;
зрелая платформенная интеграция TUN;
Android, Apple, Linux, Windows;
Hysteria/Hysteria2/TUIC/AnyTLS/WireGuard/OpenVPN/OpenConnect/Tailscale;
единая архитектура routing/DNS/service;
возможность расширения без переделки всего ядра;
новый собственный TCP/IP stack в ветке 1.15.

Где у sing-box реальные проблемы

GPL неудобна закрытым in-process продуктам;
слишком агрессивные миграции конфигов;
спорная коммуникация мейнтейнера;
отсутствие upstream XHTTP;
зависимость совместимости REALITY от синхронизации с Xray/uTLS;
небольшая bus factor вокруг ключевых архитектурных решений.

Вот это уже похоже на техническое сравнение. Без необходимости выдумывать «99,9%» и «месяцы» там, где календарь показывает десять дней.

Итог

Acelate имел полное право перейти на Xray.

У команды были рациональные причины:

лицензия;
in-process интеграция;
XHTTP;
совместимость с Xray-серверами;
нежелание сопровождать fork.

Но статья пытается продать это решение как моральную и техническую капитуляцию sing-box. Для этого реальный инцидент REALITY раздувается до «миллионов», десять дней превращаются в «месяцы», документированный helper tool объявляется запрещённым macOS, баг process supervision — фундаментальным свойством отдельного бинарника, а отсутствие собственных benchmark — доказательством чужого «синтетического перфекционизма».

Самое смешное, что технический контрпример уже существует:

REALITY-совместимость с Xray 26.9.9 исправляется локально;
клиентский XHTTP портируется в архитектуру sing-box;
поверх того же ядра реализуется mlkem768x25519plus;
всё это работает на базе нового стека sing-box 1.15, который статья успела похоронить раньше, чем нормально сравнить.

Поэтому честный заголовок оригинала должен был звучать так:

«Почему MPL и готовый XHTTP удобнее для закрытой архитектуры BEAM»

Но это было бы слишком спокойно, точно и профессионально.

А так получился #НетСингбоксу.

Мы же останемся с менее эффектным, зато проверяемым выводом:

Xray не “лучше вообще”. Он лучше подходит текущей бизнес-модели BEAM. А большинство остальных обвинений статья либо преувеличивает, либо не доказывает вовсе.

Основные источники