Самый частый сценарий: адрес и порт вбиты в настройки Wi-Fi, браузер открывается в белый экран. Или браузер грузит страницы, а приложение, ради которого всё затевалось, пишет «нет соединения». На ноутбуке тот же узел летает. Значит, проблема не в прокси, а в том, как Android с ним обращается.
Ниже причины, на которые я натыкался сам и которые чаще всего вижу в чужих вопросах. Порядок примерно по частоте.
Системный прокси на Android живёт только внутри Wi-Fi
Настройка прокси на Android привязана к конкретной Wi-Fi сети. Не к телефону и не к системе, а к точке доступа. Переключились на мобильный интернет - настройка перестала действовать, и никто об этом не сообщит. Вернулись в офис, подключились к другой сети - снова чисто.
Путь: Настройки → Сеть и интернет → Wi-Fi → выбрать сеть → Дополнительно → Прокси. Дальше либо «Нет», либо «Вручную», либо «Автонастройка (PAC)».
Системный прокси на Android - это HTTP-прокси. Он перехватывает веб-запросы, но не обязан трогать трафик приложений, которые ходят по своим протоколам. Отсюда классика «в браузере работает, в приложении нет».
Приложение может вообще не смотреть на системные настройки
Часть клиентов несёт собственный сетевой стек. Кто-то поднимает свой HTTP-клиент с кастомным DNS, кто-то общается по бинарному протоколу, где HTTP-прокси некуда вписаться. Системная настройка для них - строчка в чужом конфиге, которую никто не читает.
Проверьте настройки самого приложения. В большинстве клиентов есть раздел «Прокси», «Соединение» или «Сеть». Там указывается тип (SOCKS5, HTTP), хост, порт, логин. Если такого раздела нет, приложение, скорее всего, работать через прокси не умеет в принципе.
Второй вариант - принудительная маршрутизация. Клиенты вроде Drony поднимают локальный туннель и заворачивают трафик целиком. Работает не всегда красиво, зато предсказуемо.
Авторизация, для которой в меню нет полей
В стандартном диалоге Android нет полей для логина и пароля. Их физически некуда вписать. Если узел требует аутентификации, телефон отправит запрос без учётных данных, получит 407 и молча сдастся. Вы увидите просто «не подключается».
Три выхода. Первый - клиент, который умеет аутентификацию или токены. Второй - формат user:pass@host:port, если приложение его переваривает. Третий - привязка по IP на стороне сервиса: логин не нужен, узел пускает по адресу. У платных каталогов привязка по IP обычно есть в панели, у бесплатных - почти никогда.
Один неверный символ в PAC-файле и трафика нет
PAC - это скрипт, который решает, какой запрос куда отправить. Одно неверное условие, лишняя скобка или мёртвый адрес внутри - и весь трафик уходит в никуда. Сообщений об ошибке не будет.
Отдельная боль: стандартный диалог Android не даёт сохранить настройку, если в конце адреса висит .pac. Приходится открывать файл в текстовом редакторе, вытаскивать хост и порт и вбивать вручную в режиме «Вручную». Костыль, но рабочий.
Если не уверены, что PAC написан корректно, не используйте его. Ручные настройки на порядок предсказуемее.
DNS уходит мимо прокси
HTTP-трафик идёт через узел, а DNS-запросы могут уходить напрямую провайдеру. Снаружи это выглядит так: соединение вроде есть, но часть имён не резолвится, часть отдаёт не тот результат, приложение висит на «подключении».
Лечится сервисом с поддержкой DNS-over-HTTPS или локальным клиентом, который заворачивает всё, включая резолв. Ещё вариант - прописать DNS вручную в настройках Wi-Fi, но помогает не всегда.
Прошивки разные, логика одна
На Samsung путь лежит через Wi-Fi → нужная сеть → Дополнительно → Прокси. На Xiaomi и MIUI пункт прячется в расширенных настройках выбранной сети. У некоторых вендоров поле исчезает совсем, если сеть помечена как общедоступная. Это не баг, а логика оболочки: производитель считает, что в публичном Wi-Fi прокси вам не нужен.
Проверьте, не включена ли на сети функция «Приватный DNS» или похожая от производителя. Она перекрывает ручной резолв и даёт ровно тот эффект: прокси подключён, а приложение не открывается.
Энергосбережение душит клиент в фоне
MIUI, EMUI, One UI и прочие оболочки агрессивно выгружают фоновые процессы. Клиент, который держит соединение, вылетает через минуту после того, как экран погас. Приложение остаётся без транспорта и показывает ошибку сети.
Добавьте клиент в исключения батареи, снимите оптимизацию, разрешите автозапуск. Настройка нудная, но без неё диагностика бессмысленна: вы будете искать проблему в прокси, а она в менеджере питания.
Публичные сети и корпоративные шлюзы
В кафе и аэропортах до прокси дело часто не доходит. Сеть сначала требует вход через веб-страницу. Телефон в этот момент пытается установить туннель и не показывает форму входа. Итог - таймаут и ложное ощущение, что узел мёртв.
В корпоративных сетях уже есть свой прокси, и второй поверх первого не работает. На многих шлюзах закрыты нестандартные порты. Стандартные обычно проходят, нестандартные - не всегда. Если узел слушает порт, который сеть режет, вы получите тот же таймаут.
SOCKS5 и MTProto: понимание архитектуры экономит часы
Разница между протоколами объясняет половину странностей. SOCKS5 работает на уровне TCP-соединения и не разбирает содержимое. Он не трогает HTTP-заголовки, не расшифровывает трафик, шифрование остаётся на стороне приложения. Поэтому SOCKS5 дружит почти со всем, что умеет ходить по TCP, и почти не конфликтует с клиентами.
MTProto устроен иначе: это протокол со своим шифрованием пакетов, а прокси в этой схеме - просто транспорт. Задержка зависит не от протокола, а от расстояния до узла и его загрузки. Отсюда типичная история. У одного человека приватный MTProto-узел работает на Samsung S24 Ultra без единой проблемы. У другого тот же конфиг не поднимается. Дело не в телефоне, а в узле и в том, что ключи раздают разные люди.
Если MTProto-клиент не подключается, первым делом проверяйте узел и актуальность ключа. Настройки Wi-Fi тут почти никогда не виноваты.
Свежий Android иногда ломает приложение обновлением
На Reddit регулярно всплывает сюжет: после обновления системы или самого приложения клиент перестаёт соединяться, хотя ничего не менялось. Помогает не всегда, но проверить стоит: переустановка приложения, очистка кеша, откат на предыдущую версию.
И банальное: перезагрузка телефона. Звучит как совет из 2010-го, но на Android сетевой стек после смены сетей и правок конфигурации реально залипает. Половина «неработающих» прокси оживает именно после ребута.
В девяти случаях из десяти виноват сам узел
Неприятная правда: в девяти случаях из десяти виноват сам узел. Бесплатные прокси живут часами. Их перегружают, банят, владельцы закрывают доступ без предупреждения. Человек вбивает адрес, видит таймаут и идёт гуглить, почему не подключается прокси на андроиде. А узел уже сутки как мёртв.
Проверка занимает минуту: подставьте тот же адрес и порт в настройки браузера на компьютере. Не работает и там - вопрос закрыт, дело не в Android.
Второй маркер - стабильность. Если соединение устанавливается, но рвётся каждые несколько минут, проблема в канале узла. Нормальный рабочий прокси держит сессию часами.
Как за пять минут локализовать проблему
- Проверьте узел на компьютере. Не работает нигде - меняйте узел.
- Посмотрите, к какой сети привязана настройка. Переключение на мобильный интернет её отключает.
- Откройте настройки приложения и найдите встроенный раздел прокси.
- Проверьте, требует ли узел логин и пароль. Если да, а полей нет - меняйте клиент или просите привязку по IP.
- Отключите PAC и попробуйте ручные настройки.
- Снимите оптимизацию батареи для клиента, перезагрузите телефон и очистите кеш проблемного приложения.
Каталог вместо лотереи
Разница между «нашёл прокси в чате» и «взял в каталоге» - это разница между вечером на диагностику и пятью минутами на настройку. В каталоге прокси 3seller есть фильтры по стране, протоколу и типу узла. Сразу видно, что вы берёте: датацентр или резидентный, на какой срок, с какой пропускной способностью.
Для мобильных задач логика простая. Работа с аккаунтами в соцсетях и мессенджерах - резидентные адреса, они выглядят как обычные домашние подключения. Парсинг и сбор данных - датацентр, дешевле и быстрее, если площадка не придирается к источнику. Тесты и отладка приложений - любые стабильные, лишь бы не путать баг в коде с падением узла.
Ещё один момент, который экономит нервы: у платного узла есть панель, где видно состояние. Упал - вы это видите и меняете за минуту, а не гадаете, телефон глючит или прокси. Авторизация решается там же, в личном кабинете, без танцев с форматом строки подключения.
Что реально помогает на практике
Порядок действий на практике. Сначала проверьте узел на другом устройстве. Потом убедитесь, что смотрите в настройки того приложения, которое не работает, а не только в системные. Если узел требует авторизации - берите клиент, который её поддерживает, либо переходите на привязку по IP. PAC-файлы отложите в сторону, пока не разберётесь с базовой связностью.
Дальше - питание и порты. Снимите оптимизацию батареи с клиента и убедитесь, что сеть не режет порт, на котором слушает узел. Эти две причины дают столько же ложных диагнозов, сколько и мёртвые бесплатные списки.
И перестаньте воевать с бесплатными прокси. Один стабильный узел из каталога решает больше проблем, чем десять страниц форумов. Проверено на себе не один раз.