Прокси добавили в браузер, парсер или рабочий софт, а страницы не открываются, авторизация зацикливается или часть запросов уходит напрямую. В такой ситуации почти всегда ломается не «интернет вообще», а один конкретный слой: адрес и порт, тип прокси, логин и пароль, DNS, системные исключения или поведение самого клиента. Ниже — нормальная схема проверки без хаотичной смены настроек.
С чего начать, если соединение не поднимается
Если коротко, ответ на вопрос «почему не работает прокси сервер» обычно лежит в одном из шести мест: неверный адрес или порт, перепутанный протокол, ошибка авторизации, локальный DNS вместо удаленного, приложение игнорирует системный прокси или сам узел не пропускает нужный тип трафика.
Главная ошибка при диагностике — менять сразу всё: другой порт, другой логин, другой клиент, другую ОС. После этого уже невозможно понять, где именно была причина. Намного быстрее идти по цепочке: клиент → прокси → целевой сайт.
Практическое правило: если без прокси сайт открывается, а через прокси нет, сначала проверяют не качество IP, а совпадение протокола, авторизацию и то, использует ли конкретная программа именно этот прокси.
Где вообще ломается прокси-соединение
Прокси — это не магическая кнопка, а промежуточный узел между клиентом и целевым сервером. Сначала приложение должно подключиться к самому прокси, затем пройти аутентификацию, потом отправить запрос в правильном формате, а уже после этого прокси открывает соединение к нужному хосту и порту.
Из этого следует простая вещь: ошибка может возникнуть до выхода в целевой сайт. Например, браузер даже не дошел до шага CONNECT, потому что был указан SOCKS5 в клиенте, который ждал обычный HTTP-прокси.
Что важно знать про HTTP- и HTTPS-прокси
HTTP-прокси работает на прикладном уровне. Для обычного HTTP клиент отправляет запрос через прокси сразу. Для HTTPS сначала создается туннель командой CONNECT, и только затем внутри него поднимается защищенное соединение с целевым сайтом.
Здесь часто возникает путаница. Формулировка «HTTPS proxy» в софте может означать либо прокси для HTTPS-сайтов через CONNECT, либо отдельный тип прокси, где шифруется уже канал между клиентом и самим прокси. Если приложение ожидает второй вариант, а вы даете обычный HTTP-прокси, соединение не установится.
Что важно знать про SOCKS5
SOCKS5 гибче: клиент сначала договаривается с прокси о способе аутентификации, затем отправляет команду на установку соединения. Такой формат хорошо подходит для браузеров, автоматизации, некоторых парсеров и рабочих приложений, где нужен не только HTTP.
Но у SOCKS5 есть свой частый источник проблем: разные клиенты по-разному обращаются с DNS. Один и тот же прокси может работать в браузере и не работать в консольном инструменте, если в одном случае домен резолвится на стороне прокси, а в другом — локально.
Если вы подбираете схему под браузерную автоматизацию и хотите избежать такой путаницы, полезно заранее понимать особенности SOCKS5-прокси и поведение конкретного клиента.
Мобильные прокси России от 490 ₽ с ротацией
Отслеживайте, меняйте, переключайте и группируйте прокси в одном месте.
Перейти в личный кабинетПочему не работает прокси сервер: 12 типовых причин
1. Ошибка в адресе или порте
Самая приземленная, но очень частая причина. Неправильный IP, опечатка в доменном имени прокси, лишний пробел при копировании, старый порт из другой карточки доступа — и клиент просто не может достучаться до узла.
Если симптом выглядит как timeout, connection refused или мгновенный обрыв без запроса логина и пароля, сначала проверяют именно адрес и порт. До авторизации дело в таких случаях часто даже не доходит.
2. Перепутан тип прокси
HTTP, HTTPS и SOCKS5 не взаимозаменяемы. Если в приложении выбран SOCKS5, а по факту вы подаете HTTP-прокси, соединение развалится на старте. Обратная ситуация работает так же плохо.
На практике это особенно часто встречается в парсерах, десктопных клиентах и самописных скриптах, где в одном месте задается host:port, а тип протокола берется отдельно и о нем просто забывают.
3. Неверная авторизация
Если прокси требует логин и пароль, ошибка в одном символе уже достаточна для отказа. Для HTTP-прокси это нередко выглядит как повторяющийся запрос авторизации или ответ 407. Для SOCKS5 отказ может происходить еще на этапе выбора метода аутентификации.
Отдельная ловушка — специальные символы в логине и пароле. Когда учетные данные вставляют прямо в URL, часть клиентов ожидает корректное кодирование таких символов, а часть — отдельные поля для логина и пароля.
4. Приложение вообще не использует этот прокси
Очень частый сценарий: прокси настроен в системе, браузер работает, а нужная программа идет напрямую. Причина простая: далеко не весь софт берет системные сетевые настройки. Одни приложения читают только собственную конфигурацию, другие — переменные окружения, третьи — командную строку запуска.
Из-за этого у SEO-специалиста или арбитражной команды появляется ложное ощущение, что «прокси умер», хотя на самом деле конкретный клиент его просто игнорирует.
5. DNS резолвится не там, где вы ожидаете
Прокси может быть рабочим, но доменное имя сначала разрешается локально на вашей машине. Если локальный DNS дает другой маршрут, не отвечает или возвращает IPv6-адрес, который дальше не поддерживается цепочкой, соединение будет вести себя нестабильно или не поднимется совсем.
Особенно часто это всплывает в SOCKS5-сценариях. Один клиент отправляет на прокси уже готовый IP, другой — сам домен. Визуально настройки одинаковые, а результат разный.
6. Срабатывают исключения, PAC или NO_PROXY
Прокси может быть указан верно, но часть адресов обходится напрямую. Причина — список исключений в системе, переменная NO_PROXY, файл автоконфигурации PAC или автоматическое обнаружение прокси.
В итоге для одного домена всё открывается через прокси, для другого — напрямую, а для третьего поведение зависит от браузера. Это одна из самых неприятных причин, потому что внешне всё выглядит «почти рабочим».
7. Узел не пропускает нужный порт или тип трафика
Даже рабочий прокси не обязан разрешать любые назначения. Для HTTP-прокси это особенно заметно на HTTPS-трафике, где нужен корректный CONNECT к целевому хосту и порту. Если на стороне узла есть ограничения по портам или политике маршрутизации, отдельные сайты и сервисы будут падать, а остальные — открываться нормально.
Отсюда типичный симптом: главная страница сайта открывается, а авторизация, API или внешний ресурс внутри страницы — нет.
8. Проблема не в прокси, а в целевом сайте
Если один и тот же прокси стабильно открывает несколько ресурсов, но ломается только на одном домене, проверять нужно уже не только сам прокси. У целевого сайта может быть иной сетевой маршрут, собственные ограничения по географии, чувствительность к частоте запросов или требования к TLS.
Поэтому корректный тест всегда делают не по одному URL, а минимум по двум-трем адресам: контрольный сайт, рабочий сайт и нейтральный внешний ресурс.
9. Конфликт IPv4 и IPv6
Часть клиентов предпочитает IPv6, если он доступен. Дальше возможна цепочка проблем: локальный резолвер вернул AAAA-запись, приложение попыталось идти по IPv6, а прокси, upstream-маршрут или целевой сервис фактически рассчитаны только на IPv4.
Так появляются ситуации, когда на одном устройстве прокси работает, а на другом — нет, хотя логин, пароль и порт одинаковые. Разница может быть именно в сетевом стеке и выборе адресного семейства.
10. Локальный фаервол, защитное ПО или корпоративная политика режут соединение
Если до прокси невозможно достучаться только с одного компьютера или сервера, а с другого всё поднимается, проблему нужно искать локально. Блокироваться может исходящее соединение на нужный порт, неизвестный исполняемый файл, фоновый сервис или нестандартный тип сетевого трафика.
Диагностический признак простой: одинаковый прокси и одинаковые учетные данные ведут себя по-разному на соседних машинах.
11. Ошибка в TLS, сертификатах или системном времени
Бывает и так: прокси-соединение есть, но HTTPS-страницы не открываются, ругаются на сертификат или обрываются после CONNECT. Причина может быть не в самом прокси, а в системном времени, недоверии к сертификату на стороне клиента, старом сетевом стеке или промежуточной проверке трафика.
Здесь важно не путать транспортную доступность и успешное завершение TLS-рукопожатия. Для пользователя это выглядит одинаково как «ничего не работает», а по факту причина уже на другом уровне.
12. Сессия, белый список IP или лимиты доступа
У части поставщиков доступ завязан не только на логин и пароль, но и на белый список IP, время жизни сессии, способ ротации или ограничение по числу одновременных соединений. Если один из этих параметров не совпадает, прокси будет казаться «мертвым», хотя технически узел доступен.
Это особенно важно в многопоточном софте. Если задача требует частой смены адресов и коротких сессий, удобнее сразу брать прокси с ротацией, а не пытаться чинить неподходящую схему настройками на стороне клиента.
Как читать симптомы: что именно они обычно означают
| Симптом | Вероятная причина | Что проверить первым |
|---|---|---|
| Нет соединения вообще | Неверный адрес, порт, локальная блокировка | Host, port, доступность с другой машины |
| Браузер просит логин снова и снова | Ошибка авторизации или неподходящая схема | Логин, пароль, формат ввода, тип прокси |
| HTTP работает, HTTPS нет | Проблема с CONNECT, TLS или ограничением портов | Поддержку HTTPS, время на устройстве, логи клиента |
| В браузере работает, в парсере нет | Приложение не использует системный прокси | Отдельные настройки клиента или переменные окружения |
| Часть сайтов открывается, часть нет | DNS, исключения, ограничения назначения | PAC, NO_PROXY, тест на нескольких доменах |
| На одном ПК работает, на другом нет | Локальная фильтрация, IPv6, разные сетевые правила | Фаервол, стек ОС, способ резолва DNS |
Порядок диагностики без хаоса
Проверьте целевой ресурс без прокси. Если проблема воспроизводится и напрямую, начинать надо не с прокси, а с самого сайта или локальной сети.
Убедитесь, что адрес и порт прокси актуальны. Не копируйте старые параметры из другой программы или из сохраненного профиля браузера.
Сверьте тип подключения. Отдельно проверьте, что клиент настроен именно на HTTP, HTTPS или SOCKS5, а не просто получил host:port без схемы.
Проверьте авторизацию в минимальном тестовом клиенте. Важно убедиться, что логин и пароль валидны вне вашей основной рабочей программы.
Сделайте тест на нескольких доменах. Один контрольный адрес нужен, чтобы исключить проблему конкретного сайта.
Посмотрите, не уходит ли часть трафика мимо прокси. Для этого сравнивают внешний IP в браузере, в скрипте и в рабочем приложении.
Проверьте исключения: PAC, системный bypass list, NO_PROXY, локальные правила сети. Это особенно важно на рабочих станциях и серверах с накопленной историей настроек.
Если используется SOCKS5, отдельно проверьте DNS-сценарий: домен должен резолвиться так, как ожидает ваш клиент — локально или на стороне прокси.
Сделайте повторный тест с другой машины или другой сети. Это быстро отделяет проблему прокси от локальной блокировки или конфликтов ОС.
Если причина не найдена, собирайте в поддержку не эмоции, а факты: точное время теста, адрес прокси, тип протокола, текст ошибки, домен назначения и число одновременных подключений.
Для быстрой технической проверки удобно использовать минимальный консольный тест. Он полезен тем, что убирает из цепочки расширения браузера, антидетект-профиль, внутренние плагины и прочий шум.
curl -v -x http://login:password@host:port https://example.com
curl -v -x socks5h://login:password@host:port https://example.comПервая строка подходит для HTTP-прокси. Вторая — для SOCKS5 с удаленным резолвом доменного имени. Если в одном режиме соединение поднимается, а в другом нет, проблема почти всегда в схеме прокси или в DNS-логике клиента.
Что проверить перед обращением в поддержку
- Точный адрес прокси без опечаток
- Правильный порт
- Совпадение типа прокси и настроек клиента
- Логин и пароль без лишних символов и пробелов
- Работу этого же прокси в другом простом клиенте
- Наличие PAC, bypass list и NO_PROXY
- Разницу между тестом с локальным и удаленным DNS
- Поведение на другой машине или в другой сети
- Ошибку на двух-трех разных доменах
- Количество потоков и параллельных подключений в момент сбоя
Частые заблуждения, из-за которых диагностика затягивается
Если IP пингуется, значит прокси рабочий
Не значит. Ping показывает только доступность узла на уровне ICMP, а прокси-соединение живет на другом уровне и требует корректного сервиса на нужном порту, а иногда еще и успешной аутентификации.
Если в браузере открылось, значит в софте тоже откроется
Тоже нет. Браузер может использовать системный прокси, свои DNS-правила и отдельные исключения, а скрипт — переменные окружения или вообще прямое соединение. Сравнивать нужно одинаковые условия.
Один и тот же прокси обязан одинаково работать везде
Не обязан. Разные клиенты по-разному реализуют HTTP CONNECT, SOCKS5, работу с DNS, авторизацию и обработку сертификатов. Именно поэтому сначала тестируют в минимальной конфигурации, а потом уже в рабочем приложении.
Любой рабочий IP подходит для геозависимой проверки
Если задача связана с локальной выдачей, объявлениями, ценами или отображением страниц по региону, важна не просто доступность прокси, а соответствие локации и типу сети. Для таких сценариев обычно логичнее тестировать на российских мобильных прокси или другой нужной географии, а не делать вывод по случайному узлу.
Что из этого следует на практике
Когда прокси не работает, в большинстве случаев не нужно сразу менять провайдера или перебирать десятки IP. Сначала надо понять, на каком шаге рушится цепочка: подключение к прокси, авторизация, DNS, CONNECT, TLS или уже доступ к целевому сайту.
Хорошая диагностика почти всегда короче, чем кажется. Один контрольный тест без прокси, один тест в минимальном клиенте, проверка схемы подключения и исключений — и круг причин резко сужается. Уже после этого имеет смысл разбираться с качеством узла, ротацией, нагрузкой и поведением конкретного софта.
Вопросы, которые возникают чаще всего
Почему прокси работает в браузере, но не работает в парсере?
Потому что браузер и парсер часто используют разные источники сетевых настроек. Браузер может брать системный прокси, а парсер — ждать отдельный host, port и тип соединения внутри своей конфигурации. Дополнительно они могут по-разному резолвить DNS и обрабатывать авторизацию.
Что важнее проверить первым: логин и пароль или тип прокси?
Если соединение не устанавливается вообще, сначала проверяют адрес, порт и тип прокси. Если узел доступен, но появляется повторный запрос авторизации или отказ после подключения, уже переходят к логину и паролю. Такой порядок экономит время и убирает лишние гипотезы.
Почему часть сайтов открывается, а часть нет, хотя прокси один и тот же?
Обычно это связано не с самим фактом работы прокси, а с различием маршрутов и правил для конкретных доменов. Влиять могут DNS, ограничения по портам, исключения в системе, требования к TLS и особенности целевого сайта. Поэтому тест по одному URL почти всегда недостаточен.
Поможет ли смена HTTP на SOCKS5, если текущий прокси не работает?
Только если проблема действительно в несовместимости протокола с клиентом или сценарием. SOCKS5 часто гибче в автоматизации, но не является универсальным лекарством. Если причина в локальной блокировке, белом списке IP, неверном пароле или PAC-исключении, смена протокола ничего не исправит.
Как понять, что проблема в DNS, а не в самом прокси?
Типичный признак — прокси доступен, но один клиент работает, а другой нет; либо IP-адрес по домену отличается в зависимости от способа запуска. Полезно сравнить тест с локальным резолвом и тест, где имя передается на сторону прокси. Если результаты разные, искать нужно именно в DNS-логике.
Стоит ли сразу тестировать другой IP?
Да, но не в самом начале. Второй IP полезен как контрольная точка после проверки схемы подключения, авторизации и исключений. Если вы меняете узел раньше, чем поняли причину, можно случайно замаскировать ошибку в настройке и сделать вывод не в ту сторону.
