Приложение Android отказывается работать через VPN: какой уровень решает

Когда приложение Android перестаёт работать ровно в момент поднятия туннеля, виноваты могут быть три разные вещи, и сбои у них выглядят похоже. Приложение может прочитать состояние сети самого телефона и отказать локально. Сервер может классифицировать адрес, с которого вы приходите, и отклонить его. Или отказ вообще не связан с VPN. Порядок ниже сначала собирает доказательства и только потом что-то меняет, потому что смена выхода — самый дорогой шаг и меньше всего помогает, если проверка локальная.

Шаг 1: выясните, когда приложение отказывает

Время — первый различитель. Очистите буфер журнала, воспроизведите сбой и посмотрите, что приложение сделало до того, как пожаловалось:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Если приложение отказывает до любой попытки исходящего запроса, вы имеете дело с локальным решением. Если оно подключается, что-то отправляет и лишь затем показывает ошибку, отказ пришёл с другой стороны. Если приложение сбоит одинаково при выключенном туннеле, VPN никогда не был переменной.

Относитесь к этому времени как к доказательству, а не как к приговору. Приложение может воспроизводить ответ из кеша, а фоновые запросы могли успеть или не успеть до того, как вы посмотрели. Запишите отметки времени последнего успешного запроса и ошибки, а не только момент появления сообщения.

Шаг 2: прочитайте, как сеть видится самому телефону

Android предоставляет состояние VPN как свойство сети, поэтому приложению не нужен список коммерческих провайдеров, чтобы заметить активный туннель. Оно спрашивает у службы связи, какая сеть сейчас, и ответ содержит бит транспорта VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Эта проверка локальна и дешева, и она объясняет целый класс жалоб "это приложение не работает через VPN" без какой-либо удалённой классификации. То, что приложение может видеть, всё равно зависит от его собственного сетевого контекста, поэтому не считайте, что каждое приложение проверяет каждый профиль на устройстве.

С рабочей станции то же состояние видно на тестовом устройстве с помощью adb shell dumpsys connectivity и поиска записи сети VPN. Сравните запуск с поднятым туннелем и запуск с опущенным и сохраните оба вывода.

Шаг 3: прочитайте, что на самом деле видит сервер

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

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

Если приложение работает через сотовую сеть и сбоит через туннель с той же учётной записью, отказ находится на удалённой стороне или в политике самого приложения. Если сбоит в обоих случаях, VPN не является различием, и вам следует прекратить проверять точки выхода.

Шаг 4: соотнесите доказательства с одним из трёх вердиктов

Три комбинации покрывают почти все сообщения. Отказ без исходящей попытки при активном туннеле указывает на локальную проверку транспорта. Запрос, который уходит и возвращается с ошибкой, тайм-аут на конкретном хосте или сообщение о регионе указывают на удалённую сторону. Сбой, который повторяется в сотовой сети без туннеля, указывает на учётную запись, версию приложения или политику самой службы, и никакая смена VPN его не сдвинет.

Запишите вердикт вместе с доказательствами, которые его дали. Ценность этого шага в том, что он останавливает цикл, где кто-то четыре раза меняет выходные узлы, чтобы починить проверку, работающую на самом телефоне.

Это ещё и держит утверждения честными. Собственный сервер меняет точку выхода и её интернет-выход; он не заставляет Android забыть, что сеть VPN активна, и не гарантирует принятие службой, которая классифицирует адреса. Локальный фильтр может сработать на вашей собственной сети VPN так же легко, как на коммерческой.

Шаг 5: выберите поддерживаемый путь и проверьте его

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

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

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