Сейчас «Подводная лодка» доступна в приложениях для Android, iOS и Windows 11. Текст ниже описывает ранние этапы её разработки.
От настроек — к работе над движком
Собственное приложение даёт нам возможность менять поведение подключения. Но часть проблем возникает глубже: в том, как данные проходят между устройством, промежуточной сетью и сервером. Летом 2026 года мы продолжили работу над VPN-движком для технологии подключения «Подводная лодка».
Его основа — Xray и транспорт XHTTP. Мы развиваем свою версию движка и транспортные расширения, сохраняя совместимость там, где она нужна. Поэтому «собственный движок VPNR на базе Xray» — точное описание этой работы.
Общая основа для Android и iOS
Общий код движка написан на Go. Для Android и iOS он собирается в разные библиотеки, а приложения управляют соединением средствами своей платформы.
Мы согласовывали единый контракт между клиентом и сервером: формат передаваемых данных, выбор соединений и поведение при обрыве. Это позволяет проверять одинаковые правила на обеих платформах. При этом готовность конкретной доработки на Android и iOS подтверждается отдельно.
Отправка и получение данных — по разным путям
В июльской работе над Dual мы развивали конфигурацию, в которой отправка и получение данных используют отдельные соединения и настройки. На Android проверяли, что движок действительно открывает оба соединения и корректно освобождает их при остановке VPN.
Эти два соединения обслуживают разные направления передачи. Их наличие само по себе не означает, что одно может заменить другое при отказе.
Проверки выявляли и проблемы за пределами приложения. В конце июля отправке данных мешала неверная настройка соединения между промежуточной сетью и нашим сервером. Этот случай показал, почему правильной конфигурации клиента недостаточно: весь путь данных нужно проверить в работе.
Небольшие ответы тоже должны приходить вовремя
Для просмотра страницы или начала звонка могут быть важны короткие ответы, например ответы DNS. Если промежуточная сеть накапливает небольшие порции данных перед передачей, пользователь видит задержку, хотя соединение формально открыто.
Мы работали над транспортным кадрированием и паддингом: полезные данные и служебное заполнение передаются отдельно, а клиент убирает заполнение перед дальнейшей обработкой. Такой механизм предназначен для работы с задержками буферизации. Его эффект зависит от конкретного сетевого пути и проверяется на нём.
Продолжить поток после обрыва
Следующим направлением стал VPNRPAD2 — собственное расширение транспорта для восстановления входящего потока. Клиент получает данные целыми кадрами и учитывает, какую часть потока уже принял. Сервер сохраняет данные, необходимые для продолжения передачи.
По этому контракту после обрыва клиент запрашивает продолжение с последнего полностью принятого места. Незавершённый кадр не должен попадать в приложение, а уже принятые данные не должны передаваться ему повторно.
В июле серверную реализацию развернули в отдельном контуре и проверили прямой доступ к нему, сохранив прежний вариант подключения. В августе подготовили порт VPNRPAD2 для Android. Разработка библиотеки и проверка сервера были результатами отдельных этапов; они ещё не доказывали устойчивость всего соединения в мобильной сети.
Что дала эта работа
У VPNR появились согласованные правила взаимодействия клиента и сервера, собственные изменения транспорта и отдельные проверки его поведения. Работа затронула передачу небольших ответов, раздельные направления соединения, восстановление потока и совместимость с прежними клиентами.
Это и есть важный шаг к собственному движку: мы можем разбирать проблему внутри подключения, менять механизм передачи и проверять результат. Следующие доработки продолжают опираться на логи, испытания и обратную связь пользователей.