На старом Android приложение обращается к API по HTTP, а на новом получает сетевую ошибку. Как доказать, что причина в политике запрета незашифрованного трафика, а не в недоступности сервера?
Нужно воспроизвести запрос к тому же серверу по HTTPS и проверить тот же HTTP-запрос на устройстве с контролируемым сервером, одновременно изучив сетевые логи и фактический трафик. Если HTTPS работает, сервер доступен, а HTTP блокируется до отправки данных и ошибка коррелирует с настройкой cleartext traffic, причина находится в политике платформы или конфигурации приложения, а не в доступности сервера.
Передача данных по обычному HTTP не защищает содержимое от перехвата и подмены. Поэтому мобильные платформы постепенно стали запрещать незашифрованные соединения по умолчанию, чтобы приложение не отправляло данные в открытом виде из-за случайной ошибки конфигурации.
В Android поведение зависит не только от версии ОС, но и от целевой версии SDK приложения и его сетевой конфигурации. Для приложений, ориентированных на Android 9 и выше, незашифрованный трафик по умолчанию обычно запрещён; политика может быть изменена явными исключениями.
Одинаковая ошибка запроса может быть вызвана разными причинами: сервер недоступен, DNS не разрешается, порт заблокирован, сертификат TLS некорректен или приложение запрещает HTTP на уровне политики безопасности. Проверка только сообщения об ошибке часто не позволяет различить эти случаи.
Неверный вывод опасен в обе стороны: команда может без необходимости менять сервер либо временно разрешить небезопасный трафик, скрывая настоящую проблему. Если разрешить HTTP для всего приложения, данные пользователей и токены могут передаваться без шифрования.
Сначала нужно проверить доступность сервера независимо от приложения: выполнить запрос к тому же адресу из сети устройства или использовать контролируемый тестовый сервер. Затем следует сравнить два варианта — HTTP и HTTPS — с одинаковым маршрутом, параметрами и сетевыми условиями.
Если HTTPS успешно устанавливает соединение, а HTTP не достигает сервера, нужно проверить диагностические логи приложения и Android. Признаком политики cleartext будет отказ на этапе установления соединения, отсутствие HTTP-запроса на сервере и сообщение о запрещённом незашифрованном трафике либо эквивалентная ошибка используемого сетевого стека.
Проверку следует повторить на нескольких версиях Android и при разных целевых версиях SDK. Важно выяснить, действует ли глобальная политика приложения или адрес включён в явное исключение в Network Security Configuration. Отдельно нужно проверить, действительно ли конкретная библиотека использует системную сетевую политику: разные сетевые стеки могут сообщать ошибку по-разному.
Корректное исправление — перевести API на HTTPS и проверить сертификат, цепочку доверия, перенаправления и все используемые домены. Разрешение HTTP допустимо только как строго ограниченное временное исключение для контролируемого тестового стенда; для production это компромисс между совместимостью и конфиденциальностью.
После обновления target SDK запросы к тестовому API по HTTP перестали работать только на части устройств. Были рассмотрены три варианта: объявить сервер недоступным, глобально разрешить HTTP в приложении или сравнить HTTP и HTTPS на стендовом сервере с анализом логов.
Первый вариант был отклонён, потому что сервер принимал запросы из браузера и с устройств со старой конфигурацией. Глобальное разрешение HTTP временно устраняло симптом, но создавало риск передачи тестовых и потенциально производственных данных без шифрования.
Выбран третий вариант: HTTPS успешно проходил, HTTP не появлялся в серверных логах, а системный журнал указывал на запрет cleartext-трафика. API перевели на HTTPS, после чего проверили все окружения и удалили широкое исключение; проблема исчезла без ослабления политики безопасности.
Нет. На результат влияют версия ОС, target SDK, сетевой стек и конфигурация безопасности приложения. Поэтому тест должен фиксировать как минимум версию Android, target SDK, используемую библиотеку запросов и действующие правила для конкретного домена.
Нет. Он подтверждает доступность конкретного HTTPS-маршрута, но не исключает различия в виртуальном хосте, порте, прокси, редиректах или серверной маршрутизации. Для доказательства нужно сохранить одинаковыми домен, путь, параметры и сетевое окружение, а также проверить серверные логи.
Такое изменение снимает ограничение, но не устраняет риск перехвата и подмены данных. Даже если текущий API не содержит чувствительной информации, в запросах могут передаваться токены, идентификаторы или персональные данные; кроме того, небезопасное исключение легко случайно перенести в production. Предпочтительное решение — HTTPS, а исключение использовать только адресно и временно для изолированного тестового окружения.