Купил прокси, вставил адрес и порт в настройки, нажал сохранить - и тишина. Или соединение поднимается, но через десять минут отваливается. Или всё зелёное, а нужный сайт упорно показывает капчу и просит подтвердить, что вы не робот. За последние годы я прошёл через это десятки раз. Причина почти всегда одна: дело не в самом прокси, а в слое вокруг него.
Сервер ломается редко. Чаще виноват конфиг, репутация адреса, тип пула или несовпадение протоколов. Ниже двенадцать слоёв, на которых сыпется подключение, - от самого очевидного до того, о котором вспоминают последним.
Настройки слетают чаще, чем принято думать
Самая частая причина - пустая строка там, где вчера был рабочий адрес. Звонят: прокси перестал работать, вчера всё было нормально. Захожу на машину, смотрю - в системе прокси вообще не прописан. Пусто. Или стоит старый адрес из прошлого месяца.
Причина обычно в том, как завершилась предыдущая сессия. Внезапное отключение электричества, принудительное выключение Windows, зависшая система, которую вынесли кнопкой питания. При таком сценарии часть системных служб не успевает корректно закрыться, и настройки соединения теряются. Особенно если ИБП нет и в офисе периодически моргает свет.
Системные службы при зависании операционки отключаются неаккуратно, вместе с ними уезжает часть сетевых параметров. Лечится не молитвой, а нормальным ИБП и привычкой держать профиль подключения в отдельном файле. Восстановление тогда занимает два клика, а не полчаса воспоминаний, какой там был порт.
Порт молчит: мёртвый прокси или кривой конфиг
На Reddit в тредах про прокси регулярно всплывает одна и та же история: адрес пингуется, а прокси не работает. Человек поднял сервер, сервис вроде жужжит, но клиент не подключается и в панели ничего не видно. Половина таких тредов заканчивается одинаково - дело было не в провайдере, а в том, что сервис не слушал нужный порт или его резал файрвол.
Порядок проверки простой, экстрасенсорика не нужна. Первое - убедиться, что прокси-сервис реально запущен. Второе - посмотреть, слушает ли он тот порт, который прописан в клиенте. Третье - проверить, что до порта есть доступ снаружи и его не блокирует локальный файрвол или правила хостинга.
Самый быстрый способ отсечь догадки - постучаться на связку адрес плюс порт обычным телнетом. Ответ есть - на той стороне что-то живое и слушает. Нет ответа - идите в логи сервера и клиента, там обычно написано прямым текстом, что именно не так. Люди пропускают этот шаг и сразу пишут провайдеру гневное письмо, хотя проблема на своей стороне.
Репутация адреса - то, чего нет в описании тарифа
Вот главное, что я объясняю каждому, кто первый раз берёт прокси для работы с маркетплейсами или сбора данных. У каждого IP есть история. Крупные сайты давно собирают поведенческие сигналы: к какому диапазону относится адрес, в какой автономной системе он живёт, были ли по нему жалобы на злоупотребления, как выглядит картина трафика, есть ли следы автоматизации.
Отсюда неприятный вывод. Прокси может быть технически абсолютно исправным - пинг низкий, порт открыт, рукопожатие проходит - и при этом сайт будет его резать. Адрес унаследовал репутацию предыдущих пользователей. Вы ничего не нарушали, просто достался номер, на который уже висит пара жалоб.
«Не работает» и «не подключается» - два разных диагноза. В первом случае соединение есть, но дальше не пускают. Во втором не поднимается даже канал. Лечатся они по-разному, и путать их - самая дорогая ошибка в теме.
Дешёвый пул - один адрес на тысячу рук
Дешёвая инфраструктура почти всегда строится по принципу количества, а не качества. Экономят на всём: маршрутизация нестабильная, аптайм скачет, пулы адресов перепродаются. Нередко один и тот же адрес уходит сразу нескольким сотням клиентов.
Дальше цепная реакция. С одного диапазона одновременно работают десятки аккаунтов. Кто-то из соседей по пулу занимается спамом или гоняет агрессивный скрипт. Сайт видит подозрительные паттерны автоматизации, помечает диапазон и начинает резать всех, кто из него приходит. Вы достали чистый аккаунт, ничего не нарушили, но попали под общую метлу.
Отсюда правило, которое я вывел на своей шкуре: если цена за килограмм адресов в три раза ниже рынка, вы покупаете не прокси, а лотерейный билет. Иногда повезёт. Планировать на этом процесс с задачами на месяц вперёд - так себе идея.
Резидентные, датацентровые, мобильные: разница в поведении
Тип адреса влияет на то, как вас видят. Датацентровые диапазоны легко вычисляются по принадлежности к хостинг-провайдеру. Резидентные выглядят как обычный домашний интернет, поэтому доверия к ним больше, и живут они заметно дольше там, где нужна человеческая маска.
Мобильные адреса - отдельная категория. Они сидят за операторским NAT, и на одном адресе могут одновременно висеть сотни реальных людей. Сайты относятся к ним мягче, но ведут они себя непредсказуемо: сессия может переехать на другой адрес в любой момент.
Под каждую задачу нужен свой тип. Для сбора открытых данных с простых сайтов хватит датацентра. Для аккаунтов, соцсетей и всего, где важна репутация, смотрите в сторону резидентных. Поставили датацентр туда, где ждут живого пользователя, - не удивляйтесь капче. Прокси работает, просто вы выбрали не тот инструмент.
Протокол не совпал: SOCKS5, HTTP, MTProto
Ещё один слой, на котором всё ломается. Прокси - это не одна технология, а набор протоколов с разной архитектурой. HTTP-прокси работает с веб-трафиком, и на этом всё. SOCKS5 не влезает в содержимое, зато прокидывает произвольные TCP-соединения и умеет в аутентификацию. MTProto - отдельная история с шифрованием пакетов на уровне протокола.
Люди берут SOCKS5, вставляют в поле, которое ждёт HTTP, и получают отказ. Или наоборот. Или ставят прокси без поддержки UDP, а приложение без UDP работать не хочет. Технически сервер живой, но с конкретным клиентом он несовместим, и никакие пляски с бубном этого не изменят.
Смотрите, какой протокол поддерживает клиент, и сверяйте с тем, что продаёт провайдер. Звучит банально, но процентов двадцать обращений в поддержку - именно про это.
Клиентская сторона: где именно нажимать
В большинстве браузерных сборок настройка живёт в разделе с сетью: параметры системы, потом прокси, потом ручная настройка и поля под адрес и порт. В корпоративных сборках раздел часто закрыт политикой, и сколько ни вводи - не применится, потому что админ выставил принудительный конфиг. Проверяется за минуту: если поле неактивно или после сохранения значения откатываются, дело не в прокси.
В Telegram настройки лежат в разделе с данными и хранилищем, там же пункт про прокси и кнопка добавить. Дальше выбираете тип, вводите адрес, порт, при необходимости логин с паролем и жмёте подключиться. Ключевой момент - Telegram умеет и MTProto, и SOCKS5, но не со всем подряд, и при неверном типе просто покажет, что соединение не установлено, без подробностей.
В WhatsApp история другая. Приложение не умеет в прокси само по себе и опирается на системные настройки. На iOS это раздел Wi-Fi, где для текущей сети включается ручной прокси и вбиваются адрес с портом. На Android настройки живут в параметрах сети, но зависят от прошивки. Если в системе прокси не прописан, WhatsApp будет ходить напрямую, и настройки внутри мессенджера этого не изменят.
Публичный Wi-Fi в кафе и аэропортах добавляет свой слой. Трафик там удобно заворачивать в собственный корпоративный узел или VPS, чтобы не светить рабочие данные в чужой сети. И тут же всплывает классика: настроили, а не работает. В половине случаев виноват портал авторизации, который перехватывает первый запрос и не пускает дальше, пока вы не нажмёте принять условия. Прокси при этом исправен.
Ошибка 407 и прочая авторизация
Прокси с логином и паролем - отдельный жанр. Соединение устанавливается, но сервер отвечает требованием авторизации. Классический код 407 означает, что вы не передали учётные данные или передали их не в том виде.
Причин две. Первая - клиент не умеет в базовую авторизацию и молча отбрасывает логин с паролем. Вторая - вы скопировали пароль с лишним пробелом в конце, и он не совпал. Звучит смешно, пока не увидишь такое в третий раз за неделю.
Проверка простая: подставьте те же данные в curl или в другой клиент, который точно умеет в авторизацию. Если там всё проходит, а в вашем приложении нет - вопрос к приложению, а не к прокси.
Сессия рвётся: sticky и ротация
В работе с аккаунтами критична стабильность сессии. Если адрес меняется на каждом запросе, сайт видит, что пользователь скачет по половине страны за минуту, и реагирует предсказуемо. Для сбора данных ротация полезна, для авторизованных сценариев - губительна.
Нормальный провайдер даёт выбор: держать один адрес закреплённым на определённое время или крутить пул. Проблемы начинаются, когда в тарифе этого выбора нет и вы получаете случайную ротацию там, где она не нужна. Формально прокси работает, а по факту половина запросов улетает в капчу.
Провайдерская сторона: иногда настройки просто бессмысленны
Бывает и так, что проблема вообще не в конфиге. Если провайдер не предоставляет услугу подключения через прокси, настраивать там нечего. Не потому что вы что-то не то ввели, а потому что на стороне сети это не поддерживается.
Отдельный случай - временные работы на стороне сервиса. Обновление компонентов, плановое обслуживание, миграция узла. В такой момент прокси не отвечает не из-за вас, и лучшее, что можно сделать, - подождать или переключиться на резервный узел, а не перебирать настройки в панике.
Нормальный каталог экономит именно этот шаг: видно, что с узлом и чем его заменить. Держу под рукой каталог прокси - сравнил типы, гео и протоколы, поменял выпавший узел за минуту.
Маршрутизация и задержка: работает не значит работает быстро
Формально всё в порядке: соединение есть, страница открывается. Но каждый запрос идёт секунды, скрипт отваливается по таймауту, а вы грешите на код. А пакет до цели едет через три страны и упирается в узкое место на одном из хопов.
Тут важна нормальная маршрутизация и балансировка. Хороший провайдер держит пул и раскидывает нагрузку, чтобы сессии не сидели на одном перегруженном узле. Плохой просто выдаёт список адресов и умывает руки.
Проверить легко: погоняйте один и тот же запрос через разные узлы и сравните время ответа. Разброс в десять раз - это не интернет медленный, это конкретные проблемные узлы, которые надо убрать из ротации.
Гео и часовой пояс тоже проверяются
Купили немецкие адреса, а браузер отдаёт московское время и русскую локаль. Для сайта это несостыковка: адрес говорит одно, отпечаток браузера другое. Итог - повышенное внимание и лишние проверки.
Согласовывайте мелочи: часовой пояс, язык интерфейса, кодеки. Звучит как паранойя, но именно на этих деталях сыпется работа с аккаунтами у людей, которые дошли до правильного типа прокси, но остановились на полпути.
Порядок проверки, который экономит часы
Когда у меня в очередной раз не работает, я иду по списку сверху вниз и почти всегда нахожу причину на первых трёх шагах.
- Смотрю, что настройки на месте и не слетели после последней перезагрузки.
- Стучусь на адрес и порт, чтобы понять, живой ли сервис вообще.
- Сверяю протокол: клиент и прокси должны говорить на одном языке.
- Проверяю, что видит сайт - открывается страница или сразу прилетает капча.
- Гоняю запрос через два-три разных узла и сравниваю отклик.
- Только после этого пишу в поддержку, уже с фактами на руках.
Шестой пункт важен отдельно. Когда в поддержку пишут «прокси не работает», ответить по делу невозможно. Когда пишут, что порт открыт, рукопожатие проходит, но конкретный сайт стабильно отдаёт 403 с трёх узлов из пяти - разговор идёт совсем иначе и заканчивается заменой пула, а не отпиской.
Как выбрать прокси, чтобы не разбираться в этом каждый месяц
Покупать надо не прокси, а понятную инфраструктуру под свою задачу. Смотрите на три вещи. Тип адресов и их происхождение: перепродают ли пулы, есть ли свежие диапазоны. Протоколы: SOCKS5 и HTTP должны быть в наличии, иначе упрётесь в несовместимость на ровном месте. Прозрачность: видно ли, что с узлом, можно ли быстро поменять и не ждать сутки.
Мне в работе удобно, когда под рукой каталог с фильтрами по стране, типу и протоколу, а не переписка с менеджером. Собственно, 3seller.com/proxy я и держу как рабочий инструмент именно поэтому: выбрал параметры, сравнил, взял. Без квестов.
Проверьте свой текущий пул по трём пунктам сегодня же: тип адресов, наличие SOCKS5 и HTTP, скорость замены узла. Если хотя бы один пункт не закрывается - вы нашли свою причину, и это не поломка сервера. Дальше либо меняете пул, либо перестаёте удивляться капче.