🔍 Чем плох Happ: что подтвердилось в претензиях к VPN-клиенту

О чём заметка

Happ — самый популярный клиент для Xray-подписок, и к нему накопилось много претензий: от «бэкдора» до «закрытого кода». Здесь каждая из них сверена с первоисточниками: сайтом и документацией Happ, его GitHub, разбором на Хабре и релизами за 2026 год. Общий разбор подписок и HWID — в hwid-client-lock, как подключиться к VLESS через Happ — в clients-and-routing.

TL;DR

• Скорость и надёжность самого туннеля от клиента не зависят: во всех таких приложениях работает ядро Xray-core, и по скорости Happ не лучше и не хуже других. Различаются версия ядра, обвязка вокруг него (системный туннель, DNS, маршруты) и то, что клиент делает сверх ядра. Именно там и лежат претензии.
• Исходный код приложения закрыт. В репозиториях Happ на GitHub лежат README и файлы релизов, лицензии нет. Независимо проверить, что приложение делает с трафиком и конфигурацией, нельзя.
• Главная страница Happ говорит «не собирает никаких данных», а его же политика конфиденциальности описывает HWID, модель устройства, push-токен и отчёты Sentry. Идентификатор устройства уходит на сервер подписки по умолчанию.
• Открытый API ядра существовал, но его убрали в тот же день, когда об этом написали. Разбор от 7 апреля 2026 утверждал, что любое приложение на устройстве может выгрузить из открытого API ядра ключи и IP сервера. Прямая проверка кода подтверждает: служба HandlerService есть в версии Happ для Android 3.16.1 от 1 апреля 2026 года и пропадает уже в версии 3.16.2 от 7 апреля — в день публикации разбора. Громкое «исправить это уже невозможно» не подтвердилось.
• Локальный SOCKS5-прокси без пароля — подтверждено напрямую, в том числе на живом подключении. На чистой установке Happ 4.7.1 для Android режим авторизации для порта 10808 стоит «Disable». На физическом Android-телефоне отдельный процесс (оболочка adb shell, не Happ) без пароля прошёл SOCKS5-рукопожатие, открыл соединение через прокси и получил выходной адрес VPN-сервера.
• В манифесте и коде есть дополнительные риски. Заводской порт без пароля, ссылки happ://…_without_ui, которые запускают, останавливают и переключают туннель без подтверждения и без проверки вызывающего приложения, режим insecure без проверки сертификата, источники обновлений на стороннем pastebin и скрытая ветка сбора профиля устройства. Где что проверено на устройстве, а где только по коду, показано в разделе 9.
• Что видят российские приложения. Исследование RKS Global о поиске VPN в 30 российских приложениях сопоставлено с тем, что оставляет Happ: виден интерфейс tun0 с постоянным адресом 26.26.26.1/30, объявленная служба VPN, а MTU 1500 не попадает под эвристику «меньше 1400». Подробности и границы проверки — в разделе 10.
• Подписка управляет клиентом. Продавец может запретить пользователю смотреть настройки серверов, принудительно отправлять HWID, подменить адрес подписки и профиль маршрутизации. Шифрованные ссылки happ://crypt… скрывают сервер от пользователя, а не от всех: публичные расшифровщики уже существуют.
• Новые версии Xray-core доходят до Happ за срок от 6 до 34 дней, а в публичном трекере Happ на 18 октября 2026 года лежат восемь открытых обращений без ответа разработчиков.
• Версии про «бэкдор за деньги» доказательств нет: автор разбора сам называет это слухом.

Как проверялись претензии

Старые заметки vault, где Happ назван «особо опасным, удалить немедленно», опирались на пересказ реверс-инжиниринга с форума. Для этой статьи опорные источники открыты заново 18 октября 2026 года: страницы и документация happ.su, GitHub-организация Happ-proxy, разбор runetfreedom на Хабре, публикации «Кода Дурова» и SecurityLab, релизы Happ и Xray-core. Каждое утверждение ниже помечено так, чтобы различать факт (виден в документе или коде), заявление (чьё-то утверждение) и версию (предположение без доказательств). Чего проверить не удалось, собрано в конце.

1. Исходный код закрыт

В GitHub-организации Happ-proxy создано двенадцать репозиториев, но у приложений они устроены одинаково: в happ-android и happ-desktop лежат README, файл release и сами сборки на странице релизов. Лицензии у них нет. Исходники самих приложений отсутствуют; рядом лежат только копии чужих открытых проектов (Xray-core, 3x-ui, Marzban). Эксперт в блоге SecurityLab от 1 августа 2026 пишет то же: публичные репозитории содержат README, релизы и метаданные обновлений, а независимого аудита оболочки автор не нашёл. Ядро Xray при этом открыто, закрыта именно оболочка.

Проще говоря: ядро, которое шифрует и пересылает трафик, можно прочитать, а программа вокруг него, которая решает, какие настройки скормить ядру, куда ходить за подпиской и что отправлять разработчикам, остаётся чёрным ящиком. Закрытый код не означает вредоносный, но лишает читателя главного способа проверки: заглянуть и убедиться самому. Любое заявление Happ о своей безопасности приходится принимать на веру.

Для сравнения: у популярных клиентов с открытым кодом, например v2rayN, v2rayNG или Hiddify (см. 07-clients), исправление или ошибку можно найти в самом коде.

2. Данные: на сайте одно, в политике другое

На главной странице документации сказано, что Happ «гарантирует конфиденциальность вашей сетевой активности и не собирает никаких данных», а вся информация остаётся на устройстве. Политика конфиденциальности того же сайта описывает больше:

• приложение собирает и передаёт отчёты о сбоях и диагностику через сервис Sentry, в том числе сведения о времени на экранах;
• хранит push-токен для уведомлений (на Android вместе с аппаратным идентификатором);
• по умолчанию отправляет уникальный идентификатор устройства (HWID) и модель телефона в HTTP-заголовках при каждом обращении к адресу подписки. Отправку можно отключить в настройках.

Что такое HWID, подробно разобрано в hwid-client-lock. Здесь важен вывод: данные об устройстве уходят на сервер подписки, которым управляет не Happ, а продавец доступа. Идентификатор нужен для подсчёта устройств, то есть работает как постоянная метка. Политика называет его «кастомным идентификатором пользователя» и оговаривает, что персонально идентифицируемая информация не собирается.

Есть и вторая линия обмена, о которой в политике нет ни слова. Если продавец подключил функцию Provider ID, клиент раз в сутки отправляет запрос на сервис проверки с идентификатором провайдера, хешем домена подписки, HWID, названием и версией операционной системы. Документация объясняет это подсчётом активных устройств и статистикой; результат тот же: устойчивая связь между конкретным устройством, подпиской и сервисом Happ.

Кроме того, продавец может заставить клиента отправлять HWID без права отказаться: в документации по управлению приложением есть параметр subscription-always-hwid-enable.

Разбор кода самого приложения (APK версии 4.7.1 для Android, декомпилирован 18 октября 2026) показывает ещё один канал, о котором политика конфиденциальности не упоминает вовсе. Помимо адреса подписки, Happ обращается к собственным доменам ntp2-sync.com и time-ntp.com — в запросах install, remotepush и report туда уходят HWID, версия и модель устройства, подписанные токеном; запрос report дополнительно прикладывает файл диагностики. Отдельный адрес check.happ.su отдаёт служебный файл настроек, который дублируется и внутри самого приложения. Названия доменов (служба синхронизации времени) не объясняют, зачем им нужен HWID устройства; документация этот механизм не описывает, поэтому назначение каждого запроса установлено только по тексту кода, а не по официальному объяснению.

HWID привязан к приложению, а не к устройству

Пользователь 3x-ui описывал в профильном чате 14 октября 2026 года (пересказ, первоисточник не открыт): одно физическое устройство с Happ и INCY занимает в панели два слота лимита, потому что у приложений разные HWID. Это согласуется с тем, что идентификатор приложение формирует себе само.

3. Открытый API ядра: что было и что осталось

Самая громкая претензия касается устройства API ядра Xray. Xray-core умеет поднимать внутри себя интерфейс управления по протоколу gRPC (программный интерфейс для вызова функций ядра с локального адреса). Для статистики трафика достаточно служб статистики и журналов. Служба HandlerService умеет большее: добавлять и удалять входящие и исходящие подключения и, по описанию автора, выгружать полные настройки, включая ключи, адрес сервера и имя сайта-маскировки (SNI).

7 апреля 2026 года исследователь runetfreedom опубликовал на Хабре разбор: Happ включает такой API без авторизации вместе с HandlerService, а любое приложение на устройстве может к нему подключиться. Автор рассылал разработчикам клиентов сообщения о проблеме с 10 марта 2026 года; по его словам, Happ ответил, что API нужен для сбора статистики подключений, и автор считает это неубедительным, раз для статистики достаточно службы журналов. В разборе автор называет Happ «особо опасным», но прямо оговаривает: подробности эксплуатации он раскрывать не будет, проверял обычные подписки, а как ведут себя JSON-подписки, не знает. Это заявление автора, а не воспроизведённый другими результат; код, который выгружает конфигурацию именно из Happ, в открытом виде не опубликован.

Дальше в тексте на Хабре есть два сильных утверждения, которые нужно разделить. Первое — что причина включения API неизвестна, а «злые языки» говорят о бэкдоре за деньги; сам автор пишет, что не знает, правда ли это. Доказательств нет, поэтому версия остаётся слухом. Второе — что исправить это «уже невозможно», потому что клиенты удалены из российского App Store и не смогут выпустить обновление. Оно не подтвердилось: «Код Дурова» 11 апреля 2026 года сообщил, что Happ удалил HandlerService из конфигураций, а SecurityLab 9 мая 2026 пишет, что разработчики поначалу отказывались признавать проблему, но потом выпустили патч. Версия приложения, в которой это произошло, в самих источниках не названа, а в списках изменений Happ записи об этом нет. Прямое сравнение APK заполняет этот пробел: в Happ для Android 3.16.1 от 1 апреля 2026 строка HandlerService в коде ещё есть, а в 3.16.2 от 7 апреля 2026 её уже нет — то есть службу убрали в тот же день, когда вышел разбор на Хабре, между этими двумя сборками.

Остаётся вторая претензия: локальный SOCKS5-прокси без пароля. Через него любое приложение на устройстве может отправить запрос и по ответу узнать реальный адрес выхода в сеть. Это проблема не Happ, а почти всех клиентов на Xray и sing-box; независимо воспроизведённая демонстрация и разбор защиты — в VLESS-SOCKS5-vulnerability и Localhost-tracking-Meta-Yandex-SOCKS5. У Happ есть параметры socks-auth-mode и http-auth-mode, которыми продавец подписки может управлять удалённо, но что получает рядовой пользователь без вмешательства продавца, проверено напрямую: на чистой установке Happ 4.7.1 для Android экран «Inbounds» показывает Authorization mode: Disable для порта 10808 и подпись «Authorization is not applied. Therefore, no changes are made to the inbounds» — то есть локальный SOCKS5 без пароля работает по умолчанию, пока пользователь не включит авторизацию сам.

Это проверено и на живом подключении. На физическом Android-телефоне (Android 17, архитектура arm64) Happ 4.7.1 подключили к собственному серверу автора, после чего порт 127.0.0.1:10808 проверили из оболочки adb shell, то есть из процесса, который не принадлежит Happ. Прокси принял SOCKS5-рукопожатие без пароля (ответ 05 00), затем команду CONNECT к внешнему сайту (ответ 05 00 00 01), и запрос к сервису, который возвращает адрес клиента, дал выходной адрес VPN-сервера: он не совпал с домашним адресом проверяющего. Реальный адрес сервера и ключ в статью не включены сознательно. Значит, любое приложение на устройстве, которому разрешён доступ к локальной сети (на Android это обычное разрешение интернета), может узнать, куда выходит трафик, и сопоставить пользователя с конкретным сервером.

Старые заметки vault об этом устарели

Заметки VLESS-SOCKS5-vulnerability, Localhost-tracking-Meta-Yandex-SOCKS5 и VLESS-localhost-protection-guide называют Happ «особо опасным» из-за HandlerService и советуют блокировать его по User-Agent. По сообщениям от апреля 2026 эта служба убрана; рекомендация блокировать клиент целиком держалась на утверждении, что исправление невозможно.

Локальный SOCKS5 без пароля: что это значит на практике

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

Что такое локальный порт. Клиент на ядре Xray запускает у себя на устройстве маленький сервер, который слушает адрес 127.0.0.1 (так устройство обращается само к себе) и порт 10808. Это входная точка (на языке Xray — inbound), в которую можно отправить запрос по протоколу SOCKS5: «открой мне соединение с таким-то сайтом». Клиент передаст запрос на VPN-сервер, а сервер выйдет в интернет. Протокол допускает проверку пароля (RFC 1929), но она необязательная: если пароль не включён, прокси обслуживает любого, кто к нему обратился.

Проще говоря: на телефоне работает почтовое окошко, которое отправляет чужие письма через ваш VPN. Окошко находится внутри телефона, и снаружи, из сети, к нему не подойти. Но внутри телефона подойти может любая программа, и спрашивать у неё ничего не будут. Для обращения к 127.0.0.1 Android не требует отдельного разрешения сверх обычного доступа в интернет, которое есть у большинства приложений.

Пример 1: проверка за три шага. Так выглядит проверка, которую сделали на физическом телефоне. Адреса заменены на документационные заглушки (203.0.113.x зарезервирован под примеры), реальный адрес сервера в статью не включён.

1. Узнать, слушает ли кто-то порт: adb shell ss -ltn. В списке есть строка 127.0.0.1:10808 — порт открыт.
2. Проверить, требует ли он пароль. Посторонний процесс отправляет первые три байта SOCKS5: версия 5, один метод, метод «без авторизации» (05 01 00). Ответ 05 00 означает «согласен, пароль не нужен»; ответ 05 ff означал бы «такой метод не принимаю». Happ ответил 05 00.
3. Попросить прокси открыть соединение с сервисом, который возвращает адрес клиента (icanhazip.com, порт 80), и отправить обычный HTTP-запрос. Ответ — один адрес вида 203.0.113.45. Это не адрес телефона, а адрес, с которого трафик выходит в интернет через VPN, то есть адрес VPN-сервера.

То же самое делает одна команда на любом компьютере, где есть доступ к такому порту: curl --socks5 127.0.0.1:10808 http://icanhazip.com. Никакого взлома здесь нет, это обычное штатное использование прокси; единственное отличие в том, что пользоваться им может не тот, кому он предназначался.

Пример 2: как это выглядит для обычного приложения. Допустим, в приложении погоды или игре стоит рекламная библиотека. Ей разрешён интернет, больше ничего не нужно. Она перебирает локальные порты (полный перебор 65 535 портов на loopback занимает секунды, как показано в VLESS-SOCKS5-vulnerability), на каждом открытом отправляет три байта рукопожатия, а там, где получает 05 00, делает запрос через найденный прокси и отправляет полученный адрес на свой сервер. Теперь у владельца библиотеки есть три сведения: рекламный идентификатор устройства, адрес выхода VPN и сам факт, что на устройстве установлен VPN-клиент с открытым портом. Сам по себе принцип «локальный порт доступен любому процессу на устройстве» не теоретический: в Localhost-tracking-Meta-Yandex-SOCKS5 разобрано исследование USENIX Security 26 о том, как приложения Meta и Яндекса принимали на localhost данные от сайтов для отслеживания. Механизм там другой, но опора та же.

Пример 3: что делают с адресом выхода. Адрес сервера нужен тому, кто хочет его заблокировать, выяснить, у кого он арендован, или объединить всех его пользователей в одну группу. Если в одном и том же сервере сидят сотни людей по подписке одного продавца, то узнав адрес, можно заблокировать его для всех сразу. Для продавца подписок это потеря серверов и клиентов. Для пользователя — то, что он оказался связан с конкретным VPN-сервером, о котором не должен знать посторонний. Масштаб зависит от того, насколько приложение-сборщик распространено, и это стоит оговорить прямо: в этом разборе сам такой сбор у реальных приложений не наблюдался, показана только возможность.

Почему важно слово «по умолчанию». Защита у клиента есть: в настройках Happ есть переключатель «Authorization mode», и там можно задать логин и пароль. Но настройка помогает только тому, кто её нашёл. Большинство людей ставят клиент, вставляют ссылку на подписку, нажимают кнопку подключения и больше никогда не заходят на экран «Inbounds». Для них защита выключена на всё время, пока клиент стоит. Для сравнения, безопасная настройка по умолчанию выглядела бы иначе: при установке генерируется случайный пароль или порт, либо порт вовсе не открывается, пока пользователь сам не включит режим для сторонних программ. Если этого нет, ответственность за безопасность ложится на того, кто о проблеме не знает, и именно поэтому исследователи называют такие случаи уязвимостью конфигурации по умолчанию, а не ошибкой пользователя.

Что именно доказано, а что нет

Проверено на одном физическом телефоне (Android 17) и одной версии Happ (4.7.1): порт слушает, SOCKS5 без пароля принят, адрес выхода получен. Запрос отправлялся из оболочки adb shell, а не из обычного установленного приложения; у них разные уровни привилегий, хотя обращение к 127.0.0.1 в обоих случаях идёт через обычный сетевой стек. Опубликованный проект, который показывает такой доступ из установленного приложения, описан в Localhost-tracking-Meta-Yandex-SOCKS5; здесь его не запускали. Реальный сбор адресов сторонними приложениями тоже не проверялся.

Как проверить у себя. На Android с включённой отладкой по USB: adb shell ss -ltn покажет открытые локальные порты, а printf '\x05\x01\x00' | adb shell nc -w 3 127.0.0.1 10808 | od -An -tx1 — отвечает ли прокси без пароля (05 00) или требует авторизацию (05 ff). В самом клиенте нужно включить режим авторизации для локальных входов (в Happ — экран «Inbounds», параметр «Authorization mode»). Остальные меры, в том числе для администраторов серверов, перечислены в VLESS-localhost-protection-guide.

4. Подписка управляет клиентом

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

Параметр	Что делает
hide-settings	запрещает пользователю просматривать и редактировать настройки серверов, для уже добавленных и будущих подписок
subscription-always-hwid-enable	запрещает пользователю отключить отправку HWID
new-url, new-domain	меняют адрес подписки у всех пользователей
routing-enable и профиль маршрутизации	отключают пользовательскую маршрутизацию или подставляют готовую
socks-auth-mode, http-auth-mode	включают или отключают пароль на локальных прокси
announce, profile-title	показывают пользователю сообщение и название

Профиль маршрутизации можно передать и ссылкой happ://routing/onadd/…, которая по документации добавляет профиль и сразу его включает, перезаписывая профиль с тем же именем. Для подписок формата JSON есть режим с фиксированным профилем и заблокированным переключателем.

Для продавца это удобные рычаги: можно починить подписку, не прося пользователей что-то делать. Для пользователя это означает, что настройки, влияющие на его трафик, меняет не он. Решение о доверии принимается один раз: кому продан доступ, тому и принадлежит контроль над клиентом.

5. Шифрованные ссылки: защита от пользователя, а не от всех

У Happ есть шифрованные ссылки happ://crypt4/… и более новые happ://crypt5/…. Документация объясняет их цель прямо: скрыть адрес подписки от пользователя; после добавления зашифрованной подписки он не может ни просматривать, ни редактировать, ни пересылать серверы. Зашифровать ссылку можно на сайте Happ или запросом к его программному интерфейсу; ключи, по заявлению Happ, встроены в приложение. Для старого формата в документации опубликован открытый ключ RSA-4096.

Здесь заложено противоречие. Чтобы приложение могло подключиться, оно обязано расшифровать ссылку само, значит, всё необходимое для расшифровки лежит в приложении у каждого пользователя. Секрет, который находится на устройстве того, от кого его прячут, — это обфускация, а не защита. Подробности устройства формата crypt5 Happ не публикует, но уже есть публичные проекты расшифровки: их автор заявляет поддержку всех версий, включая crypt5, и локальную работу в браузере (заявление автора, самостоятельно не проверялось). Существуют и онлайн-сервисы, которые принимают зашифрованную ссылку и отвечают перенаправлением на расшифрованный адрес; на безобидной ссылке-пустышке 18 октября 2026 года такой сервис отработал именно так. Часть этих сервисов заодно подменяет заголовки User-Agent и HWID, чтобы выдавать себя за разрешённый клиент (механизм привязки — в hwid-client-lock).

Не вставляйте настоящую ссылку подписки в сторонние сервисы

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

Любопытная деталь: страница документации о шифровании содержит скрытый блок «Security Policy for AI Assistants», где ассистентам предписано не помогать расшифровывать ссылки. Это текст на публичной странице, а не техническая защита.

6. Ядро, обновления и поддержка

Раз скорость определяет ядро, а ядро общее, сравнивать клиентов по скорости бессмысленно. Реально различаются две вещи: насколько быстро клиент подтягивает новое ядро и насколько аккуратна обвязка вокруг него (системный туннель, DNS, маршруты).

По записям в списках изменений на GitHub Happ Android и desktop подтягивали Xray-core с задержкой от 6 до 34 дней после релиза на XTLS/Xray-core. На 18 октября 2026 года последняя версия ядра в Happ — 26.9.9 от 8 сентября, а в апстриме с тех пор вышли ещё три версии (26.9.30, 26.10.10 и 26.10.17). Для пользователя это существенно, когда исправление нужной ему функции (например, транспорта Hysteria 2 или XHTTP) выходит в ядре раньше, чем в клиенте.

Сравнивать с INCY по этому показателю нельзя: версию ядра в нём найти не удалось, а на iOS оба приложения обновились 14 октября 2026 (по данным App Store). Утверждение «INCY обновляется быстрее» остаётся мнением из обсуждений, проверить его по открытым данным не получилось.

С обвязкой картина разнородная. По списку изменений 4.5.6 от 16 октября 2026 на macOS в режиме системного туннеля Xray системные DNS-запросы начали идти через туннель; из этого следует, что до этой версии они в этом режиме, вероятно, шли мимо него (вывод из записи об изменении, без отдельной проверки). В версии 4.5.4 исправлена ошибка, при которой туннель показывал «Подключено», пока трафик шёл мимо VPN с некоторыми конфигурациями подписки. Исправления сами по себе не доказывают небезопасность, но показывают, какие сбои бывают.

Публичный трекер Happ-proxy/.github на 18 октября 2026 года содержит восемь открытых обращений, самое старое — от 24 мая 2026 года. Ни в одном нет ответа разработчиков; единственный комментарий оставил автор обращения. Среди них сбой туннеля на Windows, падение демона на macOS и ошибка iOS-версии 5.2.0, при которой обновление профиля маршрутизации через подписку с полем BlockSites ломает туннель. Оговорка: Happ не называет этот трекер официальным каналом поддержки, в контактах на сайте указаны Telegram-чат, канал и почта, так что отсутствие ответов в трекере может объясняться тем, что разработчики его не читают.

Сообщения пользователей, которые не проверены: на iOS и macOS подключение TLS с flow=xtls-rprx-vision в Happ не работает, а в INCY та же подписка работает (проверено владельцем канала на одной подписке; в трекере Happ такого обращения на 18 октября 2026 нет). Hysteria на Wi-Fi у одних пользователей перестала работать полностью, у других срабатывает через раз; связь с CDN, по обсуждению, исключили. Выводить из этих отчётов вину именно Happ рано, но это правдоподобные кандидаты на обращения в поддержку.

7. Кто стоит за Happ

Разработчики не называют имён. В App Store продавцом указана компания Flyfrog LLC, а в Google Play издатель — Veltrixor LLC. Связь между этими компаниями нигде не объяснена, страны и учредителей в открытых источниках найти не удалось. GitHub-организация создана 19 января 2026 года и не верифицирована; домен happ.info зарегистрирован 6 февраля 2025 года (данные RDAP). Для скрытой команды это само по себе не обвинение, но с закрытым кодом создаёт ситуацию, где проверить нечего.

Историю с российским App Store стоит отметить без выводов о причинах. Автор разбора на Хабре в апреле 2026 пишет, что клиенты удалены из российского App Store. На сайте Happ сейчас предлагаются две версии для iOS: общая и «только для RU» под названием Happ Lite, а в разделе частых вопросов описана установка на iPhone. Причины удаления в первоисточниках Happ не названы.

8. Что видно при обычной установке

Все перечисленные параметры проверены не только по документации, но и на самом приложении: Happ 4.7.1 для Android установлен и запущен в изолированной тестовой среде 18 октября 2026 года, без подключения к какому-либо серверу.

Идентификатор устройства (HWID) виден прямо на главном экране приложения, ещё до добавления первого сервера — он уже сформирован и ждёт, когда начнётся обмен с подпиской. Подключение к серверу Android оформляет стандартным системным диалогом «Happ wants to set up a VPN connection that allows it to monitor network traffic» — это предупреждение самой системы, а не особенность Happ, оно одинаково для любого VPN-клиента.

В настройках по умолчанию выключены пункты «Allow connections from the LAN» и «Auto-start application» — здесь Happ, наоборот, консервативен. Но ключевая деталь — на экране «Inbounds»: режим авторизации для локального SOCKS5 стоит «Disable» заранее, до каких-либо действий пользователя.

9. Что видно в манифесте и конфигурации по умолчанию

Раздел собран только по статическому разбору APK Happ 4.7.1 для Android (манифест через aapt2, декомпилированный код, файлы внутри пакета). Поведение на устройстве для пунктов ниже, кроме явно оговорённого, не проверялось, а код приложения обфусцирован, поэтому отсутствие находки не доказывает отсутствие поведения.

Настройки по умолчанию зашиты в пакет. В пакете лежит заготовка конфигурации ядра (xray_config_with_tun.json). Локальный SOCKS-вход в ней описан на порту 10808 с параметром "auth": "noauth" и включённым UDP, а список правил маршрутизации пуст. Это объясняет то, что видно на экране «Inbounds»: отсутствие пароля не результат настройки пользователя, а заводское значение. То же значение показывает экран «Inbounds» на живом телефоне: режим авторизации «Отключить», HTTP-вход выключен. Пустые правила в заготовке не означают, что у пользователя весь трафик идёт одним путём: профиль маршрутизации может подменяться подпиской или настройками приложения, и это отдельно не разбиралось.

Порт нужен самому приложению. В режиме VPN трафик телефона попадает в виртуальный интерфейс, а отдельная библиотека hev-socks5-tunnel передаёт его на этот же локальный SOCKS-порт 127.0.0.1:10808, где его принимает ядро Xray. В коде формирования настроек этой библиотеки есть поля логина и пароля, которые заполняются, если в Happ включена авторизация. Значит, включение пароля на экране «Inbounds» не ломает режим VPN: мост туннеля получает те же данные. Это следует из кода (TProxyService) и на телефоне с включённой авторизацией не проверялось.

С точки зрения устройства это скорее слабое проектное решение, чем удобство. Правильнее передать системный адаптер ядру напрямую или хотя бы не открывать для моста сетевой порт, который виден всем приложениям. Мост через локальный SOCKS-порт встречается и у других клиентов на Xray и sing-box (общая схема описана в VLESS-SOCKS5-vulnerability), поэтому это проблема отрасли, а не одного Happ. Но решение от этого лучше не становится: порт остаётся доступным любому приложению, пока нет пароля. В Happ есть отдельный переключатель «Включить Xray TUN» (на проверенном телефоне выключен); однако и в заготовке конфигурации для этого режима SOCKS-вход на порту 10808 сохраняется рядом с адаптером, так что открытого порта он не убирает.

Что найдено	Что известно	Что не проверено
Разрешение QUERY_ALL_PACKAGES	Позволяет приложению видеть все установленные программы. В коде список используется для выбора приложений в режиме «по приложениям», для проверки оболочек производителей телефонов, связанных с энергосбережением, и для таблицы соответствия номера процесса и пакета	Уходит ли список установленных программ в сеть: в прочитанных местах кода передачи наружу не найдено
allowBackup=true и usesCleartextTraffic=true	Данные приложения могут попасть в резервную копию Android, а обычный HTTP без шифрования не запрещён	Что именно хранится в данных приложения и в каком виде
Экспортируемые точки входа	Главный экран принимает ссылки схемы happ:// (в манифесте перечислены add, routing, connect, disconnect, toggle, open, close, crypt и другие), а также файлы .json и .happ. Отдельный экран принимает ссылки с суффиксом _without_ui, то есть команды без интерфейса. В коде этого экрана на команды запуска, остановки и переключения туннеля нет ни запроса подтверждения, ни проверки того, какое приложение его вызвало, ни отдельного разрешения; он сразу выполняет действие и закрывается; при остановке показывается только короткое сообщение «Остановка служб», при запуске без выбранного сервера — подсказка добавить конфигурацию. Экран «Схемы URL-адресов» в настройках лишь перечисляет эти ссылки: переключателей в его коде нет, и на живом телефоне он выглядит как простой список (рисунок ниже)	Как это ведёт себя на устройстве (запуск ссылок в этой работе сознательно не проводился), а также как устроено подтверждение при добавлении сервера или профиля маршрутизации по ссылке happ://add и routing: этот код не разбирался
Три источника сведений об обновлении	Приложение опрашивает файл release в репозитории Happ-proxy на GitHub, его копию через jsDelivr и третий адрес на pastebin.com. На момент проверки запись на pastebin описывала версию 3.6.0, то есть устарела	Кто владеет записью на pastebin и как приложение выбирает между источниками. По правилам Android обновление должно быть подписано тем же ключом, что и установленная версия, и ставится только с подтверждения пользователя. Скачанный файл сохраняется как Happ_new.apk в папке приложения; отдельной проверки хеша в прочитанном коде не найдено
Ссылки добавления и маршрутизации	Обработчик ссылок главного экрана разбирает happ://add, crypt… (расшифровывает и загружает подписку) и routing. Для happ://routing/off в коде видно, что при разборе сразу сбрасывается настройка «правила маршрутизации включены» без запроса. Импорт из буфера обмена в интерфейсе оформлен пунктом меню («Вставить из буфера обмена», «Из буфера»), то есть запускается пользователем	Показывает ли приложение подтверждение перед добавлением подписки или профиля по ссылке: диалог «Добавление подписки» в ресурсах есть, но его роль в этом пути не установлена. Эффект отключения правил зависит от профиля пользователя; в заводской заготовке правил нет
Хранилище настроек и подписок	Данные (подписки, выбранный сервер, настройки) лежат в зашифрованном хранилище MMKV. Ключ шифрования генерируется случайно и защищён ключом из хранилища ключей Android (AES-GCM), то есть по резервной копии на другом устройстве данные в обычном случае не прочитать. Запасной путь, если ключа в хранилище нет, строит ключ из публичных свойств сборки (Build.HOST, Build.BRAND, Build.MANUFACTURER) и постоянных строк, а это не секрет	В каких случаях срабатывает запасной путь, и что именно попадает в резервную копию, не проверялось. Это оценка по коду, а не подтверждённая проверка на устройстве
Расшифровка ссылок спрятана за безобидным именем	Расшифровку шифрованных ссылок happ://crypt… выполняет нативная библиотека liberror-code.so (около 4 МБ, собрана NDK r28c, символы вырезаны). Наружу она отдаёт методы с именами в духе «получить текст ошибки по коду» (jniGetErrorMessageFromCode, jniGetErrorMessageFromString), но в коде приложения (uy4.java) именно они вызываются для разбора ссылок и для сбора профиля устройства из скрытой ветки. То есть ключевая закрытая логика названа так, будто она лишь переводит коды ошибок в текст	Сам алгоритм расшифровки не восстанавливался: это не нужно для предупреждения пользователя и ближе к вскрытию защиты подписок, а не к защите пользователя. Что именно делает библиотека, видно по её вызовам в коде, не по разбору машинного кода
Скрытая ветка сбора профиля устройства	В обработчике шифрованных ссылок (crypt…) есть ветка, которая при особом входном значении собирает расширенный профиль устройства и вставляет его в адрес на домен yandex.ru: платформа, версия приложения, признаки отладочной сборки и эмулятора, бренд, модель, отпечаток сборки, версия загрузчика и радиомодуля, признаки root и Magisk (последний определяется чтением /proc/mounts), HWID, часовой пояс, язык и страна. Особое значение в статье не приводится	Назначение ветки и то, уходит ли этот адрес в запрос, не установлено. В обычной работе по коду она не вызывается, на устройстве её не запускали. Присутствие такой ветки и обращение к домену российского сервиса стоит объяснить разработчикам
Журналы приложения	Приложение ведёт три журнала в своей папке: access_log.txt (журнал ядра), subscription_log.txt и push_log.txt. В интерфейсе есть сообщение «Логирование скрыто, т.к. используется зашифрованный/пользовательский сервер»: для серверов из шифрованной подписки журнал пользователю не показывается	Что именно попадает в журнал ядра и можно ли его вытащить без доступа к устройству: не проверялось
Удалённое управление через push-сообщения	Приложение принимает сообщения Firebase с командами import-data, update-subscription, set-settings, sub-change (в коде допустим тип изменения domain), clear-stories и sub-info; подписка выбирается по Provider ID. В одной из веток значение поля sign-control сравнивается с постоянной строкой, зашитой в приложение: она одинакова у всех установок и читается из APK, то есть как защита почти ничего не даёт. Реальный барьер здесь отправка через Firebase, для которой нужны учётные данные проекта Happ. В самом коде есть адрес v1remotepush на ntp2-sync.com, судя по названию, связанный с такой отправкой	Кто и как может отправить такие сообщения и что именно произойдёт на устройстве при каждой команде: на телефоне не проверялось. Это канал, через который разработчик или тот, у кого есть доступ к отправке, меняет подписки и настройки клиента без действий пользователя
Отправка на телевизор	Функция «отправить на устройство» передаёт список ссылок и конфигураций (строки через перевод строки) POST-запросом на ntp2-sync.com/v1sendtv/<код> вместе с HWID, версией ОС и моделью устройства. То есть ссылки подписок и ключи при такой пересылке проходят через сервер разработчика, а адрес сервера выглядит как служба времени, а не как домен Happ	Хранит ли сервер переданные данные и как долго, и шифруются ли они до отправки: по коду не определено
IPv6 в VPN-интерфейсе	Служба VPN добавляет IPv6-адрес и маршрут ::/0 только при выборе типа IP «IPv6». При значениях «Auto» (на проверенном телефоне стоит оно) и «IPv4» в адаптере остаётся только IPv4	Утечку IPv6 мимо туннеля на практике я не подтвердил: проверочный запрос по IPv6 не получил ответа ни с включённым VPN, ни без него, то есть сеть телефона для такой проверки не годилась. Как Android обращается с IPv6 при IPv4-only туннеле, нужно проверять в сети с рабочим IPv6
DNS по умолчанию	В заводской настройке (локальный DNS выключен, правила выключены, не пользовательский JSON) служба VPN не задаёт DNS-серверов. Куда уходят запросы имён, определяют Android и правила ядра	Проверка на телефоне: шесть уникальных имён было разрешено с включённым VPN, и сервис проверки DNS-утечек увидел запросы только от резолверов Google (США), резолверов домашнего провайдера в списке не было. Режим частного DNS в системе стоит «Автоматически». Поэтому утечки на DNS провайдера при настройках по умолчанию не видно, но запросы получает сторонний резолвер, и из этого теста нельзя понять, идёт запрос через туннель или напрямую зашифрованным DNS системы. Сервис при этом пишет общий вывод «DNS может утекать», так как резолвер не относится к VPN-провайдеру
Свой трафик приложения и исключения	Happ исключает собственный пакет из туннеля (addDisallowedApplication), поэтому часть его запросов (проверки, обновления, отчёты) может идти напрямую с настоящего адреса; пользователь и профиль маршрутизации могут исключать адреса и приложения (на Android 13 и выше исключаются на уровне системы, excludeRoute). На экране «Исключённых маршрутов» по умолчанию шесть записей: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, 224.0.0.0/4 и 255.255.255.255, то есть трафик в домашнюю сеть и многоадресный трафик идёт мимо туннеля. Системное исключение маршрутов в коде включается только на Android 13 и выше, а как списки применяются на более старых версиях, не проверялось	Какие именно собственные запросы идут через локальный прокси, а какие напрямую: условие в коде не раскрыто
Защита от обрыва VPN	Служба VPN объявлена как поддерживающая «Постоянную сеть VPN» Android (SUPPORTS_ALWAYS_ON). В прочитанном коде нет собственного переключателя блокировки трафика без VPN и обращений к состоянию блокировки Android	Что происходит при падении службы или ядра на телефоне, не проверялось. Защиту даёт системная настройка Android «Постоянная сеть VPN» с блокировкой соединений без VPN, а не само приложение
Заголовки запроса к серверу подписки	В коде есть заголовки X-HWID, X-Device-OS, X-Ver-OS, X-Device-model, X-Device-Locale и X-App-Version: продавец подписки получает идентификатор устройства, систему, её версию, модель телефона и язык. Как продавцы используют такой идентификатор, разобрано в заметке о HWID-привязке	Как именно приложение вычисляет HWID: источник значения в прочитанном коде не установлен
Режим без проверки сертификата	В коде есть клиент, который доверяет любому сертификату и не сверяет имя узла. Он нужен для режима insecure: этот параметр описан в документации Happ в формате ссылки, в приложении есть пункт «Allow insecure» в изменении подписки, а у подписки есть соответствующее поле. Обычная загрузка подписки сначала идёт с проверкой, а отключение проверки включается только этим параметром	Кто и в каких случаях выставляет параметр на практике и доходит ли значение от продавца подписки до клиента без ведома пользователя: этот путь до конца не прослежен. Включённый insecure позволяет подменить ответ сервера подписки в сети
Базы геоданных для маршрутизации	По умолчанию Happ скачивает geoip.dat и geosite.dat из репозитория стороннего автора Loyalsoldier по адресу «latest», то есть без закреплённой версии. Ядро проверяет только, что файл разбирается; в приложении есть сообщение «повреждённый файл геоданных», а проверки хеша или подписи в прочитанном коде не найдено	Есть ли проверка целостности на другом уровне: код обфусцирован. Подмена такого файла изменила бы правила маршрутизации, то есть то, какой трафик идёт напрямую, а какой через VPN
Отправка отчёта о проблеме	Запускается из интерфейса (в приложении есть подпись «Я согласен отправить данные»; порядок работы диалога на устройстве не проверялся) и уходит на time-ntp.com вместе с HWID, версией ОС и моделью устройства	Содержимое отправляемого файла целиком

На экране перечислены ссылки запуска (connect, open), остановки (disconnect, close) и переключения (toggle) туннеля, у каждой есть вариант _without_ui, затем ссылки добавления сервера (add и пять вариантов crypt) и профиля маршрутизации (routing/add, routing/onadd, routing/off). Включить или выключить их на этом экране нельзя: он только показывает адреса. Какая из этих ссылок что делает на устройстве, мы не проверяли.

Самый серьёзный пункт таблицы — команды без интерфейса. По коду выходит, что любое приложение или веб-страница, которым удаётся открыть такую ссылку, способны остановить или переключить туннель, показав пользователю лишь короткое всплывающее сообщение. Для человека, которому VPN нужен, чтобы российские приложения и сайты не видели его настоящий адрес, это сводит на нет защиту в момент отключения. При ручной проверке в мобильном браузере открытие ссылки схемы happ:// сопровождалось запросом браузера на разрешение открыть Happ, то есть для страницы в браузере есть дополнительный барьер: подтверждение даёт браузер, а не Happ (какой браузер, какая ссылка и что происходит после согласия, не фиксировалось). Для приложения на экране такого запроса может не быть. Нужны уточнения: Android ограничивает запуск окон приложениями, которые работают в фоне, а сама возможность задумана как автоматизация (ссылки показаны в настройках самого Happ). Но у защиты от постороннего вызывающего в разобранном коде признаков нет, и поэтому пункт записан как риск по коду, а не как подтверждённая на устройстве атака.

Для читателя, которому важно, что видят приложения на устройстве, из этого следуют две вещи. Первая: заводской пароль на локальном порту отсутствует, и это не ошибка пользователя, а значение, с которым Happ приходит. Вторая: у приложения широкий доступ к списку установленных программ и несколько внешних точек входа, а значит, его стоит держать обновлённым и отключать ненужные возможности, если настройки это позволяют. Как банки и другие приложения проверяют VPN и что они видят на телефоне, разобрано в banks-malware-scan-2027 и tunnel-detection-fix-split-ip.

10. Что из устройства Happ видят российские приложения: сопоставление с исследованием RKS Global

В апреле 2026 года компания RKS Global опубликовала исследование о том, как 30 популярных российских приложений для Android ищут VPN на телефоне пользователя; подробные таблицы и результаты повторной проверки от 16 апреля лежат в техническом документе в формате PDF. Методика у исследования ограничена: сначала только статический анализ APK, при повторной проверке добавилось динамическое тестирование на устройстве; банки и сервисы результаты публично не подтверждали. Но набор методов конкретный, и его можно сопоставить с тем, что Happ оставляет на устройстве. Ниже разобрано именно это, то есть какие следы Happ видны приложениям, которые такие проверки выполняют.

Исследователи описали шесть методов, и после повторной проверки детекция VPN нашлась во всех 30 приложениях. Первый метод — прямой запрос к системе, включён ли VPN (TRANSPORT_VPN). Второй — перечисление сетевых интерфейсов и поиск tun0: по результатам повторной проверки такой перебор выполняют 13 приложений, причём Android отдаёт эти сведения любому приложению независимо от маршрутизации и от того, исключено ли оно из туннеля. Третий — чтение таблицы соединений ядра /proc/net/tcp; в самом исследовании в этом разделе описан поиск порта инструмента анализа Frida, а не порта VPN. Четвёртый — чтение настроек системного прокси. Пятый — отправка признака VPN на сервер, а шестой — список установленных VPN-приложений через запрос служб android.net.VpnService (после повторной проверки такой список получают семь приложений, в первый раз их было два).

Метод из исследования	Что при этом видно у Happ	Откуда известно
Запрос TRANSPORT_VPN	В режиме VPN Happ работает как системная служба VPN, и признак VPN у системы поднят	В манифесте служба XRayVpnService с разрешением BIND_VPN_SERVICE; на телефоне при подключении появляется интерфейс tun0
Поиск интерфейса tun0	Интерфейс tun0 виден; в коде ему заданы постоянные значения: адрес 26.26.26.1/30, IPv6-адрес da26:2626::1, DNS 26.26.26.2. Эти значения одинаковы у каждой установки, то есть отличают Happ от других клиентов	Код XRayVpnService; адрес 26.26.26.1/30 подтверждён на телефоне. Сопоставление по этим адресам в исследовании не описано, так что это возможность, а не зафиксированная практика
Эвристика «MTU меньше 1400» (по сообщению исследования, её используют Mail.ru и «Дзен»)	Не сработает: MTU туннеля у Happ 1500	Код и вывод ip addr на телефоне
Список служб android.net.VpnService	Happ объявляет службу с таким действием, поэтому попадает в список; имя пакета su.happ.proxyutility постоянно. Это не зависит от маршрутизации и раздельного туннелирования	Манифест. Что семь названных в исследовании приложений передают такой список на сервер через антифрод-модуль, известно из самого исследования, не проверено нами
Системный прокси (http.proxyHost)	Для режима VPN не проверялось	Нет
Локальный порт SOCKS5	Порт 10808 открыт без пароля. В отчёте исследования перебор локальных портов с поиском прокси в этих приложениях не описан, поэтому это скрытый риск, а не зафиксированная практика. Приложение, которое такой порт нашло бы, получило бы выходной адрес сервера способом из раздела 3	Проверка на телефоне, см. раздел 3
Режим «только прокси»	В настройках VPN есть переключатель «Режим» с вариантами «VPN» и «Только прокси». В режиме «Только прокси» интерфейс tun0 не создаётся (в списке интерфейсов телефона остаются только системные), значка VPN в строке состояния нет, поэтому поиск tun0 и запрос TRANSPORT_VPN на нём ничего не найдут. Порт 10808 при этом слушает и принимает рукопожатие без пароля (ответ 05 00), а служба VPN остаётся объявленной в манифесте	Проверено на телефоне. Не проверено: что видят приложения в режиме «Только прокси» через список служб VPN и как через него направить трафик нужных приложений

Из таблицы следуют два вывода для читателя. Первый: то, что Happ сам изменить не может, — это факт наличия VPN-интерфейса и объявленной службы VPN; такие признаки есть у любого клиента, который строит туннель через системный механизм Android, а исследование прямо называет раздельное туннелирование недостаточной защитой. Второй: то, что зависит от разработчика, — постоянные адреса туннеля (26.26.26.1/30), которые делают клиент узнаваемым, пароль на локальном порту, который в Happ по умолчанию выключен, и отсутствие подтверждения у ссылок управления из раздела 9. Меры самой исследовательской группы (отдельный телефон, рабочий профиль Android, VPN на роутере) сохраняют силу, а заметки о том, как банки и приложения проверяют устройство, разобраны в banks-malware-scan-2027 и tunnel-detection-fix-split-ip.

Итог: чем плох Happ и что с этим делать

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

Ситуация	Что учесть
Свой сервер, подписка своя	Happ нужен только как удобная оболочка; можно взять клиент с открытым кодом и не отправлять HWID
Подписка от продавца с hide-settings и шифрованной ссылкой	Вы не видите, к какому серверу подключены; доверие к продавцу нельзя проверить
Нужна последняя версия ядра ради нового транспорта	Сверьте версию ядра в клиенте с апстримом и не рассчитывайте на выход обновления за пару дней
Нужна защита от локального сканирования	Включайте пароль на локальных SOCKS5 и HTTP, где клиент это позволяет; проблема общая, а не только у Happ
Важно, что видят российские приложения	Happ оставляет интерфейс tun0 с постоянным адресом и объявленную службу VPN; режим «Только прокси» убирает tun0, но не порт без пароля; надёжнее отдельный профиль Android или VPN на роутере (раздел 10)
Телефон используют для автоматизации (виджеты, ссылки)	Ссылки happ://…_without_ui не просят подтверждения; не открывайте непроверенные ссылки и страницы, пока не убедитесь, что для вас это приемлемо (раздел 9)

Что не проверено

• Поведение внешних точек входа Happ (ссылки happ://… и …_without_ui) на устройстве: в статье приведены только данные манифеста и код обработчика. Разбор кода выполнен по обфусцированному APK и не претендует на полноту.
• Выходной адрес получен через локальный порт, но то, что именно он принадлежит серверу, а не провайдеру телефона, выведено косвенно: он не совпал с домашним адресом, с которого шла проверка. Отдельной сверки с адресом сервера по его домену не делали, потому что сам домен в статью не включается. Проверка выполнена на одном телефоне и одной версии Happ (4.7.1); для iOS и других версий результат не проверялся.
• Версия ядра и скорость обновлений в INCY и других клиентах.
• Работа xtls-rprx-vision в Happ на Apple и Hysteria на Wi-Fi: данные пользователей без воспроизведения.
• Юридическая принадлежность Flyfrog LLC и Veltrixor LLC.
• Причины удаления из российского App Store.

Источники

• Happ: главная страница документации
• Happ: политика конфиденциальности
• Happ: управление приложением через подписку
• Happ: Provider ID
• Happ: шифрованные ссылки
• Happ: профили маршрутизации и deeplink
• Happ: частые вопросы, в том числе установка на iPhone
• GitHub-организация Happ-proxy
• Репозиторий happ-android
• Репозиторий happ-desktop
• Трекер обращений Happ-proxy/.github
• Список изменений Happ для desktop 4.5.6, 16.10.2026
• Списки изменений Happ для Android
• Списки изменений Happ для desktop
• Happ для Android 3.16.1, 1 апреля 2026
• Happ для Android 3.16.2, 7 апреля 2026
• Релизы XTLS/Xray-core
• Хабр, runetfreedom, 7 апреля 2026 — критическая уязвимость VLESS-клиентов
• «Код Дурова», 11 апреля 2026 — Happ исправил уязвимость, но риск утечки IP остался
• SecurityLab, 9 мая 2026 — бесплатные ключи для Happ
• SecurityLab, 1 августа 2026 — Happ VPN: архитектура и риски клиента
• RKS Global, апрель 2026 — как российские приложения ищут VPN на телефоне
• RKS Global — технический документ с повторной проверкой, PDF
• RFC 1928 — протокол SOCKS5
• RFC 1929 — проверка пароля в SOCKS5
• Публичный проект расшифровки happ-decrypt
• App Store: Happ — Proxy Utility
• Google Play: Happ

📚 См. также

• Клиенты и маршрутизация — как подключить VLESS и настроить раздельную маршрутизацию
• HWID-привязка и запрет «чужих» клиентов — как продавцы ограничивают выбор клиента
• Уязвимость SOCKS5 на localhost — проблема всех клиентов на Xray и sing-box
• Project X (Xray-core) — откуда берётся общее ядро
• XTLS и Vision — что такое flow=xtls-rprx-vision

---

🤖 Эти статьи открыты — можно обучать на них ИИ

При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: исходник этой заметки · скачать весь репозиторий одним zip-архивом.