Вчера парсер работал, сегодня половина запросов уходит с домашнего адреса. Или так: купил прокси, вбил данные в настройки, открыл сайт проверки, а там твой родной IP. Знакомая картина.
Проверка настроек прокси - это не одна кнопка. Тут три уровня, и валить их в кучу нельзя: настройки операционной системы, настройки конкретного браузера или приложения и то, что реально видит удалённый сайт. Ломается обычно что-то одно, а симптомы всегда одинаковые - «не работает».
Разберу по порядку, с шагами и с граблями, на которые сам наступал не раз.
Сначала выясни, какой адрес видит сайт
Перед тем как лезть в дебри настроек, нужна точка отсчёта. Открой любой сервис, который показывает IP в открытом виде, запомни адрес. Дальше включай прокси и обновляй страницу с очисткой кэша (Ctrl+F5). Адрес должен поменяться.
Если он остался прежним, вопрос уже не в том, правильно ли введён пароль, а в том, доходит ли трафик до узла. Причин три: настройки не применились, приложение их игнорирует, узел не отвечает.
Отдельная ловушка - IPv6. Сайт может отдавать адрес версии 6, который идёт мимо туннеля, потому что тот настроен только под IPv4. Выглядит как «прокси не работает», хотя он работает, просто не для всего трафика. Проверяй на сервисе, который показывает оба стека, и сравнивай именно тот, который тебе нужен.
Ещё момент, который пропускают. Совпадение гео - это не гарантия. Узел в Германии вполне может отдавать адрес голландской подсети, если у провайдера там пул. Смотри не на город, а на то, что адрес не твой и он стабилен между запросами.
Windows 10 и 11: где именно лежат настройки
Путь короткий: Параметры, Сеть и Интернет, Прокси. Там три блока, и каждый умеет перебивать остальные.
Первый - автоматическое определение параметров. Галочка включает поиск конфигурации в локальной сети. В домашней сети и в большинстве офисов искать нечего, а висит поиск долго и иногда роняет соединение. Если своего сервера автонастройки у тебя нет, галочку лучше снять.
Второй - скрипт настройки (PAC-файл). Если в поле вбит адрес скрипта, он имеет приоритет над ручными настройками. Частая история: человек вводит host и порт, сохраняет, а трафик идёт по старому PAC-адресу, который остался от прошлой настройки или от корпоративного ноутбука. Поле надо очистить, а не просто оставить как есть.
Третий - настройка прокси вручную. Здесь галочка «Использовать прокси-сервер», адрес, порт и, если нужно, логин с паролем. Сверь символ в символ с тем, что написано в кабинете провайдера. Классика жанра - лишний пробел в конце скопированного пароля и полчаса диагностики. После ввода нажми «Сохранить» и перезапусти браузер целиком. Вкладки держат старые соединения и могут продолжать работать напрямую, хотя система уже переключилась.
Ниже есть поле исключений и галочка про локальные адреса. Если она стоит, запросы к localhost пойдут мимо прокси, и это нормально: локальные сервисы через внешний узел гонять бессмысленно. Список исключений заполняется через точку с запятой, без пробелов, иначе правило не сработает.
Брандмауэр, который тихо режет соединение
Windows Defender Firewall держит три профиля: общий, частный и доменный. Соединение может не идти только на одном из них, и это сбивает с толку. Дома всё работает, а в офисе тот же прокси молчит, потому что сеть определилась как доменная и правила другие.
Проверять просто: открой монитор брандмауэра и посмотри, есть ли заблокированные исходящие для твоего приложения - браузера, парсера, клиента. Полностью отключать защиту на постоянной основе не стоит, лучше добавить правило для конкретного exe и конкретного порта.
Деталь, которую мало кто ждёт. После крупного обновления Windows профиль сети иногда перескакивает с «частной» на «общедоступную». Правило остаётся, но перестаёт применяться, и соединение умирает без единой ошибки в интерфейсе. Если прокси работал месяцами и резко перестал, посмотри профиль сети первым делом.
Браузеры живут отдельной жизнью
Chrome и Edge по умолчанию берут системные настройки, так что после правок в Windows их достаточно перезапустить. Firefox устроен иначе, и это источник половины путаницы.
У него свой раздел: Настройки, Основные, в самом низу Настройки сети, кнопка «Настроить». Там три режима: без прокси, использовать системные настройки, ручная настройка. Если стоит «без прокси», система может быть настроена идеально, а Firefox будет ходить напрямую. И наоборот: в браузере прописан старый узел, в системе новый, и ты смотришь на разные IP в двух окнах и не понимаешь, кому верить.
Расширения перекрывают всё. Любой менеджер прокси в виде плагина имеет собственный приоритет и свои профили. Перед диагностикой отключи такие расширения полностью, а не просто переключи профиль. Конфликт двух плагинов между собой выглядит как «настройки слетают сами».
И ещё про кэш. Некоторые сайты отдают адрес из кэша или из сервис-воркера. Проверяй в приватном окне, это дешевле, чем искать несуществующую проблему.
Android: прокси спрятан в настройках Wi-Fi
На телефоне настройки привязаны к конкретной сети, а не к устройству. Путь такой: Настройки, Wi-Fi, долгое нажатие на сеть, Изменить сеть, Дополнительные параметры, Прокси. Значение «Нет» означает прямое подключение, «Вручную» открывает поля host и порт.
Если телефон пишет ошибку при подключении к Wi-Fi, первым делом проверь именно этот пункт. Мобильный интернет настройки Wi-Fi не использует, там всё задаётся в параметрах точки доступа, и после сброса настроек сети они слетают до заводских.
Нюанс: на Android часть приложений игнорирует системный прокси и ходит своим транспортом. Проверка через браузер покажет одно, а приложение будет работать совсем иначе. Для диагностики это нормально, для постоянной работы - повод смотреть в сторону клиента с поддержкой SOCKS5.
Ошибка «не удалось автоматически обнаружить параметры прокси»
Сообщение появляется, когда система пытается найти конфигурацию в сети и не находит. Причин обычно четыре.
Первая - включён автопоиск, а сервера автонастройки в сети нет. Лечится снятием галочки автоматического определения.
Вторая - битый или недоступный PAC-файл. Скрипт может лежать на сервере, который выключен, или содержать синтаксическую ошибку. Проверяется открытием адреса скрипта в браузере: если он не отдаётся, настройка мертва.
Третья - постороннее ПО. Вредоносные расширения и «оптимизаторы» любят прописывать свой прокси, чтобы гнать трафик через чужой узел. Симптом: настройки возвращаются после каждой перезагрузки, сколько бы раз ты их ни менял. Смотри ветку Internet Settings в реестре текущего пользователя, сверяй значения с тем, что вводил сам, и прогоняй полную проверку антивирусом.
Четвёртая - хвосты от VPN-клиента. Часть таких программ при кривом завершении оставляет системные настройки за собой. Помогает переустановка клиента или сброс сети в параметрах Windows.
Проверка из командной строки быстрее любых кликов
Когда непонятно, где сломалось, помогает один запрос из терминала. Утилита curl умеет ходить через прокси напрямую и показывает код ответа, а код ответа - это уже диагноз.
Смысл в том, чтобы отделить транспорт от приложения. Если curl через прокси возвращает чужой адрес, значит до узла есть связь, авторизация прошла, и проблема сидит в браузере, расширении или конкретной программе. Если вместо ответа таймаут, вопрос к узлу или к сети.
Расшифровка кодов, которые видишь чаще всего. 407 - прокси требует авторизации, логин с паролем не подошли или не передались. 403 - тебя не пускают, обычно при авторизации по IP адрес не внесён в белый список в кабинете. 502 и 504 - узел живой, но upstream за ним не отвечает, это уже сторона провайдера. Медленные ответы на 5-10 секунд при нормальном коде говорят о перегруженном узле, а не о твоих настройках.
Полезно посмотреть системную конфигурацию без графики: команда netsh winhttp show proxy покажет, что видит служба WinHTTP. Расхождение с тем, что в параметрах, объясняет странности у программ, которые ходят не через браузерный стек.
Что показывает проверка на уровне протокола
SOCKS5 работает на уровне сессии: клиент договаривается с узлом, тот устанавливает соединение к цели, дальше пакеты идут через туннель. Для диагностики важно, что протокол отдаёт разные коды на этапе рукопожатия. Отказ на авторизации и отказ на соединении с целью - это разные ошибки, и в логах клиента они выглядят по-разному.
HTTP-прокси проще: он видит конкретный запрос и может ответить кодом прямо в браузер, поэтому в вебе диагностируется легче. Для парсинга и балансировки чаще берут SOCKS5, потому что он не трогает содержимое пакетов и меньше влияет на задержку.
Если узел свой, проверять надо с двух сторон
Когда прокси поднят на собственном сервере, настройки клиента - это половина картины. Вторая половина - сам сервер: слушается ли порт, открыт ли он в фаерволе, не упёрся ли в лимит одновременных соединений.
Быстрая последовательность: проверь, что сервис запущен и слушает нужный порт, затем что порт доступен снаружи, затем что авторизация настроена. Ошибка на любом шаге даёт одинаковый симптом на клиенте - таймаут.
Telegram и мессенджеры: отдельный туннель
В Telegram Desktop настройки живут отдельно от системы: Настройки, Продвинутые, Тип подключения, Прокси. Добавляешь узел, вводишь host и порт, при необходимости логин с паролем по SOCKS5, сохраняешь и включаешь. Проверка: внизу списка появится отметка подключения и задержка в миллисекундах, а в свойствах узла видно, сколько трафика через него прошло.
Если задержка растёт до тысяч или соединение рвётся, дело не в настройках, а в узле или канале. Полезно сравнить два узла в разное время суток, картина становится очевидной.
Для спокойной работы в публичной сети Wi-Fi логика та же: сначала убедись, что системные настройки чистые, потом поднимай туннель через свой узел или корпоративный шлюз, а не через случайный публичный сервер из объявления.
Настройки слетают сами, и это не магия
Если параметры возвращаются к прежним после перезагрузки, ищи не в браузере. Типичные виновники: вредоносное ПО, «чистильщики» реестра, клиенты VPN, групповые политики на рабочем ноутбуке и корпоративные агенты безопасности.
На машине, выданной компанией, настройки может диктовать политика домена, и менять их руками бесполезно. Проверяется просто: зайди под локальной учётной записью и посмотри, держатся ли правки. Держатся - дело в профиле или политике, не держатся - дело в системе.
Почему на бесплатном узле проверять приходится каждый день
Значительная часть проблем с настройками на самом деле не в настройках. Узел, который умер час назад, ведёт себя точно так же, как неправильно введённый порт. Бесплатные публичные прокси живут недолго, делятся на сотни людей, отваливаются по нагрузке и иногда подменяют содержимое страниц. Тратить час на перебор и сверку адресов выходит дороже, чем взять нормальный канал.
Когда настройки приходится проверять раз в неделю, а не раз в день, проще работать с провайдером, у которого понятные параметры подключения и предсказуемое поведение. Каталог прокси 3seller как раз про это: там сразу видно протокол, тип узла, гео, способ авторизации и формат сессии, без сюрпризов в духе «а этот порт только для HTTP».
На что смотреть при выборе, чтобы потом не гадать, где ошибка. Протокол: SOCKS5 не разбирает содержимое пакетов и держит любые типы трафика, HTTP работает только с вебом. Тип узла: датацентр быстрый и дешёвый, резидентные дороже и выглядят для сайтов как обычные пользователи. Авторизация: по логину и паролю проще в настройках, по IP удобнее для серверов без ввода пароля, но адрес сервера надо заранее внести в кабинет. Сессия: sticky держит один адрес для длинной цепочки действий, rotating меняет его на каждом запросе.
Практический смысл в том, что при таких параметрах проверка сводится к одной операции: сравнил адрес до и после. Всё остальное уже исключено на этапе выбора.
Что проверить, прежде чем писать в поддержку
Половина обращений в поддержку закрывается на первых двух пунктах. Пройди по списку, это занимает минуту.
- Адрес на сайте проверки совпадает с тем, что указан в кабинете провайдера, и он стабилен при обновлении страницы.
- Порт, логин и пароль скопированы без пробелов в начале и в конце.
- Автопоиск и PAC-файл отключены, если своего сервера автонастройки нет.
- Расширения-менеджеры прокси в браузере выключены полностью.
- Запрос из терминала через тот же узел проходит, а браузер молчит, значит дело в приложении, а не в прокси.
- Брандмауэр и антивирус не блокируют конкретную программу, профиль сети не сменился на общедоступный.
- На телефоне проверено именно в настройках Wi-Fi, а не в мобильной сети.
Дальше уже можно писать провайдеру, приложив код ответа и текст ошибки. С такой информацией отвечают по делу, а не «попробуйте перезагрузить».
Привычка, которая экономит вечер
Заведи правило: перед любой задачей, где важен адрес, прогоняй один тестовый запрос. Открыл сайт проверки, сравнил IP, закрыл. Пятнадцать секунд. Зато ты никогда не узнаешь о проблеме из письма «ваш аккаунт заблокирован» и не будешь потом восстанавливать логи цепочки, которая три часа шла с домашнего адреса.
Проверка настроек прокси - это по сути сравнение двух картинок: что ты настроил и что видит внешний мир. Как только расхождение локализовано до уровня (система, браузер, приложение, узел), починка занимает минуты. А нормальный провайдер с прозрачными параметрами убирает из этого уравнения самый нестабильный элемент.