Планшет купили, Wi-Fi раздали, а трафик упорно идёт с домашнего адреса. Знакомая история. Дальше начинается беготня по настройкам, где половина пунктов называется не так, как в чужой инструкции, а вторая половина спрятана на два экрана вниз. Разберу по порядку, как установить прокси на айпад, что вбивать в поля, чем системная настройка отличается от клиента и почему у некоторых после сохранения ровным счётом ничего не меняется.
Сразу к делу: iPadOS умеет прокси на системном уровне, но только для Wi-Fi. На сотовом подключении встроенной настройки нет вообще. Дальше либо конфигурационный профиль, либо приложение с собственным туннелем. Запомните эту развилку, она объясняет 90% вопросов в поддержке.
Системный прокси в iPad есть, но он привязан к конкретной сети
Речь не про костыль и не про сторонний софт. Настройка живёт в параметрах Wi-Fi сети, и трафик Safari, а также большинства приложений, идёт через указанный узел. Важная деталь, которую пропускают почти все гайды: параметр привязан к одной сети. Переключились на другую точку доступа или ушли в сотовую, прокси как не бывало. Настройка не слетела, она просто не применяется.
Отсюда практический вывод. Если планшет работает в двух офисах и дома, придётся либо настраивать каждую сеть отдельно, либо один раз поставить клиентское приложение, которое держит туннель независимо от того, к чему вы подключились.
Пошагово: включаем прокси через Wi-Fi
- Открываете «Настройки», заходите в «Wi-Fi» и подключаетесь к нужной сети.
- Нажимаете синий кружок с буквой «i» справа от названия сети.
- Листаете страницу до конца, находите раздел «HTTP-прокси» (в некоторых сборках подписан как «Настройка прокси»).
- Выбираете «Вручную».
- Заполняете поля «Сервер» и «Порт» данными из панели вашего провайдера.
- Если провайдер выдал логин и пароль, включаете тумблер «Аутентификация» и вводите их.
- Нажимаете «Сохранить» в правом верхнем углу.
Всё. Дальше система сама подхватит параметры, перезагружать планшет не нужно. Проверка занимает десять секунд: открываете Safari, идёте на любой сервис определения IP и смотрите, чей адрес показывает.
Что именно вписать в «Сервер» и «Порт»
В поле «Сервер» идёт адрес или хост из личного кабинета. В «Порт» число, которое стоит рядом с ним. Тут начинается классическая ошибка: у одного и того же узла HTTP и SOCKS5 почти всегда висят на разных портах. Перепутали, и соединение отваливается по таймауту, причём без внятного сообщения об ошибке. iOS просто молча не грузит страницы, и вы полчаса ищете проблему в роутере.
Второй момент: не копируйте адрес вместе с портом в одну строку. Поле «Сервер» принимает только адрес, цифры после двоеточия система не распарсит и сохранит как есть, а потом будете гадать, почему не работает. И проверьте, что не прицепился пробел при вставке, это смешнее, чем кажется, но встречается постоянно.
Автоматический режим и PAC-файл: когда нужна выборочная маршрутизация
В том же разделе есть пункт «Автоматически». Здесь вводится не адрес с портом, а ссылка на PAC-скрипт, которую провайдер отдаёт вместе с доступом. Смысл в правилах: часть сайтов идёт через узел, остальное напрямую. Удобно, когда планшет используется и для рабочих задач, и для личного, а гонять весь трафик через удалённый сервер нет ни желания, ни смысла.
Типичный сценарий: маркетолог снимает гео-выдачу и проверяет рекламные кабинеты с нужной страны, но при этом сидит в том же планшете в корпоративной почте, которая к удалённому узлу привязана не должна быть вовсе. PAC решает это одной строкой правил. Минус тоже есть: скрипт нужно поддерживать, а при смене пула адресов обновлять ссылку. Для разовой задачи проще ручной режим.
Клиентское приложение: профили, правила и разрешение на VPN
Когда встроенных настроек мало, ставят клиент из App Store. Логика везде похожая. Открываете приложение, добавляете профиль, выбираете тип протокола, вводите адрес, порт и данные авторизации, сохраняете. Дальше самое интересное: правила. Можно направить через узел только Safari, только конкретное приложение или всё сразу, а остальное оставить напрямую.
При первом запуске приложение попросит разрешение на создание конфигурации VPN. Пугаться не стоит, это штатный механизм: без системного туннеля клиент не сможет перехватывать трафик приложений. Подтверждаете через Face ID, Touch ID или пароль устройства, и профиль активируется. Кнопка включения обычно синяя, выключение красное, всё как везде.
Зачем вообще платить за клиент, если есть системная настройка? Причины три. Первая: работа на сотовой сети, где встроенного прокси нет. Вторая: разные правила для разных приложений. Третья: несколько профилей под разные задачи с быстрым переключением между ними. Для одного Wi-Fi и одной задачи клиент избыточен.
Сотовая сеть: почему настройки Wi-Fi здесь бессильны
В iPadOS нет системного прокси для сотового подключения. Раздел привязан к интерфейсу Wi-Fi, и никакие танцы с бубном этого не изменят. Вариантов ровно два: конфигурационный профиль, который устанавливается как файл, или клиентское приложение с собственным туннелем.
Профиль удобен, когда устройств много и их настраивает один человек: раздал файл, установил, подтвердил, готово. Приложение удобнее для одного планшета, потому что переключение профилей и правила делаются в два тапа. Если планшет корпоративный и выдан сотруднику, профиль ещё и дисциплинирует: меньше шансов, что человек случайно отключит маршрутизацию и утащит рабочий аккаунт с чужого адреса.
SOCKS5 и HTTP: разница не в скорости, а в уровне работы
SOCKS5 работает на уровне сессии и не разбирает содержимое пакетов. Меньше накладных расходов, стабильнее задержка, нормально держит длинные соединения и UDP. HTTP-прокси понимает сам протокол, умеет заголовки и кэширование, но на потоковых задачах и вебсокетах ведёт себя капризнее.
Для парсинга, работы с API и десятков параллельных запросов берут SOCKS5. Для простых сценариев в браузере хватит HTTP. И да, порт под каждый протокол свой, это уже говорил, но повторю, потому что на этом спотыкаются чаще всего. На Reddit практикующие маркетологи в ветках про настройку мобильных узлов тоже советуют сразу помечать себе протокол рядом с портом, чтобы не путаться.
Как убедиться, что трафик действительно идёт через узел
Открываете Safari и любой сервис проверки IP. Видите адрес узла, а не свой домашний, значит всё работает. Видите свой, значит прокси не подхватился. Дальше по списку: не сохранили настройку, перепутали порт, сеть переключилась на сотовую, приложение не получило разрешение на конфигурацию VPN.
Есть второй, более честный тест. Отключаете Wi-Fi и повторяете проверку на сотовой сети. Адрес вернётся к исходному, и это нормальное поведение для системной настройки. Если хотите, чтобы адрес сохранялся и на мобильном интернете, вам нужен клиент или профиль, третьего не дано.
Пять причин, по которым ничего не заводится
- Порт взят от другого протокола, например от HTTP вместо SOCKS5.
- В поле «Сервер» вставили адрес вместе с портом или с лишним пробелом.
- Не включили аутентификацию, хотя провайдер требует логин и пароль.
- Планшет ушёл на другую Wi-Fi сеть или в сотовую, где настройка не применяется.
- Клиент не получил разрешение на создание конфигурации VPN и молча ничего не делает.
Отдельная история, которая не в списке: после крупного обновления iPadOS настройки сети иногда сбрасываются. Не часто, но бывает. Если вчера всё работало, а сегодня нет, первым делом загляните в раздел «HTTP-прокси» и убедитесь, что там всё ещё «Вручную», а не «Выключено».
Когда планшет превращается в рабочую станцию
Один iPad с одним статичным адресом закрывает базовые задачи. Другое дело, когда планшетов три, а задачи разные: снять выдачу поиска по нужному региону, проверить рекламный кабинет, посмотреть, как отображается карточка товара у конкурента в другой стране, протестировать приложение на мобильном соединении. Здесь один адрес уже не работает, нужен пул и ротация.
Для таких сценариев смотрят на мобильные и резидентские узлы, на поддержку липких сессий (когда адрес держится за вами определённое время, а не меняется на каждом запросе) и на объём трафика в тарифе. Липкая сессия критична для всего, где есть авторизация: если адрес меняется посреди сессии, вас просто выкинет из аккаунта, и это будет выглядеть как поломка сервиса, а не как ошибка настройки.
Если у вас собственный сервер на VPS или корпоративный узел, схема настройки на планшете точно такая же. Разница только в том, откуда берутся адрес и порт.
Где брать узел под конкретную задачу
Когда дело доходит до выбора, удобнее не собирать адреса по форумам, а открыть каталог и отфильтровать нужное. В каталоге прокси 3seller есть фильтры по стране, типу узла, протоколу и объёму трафика, так что под задачу с гео-тестами или парсингом подобрать вариант получается за пару минут, а не за вечер переписки.
Логика простая. Для проверки одного кабинета хватит одного статичного адреса. Для регулярного сбора данных и работы с несколькими аккаунтами нужен пул с ротацией и липкими сессиями. Для задач, где важна максимальная близость к реальному пользователю, смотрят в сторону мобильных. Покупать пакет на сотню адресов, чтобы раз в месяц зайти в рекламный кабинет, смысла ноль.
Мелочи, которые экономят вечер
Данные доступа сохраните в заметки или в менеджер паролей. Вводить длинный логин с планшета на весу, да ещё и с чувствительностью к регистру, то ещё удовольствие, а ошибка в одном символе выглядит как неработающий сервер.
Держите под рукой ссылку на PAC-скрипт, если используете автоматический режим. Провайдеры меняют пулы, и старая ссылка тихо перестаёт возвращать правила. Внешне всё то же самое: страницы грузятся, только адрес уже не тот, что вы ожидали.
И не настраивайте прокси в спешке перед встречей. Проверка занимает полминуты, зато потом не придётся объяснять заказчику, почему скриншот из нужного региона сделан с домашнего IP.
Начните с одного профиля Wi-Fi, проверьте адрес через Safari и только потом расширяйте схему: второй профиль, PAC-файл, клиент под сотовую сеть. Так вы хотя бы будете понимать, на каком шаге что сломалось, а не перебирать все настройки сразу.