Самая частая история: вчера всё работало, сегодня браузер выдаёт «Настроенный прокси-сервер не отвечает», и человек начинает лезть в дебри — переустанавливать браузер, менять DNS, читать форумы десятилетней давности. А причина в одном снятом флажке, который кто-то поставил случайно.
Я видел эту ошибку сотни раз в разных контекстах: у коллег на корпоративных ноутбуках, у парсеров, которые вдруг перестали собирать данные, у ребят, которые поднимают собственный узел на VPS. И почти всегда диагноз ставится за пять минут, если идти в правильном порядке. Порядок и разберу.
Сначала определите, кто виноват: сеть, клиент или сам узел
Прежде чем что-то менять, нужен один ответ: интернет работает без прокси или нет. Отключаете прокси в системе — если страницы открываются, значит, канал жив, а проблема в настройках клиента или в самом узле. Если и без прокси глухо, вы воюете не с прокси, а с сетью, и дальше идти смысла нет.
Второй быстрый тест — другой клиент. Браузер ругается, а Telegram через тот же узел спокойно отправляет сообщения? Значит, узел жив, а сломаны именно настройки в браузере или в системе. Такая развилка экономит час времени.
И третье: ошибка появляется на всех сайтах или на одном? Если только на одном — дело в самом сайте, а не в прокси. Банально, но люди на этом застревают.
Windows: отключите то, что прописал кто-то другой
В Windows 10 и 11 настройка живёт в двух местах, и это главная ловушка. Первое — современные «Параметры». Жмёте Пуск, начинаете печатать «прокси», открываете «Параметры прокси-сервера». Там два переключателя: «Использовать сценарий настройки» и «Использовать прокси-сервер». Снимаете оба, сохраняете, перезапускаете браузер.
Второе место — старый добрый аплет «Свойства браузера». Открывается через поиск по фразе «свойства браузера» либо через Панель управления — Сеть и Интернет — Свойства браузера. Вкладка «Подключения», кнопка «Настройка сети». Вот там и сидит та самая галочка, из-за которой всё падает.
Частая ситуация: старая корпоративная сеть оставила после себя сценарий автоматической конфигурации. Человек ушёл на удалёнку, а система по-прежнему лезет за конфигом на адрес, которого больше не существует. Ждёт ответа, не дожидается, выдаёт ошибку. Сняли галочку — всё поехало.
Отдельно про перезагрузку. Звучит как совет из 2005 года, но после смены системных настроек прокси Windows иногда держит соединение в кэше, и браузер продолжает стучаться по старому маршруту. Перезагрузка занимает минуту, а снимает половину ложных диагнозов.
Галочка «использовать прокси для локальных адресов» ломает больше всего
Если у вас в настройках стоит флажок «Не использовать прокси-сервер для локальных адресов» — не трогайте. А вот обратная ситуация, когда система гонит через прокси всё, включая 127.0.0.1 и внутренние адреса, встречается постоянно. Итог: браузер пытается отправить локальный запрос на внешний узел, узел его, естественно, не обслуживает, вы получаете ошибку и думаете, что умер прокси.
Посмотрите на список исключений. Пустой список — почти гарантированная проблема, если вы работаете с локальными сервисами, админками, тестовыми стендами. Добавьте локальные диапазоны в исключения, и часть ошибок исчезнет сама.
Та же история с расширениями-менеджерами прокси в браузере. Chrome и Firefox могут иметь своё расширение, которое перебивает системные настройки. Расширение выключено, а профиль остался — и браузер ведёт себя необъяснимо. Проверяется в три клика: отключить все расширения, связанные с сетью, и посмотреть, ушла ли ошибка.
Порт и тип прокси — источник половины ошибок «не отвечает»
Прокси не отвечает не потому, что умер, а потому что вы стучитесь не в ту дверь. HTTP-прокси на 8080, SOCKS5 на 1080, кто-то ставит 3128, кто-то 8888. Перепутали порт — получили таймаут и красивую ошибку.
Второй нюанс — тип. HTTP-прокси не умеет то, что умеет SOCKS5, и наоборот. Если в настройках браузера вы выбрали HTTP, а узел слушает SOCKS5, соединения не будет никогда. Проверять надо оба параметра одновременно: адрес и тип, адрес и порт. Копипаст из письма с настройками — худший враг, там вечно прилипает лишний пробел или цифра из соседней строки.
Отдельный класс проблем — авторизация. Прокси требует логин и пароль, а клиент их не отправляет или отправляет устаревшие. Код ответа в таких случаях отличается от таймаута, но браузер показывает пользователю всё то же «не отвечает». Если у вас сменился пароль на узле, а в браузере остался старый — вы будете ловить эту ошибку до посинения.
У себя в практике я выработал простое правило: любые настройки прокси проверяю на чистом профиле браузера. Новый профиль без расширений и кэша. Если там работает, а в основном нет — проблема в клиенте, а не в узле. Это дешевле, чем полчаса гадать.
Антивирус, файрвол и второй прокси в цепочке
Почти все современные антивирусы лезут в сетевой трафик. У некоторых есть собственный модуль проверки HTTPS, который работает как промежуточный прокси. Ставите сверху ещё один прокси — и два перехватчика начинают спорить друг с другом. Результат: соединение рвётся, браузер сообщает, что прокси не отвечает.
Диагностика простая: отключите сетевой экран антивируса на пять минут. Не удаляйте, не сносите — просто приостановите защиту и повторите запрос. Заработало — значит, надо не отключать навсегда, а добавить адрес узла в исключения и выключить перехват HTTPS для этого направления.
Второй прокси в цепочке — отдельная песня. VPN плюс прокси одновременно, прокси в системе плюс прокси в браузере, прокси в браузере плюс прокси в расширении. Каждый следующий уровень думает, что говорит с предыдущим, а на деле трафик уходит в никуда. Виноват всегда последний добавленный элемент. Правило простое: один уровень, один прокси. Проверили — добавили следующий.
Вредоносное ПО тоже никто не отменял. Есть категория программ, которая молча прописывает свои настройки соединения в систему, чтобы гнать трафик через чужой узел. Симптом ровно тот, что мы разбираем: ошибка появляется сама, без вашего участия, часто после установки какой-то «оптимизации» или кряка. Лечится полной проверкой антивирусом плюс ручным просмотром параметров соединения в системе. Если видите там незнакомый адрес, который вы не вводили — это красный флаг.
Проверка самого узла: жив ли он вообще
Дальше стоит убедиться, что узел существует и принимает соединения. Самый честный способ — проверить порт извне. Сделать это можно через терминал (команда проверки TCP-порта), через онлайн-чекер доступности портов или через сам сервис, который вам этот прокси выдал. Если порт закрыт — дальше обсуждать нечего, вопрос к владельцу узла.
Типичные причины недоступности на стороне сервера: плановое обслуживание, обновление компонентов, закончился оплаченный период, исчерпан лимит одновременных подключений, сработала защита от слишком частых запросов. Последнее особенно любят парсеры: скрипт влетает тысячью соединений, узел включает ограничитель, и все последующие запросы получают отказ. Со стороны клиента это выглядит как «прокси не отвечает».
Если узел ваш собственный, на VPS, смотреть надо в логи сервиса и в состояние службы. Классика: процесс упал после обновления пакетов и не поднялся. Или файрвол на самом сервере закрыл порт после перезагрузки. Или вы в панели управления облаком не открыли порт в правилах сетевой безопасности — тогда снаружи он просто не виден, хотя внутри всё прекрасно работает.
Ещё один момент для собственных узлов: лимит соединений и размер буферов. При аккуратной нагрузке всё живо, при параллельном парсинге в двадцать потоков узел начинает отваливаться по таймауту. Лечится не настройками клиента, а балансировкой и пулом адресов.
Браузеры: где именно смотреть в Chrome, Firefox и Edge
В Chrome и Edge настройки прокси вынесены в системные. Открываете меню, идёте в настройки, разворачиваете дополнительные, находите раздел системы и нажимаете кнопку открытия настроек прокси компьютера. Дальше вы попадаете в то самое окно Windows, о котором я писал выше. То есть браузер своего прокси не имеет, он целиком зависит от системы.
Firefox — исключение. У него исторически своя настройка в разделе «Сеть» в параметрах. И это порождает конфликт: в системе прокси выключен, в Firefox включён, и человек искренне не понимает, почему ошибка только в одном браузере. Проверяйте оба места, если пользуетесь разными браузерами под разные задачи.
Мобильные браузеры и приложения берут настройки из системы телефона. Android: Wi-Fi — нужная сеть — дополнительные параметры — прокси, там ручной режим с адресом и портом. iOS: настройки Wi-Fi, блок прокси, режим вручную. Если в приложении ошибка, а в браузере на том же телефоне всё открывается, смотрите настройки внутри самого приложения, они могут быть отдельными.
Telegram и WhatsApp: настройки интерфейса, без магии
В Telegram прокси настраивается внутри приложения: настройки, продвинутые, тип подключения, добавить прокси. Там выбирается протокол, вводятся адрес, порт и секрет для MTProto. Дальше кнопка проверки соединения — она честно показывает, отвечает узел или нет, что избавляет от гадания.
Главные грабли в интерфейсе: не тот тип протокола и лишний пробел при копировании секрета. Секрет для MTProto — длинная строка, и один потерянный символ превращает рабочий узел в нерабочий. Второй момент: несколько сохранённых профилей, и приложение пытается использовать выключенный. Удалите всё лишнее, оставьте один активный.
В WhatsApp отдельной настройки прокси в самом приложении нет, он наследует системный. На Android это делается через параметры Wi-Fi сети, на iOS — там же в настройках сети. То есть чинить надо не WhatsApp, а систему.
И ещё: интерфейс проверки соединения во многих приложениях врёт в мелочах. Он проверяет доступность узла, но не проверяет, что трафик через него реально идёт. Если статус зелёный, а сообщения не уходят, смотрите на системные настройки и на другие активные профили.
Когда вы работаете в публичной сети
Кафе, аэропорт, коворкинг. Сначала сеть требует авторизации на своей странице, и только потом пускает трафик. Прокси в этой схеме не работает вообще, пока вы не прошли вход на портале. Симптом: ошибка соединения на любых настройках. Решение — отключить прокси, пройти авторизацию, включить обратно.
Вторая проблема публичных сетей — закрытые порты. Администратор сети может резать всё, кроме 80 и 443. Ваш узел на нестандартном порту в такой сети просто не увидит запросов. Проверяется сменой порта на 443 у того же узла — если заработало, дело было в фильтрации.
И третье: в общественном Wi-Fi трафик без шифрования лучше не гонять. Если вы настраиваете соединение для работы с корпоративными системами или собираете данные через пул адресов, шифрование на уровне протокола — не опция, а базовая гигиена. Об этом ниже.
Что важно понимать в архитектуре: SOCKS5, HTTP и MTProto
Разница между протоколами объясняет половину загадочных ошибок. HTTP-прокси работает на уровне приложения и хорошо понимает веб-запросы, но с нестандартными протоколами у него беда. SOCKS5 работает на уровне сокетов, ему всё равно, что внутри, он просто гонит байты — поэтому его любят за универсальность.
С DNS отдельная история. Часть клиентов резолвит имена локально, а потом отправляет прокси уже готовый адрес. Часть просит узел резолвить сам. Если у узла нет доступа к DNS, вы получаете таймаут и стандартную ошибку, хотя сам прокси жив и порт открыт. В SOCKS5 за это отвечает отдельный флаг, и его стоит проверить в первую очередь, если рвутся именно именованные запросы, а по прямым адресам всё идёт.
Важно: у SOCKS5 нет шифрования пакетов. Трафик внутри туннеля не защищён, защита приходит сверху — через HTTPS, TLS или отдельный шифрованный слой вроде MTProto. MTProto в этом смысле интереснее: там шифрование встроено, а секрет в настройках как раз участвует в установлении сессии. Ошибка с секретом даёт ровно тот же симптом «не отвечает», хотя узел доступен.
В корпоративных сетях часто используют схему с балансировкой пула: несколько узлов, health-check, автоматическое переключение при отказе. В такой архитектуре периодические отказы отдельных узлов — норма, а не авария. Клиент должен уметь переспросить через другой узел, а не показывать пользователю ошибку. Если ваша система этого не умеет, она будет «не отвечать» регулярно, и это вопрос проектирования, а не настроек.
Как выбрать узел, который не будет отваливаться
Большая часть проблем, с которыми ко мне приходят, растёт из одного корня: узел взят из бесплатного списка. Публичные списки — это лотерея. Сегодня адрес живой, завтра его выключили, послезавтра он уже в чёрных списках у кучи сервисов, а вы сидите и думаете, что у вас неправильный порт.
Бесплатные узлы живут часами. Их перегружают, на них висит чужой парсинг, их владельцы пропадают. Если вы настроили соединение и оно перестало работать через сутки — это не ваша ошибка и не ошибка Windows. Это свойство бесплатного сегмента.
Для рабочих задач я смотрю на три вещи: стабильность аптайма, наличие протокола, который мне нужен (SOCKS5 или HTTP), и возможность быстро заменить узел, когда он выйдет из строя. Нормальный каталог с фильтрами по стране, протоколу и типу ротации закрывает вопрос за пару минут. Смотрю обычно в каталог прокси — там есть и SOCKS5, и HTTP, и варианты под мобильные и резидентные задачи, с понятными условиями вместо кота в мешке.
И обязательно проверяйте узел до того, как зашивать его в скрипт или в настройки браузера. Любой нормальный сервис даёт возможность протестировать соединение. Десять минут проверки экономят три часа поиска причины, которой нет.
Если вы берёте пул под парсинг, добавляйте health-check со стороны клиента: раз в несколько минут пробный запрос, при неудаче — замена узла и повтор. При аккуратной схеме пользователь вообще не замечает, что один из адресов выпал.
Если ошибка возвращается снова и снова
Бывает, что все шаги пройдены, ошибка ушла, а через день вернулась. Тут три частые причины. Первая — настройки сбрасываются программой. Вторая — обновление системы перезаписало параметры и вернуло схему автоконфигурации. Третья — сам узел нестабилен, и вы просто ловите его падения.
Проверить легко. Запишите, что было в настройках в момент, когда всё работало. Не поленитесь, сохраните скриншот. При следующем сбое сравните — расхождения сразу покажут, кто вмешался. Пять секунд на скриншот, а сколько раз выручает.
И отдельно про частоту. Если один и тот же узел отваливается раз в несколько дней, менять настройки бессмысленно. Надо менять узел. Настройки не лечат железо и перегруженный канал.
Быстрый порядок действий, который работает
Сначала выключите прокси в параметрах Windows и перезагрузитесь. Интернет вернулся — значит, проблема в настройках или в узле, а не в сети. Затем зайдите в свойства браузера, вкладка подключений, и проверьте, что не висит старый сценарий автоматической конфигурации и галка на локальных адресах. Дальше сверьте тип протокола, адрес и порт с тем, что вам выдали — посимвольно, без копипаста из мессенджера. Потом на пять минут отключите сетевой модуль антивируса. Если ничего не помогло, проверьте порт извне — и, если он закрыт, идите к владельцу узла или меняйте узел.
В девяти случаях из десяти этой последовательности хватает. Остальное — либо сломанный узел, либо архитектурная проблема, которую настройками клиента не решить. И если вы устали от второго варианта, начните с нормального пула адресов, а не с очередной переустановки браузера. Каталог прокси для этого и существует.