Прокси не работает: как найти причину по шагам
Прокси не подключается, соединение сбрасывается или сайт не открывается? Порядок проверок: сеть без прокси, host и port, протокол, пароль и whitelist, целевой сайт.
Материал для тех, у кого купленный или выданный провайдером прокси перестал открывать сайты: ошибка подключения, «соединение сброшено», бесконечная загрузка. Ниже — порядок проверок, который помогает отделить проблему вашей сети от проблемы прокси и от реакции целевого сайта. Бесплатных ключей и адресов здесь нет, Top Proxy не продаёт IP: мы сравниваем сервисы, а диагностику вы делаете со своими данными доступа.
Главное правило: проверяйте по одному звену за раз и двигайтесь от себя к цели. Цепочка выглядит так: ваше устройство → сеть → сервер прокси → целевой сайт.
01Дерево диагностики: в каком порядке проверять
| Шаг | Что проверяем | Что подсказывает неудача |
|---|---|---|
| 1 | Интернет без прокси | Сначала нужно разобраться с сетью или устройством; участие прокси или политики сети это не исключает |
| 2 | Доступен ли host:port прокси | Неверный адрес, закрытый порт, сервер недоступен или фильтр на пути |
| 3 | Протокол (HTTP, HTTPS, SOCKS5) | Клиент и сервер могут говорить на разных протоколах |
| 4 | Авторизация: логин/пароль или whitelist | Отказ в доступе: у HTTP-прокси часто код 407, иначе ошибка клиента или обрыв |
| 5 | Запрос через прокси к нейтральному сайту | Повод проверить тариф, трафик и состояние сервиса, но не окончательный вердикт |
| 6 | Целевой сайт и итоговый IP | Сайт по-своему реагирует на этот выход, либо трафик идёт мимо прокси |
Порядок помогает сузить круг: рабочий запрос без прокси и неудачный через прокси уже говорят больше, чем любая одна проверка отдельно.
02Шаг 1. Работает ли интернет без прокси
Отключите прокси в приложении или системе и откройте любой сайт. Если без прокси интернета нет, сначала разберитесь с сетью: роутер, мобильный оператор, VPN, корпоративный фильтр. Это не доказывает, что прокси ни при чём, но без рабочей базы дальнейшие проверки мало что покажут. Обратная ситуация — «интернет не работает без прокси» — бывает, например, когда в системе остался адрес недоступного прокси, или когда сеть пускает наружу только через обязательный прокси организации.
Здесь же откройте страницу «Мой IP» без прокси и запомните адрес. Это IP, с которого пришёл именно этот запрос по текущему маршруту. Он не обязательно совпадает с адресом, с которого вы подключаетесь к прокси: VPN, разные маршруты для IPv4 и IPv6 или отдельные правила приложений могут дать другой исходящий IP. Адрес пригодится на шаге 4 и на шаге 6 как точка сравнения.
На рабочем или управляемом устройстве настройки прокси и маршруты может задавать администратор. Не удаляйте их вслепую, а сначала уточните, разрешён ли сторонний прокси.
03Шаг 2. Доступен ли host и port прокси
Частая и банальная причина ошибки подключения — опечатка в адресе, перепутанные порты для разных протоколов, адрес из старого заказа. Сверьте host и port с личным кабинетом провайдера символ в символ. У многих сервисов HTTP и SOCKS5 работают на разных портах, а у ротационных и «липких» пулов — ещё и на разных шлюзах.
Затем проверьте, открывается ли TCP-соединение до сервера. На macOS и Linux:
nc -vz PROXY_HOST PROXY_PORT
В Windows PowerShell:
Test-NetConnection PROXY_HOST -Port PROXY_PORT
Если соединение не устанавливается или висит до тайм-аута, до авторизации дело не доходит. Возможные причины: сервер выключен или тариф закончился, адрес неверный, исходящий порт фильтруется на пути (так бывает в публичном Wi-Fi и офисах). Проверьте тот же host:port из другой сети, например с мобильного интернета вместо домашнего Wi-Fi. Если там соединение есть, значит, первый путь отличается — DNS, маршрут или политика сети. Провайдера это не оправдывает полностью, но подсказывает, где искать.
Удобно сделать и внешнюю проверку: чекер прокси подключается к указанному адресу со своего сервера и показывает результат. Помните о двух оговорках. Успех в чекере означает, что прокси отвечает с его точки сети, но не доказывает, что ваше приложение действительно отправляет трафик через прокси. А если провайдер пускает только по whitelist, чекер с его собственным IP получит отказ, даже когда у вас всё работает. Такой провал не говорит о поломке прокси.
04Шаг 3. Совпадает ли протокол
Когда порт открыт, но соединение сразу обрывается («соединение сброшено», в Chrome это обычно ERR_CONNECTION_RESET или ERR_TUNNEL_CONNECTION_FAILED), проверьте протокол. Сам текст ошибки не говорит, кто закрыл соединение: прокси, целевой сервер или узел сети между ними. Но несовпадение протоколов — одна из самых простых для проверки причин. HTTP-прокси и SOCKS5 говорят на разных языках: если клиент шлёт HTTP-запрос в SOCKS-порт или наоборот, сервер не понимает начало разговора.
| Что выбрано в клиенте | Что выдал провайдер | Возможный симптом |
|---|---|---|
| HTTP | SOCKS5 | Мгновенный обрыв, пустой ответ |
| SOCKS5 | HTTP | Ошибка рукопожатия SOCKS, тайм-аут |
| SOCKS4 | SOCKS5 с паролем | Авторизация не проходит: в SOCKS4 нет пароля |
| HTTPS-прокси (TLS до прокси) | Обычный HTTP-прокси | Ошибка TLS при подключении к прокси |
Последняя строка часто путает. «HTTPS-прокси» в настройках некоторых клиентов означает шифрованное соединение до самого прокси. Это не то же самое, что открыть HTTPS-сайт через обычный HTTP-прокси: во втором случае клиент просит прокси открыть туннель методом CONNECT, и шифрование идёт между вами и сайтом. Если провайдер не заявлял TLS до прокси, выбирайте обычный HTTP.
Для SOCKS5 есть ещё нюанс с DNS. В curl схема socks5:// означает, что имя сайта резолвит сам клиент, а socks5h:// передаёт имя прокси, и резолвит уже он (документация curl). Если локальный DNS не находит сайт или отдаёт другой адрес, со socks5h картина может измениться. В других приложениях эта настройка называется по-разному и есть не везде.
Проверка из терминала помогает отделить приложение от прокси. Это общие примеры, а не результат нашего теста:
curl -q -v --noproxy '' --connect-timeout 10 --max-time 30 \
-x http://PROXY_HOST:PROXY_PORT -U 'USER:PASSWORD' https://example.com/
curl -q -v --noproxy '' --connect-timeout 10 --max-time 30 \
-x socks5h://PROXY_HOST:PROXY_PORT -U 'USER:PASSWORD' https://example.com/
Замените PROXY_HOST, PROXY_PORT, USER и PASSWORD своими данными; порт указывается числом. Что делают опции, описано в руководстве curl: -q, стоящая первой, не даёт подхватить настройки из файла .curlrc; --noproxy '' отменяет исключения из переменных no_proxy/NO_PROXY, чтобы запрос не ушёл напрямую; --connect-timeout ограничивает время подключения, а --max-time — всю операцию целиком. -U передаёт логин и пароль прокси отдельной опцией, без URL-кодирования. Учтите, что пароль, набранный прямо в команде, остаётся в истории оболочки; для реальных данных используйте безопасный для вас способ ввода.
Флаг -v выводит ход соединения: видно, на каком этапе обрыв — подключение к прокси, ответ на CONNECT или TLS с сайтом. Не отключайте проверку сертификатов «для теста»: ошибка TLS сама по себе полезный сигнал. Если curl через прокси работает, а приложение — нет, ищите причину в настройках приложения; для популярных программ у нас есть отдельные инструкции.
Что показала проверка на тестовом прокси
Мы прогнали такие команды через curl 8.7.1 на локальном испытательном прокси с тестовыми учётными данными, включённой проверкой TLS и короткими тайм-аутами. Коммерческие сервисы в этой проверке не участвовали, поэтому таблица показывает, как выглядят ошибки, а не качество какого-либо провайдера.
Ситуация → Что вернул curl
- 01HTTP-сайт без логина на прокси, где он нуженОтвет 407, но код выхода 0: без
--failcurl не считает это ошибкой - 02HTTPS-сайт без логина на тот же проксиКод выхода 56, «CONNECT tunnel failed, response 407»
- 03Верный логин через
--proxy-userОтвет 200 - 04Закрытый порт проксиКод выхода 7, «Couldn't connect to server»
- 05Сайт сам ответил 401 или 502Код прошёл через прокси без изменений
Отсюда два практических вывода. Смотрите на HTTP-код в выводе -v, а не только на код выхода curl. И 401 или 502 в ответе ещё не значит, что ошибку создал прокси: в нашем тесте их вернул сам тестовый сайт. Обрыв соединения, тайм-аут и отказ по whitelist в этой проверке не воспроизводились.
Отчёт по реальному выводу curl на локальном испытательном прокси; заголовки авторизации скрыты.
05Шаг 4. Пароль и whitelist
У платных прокси два основных способа авторизации, и они не взаимозаменяемы.
Логин и пароль. HTTP-прокси, отвергнувший учётные данные, обычно отвечает кодом 407 Proxy Authentication Required. У SOCKS5 своя схема авторизации, и её отказ выглядит как ошибка клиента или обрыв, а не как HTTP-код. Код 401 обычно приходит от целевого сервера, когда авторизации требует он, хотя сам по себе код не исключает проблему на промежуточном узле. Разбору 407 мы посвятим отдельный материал, здесь коротко. Проверьте, что логин и пароль скопированы без пробелов в начале и конце и что вы не перепутали пользователя кабинета с пользователем прокси. Если клиент принимает пароль отдельным полем, вводите его как есть. Если пароль вставляется в URL вида http://user:pass@host:port, символы вроде @, : или / придётся кодировать по правилам этого клиента.
Whitelist по IP. Провайдер пропускает запросы только с адресов, которые вы добавили в кабинет. Лучше всего сверить список с адресом, который видит сам провайдер: некоторые кабинеты показывают IP входящих подключений. Если такого нет, сравните с адресом со страницы «Мой IP», помня, что он может отличаться от источника подключения к прокси. Расхождения встречаются часто: домашний IP сменился после переподключения роутера, вы зашли с мобильного интернета вместо Wi-Fi, включён VPN, у оператора общий NAT, запрос ушёл по IPv6 вместо IPv4. Не ломайте управляемые маршруты ради теста — лучше добавьте в список реальный адрес. При отказе по whitelist некоторые провайдеры возвращают 407, а некоторые просто закрывают соединение.
Ещё одна частая причина отказа — закончился трафик или срок тарифа.
06Шаг 5. Запрос через прокси к нейтральному сайту
Если до этого места всё сходится, сделайте запрос через прокси к простому сайту, например https://example.com/. Успех здесь показывает, что прокси в целом пропускает трафик, но не снимает подозрений целиком: DNS на стороне прокси, CONNECT к конкретному адресу или маршрут до нужного сайта могут вести себя иначе. Неудача тоже не обязательно вина провайдера — сравните её с результатами шагов 1–4.
Обратите внимание на коды ответа. Ошибки 502 Bad Gateway и 504 Gateway Timeout выдаёт промежуточный узел: по описанию MDN, 502 означает, что шлюз или прокси получил некорректный ответ от следующего сервера, а 504 — что вовремя не получил ответа. Получив такой код через прокси, нельзя сразу сказать, сломан ли сайт: ответ мог сформировать сам прокси или другой шлюз на пути. Если 502/504 повторяются и на нейтральном сайте, это весомый повод написать провайдеру.
У ротационных и мобильных прокси отдельный выход иногда временно недоступен. Повторите запрос несколько раз с паузой, но не ставьте бесконечные автоматические повторы: это лишний трафик и риск блокировки аккаунта у провайдера. Если проблема держится, напишите в поддержку, указав host, port, время и вывод curl -v. Перед отправкой замаскируйте в нём логин, пароль, токены, заголовок Proxy-Authorization и cookies.
07Шаг 6. Целевой сайт и проверка результата
Нейтральный сайт открывается через прокси, а нужный — нет? Возможно, сайт реагирует на запрос по-своему: показывает капчу, отвечает 403, требует подтверждение или режет целые подсети. Но проверьте и путь до сайта: DNS через прокси и маршрут к конкретному адресу тоже могут отличаться. Варианты: сменить выход в пуле, попробовать другой тип IP — резидентские или мобильные прокси, — либо проверить, не заблокирован ли сайт в вашей стране на уровне сети.
Финальная проверка — откройте «Мой IP» через то же приложение, в котором настроили прокси. Сравните показанный адрес с ожидаемым выходом провайдера: конкретным IP или диапазоном из кабинета. Одной страны для такого сравнения мало. Тут есть две ловушки. Неизменившийся IP не всегда значит, что прокси «не работает»: возможно, именно это приложение не пользуется системными настройками, и трафик идёт напрямую. А изменившийся IP ещё не доказывает, что трафик идёт через нужный прокси: адрес мог смениться из-за VPN или другого маршрута.
Прокси не работает на телефоне и в мобильном интернете
Системный HTTP-прокси на телефоне обычно задаётся в настройках конкретной сети Wi-Fi, а на сотовую связь эта настройка не распространяется. При этом VPN, отдельные приложения или профили управления устройством могут задавать собственные маршруты, а часть приложений игнорирует системный прокси даже в Wi-Fi. Поэтому «прокси не работает на мобильном» часто означает, что трафик идёт не тем путём, которым вы ожидаете. Нужен клиент, который сам умеет работать с прокси; названия пунктов меню и поведение зависят от модели телефона, версии системы и программы.
Если прокси не работает только у мобильного оператора, а по Wi-Fi порт доступен, проверьте шаг 2 именно из мобильной сети: путь до прокси там другой.
08Если проблема у провайдера
Когда шаги сходятся на сервисе — порт недоступен из разных сетей, тариф активен, данные верны, — это повод написать в поддержку и, если сбои повторяются, сравнить альтернативы. Ниже сервисы из каталога Top Proxy; наличие в списке не означает, что мы проверили их совместимость с вашей задачей или приложением.
SOAX продаёт ротационные резидентские и мобильные прокси на общем пуле кредитов; в тех же планах доступны датацентровые и ISP. Builder — от $200/мес + VAT (200 кредитов); Tier 1 на Builder — $3/GB.
Bright Data — крупная сеть прокси для сбора данных: резидентские, мобильные, ISP и датацентровые IP примерно в 195 странах. Резидентский трафик можно оплачивать по факту без подписки, серверные и ISP-адреса продаются пакетами от 10 IP. Для резидентских и мобильных прокси нужна проверка личности.
Froxy предлагает резидентские, мобильные, быстрые резидентские и серверные прокси с оплатой за трафик, месячными пакетами и платным тестом $1.99 / 3 дня / 100 МБ.
Перед покупкой уточните в документации провайдера протоколы, способ авторизации и порты для вашего тарифа, а после подключения прогоните адрес через чекер прокси.
