Первый раз я настраивал прокси на Android в аэропорту, за двадцать минут до посадки, на чужом телефоне. Владелец аппарата просил просто поставить галочку, а в итоге у него не работало ничего: приложение, ради которого всё затевалось, системные настройки игнорировало. С тех пор у меня есть правило - сначала выяснить, кто в телефоне вообще умеет слушать прокси, и только потом лезть в меню.
Дальше разберу честно, без иллюзий, как это устроено на современных Android. Где настройка живёт, почему она не всегда применяется, чем SOCKS5 отличается от HTTP на уровне архитектуры и почему половина проблем со связкой телефон плюс прокси решается не в прокси.
Системный прокси на Android прикручен к конкретной Wi-Fi сети
Главное, что многие упускают: в стандартных настройках Android прокси задаётся не для телефона в целом, а для одной конкретной точки доступа Wi-Fi. Переключились на другую сеть или на мобильный интернет - настройка перестала действовать. Сама система об этом не сообщает, значок ничего не показывает, и человек искренне уверен, что сидит через прокси, хотя уже час ходит напрямую.
Путь на чистом Android (версии 10-15, у Samsung, Xiaomi, Pixel логика одинаковая, отличаются только названия пунктов):
- Настройки - Сеть и интернет - Wi-Fi.
- Нажимаете на название сети, к которой подключены, или на шестерёнку рядом с ней.
- Выбираете «Изменить» или «Управление сетью».
- Разворачиваете блок «Дополнительные параметры» (иногда «Расширенные настройки»).
- Находите пункт «Прокси», переключаете с «Нет» на «Вручную».
- Вписываете имя хоста и порт, сохраняете.
На старых оболочках пункт прячется иначе: сеть нужно не просто открыть, а зажать долгим тапом, пока не появится меню «Изменить сеть». Логика та же, разница в лишнем движении пальцем.
После сохранения сеть нужно переподключить. Android частенько подхватывает новые параметры только при следующем рукопожатии с роутером, и без переподключения вы будете смотреть на сохранённый конфиг, который фактически не применился. На это у меня ушло два года рабочих нервов, пока я не начал выключать и включать Wi-Fi сразу после сохранения, каждый раз, всегда.
Что писать в поля Hostname и Port
В поле хоста идёт IP-адрес или доменное имя прокси-сервера из вашего кабинета, в поле порта - номер порта оттуда же. Ничего вычислять не нужно, эти два значения выдаются вместе с логином и паролем при покупке доступа. Если вам дали логин с паролем, а полей для них в системных настройках Android нет, это нормально: стандартный системный прокси логин и пароль не передаёт вообще.
Дальше начинается самое интересное, о чём в инструкциях пишут редко. Системные настройки Android поддерживают только HTTP-прокси, а трафик на них идёт чаще всего тоже по HTTP. Авторизацию по логину и паролю такой прокси не переваривает. Значит, привязка идёт по IP-адресу устройства: вы заранее добавляете свой IP в белый список в панели провайдера, и сервер пускает только его. Поменяли сеть, получили новый IP от оператора - доступ отвалился, а вы ещё минут десять ищете причину в телефоне.
Ещё есть поле «Пропускать прокси для» (Bypass proxy for). Туда стоит дописать локальные адреса, чтобы принтер в офисе, камера и умная розетка не пытались идти через удалённый узел. Достаточно localhost и маски локальной сети, подробности обычно указаны в документации к вашей прошивке.
Мобильный интернет: пункта просто нет, и это не баг
Самый частый вопрос, который мне задают: где настроить прокси для LTE. Ответ - нигде. В Android нет системной настройки прокси для сотовой сети, в интерфейсе её физически не существует, никакая прошивка этого не добавляет. Люди ищут её часами, устанавливают сомнительные приложения и в итоге бросают затею.
Рабочих путей три, и все они обходятся без системного меню. Первый - приложения-клиенты, которые создают локальный VPN-интерфейс и заворачивают в него весь трафик телефона, включая мобильный. Второй - точка доступа: раздать интернет на второй аппарат и там настроить что нужно. Третий - root-права и перехват трафика на уровне ядра.
Первый вариант самый доступный. Клиенты такого типа (Postern, Drony, Shadowsocks- и v2ray-клиенты, компаньон-приложения к прокси-сервисам) работают как локальный туннель: приложение поднимает виртуальный сетевой интерфейс, система думает, что это VPN, и отдаёт туда всё. Внутри уже настраиваются правила: по каким приложениям идти через прокси, а какие пускать напрямую. Удобно, когда нужно гонять через узел только клиент аналитики, а банк и мессенджеры оставить в покое.
Подвох в том, что слот VPN в Android один. Включили прокси-клиент, и корпоративный VPN тут же отключился. Плюс расход батареи заметно выше, чем при системной настройке, потому что весь трафик проходит через дополнительный слой. На бюджетных аппаратах это чувствуется.
Root и ProxyDroid: когда он действительно нужен
Прозрачный перехват на уровне ядра через iptables даёт то, чего не даст ни одно приложение без прав суперпользователя: абсолютно любое приложение на телефоне идёт через прокси, даже то, которое знать не знает про системные настройки. Именно поэтому ProxyDroid годами живёт в инструкциях.
Цена вопроса высокая. Разблокировка загрузчика, кастомное ядро, потеря гарантии, а на многих аппаратах ещё и потеря оплаты по NFC. Банковские приложения и сервисы с проверкой целостности системы на рутованном телефоне часто отказываются работать, и обойти их проверки с каждым годом всё сложнее. Для рабочего телефона маркетолога или аккаунт-менеджера я это не рекомендую. Для отдельного тестового аппарата, где гоняются парсеры и мультиаккаунты, - вполне рабочая история.
Внутри ProxyDroid настройка выглядит так: хост, порт, логин, пароль, тип прокси, затем переключатель включения. В логе после запуска появляется строка о том, что прокси слушает на локальном адресе, и дальше идёт подтверждение соединения. Если строки нет - почти всегда проблема в правах или в том, что модуль ядра не подхватился после обновления прошивки.
SOCKS5 и HTTP: разница в том, что видит сервер на той стороне
Про скорость спорить бессмысленно, она зависит от канала, а не от протокола. Разница архитектурная.
HTTP-прокси работает на уровне приложения. Он читает запрос, видит URL, заголовки, умеет кэшировать ответы и подменять их. Это удобно для веб-задач и одновременно означает, что сервер на той стороне знает про ваш трафик больше, чем хотелось бы. Авторизация там простая, как дверь в подсобку.
SOCKS5 работает ниже, на уровне TCP-соединения. Он не разбирает, что именно вы передаёте, просто устанавливает канал между клиентом и целевым адресом. Меньше служебных заголовков - ниже задержка на каждом запросе, а при тысяче мелких запросов из парсера это складывается в ощутимую разницу. SOCKS5 умеет UDP, а значит корректно работает с современными протоколами поверх UDP, которые сейчас использует половина мобильных приложений. Для сбора данных, работы с API и мультиаккаунтов я почти всегда выбираю SOCKS5.
MTProto - отдельная история, это протокол Telegram. Он рассчитан на мобильные сети с нестабильным каналом, быстро переподключается и меньше страдает от потери пакетов. Для мессенджера это идеальный вариант, для остального трафика он не предназначен.
Telegram: прокси ставится внутри приложения, а не в Android
Здесь многие путаются, потому что системная настройка Wi-Fi на Telegram не действует вообще. Мессенджер держит собственный стек соединений и ходит по своим правилам. Настройка живёт внутри него, и это, кстати, удобно: работает и на мобильном интернете.
Порядок действий в приложении:
- Открываете «Настройки».
- Раздел «Данные и память».
- Пункт «Прокси».
- «Добавить прокси».
- Выбираете тип: SOCKS5 или MTProto.
- Вписываете сервер, порт, при необходимости логин и пароль.
- Сохраняете и включаете переключателем.
Проверка простая: под аватаркой в списке чатов появляется плашка о подключении через прокси. Нет плашки - не подключилось, даже если переключатель горит зелёным. У Telegram бывает так, что настройка сохранена, но соединение не установлено, и он молча падает обратно на прямое подключение.
Важный нюанс для рабочих аккаунтов: прокси в Telegram применяется ко всем аккаунтам сразу. Разнести разные аккаунты по разным узлам внутри одного приложения нельзя, нужен либо второй профиль на телефоне, либо отдельный аппарат.
WhatsApp и браузеры: кто наследует системные настройки, а кто нет
WhatsApp на Android своего пункта прокси не имеет. Он наследует системную настройку Wi-Fi, а на мобильном интернете идёт напрямую. Значит, на LTE для него остаётся только вариант с локальным VPN-клиентом, о котором писал выше. В настройках самого WhatsApp искать нечего, там этого пункта нет и не появится.
Firefox на Android умеет собственный прокси. Настраивается через служебную страницу about:config: параметр типа соединения, адрес HTTP-сервера, адрес HTTPS-сервера и флаги использования для каждого из них. Chrome на Android своей настройки не имеет, он берёт системную и всё. Для большинства задач этого достаточно, но помните: Chrome и WebView внутри приложений системный прокси уважают, а вот приложения с собственными сетевыми библиотеками - не всегда.
Три ошибки, на которых я потерял больше всего времени
Первая - проверка «на глаз». Человек включает прокси, видит, что интернет работает, и успокаивается. А адрес на выходе остался прежним. Проверять нужно всегда через сервис определения IP и только в том приложении, для которого настройка делалась. Работающий браузер ничего не доказывает.
Вторая - DNS. Даже когда трафик идёт через прокси, запросы на разрешение имён могут уходить напрямую к провайдеру. На уровне телефона это почти не видно, а на стороне сервиса вы получаете несоответствие гео и странные капчи. Если работаете с чувствительными к геолокации сервисами, проверьте отдельно, какой DNS фактически используется.
Третья - HTTPS и подмена сертификатов. Некоторые схемы требуют установки корневого сертификата на устройство, иначе приложение просто не примет соединение. На Android 7 и выше пользовательские сертификаты по умолчанию не доверяются приложениям, нужно либо править манифест, либо ставить сертификат в системное хранилище, что без root не выйдет. Если задача не требует разбора содержимого трафика, а нужен только выход с другого адреса, эта возня вообще не нужна.
Как выбрать прокси, если задачи мобильные
Для телефона критерии отличаются от десктопа. Первое - гео. Мобильные приложения часто отдают разный контент в зависимости от страны, и проверять это с датацентрового адреса бессмысленно: сервис быстро понимает, что за ним не живой пользователь, и показывает заглушку либо режет запросы. Мобильные и резидентные адреса в этом смысле честнее, они выглядят как обычные абоненты.
Второе - тип и стабильность канала. Для сбора данных по расписанию нужна предсказуемость: если узел отваливается каждые десять минут, половина выгрузки будет битой, а вы потратите вечер на разбор логов. Третье - лимиты трафика и тарификация. Парсинг с телефона незаметно съедает гигабайты, особенно если в запросах летят картинки.
Каталог прокси 3seller.com/proxy удобен тем, что фильтры сразу режут выборку по стране, типу адреса и способу ротации, а не заставляют читать простыню описаний. Я обычно начинаю с мобильных под гео-тесты и с резидентных под долгую работу с аккаунтами, а датацентр оставляю для задач, где важна только скорость и объём.
Проверка перед работой: короткий ритуал
Первое. Отключите мобильный интернет, оставьте только Wi-Fi. Системная настройка на сотовую сеть не действует, и половина странных результатов именно оттуда.
Второе. Переподключитесь к сети после сохранения. Третье. Откройте сервис определения IP в том приложении, где планируете работать, и сверьте страну и город. Четвёртое. Сделайте один тестовый запрос в целевом сервисе и посмотрите на реакцию: капча, 403 или нормальный ответ скажут больше, чем любой лог.
Пятое. Запишите, для какой Wi-Fi сети настройка сделана. Через неделю вы забудете, а телефон будет вести себя «странно» в другой сети, и разбираться придётся заново.
Начните с одного телефона и одной сети, доведите до стабильного результата, и только потом тиражируйте на остальные аппараты. Схема простая, ловушки все на поверхности, а времени она экономит столько, что после третьего раза вы будете настраивать её за две минуты, стоя в аэропорту, с чужим телефоном в руках.