Karing 1.2.24 стал стабильным: что за месяц беты изменилось в разборе подписок

Что именно вышло и когда

Karing — это графическая оболочка над ядром sing-box, написанная на Flutter; в описании репозитория проект называет себя утилитой, поддерживающей правила маршрутизации clash и sing-box. Приложение собирается под Android, Windows, macOS, Linux, iOS и tvOS, то есть закрывает практически все платформы разом, и именно поэтому им часто пользуются те, кому нужен один и тот же профиль на телефоне и на компьютере.

Сборка 1.2.24.2709 опубликована 1 сентября 2026 года в 05:38 UTC и помечена в репозитории как последняя стабильная. Файлы сборок — пакеты для Android, образы для macOS, установщики для Windows и пакеты для Linux — были загружены в тот же день, с 05:05 до 06:55 UTC. Это важная деталь методики: дата карточки релиза и дата появления самих файлов совпадают не всегда, и мы датируем событие по файлам.

Перед этим ветка 1.2.24 выходила девять раз подряд только в статусе пре-релиза — с 12 по 31 августа. Предыдущая стабильная сборка, 1.2.23.2606, датируется 5 августа. То есть ветка провела в бете почти месяц, и её перевод в стабильные — это не смена номера, а решение разработчика о том, что накопленное можно отдавать обычным пользователям.

Главное содержимое ветки лежит в бетах, а не в финальной сборке

Список изменений сборки 2709 состоит из трёх пунктов: удалён ошибочный перехват DNS на порту 853, исправлено уведомление о поставщике VPN-сервиса, которое сбрасывалось после прочтения, и в образ для macOS добавлен скрипт запуска, который нужно выполнить вручную после обновления — иначе на части систем приложение может не стартовать. Как содержание месячной работы это не читается, и читать так не следует.

Существенное распределено по августовским бетам. Сборка 2700 добавила поддержку шифрования VLESS при конвертации, 2701 — поддержку конвертации Trojan через XHTTP и исправление, при котором часть полей мультиплексирования не переносилась в конфигурацию. Сборка 2704 добавила совместимость с вложенной формой параметра extra у VLESS и Trojan, а 2705 закрыла потерю поля mode при конвертации XHTTP.

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

Почему потерянное поле mode ломало соединение через CDN

XHTTP — это транспорт Xray, задуманный так, чтобы соединение шло через обычные сети доставки контента и не отличалось от постороннего трафика. Автор транспорта формулирует замысел прямо: смысл в том, чтобы поднять для цензора цену блокировки, поскольку сети доставки контента обслуживают слишком много обычных сайтов, чтобы блокировать их целиком. Отсюда и набор приёмов внутри: случайная набивка заголовков запроса и ответа длиной от 100 до 1000 байт, маскировка под потоковые события и заголовки gRPC.

Поле mode выбирает, каким именно способом транспорт отправляет данные. По умолчанию в конфигурации стоит значение auto, а документация отдельным пунктом советует: если пройти через стороннюю сеть доставки контента или реверс-прокси не удаётся, следует выбрать режим packet-up как обладающий наибольшей совместимостью. То есть mode — это не косметика, а именно тот переключатель, которым администратор решает задачу прохождения через конкретного посредника.

Сложив одно с другим, получаем механику сбоя: пока конвертер терял поле mode, явно выбранный на стороне сервера режим до ядра не доезжал, и клиент работал в режиме по умолчанию. У пользователя это выглядело как подписка, которая в одном приложении работает, а в Karing — нет. По той же логике важен и параметр extra: он существует ровно для того, чтобы передать в ссылке все детали конфигурации, и его неполный разбор давал тот же класс расхождения между сервером и клиентом.

Шифрование VLESS и оговорки, о которых стоит знать

Второй механизм, разбор которого ветка дотянула, — шифрование VLESS. По документации Xray метод рукопожатия здесь пока единственный и построен на постквантовом обмене ключами; отдельным блоком настройки задаётся внешний вид трафика — исходный формат, исходный формат с обфускацией части открытого ключа или полностью случайные данные, наподобие того, как выглядят VMess и Shadowsocks. Дальше идёт набивка: после установления соединения клиент отправляет мусорные данные, чтобы смазать характерные длины пакетов.

Практическое следствие описано в документации явно: обычно VLESS требует внешнего слоя транспортной безопасности, и обойтись без него разрешается лишь в нескольких случаях — в том числе если включено собственное шифрование VLESS. Иными словами, это не добавка к TLS, а механизм, который в некоторых схемах его заменяет, и клиент, не умеющий разобрать такую ссылку, просто не соберёт рабочую конфигурацию.

Отдельно — про удалённый в 2709 перехват порта 853. Это порт DNS поверх TLS, и клиент, судя по формулировке разработчика, забирал этот трафик себе ошибочно. Мы не нашли в опубликованной истории релизов момента, когда такое поведение появилось, поэтому не беремся утверждать, с какой версии оно действовало. Стоит только развести две разные вещи: сбои шифрованного DNS бывают и от сетевых ограничений, и от самого приложения на устройстве, и это разные причины с одинаковым внешним проявлением.

И последнее, что полезно учитывать перед обновлением: стабильная ветка пока доехала не везде. В App Store на момент публикации значилась сборка 1.2.23.2607 от 12 августа — то есть версия предыдущей ветки. Пользователи магазина Apple получат 1.2.24 позже, после прохождения проверки, и это нормальный порядок вещей, а не признак проблемы.