Ситуация знакомая до боли. Вписал данные прокси, нажимаешь «проверить», а в ответ тишина. Или браузер минуту думает и выдаёт ERR_PROXY_CONNECTION_FAILED. Вчера всё работало, а сегодня - нет.
За семь лет работы с прокси я собрал коллекцию причин, почему подключение рассыпается: от опечатки в порте до файрвола, который молча рубит соединение. На Reddit в тредах по сетевой диагностике повторяют одну мысль - прежде чем лезть в глубокие настройки, проверь, жив ли сам узел. Ниже рабочий порядок проверки от простого к сложному. В 70% случаев проблема сидит в первых трёх пунктах.
Первое: сервер вообще существует и он живой
Самая частая причина и самая обидная. IP, который ты вписал, либо не отвечает, либо уже не твой. Прокси, купленные на месяц, истекают. У некоторых провайдеров сессия привязана к белому списку IP: сменил домашний интернет или перезагрузил роутер с новым адресом - доступ отвалился. Ты сидишь и ждёшь подключения, а сервер тебя уже не пускает.
Проверить активность можно без танцев с бубном. Открой настройки аккаунта у провайдера и посмотри, не истёк ли срок и не заблокирован ли адрес из-за лимита. Если брал прокси в каталоге вроде 3seller.com/proxy, статус каждого узла видно в панели, а срок и привязка по IP отображаются сразу. Гадать, живо соединение или нет, не придётся.
Отдельно про опечатки. Порт вводят вручную, цифры на клавиатуре рядом, и один неверный символ убивает всё. Проверь посимвольно. Логин и пароль тоже вводятся руками, а регистр имеет значение. Многие копируют пароль из письма вместе с пробелом на конце - прокси такой пароль не примет и никакой ошибки об этом не покажет.
Формат авторизации: где чаще всего ломается
У прокси с авторизацией два способа передать логин и пароль. Первый - вписать их в отдельные поля в настройках. Второй - включить прямо в адрес: логин:пароль@ip:порт. Второй способ удобен, но именно в нём путаются чаще всего. Спецсимволы в пароле вроде @ или : ломают конструкцию, и клиент режет строку не там, где надо.
Если пароль сложный, проще использовать поля. Заодно проверь тип авторизации. Некоторые клиенты по умолчанию ставят Basic, хотя сервер ждёт Digest или NTLM. Соединение устанавливается, а потом отваливается на этапе проверки учётных данных. В логах это выглядит как «authentication failed», хотя логин и пароль абсолютно верные.
Браузер: там свои настройки, и они конфликтуют
Каждый браузер хранит настройки прокси отдельно. Firefox, Chrome, Яндекс.Браузер - у всех свой путь и свои нюансы. Плюс поверх сидят расширения, которые тоже лезут в прокси. Два инструмента, настроенных на разные узлы, дерутся между собой, и в итоге не работает ни один.
В Firefox зайди в «Настройки», открой вкладку «Основные», прокрути до раздела «Параметры сети» и нажми «Настроить». Там увидишь, что выставлено: ручная настройка, системные параметры или автоконфигурация. Если стоит автоконфигурация по PAC-файлу, а ты вписываешь прокси руками, браузер тебя не послушает. Поставь «Ручная настройка прокси» и введи данные заново.
Быстрый тест на виновника. Отключи прокси в браузере полностью и открой любой сайт. Страница грузится - значит сеть в порядке, и проблема именно в прописанных данных. Тогда возвращай прокси обратно и проверяй посимвольно. Если же сайты не открываются и без прокси, копай в сторону сети и системы, а не настроек узла.
Chrome и всё, что на его движке, берёт настройки из системы. Меняешь прокси в Windows, меняется и в браузере. Но расширения вроде VPN-плагинов или менеджеров прокси перекрывают системные настройки своим слоем. Отключи все подобные расширения на время диагностики. Не раз и не два видел, как человек час правит настройки, а виноват плагин, который тянул старый мёртвый узел из своего кэша.
Антивирус и файрвол: тихие убийцы соединения
Вот этот пункт пропускают чаще всего. Антивирус видит, что трафик пошёл не напрямую, а через сторонний узел, и блокирует его. Молча. Без всплывающего окна, без предупреждения. Kaspersky, Avast, ESET NOD32 - у всех есть модули сетевой защиты, которые рубят соединение через прокси, даже если всё настроено идеально.
Проверяется просто. Временно отключи сетевой экран антивируса и попробуй подключиться снова. Заработало - значит виноват он. Тогда не оставляй защиту выключенной: добавь браузер или клиент в исключения и разреши соединения через прокси в настройках самого антивируса. После изменений перезапусти компьютер, иначе настройки не подхватятся.
С файрволами та же история. Сторонние вроде Comodo или Outpost часто настроены строже стандартного защитника Windows. Они могут резать исходящие соединения на нестандартные порты, а прокси как раз на них и висит. Загляни в правила файрвола и проверь, нет ли запрета на исходящий трафик для твоего приложения.
Система: hosts, TCP/IP и последствия чистки вирусов
Бывает, что сетевые настройки слетели. Человек ловил вирус, чистил систему утилитой, ставил подозрительный софт - и после этого конфигурация TCP/IP или файл hosts остались в странном состоянии. Система просто не знает, через что ей подключаться. Внешне всё выглядит нормально, а соединение не встаёт.
Сброс сетевых настроек делается через командную строку с правами администратора. Команды netsh winsock reset и netsh int ip reset возвращают сетевой стек к заводскому виду. После этого обязательна перезагрузка. Файл hosts лежит в системной папке, и его стоит открыть блокнотом: куча строк с незнакомыми адресами означает, что систему почистили не до конца.
Заодно проверь системное время. Звучит странно, но расхождение часов хоть на пару минут ломает соединения с шифрованием. Сертификаты и токены не сходятся, и прокси отказывает в подключении. Синхронизация времени через интернет решает вопрос за минуту.
Телефон не подключается, а компьютер работает
Классика из личного опыта. Один и тот же прокси стабильно работает на десктопе и на старом телефоне, а на новом смартфоне соединения нет. Настройки вроде одинаковые, сеть одна, результата ноль. Причина почти всегда в самом приложении, а не в прокси.
В Telegram настройки прячутся в разделе «Данные и память», оттуда идёшь в «Прокси». Добавляешь узел через плюсик, выбираешь тип, вписываешь адрес, порт, логин и пароль. После сохранения нажми на добавленный узел, чтобы он стал активным. Частая ошибка: узел сохранён, но не выбран, и приложение продолжает ходить напрямую.
Дальше проверь разрешения. Android и iOS любят душить фоновую активность мессенджеров. Если у Telegram отобрали право работать в фоне или включили жёсткую экономию батареи, соединение будет рваться сразу после того, как экран погаснет. В настройках телефона найди приложение и сними ограничения на фоновый режим и автозапуск.
Ещё один момент: системный прокси и прокси внутри приложения - разные вещи. Telegram со своим прокси не смотрит на системные настройки, и наоборот. Прописал узел в настройках Wi-Fi, а мессенджер настроен на свой собственный - они не связаны. Отсюда и путаница, почему на одном устройстве всё летает, а на другом нет.
SOCKS5 и MTProto: почему тип подключения решает
SOCKS5 работает на уровне сессии, не вникая в содержимое пакетов. Он заворачивает трафик любого приложения целиком, поддерживает TCP и UDP, умеет передавать логин с паролем. Для парсинга, работы с API и корпоративных задач это самый предсказуемый вариант. Но SOCKS5 требователен к корректности данных: неверный порт или тип авторизации, и соединение молча не встанет.
MTProto - протокол Telegram, у него своя архитектура. Шифрование держится на уровне приложения, а прокси в этой схеме выступает просто транспортом для пакетов. Задержки у MTProto обычно ниже, потому что нет лишних слоёв поверх. Но и требований больше: нужен именно MTProto-узел, обычный SOCKS5 в этом режиме не подойдёт. Выберешь тип MTProto, а дашь адрес SOCKS5-сервера - подключение не пройдёт никогда.
Отсюда практическое правило. Не подключается через SOCKS5 - проверь, поддерживает ли узел этот протокол и правильный ли порт. Не подключается через MTProto - убедись, что сервер вообще MTProto, а не просто SOCKS5 с красивым названием. В каталогах эти типы всегда разделены, и брать нужно тот, что совпадает с твоим клиентом.
Когда виноват не прокси, а сеть
Публичный Wi-Fi в кафе или аэропорту часто режет нестандартные порты. Домашний провайдер может фильтровать исходящие соединения на определённые диапазоны. Прокси при этом полностью рабочий, просто до него физически не достучаться из этой сети. Проверяется переключением на мобильный интернет: заработало - значит дело в локальной сети, а не в узле.
Корпоративные сети вообще отдельная песня. Там стоит шлюз, который пропускает трафик только через свои узлы, а сторонние прокси рубит на корню. В такой ситуации поможет собственный VPS внутри периметра или согласование узла с администратором. Подбирать что-то наугад бессмысленно, политика безопасности всё равно отсечёт.
Задержка тоже играет роль. Если пинг до узла выше 300-400 мс, клиент может отваливаться по таймауту ещё до завершения рукопожатия. Для работы с базами, парсинга и торговых задач бери узлы в своём регионе, а не на другом континенте. Разница в скорости обработки запросов бывает в разы, особенно когда параллельно крутится десяток потоков.
Что делать, если перебрал всё, а результата нет
Тогда меняй узел. Это не поражение, а нормальная диагностика. Если данные введены верно, антивирус отключён, сеть проверена, а соединения нет - скорее всего сервер просто умер или узел сняли с обслуживания. Прокси - расходник, и держать один адрес на все задачи глупо. Нормальная практика: иметь в запасе пару узлов и переключаться между ними за минуту.
Постоянные проблемы с одним и тем же поставщиком - повод его сменить. Смотри на три вещи. Первое: скорость отклика, она должна быть стабильной, а не прыгать от запроса к запросу. Второе: поддержка нужного протокола, SOCKS5 и MTProto в идеале оба. Третье: внятная панель со статусом узлов, чтобы не гадать, живой прокси или уже нет. На Хабре в разборах сетевых ошибок давно подметили: половина «сломанных» прокси на деле оказывается мёртвым узлом в панели.
Каталог на 3seller.com/proxy как раз из таких. Узлы разбиты по странам и типам, статус виден сразу, а привязка по IP и срок аренды отображаются в личном кабинете. Когда прокси перестаёт подключаться, ты заходишь и видишь причину, а не сидишь с немым ERR_PROXY_CONNECTION_FAILED. Меняешь узел на рабочий, продолжаешь работу.
Короткий чек-лист на будущее
Держи порядок действий под рукой, чтобы в следующий раз не терять час.
- Проверь активность узла и срок аренды в панели провайдера
- Перечитай адрес, порт, логин и пароль посимвольно, без пробелов на концах
- Убедись, что тип протокола совпадает с тем, что ждёт клиент
- Отключи антивирус и сторонние расширения на время теста
- Сбрось сетевые настройки, если система недавно пережила чистку
- Переключись на другую сеть, чтобы исключить фильтрацию порта
- Не помогло - замени узел, не трать время на реанимацию мёртвого
Практический шаг на сегодня: если прокси висит и не отвечает, не начинай с переустановки браузера. Начни с панели провайдера и проверки, жив ли узел. В большинстве случаев проблема решается там за две минуты, а не в глубоких настройках системы.