Путь этой экосистемы начался с десктопа - как ядро для лаунчера, которому нужно было не "просто поднять туннель", а уметь жить в конфигурациях, где одновременно работают десятки соединений, включаются сложные правила маршрутизации, каскады detour и диагностика на уровне, пригодном для разборов "почему именно сейчас всё сломалось". Если вы уже запускали мои L×Box или Sing-box Launcher, то примерно представляете идею: это VPN‑клиенты, заточенные под экстремальные сценарии и гибкую связку нескольких туннелей. Само ядро при этом тоже открытое и со временем оказалось среди самых заметных форков sing-box - и не за счёт косметики, а благодаря новым протоколам, адаптациям и дисциплине разработки.
Летом история резко ускорилась: с июня в репозитории набежало свыше 1700 коммитов, появилось два десятка с лишним стабильных тегов ветки 1.14 и под семь десятков спеκов и описаний. Траектория стала очевидной: движок, выросший из десктопного мира, пришлось "пересобрать" под Android, а затем почти без паузы перенести те же подходы в роутеры - потому что многие улучшения на самом деле универсальны и одинаково важны и для телефона, и для домашнего шлюза.
MASQUE: CONNECT-IP как полноценный туннель
Одним из самых заметных расширений стал MASQUE, которого нет в апстримном sing-box. В ядре появился клиентский outbound `masque`: CONNECT-IP по RFC 9484 - именно CONNECT-IP, а не CONNECT-UDP, который часто ошибочно подразумевают под тем же названием. Разница принципиальная: прокидываются целые IP‑пакеты, поверх потока поднимается userspace‑сетевой стек уровня WireGuard‑эндпоинта, а приложения получают полноценный туннель, а не "шланг" для датаграмм.
Практический профиль, ради которого чаще всего всё и затевается, - Cloudflare WARP. Но реализация не замкнута на один сервис: протокольная часть сделана как общий CONNECT-IP, а WARP - всего лишь удобный пресет. При этом регистрацию устройства в WARP сознательно вынесли из ядра: ей место на стороне клиентов, где можно делать UX‑шаги, хранить токены и не смешивать "сетевую механику" с логикой онбординга.
AmneziaWG 2.0: когда спецификации нет, приходится доказывать корректность иначе
В первой итерации AmneziaWG 2.0 выглядел как "фича форка", но за лето доведён до уровня эталонной клиентской реализации. Здесь есть неприятная методологическая ловушка: у AmneziaWG нет нормальной спецификации - ни RFC, ни whitepaper, протокол задан живыми реализациями. Поэтому проверка "на глаз" не работает: вместо уверенности "кажется, мы всё учли" понадобилась формальная сверка сразу по трём независимым линиям - конфиг‑парсеру `amneziawg-tools`, netlink‑контракту ядерного модуля и нашему форку.
Результат - полный паритет по 16 из 16 параметров обфускации: junk‑пакеты Jc/Jmin/Jmax, паддинги S1-S4, магические заголовки H1-H4 (включая диапазонные), сигнатурные пакеты I1-I5 с их CPS‑мини‑языком - восемь тегов один в один, причём проверенные не "грепом по исходникам", а живым прогоном IpcSet → IpcGet, где случайно "промахнуться" заметно сложнее. Заодно закрыт болезненный кейс AWG поверх WireGuard: вложенные туннели заработали, включая AWG-over-AWG через detour. Для этого пришлось разрешить фрагментацию внешней UDP‑датаграммы - ту самую, которую ядро по умолчанию блокирует.
Десктоп терпит, Android - нет: как телефон заставляет переписывать архитектуру
На компьютере многое сходит с рук: лишний таймер, лишний сокет, пара "вечно живых" эндпоинтов. Телефон этого не прощает вообще. Попробуйте подержать на Android пару десятков WireGuard/AWG‑туннелей - и очень быстро получите не сеть, а грелку. Поэтому пришлось строить полноценную машину состояний: простаивающие эндпоинты усыпляются вплоть до полного удаления userspace‑устройства, просыпаются лениво при первом dial, health-check'и научились пропускать циклы, если через узел только что прошёл реальный трафик. На боевой конфигурации это дало минус 31% RSS и примерно минус 80% нагрузки на ядро.
Самая "неочевидная" часть - даже не усыпление как таковое, а корректный ответ на вопрос: кого именно можно усыпить. Конфиг sing-box - это ориентированный граф "назад": каждый узел знает, через кого он дайлит (detour), но не знает, кто дайлит через него. Плюс граф динамический: `selector` меняется руками, `urltest` - автоматически. Всё это пришлось аккуратно увязать, чтобы остановы происходили быстро и массово: сокеты закрываются пачкой, эндпоинты останавливаются конкурентно, а вся процедура укладывается в доли секунды.
Сон, пробуждение и неприятные 127 секунд тишины
Отдельный класс боли - doze. Телефон проснулся, пользователь первым делом запускает пинг или открывает страницу - и именно здесь раньше появлялось окно ошибок вплоть до полутора минут. Сейчас оно схлопнулось до одного RTT рукопожатия: фактически "проснулся - и сразу в деле".
Самый красивый унаследованный баг выглядел почти издевательством: TCP‑дайлы через userspace‑netstack были единственным классом путей вообще без таймаута. Границей оставался лишь SYN‑бэкофф gVisor: 1+2+4+8+16+32+64 - больше двух минут до ошибки, а для доменных назначений ещё и умножение на число адресов. Исправление сделано без добавления "хрупких" таймеров: все проверки считаются по дельтам меток времени, потому что на Android таймеры переживают сон непредсказуемо и могут "стрельнуть" не там и не тогда.
---
Отдельно стоит сказать о том, как это воспринимается со стороны пользователя. Когда люди ищут, где *VPN для Android скачать*, их обычно интересует кнопка "включить" и быстрый результат. Но как только появляется несколько профилей, разные маршруты для приложений, резервирование и диагностика - внезапно важнее становится не один удачный коннект, а предсказуемое поведение при смене сетей, уходе в сон, деградации канала и переборе узлов.
Десктопная аудитория мыслит иначе: там чаще спрашивают, где *VPN клиент для Windows скачать*, чтобы быстро проверить провайдера, протокол и скорость. И вот здесь как раз проявляется преимущество общего ядра: одни и те же принципы маршрутизации и диагностики работают на Windows, на Android и затем переезжают в роутер без переписывания "с нуля". Если вам нужно вникнуть в детали развития этой ветки и того, как из десктопного движка получился универсальный набор для разных платформ, это удобно прослеживается в материале, встроенном прямо в рабочий контекст: sing-box VPN клиент скачать.
Дальше логичный шаг - домашняя сеть. Пока на телефоне и ПК можно "пощёлкать" профили, в квартире обычно хочется один раз решить вопрос для всех устройств: телевизора, приставки, умных колонок, гостевых телефонов. Поэтому запрос *настроить VPN на роутере* всплывает неизбежно - и здесь снова выигрывает подход с единым ядром и воспроизводимыми сборками, где одинаковые адаптации (энергетика на мобильном, стабильность и наблюдаемость на шлюзе) усиливают друг друга. В этом же ключе хорошо читается развитие роутерного направления: настроить VPN на роутере.
Ещё один практический слой - эксплуатация "как сервис". Когда пользователь решает купить VPN подписку, он на самом деле платит не только за канал, но и за спокойствие: чтобы протоколы обновлялись, клиенты не отваливались после апдейта Android, а роутер не требовал шаманства при каждой смене провайдера. Поэтому в разработке ядра важны не только новые outbound'ы вроде MASQUE, но и "скучная" инженерия: регулярный ребейз, минимальное касание апстрима, воспроизводимые сборки и диагностика, позволяющая чинить проблемы по логам, а не гаданием.
И наконец, про "что дальше". Самое интересное в этой истории - эффект домино: как только ядро учится корректно переживать сон на Android, выигрывают и роутеры (меньше лишних проверок и зависаний), и десктоп (меньше латентных зависаний при нестабильных сетях). А когда появляются новые протоколы уровня CONNECT-IP, становится проще строить профили под разные инфраструктуры - от корпоративных прокси до публичных сетей, где важна не только скорость, но и устойчивость к фильтрации. Именно поэтому движение "от десктопа к Android и дальше в роутеры" - не маркетинговая траектория, а почти неизбежный маршрут для ядра, которое пытается быть универсальным и при этом не сгнить по дороге.