Короткий ответ: чем приложение отличается от сервиса
Человек нажал «Подключиться», кнопка стала зелёной, но сайты не открываются. Для него это одна ошибка. Для команды — три разных вопроса: действителен ли доступ, получил ли телефон настройки и отвечает ли узел. Если приложение не различает эти случаи, поддержка будет советовать «переустановить», даже когда сломан сервер. Поэтому понятный статус и действие при сбое входят в первую версию.
VPN-приложение человек устанавливает на телефон или компьютер: входит, выбирает подключение, видит его состояние и получает помощь при ошибке. За экраном находятся конфигурация, право доступа, сетевой компонент и удалённый узел. Если узла нет, одна красивая кнопка «Подключиться» ничего не даст. Если сеть уже работает, писать её заново ради нового интерфейса может быть лишней работой.
Поэтому первый вопрос заказчику: какая часть уже есть и кому она принадлежит? Ниже мы различаем три маршрута. «Готовый white-label» означает продукт другого поставщика под вашим брендом; «свой клиент» означает приложение, которое подключается к согласованной сети; «полный сервис» включает также управление узлами, доступами, оплатой и эксплуатацией. Это проектные категории, а не обязательные пакеты одного продавца.
Три варианта разработки: что входит и где граница
| Вариант | Что получает заказчик | Что проверить до договора |
|---|---|---|
| Готовый white-label | Брендированную версию существующего клиента; сеть и управление иногда остаются у поставщика | Права на название и сборку, магазинные аккаунты, выгрузка пользователей, изменение функций, выход из договора |
| Свой клиент к сети | Собственный интерфейс и путь пользователя, связь с действующей системой через API (программное подключение) и выбранным сетевым компонентом | Кто выдаёт конфигурацию, подтверждает подписку, отзывает доступ и чинит узлы |
| Полный VPN-сервис | Клиент, серверное управление, выдачу доступов, наблюдение за узлами и операционный процесс | Кто отвечает за инфраструктуру, инциденты, данные, оплату, поддержку и дальнейшие обновления |
Например, у владельца уже работают узлы и есть кабинет, но вход нового пользователя устроен через ручную отправку ключа. Ему может понадобиться только свой клиент и API выдачи конфигурации. А у компании, которая лишь придумала бренд, сначала появится выбор: договориться с white-label поставщиком или строить серверную часть тоже. На рынке есть оба типа предложений; сравнивать цену «приложения» без состава бессмысленно.
Какой опыт подтверждён нашими проектами
В Aegis VPN мы делали клиент с подключением одним касанием, режимами маршрутизации и пользовательским сценарием подписки. По публичному кейсу видны возможности интерфейса и поддержка конкретных способов подключения. Это полезный пример клиентского продукта, но из него нельзя выводить, что все серверы, право на каждый протокол и публикация под любой рынок включены в любой наш проект.
Реальный проект 13FOX
Aegis: собственный путь подключения и управления
Для Aegis мы спроектировали и разработали мобильный клиент на Flutter: подключение одним касанием, выбор режима маршрутизации и пользовательский путь подписки. Кейс показывает работу над клиентским продуктом; он не доказывает, что мы владели всей серверной сетью или обещает такой же состав каждому проекту.
В ProxyControl мы решали близкую задачу управления подключением: импорт профилей, состояние, пинг и трафик. Это менеджер прокси, а не доказательство разработки полного VPN-сервиса; пример помогает обсуждать, какие действия и ошибки пользователь должен видеть. Отдельно опубликован наш Flutter VLESS plugin для связи Flutter-приложения с Xray/V2Ray. Открытый компонент ускоряет исследование технического пути, но сам по себе не заменяет аудит проекта, серверы, поддержку или проверку правил магазина.
Из каких частей складывается работающий продукт
Приложение на устройстве. Человек входит в аккаунт, видит доступный узел и состояние соединения, может его включить и выключить. Нужно заранее решить, что показать при неверной конфигурации, недоступном узле и истёкшем доступе. «Подключено» должно означать наблюдаемый результат, а не только смену цвета кнопки.
Сетевой слой. Приложение связывает системный VPN-интерфейс устройства с выбранным сетевым компонентом (программой, которая создаёт и поддерживает соединение) или протоколом. Не стоит изобретать новый протокол из-за дизайна. Выбор зависит от существующей сети, платформ, лицензий компонентов и проверок безопасности. VLESS в стеке Xray является одним возможным вариантом для конкретного проекта; это не универсальный синоним VPN и не гарантия доступности в любом магазине.
Управление доступом. Серверная часть знает, кто пользователь, какие устройства разрешены и до какого момента есть доступ. Она выдаёт или отзывает конфигурацию и сообщает клиенту понятную причину отказа. Если подписка оплачена, но приложение не видит это состояние, пользователь получает не сервис, а обращение в поддержку. Если деньги принимает внешняя система, её правила и связь с аккаунтом нужно включить в схему.
Узлы и эксплуатация. Кто-то разворачивает и обновляет серверы, следит за отказами, отвечает на обращения и решает, как меняется конфигурация без потери доступа. Для полного сервиса это самостоятельный блок работ и расходов. Для клиента к готовой сети он может оставаться у заказчика или другого поставщика. Документация Android наглядно разделяет приложение, системный интерфейс и VPN gateway (удалённый узел сети).
Матрица состава: что включить в задачу и как принять
Скопируйте таблицу в запрос подрядчику или скачайте CSV-шаблон. В файле есть условно заполненная строка для проекта, где сеть уже принадлежит заказчику; замените её своим фактическим составом. В остальных строках укажите «есть», «делаем» или «вне проекта» и ответственного. Пустая клетка особенно опасна между приложением и сервером: обе команды могут считать, что настройки выдаёт другая сторона.
| Часть | Вопрос для состава | Наблюдаемая приёмка |
|---|---|---|
| Аккаунт и права | Кто создаёт пользователя, управляет устройствами и отзывает доступ? | Новый пользователь входит; после отзыва не может получить действующую конфигурацию |
| Конфигурация и ключи | Как клиент получает настройки и где они хранятся? | Настройки обновляются без ручной пересылки; чувствительные данные не попадают в открытый журнал |
| Подключение | Какие платформы, режимы маршрутизации и состояние сети нужны? | Включение, выключение, смена Wi‑Fi/мобильной сети и понятное сообщение о разрыве проверены на устройствах |
| Узлы | Кто управляет удалённой сетью и её отказами? | При недоступности узла статус и маршрут поддержки известны; приложение не показывает ложное «подключено» |
| Оплата и доступ | Где оплачивается услуга и что происходит при окончании срока? | Оплаченный доступ включается согласно согласованному правилу, истёкший и отменённый не остаётся действующим |
| Магазины и данные | Какие страны выпуска, аккаунты, политика данных и раскрытия? | Подготовлены точные сведения и материалы для подачи; решение магазина отслеживается отдельно |
| Передача и поддержка | Кому достаются код, сборки, документация и доступы? | Заказчик может выпустить обновление и разобраться в типовой ошибке по переданной инструкции |
Эта матрица служит проектной заготовкой, не универсальный технический стандарт. Если вы берёте white-label, большинство строк остаётся в ответственности поставщика, но проверять их всё равно нужно. Если заказываете клиент к своей сети, особенно подробно опишите границу API и порядок устранения сбоя. Для полного сервиса дополните документ правилами эксплуатации, восстановления и реагирования.
Android, iPhone и публикация: ограничения планируют заранее
На Android приложение использует системный VpnService: система отдельно спрашивает разрешение пользователя и показывает активное VPN-подключение. Google Play требует декларацию использования VpnService, описания в карточке приложения и шифрования данных до конечной точки туннеля; при сборе чувствительных данных действуют требования к явному раскрытию и согласию. Эти требования нужно проверить по текущей версии правил перед подачей.
В App Review Guidelines, пункт 5.4, Apple требует для VPN-приложений NEVPNManager API, аккаунт разработчика-организации и ясное объяснение сбора и использования пользовательских данных на экране приложения до любого действия по покупке или использованию сервиса. Правило Apple отдельно говорит, что VPN-приложения не вправе продавать, использовать или раскрывать третьим лицам какие-либо данные для каких-либо целей; это обязательство нужно закрепить в политике конфиденциальности. Apple отсылает к правилам рынков, где приложение доступно. Мы не делаем здесь вывод, какие разрешения нужны для конкретной страны или продукта: это проверяют отдельно для выбранных рынков и модели сервиса.
Кроссплатформенный интерфейс может сократить дублирование экранов, но системное соединение, магазинные разрешения, политика данных и реальные устройства проверяются отдельно. Заранее решите, кто публикует сборку и кому принадлежит аккаунт магазина; перенос после запуска может оказаться отдельной задачей.
Тест приёмки: успешного соединения недостаточно
Проведите один и тот же короткий сценарий на каждой заявленной платформе. Начните с тестового пользователя и отдельного узла. Запишите, что должно увидеть приложение, что произошло на сервере и кто исправляет проблему. Не тестируйте на настоящих ключах клиентов, если для этого достаточно временных.
| Проверка | Ожидаемый результат | Сигнал ошибки |
|---|---|---|
| Первый вход и подключение | Человек получает нужную конфигурацию, соглашается с системным запросом и видит итоговое состояние | Кнопка показывает успех без связи с узлом |
| Смена сети и разрыв | После перехода между сетями состояние обновляется по согласованному сценарию | Интерфейс скрывает разрыв или бесконечно «подключается» |
| Истёкший или отозванный доступ | Новые настройки не выдаются, уже выданный доступ прекращается по согласованному правилу, приложение объясняет причину | Старый ключ продолжает открывать услугу вопреки правилам |
| Недоступный узел | Виден сбой, известен маршрут поддержки или переключения, если он включён в проект | Ложный статус «подключено» и нет диагностики |
| Публикация и передача | Подготовлены сборки, описание данных, материалы подачи, исходники и инструкция обновления | Рабочий прототип есть, а выпустить и поддерживать его некому |
После теста отдельно проверьте, какая информация о пользователе, соединении и платеже действительно собирается, кому она доступна и как удаляется. Не обещайте «полную анонимность» просто потому, что соединение работает: такое утверждение потребовало бы проверки всей системы и процессов, а не интерфейса.
Из чего складывается смета и как сравнивать предложения
Стоимость зависит от объёма из первого раздела, числа платформ и уже существующих частей. В оценку своего клиента обычно входят сценарии и дизайн, интеграция с аккаунтом и выдачей настроек, платформенный сетевой слой, проверка соединения и ошибок, подготовка к публикации. Если нужны серверы, панель управления, оплата и поддержка, это отдельные блоки. Не смешивайте разовый выпуск с постоянной оплатой инфраструктуры, сторонних компонентов и сопровождения.
Попросите двух исполнителей заполнить одну матрицу выше. Если один пишет «VPN под ключ», а другой «мобильное приложение», сравните строки «узлы», «оплата», «магазины», «передача» и тесты отказа. Тогда разница в предложениях станет понятной без произвольной цены за экран. Серверы и их ежедневное обслуживание нужно оценивать отдельно от экранов клиента.
Первое решение перед сметой: напишите одним предложением, кто отвечает за сеть сегодня и кто должен отвечать после запуска. Приложите список платформ, стран выпуска и один путь пользователя от регистрации до подключения. На этой основе можно честно разделить готовый продукт, клиент и полный сервис.
Частые вопросы
Можно ли просто купить готовое VPN-приложение под своим брендом?
Да, white-label поставщик может дать готовый клиент и иногда сеть, кабинет и публикацию. Но состав договора различается. Проверьте, кому принадлежат аккаунты пользователей и магазинные учётные записи, кто управляет узлами, как выгрузить данные и что произойдёт при смене поставщика. Брендированная сборка не становится вашей разработкой автоматически.
Если серверы уже есть, нужен ли полный VPN-сервис?
Обычно задача уже: сделать клиент, связать его с выдачей конфигураций и учётными записями, настроить вход, доступ и поддержку. Но сначала проверьте API существующей системы и право использовать выбранный компонент соединения. Серверную сеть и биллинг включают в смету только если их действительно нужно создавать или менять.
Можно ли сделать один Flutter-код для Android и iPhone?
Flutter может объединить интерфейс, но сетевой слой опирается на возможности каждой платформы. Android описывает VpnService, а Apple предъявляет отдельные требования к VPN-приложениям и API. Поэтому «одна кодовая база» не означает отсутствие платформенной работы, отдельных проверок и магазинной подачи.
Сколько стоит разработка VPN-приложения?
Единой суммы без требований нет: брендирование готового продукта, клиент к существующей сети и полный сервис имеют разный состав. Попросите смету по блокам: платформы, вход и доступ, сетевое ядро, серверное управление, подписки, публикация, безопасность и поддержка. Сравнивайте предложения по одинаковой матрице и явно отмечайте, кто оплачивает инфраструктуру и сторонние лицензии.
Гарантирует ли рабочая сборка публикацию в App Store и Google Play?
Нет. Помимо работающего приложения магазины проверяют отдельные требования к VPN, данным, раскрытию использования сетевых API и аккаунту разработчика. Перед разработкой выберите страны распространения и проверьте актуальные правила площадок и применимые требования для этих рынков. Само техническое прохождение тестов не равно одобрению публикации.
Источники и границы
- Android Developers: создание VPN-клиента и работа VpnService, проверено 23.09.2026.
- Google Play: правила использования VpnService, проверено 23.09.2026.
- Apple: App Review Guidelines, пункт 5.4 VPN Apps, проверено 23.09.2026.
- 13FOX: открытый Flutter VLESS plugin, проверено 23.09.2026.
Подробности реализованного интерфейса показаны в кейсе Aegis, а подход к профилям и состоянию смотрите в кейсе ProxyControl. Если уже есть инфраструктура, принесите её схему без секретных ключей: по ней мы определим реальную границу разработки мобильного клиента.
Разложим ваш VPN-проект на проверяемые части
Оставьте номер для короткого разговора. На нём расскажите, есть ли серверы, кабинет, оплата и пользователи, и назовите платформы и страны выпуска. Мы сравним готовую сборку со своим клиентом и полным сервисом, обозначим границы сметы и приёмки. Ключи доступа не нужны.
Для первого разговора не нужны пароли и доступы к рабочим системам.