Прокси сервер не отвечает: пошаговая диагностика таймаутов, портов и брандмауэра

Введение: что вы получите от этого руководства

Ситуация знакома каждому, кто работает с прокси: вчера всё летало, а сегодня браузер крутит колесо загрузки, скрипт парсинга виснет на первом запросе, антидетект-браузер пишет, что прокси сервер не отвечает. Никаких понятных сообщений, только ожидание и тишина. Хочется сразу писать в поддержку или менять провайдера, но в большинстве случаев причина находится на вашей стороне и устраняется за десять минут.

Это практическое руководство поможет вам пройти путь от "ничего не работает" до "соединение стабильно" без гадания. Мы разберём три самых частых сетевых виновника: таймауты, закрытые или неправильные порты и брандмауэр. Вы научитесь определять, где именно обрывается цепочка между вашим компьютером и прокси, и получите набор команд, которые за минуту показывают источник проблемы.

Важная граница: здесь мы говорим только о сетевых причинах, когда соединение не устанавливается вовсе или зависает. Ситуации, когда прокси отвечает, но возвращает код ошибки вроде 407 или 502, это отдельная тема, и её мы не затрагиваем. Если вы видите конкретный HTTP-код в ответе, значит прокси жив, и ваш случай не про эту статью.

Для кого этот гайд

• Маркетологи и SMM-специалисты, которые ведут несколько аккаунтов через мобильные прокси и столкнулись с тем, что браузер не подключается.
• Арбитражники, у которых связки вдруг перестали работать, а рекламные кабинеты не открываются через прокси.
• Разработчики, чьи скрипты на Python, Node.js или Go получают таймаут вместо ответа.
• Владельцы бизнеса, которые настроили прокси для сотрудников и хотят понимать, почему у одного всё работает, а у другого нет.

Что нужно знать заранее

Практически ничего специального. Достаточно уметь открывать командную строку или терминал, копировать команды и читать то, что они выводят. Все термины мы объясним по ходу. Если вы никогда не открывали терминал, не переживайте: каждое действие расписано до уровня "нажмите эту клавишу, введите этот текст".

Сколько времени потребуется

Полная диагностика по всем шагам занимает от 30 до 60 минут. Чаще всего проблема обнаруживается на первом или втором шаге, и тогда вы уложитесь в 10-15 минут. Продвинутый блок в конце можно изучать отдельно, когда базовое соединение уже восстановлено.

Предварительная подготовка: инструменты и данные

Прежде чем начинать, соберите всё необходимое в одном месте. Это сэкономит время и избавит от беготни между вкладками в самый неподходящий момент.

Данные вашего прокси

Откройте личный кабинет провайдера и выпишите в текстовый файл следующие параметры. Они понадобятся почти на каждом шаге.

1. Адрес сервера (host). Это либо доменное имя вида proxy.example.net, либо IP-адрес вида 185.10.20.30.
2. Порт для HTTP-подключения. У мобильных прокси это часто пятизначное число, например 30001 или 51234.
3. Порт для SOCKS5, если провайдер выдаёт его отдельно. Иногда он отличается от HTTP-порта на единицу или на несколько тысяч.
4. Логин и пароль для авторизации, если вы используете авторизацию по учётным данным.
5. Список разрешённых IP, если у вас включена авторизация по IP-адресу. Проверьте, какой адрес там указан.
6. Ссылку для смены IP и информацию о режиме ротации: по расписанию, по ссылке или при каждом запросе.

Совет: сохраните эти данные не только в менеджере паролей, но и в обычном текстовом файле на время диагностики. Вы будете вставлять их в команды десятки раз, и постоянное переключение между окнами утомляет.

Инструменты, которые уже есть в вашей системе

Хорошая новость: почти всё нужное встроено в операционную систему. Ничего покупать не придётся.

• Windows 10 и 11: PowerShell (найдите его через поиск в меню Пуск) и командная строка cmd. В PowerShell есть команда Test-NetConnection, которая заменит вам отдельные утилиты.
• macOS: приложение Терминал (Программы, папка Утилиты). Утилиты nc и curl уже установлены.
• Linux (Ubuntu, Debian, Fedora): любой терминал. Возможно, потребуется установить пакеты curl, netcat и mtr через менеджер пакетов вашей системы.

Что желательно установить дополнительно

1. curl для Windows. В Windows 10 версии 1803 и новее, а также в Windows 11 curl уже есть. Проверьте: откройте cmd и введите curl --version. Если увидите номер версии, всё в порядке.
2. Второе устройство для сравнения: смартфон, второй ноутбук или виртуальная машина. Это не программа, но очень полезный инструмент, о котором мы поговорим на первом шаге.
3. Доступ к настройкам роутера: адрес панели (чаще всего 192.168.0.1 или 192.168.1.1) и пароль администратора. Понадобится на пятом шаге.

Резервные копии перед началом

Мы будем менять настройки брандмауэра и, возможно, роутера. Перед этим сделайте две вещи, чтобы всегда можно было вернуться к исходному состоянию.

1. В Windows создайте точку восстановления: откройте поиск, введите "Создание точки восстановления", нажмите кнопку Создать и дайте ей понятное имя, например "До настройки прокси".
2. Экспортируйте текущие правила брандмауэра Windows. Откройте PowerShell от имени администратора и выполните команду netsh advfirewall export "C:/firewall-backup.wfw". Файл появится в корне диска C.
3. В панели роутера найдите раздел вроде "Система", "Обслуживание" или "Резервное копирование" и сохраните файл конфигурации на компьютер.

Внимание: не отключайте брандмауэр целиком "на всякий случай" и не оставляйте его отключённым. Во время диагностики мы будем выключать защиту максимум на две минуты для проверки гипотезы, а затем возвращать всё обратно и создавать точечное правило.

Базовые понятия: что происходит, когда прокси не отвечает

Чтобы диагностика была осмысленной, а не хаотичным перебором, важно понять, как устроена цепочка соединения. Тогда каждый шаг гайда будет проверять один конкретный участок этой цепочки.

Путь запроса от вас до сайта

Когда вы работаете через мобильный прокси, запрос проходит такой путь. Сначала ваше приложение (браузер, скрипт, антидетект) отправляет данные в операционную систему. Система пропускает их через свой брандмауэр и передаёт на роутер. Роутер отдаёт трафик вашему интернет-провайдеру. Провайдер доставляет пакеты на сервер прокси. Сервер прокси перенаправляет запрос через мобильный модем с SIM-картой в сеть сотового оператора. И только затем запрос уходит на целевой сайт. Ответ идёт по тому же маршруту в обратном порядке.

Обрыв возможен на любом из этих участков. Фраза "прокси сервер не отвечает" на самом деле означает лишь одно: ответ не дошёл до вашего приложения за отведённое время. Где именно он потерялся, и предстоит выяснить.

Порт: дверь в сервер

У любого сервера один IP-адрес, но множество портов, пронумерованных от 1 до 65535. Представьте многоэтажный дом с одним адресом и тысячами квартир. Прокси-служба "живёт" в конкретной квартире, то есть слушает конкретный порт. Если вы стучитесь в другой порт, никто не откроет, и вы будете ждать до истечения таймаута. Причём сервер при этом абсолютно исправен.

Порты бывают открыты, закрыты и фильтруемы. Открытый порт отвечает на попытку соединения согласием. Закрытый порт сразу отвечает отказом, и вы получаете мгновенную ошибку вроде "connection refused". Фильтруемый порт молчит: ваши пакеты выбрасываются по пути, а вы не получаете ничего. Именно фильтрация даёт классическую картину зависания без ответа, и виноват в ней почти всегда какой-нибудь брандмауэр.

Таймаут: сколько ждать, прежде чем сдаться

Таймаут это предел ожидания, после которого приложение прекращает попытку и сообщает об ошибке. Таймаутов бывает несколько, и путать их не стоит.

• Таймаут соединения (connect timeout). Сколько ждать, пока сервер согласится установить связь. Если истёк он, значит до порта прокси вы вообще не достучались.
• Таймаут чтения (read timeout). Сколько ждать данных после того, как соединение установлено. Если истёк он, значит прокси вас принял, но целевой сайт или мобильная сеть отвечали слишком медленно.
• Общий таймаут запроса. Верхняя граница на всё вместе.

Мобильные прокси работают через сотовую сеть, где задержки естественным образом выше, чем у датацентровых. Если ваш софт настроен на таймаут в 5 секунд, он может отваливаться на абсолютно исправном мобильном прокси просто потому, что ответ пришёл на шестой секунде.

Брандмауэр: фильтр, который решает, что пропускать

Брандмауэр (файрвол, межсетевой экран) это программа или устройство, которое просматривает сетевые пакеты и решает, пропустить их или отбросить. В вашей цепочке брандмауэров может быть три или четыре: встроенный в Windows или macOS, в составе антивируса, на роутере и у корпоративного администратора. Любой из них способен молча выбросить пакеты на нестандартный порт, а вы увидите лишь зависание.

Авторизация по IP: невидимый брандмауэр на стороне прокси

У многих провайдеров мобильных прокси есть режим, при котором вместо логина и пароля используется белый список IP-адресов. Сервер принимает соединения только от адресов из списка, а остальные попытки может просто игнорировать. Если ваш домашний IP сменился (это происходит при перезагрузке роутера у большинства провайдеров), прокси перестанет вас узнавать. Внешне это выглядит точно так же, как заблокированный порт.

Теперь, когда картина ясна, переходим к практике. Каждый следующий шаг проверяет один участок цепочки и либо снимает с него подозрение, либо находит виновника.

Шаг 1: Определяем, где обрывается соединение

Цель этапа: за пять минут понять, проблема на вашей стороне, на стороне сети или на стороне прокси. Это самый важный шаг, потому что он отсекает половину возможных причин сразу.

Проверяем интернет без прокси

1. Откройте браузер и в его настройках временно отключите прокси. В Chrome это Настройки, раздел Система, пункт "Открыть настройки прокси-сервера компьютера". В антидетект-браузере создайте профиль без прокси или выберите режим "Без прокси" в настройках профиля.
2. Откройте любой крупный сайт, например страницу поисковика. Она должна загрузиться за секунду-две.
3. Если сайт не открывается и без прокси, проблема не в прокси. Перезагрузите роутер, проверьте кабель или Wi-Fi и вернитесь к этому гайду позже.

Проверяем прокси с другого устройства

1. Возьмите смартфон и отключите на нём Wi-Fi, чтобы он работал через мобильный интернет. Так вы окажетесь в совершенно другой сети, минуя ваш роутер и провайдера.
2. Установите на телефон любой браузер с поддержкой прокси или используйте системные настройки: на Android в свойствах точки доступа это делается через APN, но проще поставить приложение-браузер с ручным вводом прокси.
3. Введите адрес, порт, логин и пароль вашего прокси и откройте любой сайт, показывающий ваш IP-адрес.
4. Если с телефона прокси работает, значит сам прокси жив, и проблема между вашим компьютером и интернетом: брандмауэр, роутер или настройки софта. Идите на шаги 2, 3, 4 и 5.
5. Если с телефона тоже не работает, проблема либо в самом прокси, либо в его настройках авторизации. Переходите к шагу 6, а затем в поддержку.

Совет: если второго устройства нет, попробуйте подключить компьютер к мобильной точке доступа с телефона. Смена сети даст тот же эффект, что и проверка с другого устройства.

Проверяем статус прокси в личном кабинете

1. Войдите в личный кабинет провайдера мобильных прокси.
2. Найдите карточку вашего прокси и посмотрите на индикатор состояния. У большинства сервисов он показывает, в сети ли модем и когда была последняя активность.
3. Если индикатор показывает, что прокси отключён или модем не в сети, дальше можно не диагностировать: причина на стороне оборудования, и её решает поддержка.

Проверка: к концу этого шага у вас должен быть ответ на один вопрос: прокси работает хотя бы откуда-нибудь или не работает ни откуда. Запишите этот вывод. Он определяет, какие шаги дальше будут главными.

Возможные проблемы на этом шаге

Иногда с телефона прокси работает, а через минуту перестаёт. Это может быть ротация IP на прокси или нестабильная сотовая сеть у модема. Повторите проверку два-три раза с интервалом в минуту, чтобы не сделать ложных выводов из единственной попытки.

Шаг 2: Проверяем адрес и порт прокси

Цель этапа: убедиться, что порт прокси открыт и доступен именно с вашего компьютера. Это ключевая проверка: если порт не отвечает, всё остальное бессмысленно.

Почему ping не подходит

Первая мысль многих: пропинговать сервер. Но ping проверяет только доступность IP-адреса по протоколу ICMP, а не открытость конкретного порта. Многие серверы прокси вообще не отвечают на ping из соображений безопасности. Так что успешный ping ничего не гарантирует, а неуспешный ничего не значит. Нам нужна проверка именно TCP-порта.

Проверка порта в Windows

1. Нажмите клавишу Windows, введите PowerShell и откройте его.
2. Введите команду, подставив свои адрес и порт:

   Test-NetConnection -ComputerName proxy.example.net -Port 30001

3. Нажмите Enter и подождите. Команда может думать до 20 секунд.
4. Найдите в выводе строку TcpTestSucceeded. Значение True означает, что порт открыт и принимает соединения. Значение False означает, что до порта достучаться не удалось.
5. Обратите внимание на строку PingSucceeded. Если она False, а TcpTestSucceeded True, всё в порядке: сервер просто не отвечает на ping.

Проверка порта в macOS и Linux

1. Откройте Терминал.
2. Введите команду:

   nc -zv proxy.example.net 30001

3. Ключ -z говорит утилите не отправлять данные, а только проверить соединение. Ключ -v включает подробный вывод.
4. Ответ вида succeeded или Connection to ... port 30001 succeeded! означает успех. Ответ Connection refused означает, что порт закрыт, а сервер сразу отказал. Если команда висит без ответа, а потом пишет timed out, порт фильтруется где-то по пути.

Проверка через curl на любой системе

curl умеет не просто проверить порт, но и сразу сделать запрос через прокси. Это следующий уровень проверки.

1. Введите команду, подставив свои данные:

   curl -x http://login:password@proxy.example.net:30001 --connect-timeout 15 -v https://api.ipify.org

2. Ключ -x задаёт прокси. Ключ -v показывает все этапы соединения. Ключ --connect-timeout ограничивает ожидание установки связи 15 секундами.
3. Читайте вывод сверху вниз. Строка Connected to proxy.example.net означает, что порт открыт. Строка CONNECT api.ipify.org:443 показывает, что curl попросил прокси установить туннель. Если после этого пришёл ответ 200, а в конце вы видите IP-адрес, прокси полностью работает.
4. Если вывод остановился на строке Trying 185.10.20.30:30001... и через 15 секунд появилось Connection timed out, порт недоступен с вашего компьютера.

Совет: если в пароле есть специальные символы вроде @ или #, curl может неправильно разобрать адрес. Используйте отдельный ключ -U для учётных данных: curl -x http://proxy.example.net:30001 -U login:password ... Так пароль не смешается с адресом.

Проверяем протокол и порт SOCKS5

Частая ошибка: указать HTTP-порт там, где софт ожидает SOCKS5, или наоборот. Соединение при этом установится, но данные не пойдут, и приложение может выдать таймаут.

1. Проверьте в кабинете провайдера, какие порты выданы для HTTP и для SOCKS5.
2. Выполните проверку через curl с протоколом SOCKS5:

   curl -x socks5://login:password@proxy.example.net:30002 --connect-timeout 15 https://api.ipify.org

3. Убедитесь, что в вашем приложении выбран тот же протокол, что и в успешной команде curl.

Проверка: после этого шага вы точно знаете одно из трёх: порт открыт и прокси отвечает через curl (тогда проблема в настройках вашего приложения, переходите к шагу 3); порт открыт, но запрос через прокси зависает (проблема с авторизацией или на стороне прокси, шаг 6); порт не отвечает (проблема в брандмауэре или сети, шаги 4 и 5).

Возможные проблемы на этом шаге

Если Test-NetConnection выдаёт ошибку разрешения имени, значит компьютер не может превратить доменное имя в IP-адрес. Попробуйте подставить вместо имени IP-адрес из личного кабинета. Если с IP работает, а с именем нет, у вас проблема с DNS: смените DNS-сервер в настройках сетевого адаптера на публичный и повторите.

Шаг 3: Разбираемся с таймаутами в вашем софте

Цель этапа: убедиться, что приложение даёт мобильному прокси достаточно времени на ответ, и научиться отличать таймаут соединения от таймаута чтения.

Измеряем реальное время ответа

1. Выполните команду curl с выводом тайминга:

   curl -x http://login:password@proxy.example.net:30001 -o /dev/null -s -w "connect: %{time_connect}s total: %{time_total}s" https://api.ipify.org

   В Windows вместо /dev/null используйте NUL.
2. Значение connect показывает, за сколько установилось TCP-соединение с прокси. Норма для мобильных прокси: от 0,05 до 0,5 секунды.
3. Значение total показывает время всего запроса. Для мобильных прокси нормально видеть 1-4 секунды, а в часы пиковой нагрузки сотовой сети и до 6-8 секунд.
4. Повторите команду пять раз и запишите разброс. Если connect стабильно низкий, а total иногда прыгает до 10 секунд, ваш софт должен быть готов к таким задержкам.

Настраиваем таймауты в популярных инструментах

Python и библиотека requests

Параметр timeout принимает кортеж из двух значений: таймаут соединения и таймаут чтения. Рекомендованные значения для мобильных прокси: 10 секунд на соединение и 30 секунд на чтение.

proxies = {"http": "http://login:password@proxy.example.net:30001", "https": "http://login:password@proxy.example.net:30001"}
response = requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

Если вы указываете одно число, например timeout=5, оно применяется к обоим таймаутам, и это частая причина ложных сообщений о том, что прокси сервер не отвечает.

Node.js и axios

В axios параметр timeout один и общий. Установите его не меньше 30000 миллисекунд. Для прокси используйте агент, например из пакета https-proxy-agent, и передавайте его в параметр httpsAgent.

Антидетект-браузеры

1. Откройте настройки профиля, раздел с прокси.
2. Найдите кнопку проверки соединения. Она есть практически во всех современных антидетектах.
3. Обратите внимание, за какое время приходит результат. Если проверка длится больше 10 секунд и заканчивается неудачей, а curl при этом работает, посмотрите в общих настройках браузера параметр таймаута прокси и увеличьте его.
4. Убедитесь, что в поле протокола выбрано именно HTTP или SOCKS5 в соответствии с портом, который прошёл проверку на шаге 2.

Инструменты для парсинга и автоматизации

В Scrapy отвечает параметр DOWNLOAD_TIMEOUT, по умолчанию 180 секунд, и он редко бывает проблемой. В Puppeteer и Playwright таймаут навигации по умолчанию 30 секунд, но при работе через медленную сотовую сеть тяжёлые страницы могут не успевать: увеличьте до 60 секунд через параметр timeout в методе goto.

Совет: не ставьте таймауты слишком большими. 30-60 секунд для чтения это разумный предел. Если поставить 300 секунд, ваш скрипт будет часами висеть на мёртвых соединениях вместо того, чтобы быстро повторить запрос.

Отличаем таймаут соединения от таймаута чтения

Это важно, потому что лечатся они по-разному.

• Таймаут соединения в curl выглядит как "Connection timed out after 15001 milliseconds" сразу после строки Trying. В Python requests это исключение ConnectTimeout. Лечение: шаги 4, 5 и 6, потому что вы не достучались до порта.
• Таймаут чтения в curl выглядит как "Operation timed out after 30000 milliseconds with 0 bytes received" уже после строки Connected. В Python это ReadTimeout. Лечение: увеличить таймаут чтения, проверить, не идёт ли в этот момент ротация IP на прокси, и убедиться, что целевой сайт вообще доступен.

Проверка: после этого шага время ответа прокси через curl укладывается в таймауты вашего приложения с запасом хотя бы в два раза. Если curl отвечает за 3 секунды, в софте должно стоять не меньше 10 секунд на чтение.

Шаг 4: Проверяем брандмауэр и антивирус на вашем устройстве

Цель этапа: убедиться, что защитное ПО на компьютере не блокирует исходящие соединения на порт прокси, и при необходимости создать точечное разрешающее правило.

Быстрый тест: временное отключение

Прежде чем копаться в правилах, проверим гипотезу самым простым способом. Отключаем защиту на минуту, повторяем проверку порта, включаем обратно.

1. В Windows откройте поиск, введите "Брандмауэр Защитника Windows" и откройте его.
2. Слева нажмите "Включение и отключение брандмауэра Защитника Windows".
3. Для текущего активного профиля сети (обычно это Частная или Общедоступная сеть) выберите "Отключить" и нажмите ОК.
4. Немедленно выполните Test-NetConnection из шага 2.
5. Сразу верните переключатель в положение "Включить" и нажмите ОК.

Внимание: не работайте с отключённым брандмауэром дольше, чем нужно для одной проверки. Одна команда занимает секунды, а открытая система в сети это реальный риск. Если забыли включить обратно, Windows напомнит уведомлением, но лучше не полагаться на это.

Если с отключённым брандмауэром порт стал доступен, виновник найден. Если нет, проверяем антивирус тем же способом: у большинства продуктов есть пункт "Приостановить защиту на 5 минут" в контекстном меню значка в трее. Повторите проверку порта и верните защиту.

Создаём разрешающее правило в брандмауэре Windows

Отключать брандмауэр навсегда нельзя. Вместо этого создадим правило, которое разрешит именно вашему приложению исходящие соединения.

1. Откройте "Брандмауэр Защитника Windows" и слева нажмите "Дополнительные параметры". Откроется окно с расширенными настройками.
2. В левой колонке выберите "Правила для исходящего подключения".
3. В правой колонке нажмите "Создать правило".
4. Выберите тип "Для программы" и нажмите Далее.
5. Выберите "Путь программы" и через кнопку Обзор укажите исполняемый файл вашего приложения: браузера, антидетекта или интерпретатора Python. Нажмите Далее.
6. Выберите "Разрешить подключение" и нажмите Далее.
7. Отметьте все три профиля: Доменный, Частный, Публичный. Нажмите Далее.
8. Дайте правилу понятное имя, например "Разрешить прокси для антидетект-браузера", и нажмите Готово.

Альтернативный вариант, если приложений много: создать правило типа "Для порта", выбрать протокол TCP, указать конкретный удалённый порт прокси и разрешить его для всех программ. Для этого на четвёртом пункте выберите "Настраиваемые", в разделе "Протокол и порты" укажите TCP и в поле "Удалённый порт" введите номер порта прокси.

Проверяем, нет ли блокирующего правила

Иногда проблема не в отсутствии разрешения, а в наличии запрета, который создал антивирус или корпоративная политика.

1. В том же окне расширенных настроек откройте "Правила для исходящего подключения".
2. Нажмите на заголовок столбца "Действие", чтобы отсортировать список. Правила с действием "Блокировать" окажутся рядом.
3. Просмотрите их. Если видите правило, блокирующее ваше приложение или диапазон портов, в который попадает порт прокси, щёлкните по нему правой кнопкой и выберите "Отключить правило".
4. Повторите проверку порта.

Брандмауэр в macOS

1. Откройте Системные настройки, раздел Сеть, затем Брандмауэр.
2. Если брандмауэр включён, нажмите Параметры.
3. Убедитесь, что ваше приложение в списке имеет статус "Разрешить входящие подключения". Хотя нас интересуют исходящие, некоторые приложения открывают локальный порт для работы с прокси.
4. Снимите галочку "Блокировать все входящие подключения", если она стоит, и повторите проверку.

Отдельно проверьте сторонние утилиты вроде Little Snitch или LuLu: они контролируют именно исходящий трафик и могли когда-то запомнить ваш отказ на запрос разрешения. Найдите в их списке правил ваше приложение и разрешите соединения на адрес прокси.

Брандмауэр в Linux

1. Проверьте статус ufw командой sudo ufw status verbose. Обратите внимание на строку Default: если для outgoing указано deny, исходящие соединения блокируются по умолчанию.
2. Разрешите исходящее соединение на порт прокси:

   sudo ufw allow out to 185.10.20.30 port 30001 proto tcp

3. Если используете iptables напрямую, посмотрите правила командой sudo iptables -L OUTPUT -n -v и найдите строки с DROP или REJECT, под которые попадает ваш трафик.
4. На серверах с Docker помните, что контейнеры используют отдельную сетевую подсистему. Проверяйте доступность порта изнутри контейнера, а не только с хоста.

Совет: запишите точное время, когда вы меняли правила брандмауэра. Если через неделю что-то сломается, вы быстро вспомните, какое изменение могло быть причиной, и откатите его через экспортированный на этапе подготовки файл.

Проверка: после этого шага Test-NetConnection или nc показывают успешное соединение с включённым брандмауэром и активным антивирусом. Если порт всё ещё недоступен, а с отключённой защитой тоже не открывался, проблема выше, на уровне роутера или сети. Переходите к шагу 5.

Шаг 5: Проверяем роутер, корпоративную сеть и провайдера

Цель этапа: выяснить, не отбрасывает ли ваш трафик оборудование между компьютером и сервером прокси, и при необходимости исправить настройки роутера или сменить сеть.

Смотрим, где именно теряются пакеты

Утилита трассировки показывает список узлов, через которые проходят пакеты до сервера. Если пакеты доходят до какого-то узла и дальше пропадают, вы видите, чей это узел: ваш роутер, провайдер или что-то дальше.

1. В Windows откройте cmd и выполните tracert 185.10.20.30, подставив IP прокси.
2. В macOS выполните traceroute 185.10.20.30. В Linux лучше использовать mtr -n 185.10.20.30: он показывает статистику в реальном времени и потери на каждом узле.
3. Первая строка это ваш роутер. Вторая и третья обычно оборудование провайдера. Далее магистральные узлы и в конце сервер прокси.
4. Если ответ приходит от всех узлов, кроме последнего, это нормально: серверы прокси часто не отвечают на такие запросы. Смотрите на потери в середине пути.
5. Если звёздочки начинаются сразу после первого узла, ваш роутер или провайдер не пропускают трафик к этому адресу.

Помните: трассировка использует ICMP или UDP, а не TCP на нужный порт, поэтому она показывает общую доступность маршрута, а не открытость порта. Это дополнительный инструмент, а не замена проверке из шага 2.

Проверяем роутер

1. Откройте браузер и введите в адресную строку адрес роутера, обычно 192.168.0.1 или 192.168.1.1. Логин и пароль напечатаны на наклейке снизу устройства, если вы их не меняли.
2. Найдите раздел с названием вроде "Безопасность", "Межсетевой экран", "Фильтрация" или "Родительский контроль".
3. Посмотрите, нет ли включённой фильтрации по портам или по URL. Некоторые роутеры имеют предустановленные профили вроде "Высокий уровень защиты", которые блокируют всё, кроме портов 80 и 443. Переключите на стандартный уровень.
4. Проверьте раздел "Контроль доступа" или "Расписание": там может быть правило, ограничивающее интернет для вашего устройства в определённые часы.
5. Найдите настройку SPI Firewall или "Защита от DoS". Иногда чересчур агрессивная защита воспринимает много параллельных соединений к одному адресу как атаку и начинает их резать. Если у вас десятки потоков парсинга, попробуйте временно отключить эту защиту и повторить проверку.
6. Сохраните изменения и при необходимости перезагрузите роутер.

Внимание: не меняйте настройки роутера, назначение которых вам непонятно, особенно в разделах WAN и DHCP. Ошибка там оставит без интернета весь дом или офис. Если сомневаетесь, сделайте резервную копию конфигурации, как описано в подготовке, и меняйте только один параметр за раз.

Проверяем MTU

MTU это максимальный размер одного пакета данных. Если он выставлен неверно, мелкие запросы проходят, а крупные ответы теряются. Симптом характерный: соединение с прокси устанавливается, маленькие страницы открываются, а большие зависают.

1. В Windows выполните в cmd: ping -f -l 1472 8.8.8.8. Если пакеты проходят, MTU 1500 в порядке. Если пишет "требуется фрагментация", уменьшайте число с шагом 10, пока не пройдёт.
2. Найдите в роутере настройку MTU (обычно в разделе WAN или Интернет) и установите найденное значение плюс 28.
3. Типичные значения: 1500 для обычного кабельного подключения, 1492 для PPPoE, 1400-1450 для некоторых мобильных и спутниковых каналов.

Корпоративная сеть и публичный Wi-Fi

Если вы работаете в офисе, коворкинге или отеле, между вами и интернетом почти наверняка стоит корпоративный шлюз с собственным брандмауэром. Такие шлюзы очень часто разрешают только порты 80 и 443 и режут всё остальное. Пятизначный порт мобильного прокси при этом просто не проходит.

1. Подключитесь к мобильной точке доступа с телефона и повторите проверку порта. Если заработало, виноват корпоративный шлюз.
2. Обратитесь к системному администратору с конкретным запросом: разрешить исходящие TCP-соединения на такой-то IP и такой-то порт. Чем точнее запрос, тем быстрее его выполнят.
3. Уточните у провайдера прокси, есть ли возможность получить порт из стандартного диапазона, например 443 или 8080. У многих сервисов это настраивается.

Домашний провайдер

Домашние провайдеры блокируют исходящие порты редко, но некоторые режут известные диапазоны, связанные с торрентами или почтовыми серверами. Если после всех проверок порт не отвечает из домашней сети, но отвечает через мобильный интернет, позвоните в поддержку провайдера и спросите напрямую, не фильтруют ли они исходящие соединения на указанный порт.

Совет: сохраните вывод трассировки и проверки порта из вашей сети и из мобильной сети в один файл. Когда будете писать провайдеру или администратору, приложите оба результата. Это сократит диалог с недели до одного дня.

Проверка: порт прокси доступен из вашей сети командой из шага 2, трассировка не показывает потерь на узлах провайдера, а ping с флагом -f проходит на размере 1472. Если все три условия выполнены, а прокси всё равно не отвечает, дело в его собственных настройках. Идём к шагу 6.

Шаг 6: Проверяем настройки на стороне прокси

Цель этапа: убедиться, что сервер прокси принимает именно вас: ваш IP в белом списке, модем в сети, ротация не совпадает с вашими запросами, а лимит соединений не превышен.

Проверяем авторизацию по IP

Это самая частая причина, когда прокси работает с телефона, но не работает с компьютера, или работал вчера, а сегодня нет.

1. Узнайте ваш текущий внешний IP. Откройте без прокси любой сайт, показывающий IP, или выполните curl https://api.ipify.org в терминале.
2. Откройте личный кабинет провайдера прокси, раздел с настройками авторизации.
3. Сравните адрес из белого списка с вашим текущим адресом. Если они различаются, вот и причина: ваш провайдер выдал новый адрес после перезагрузки роутера или по расписанию.
4. Обновите адрес в белом списке или переключитесь на авторизацию по логину и паролю. Второй вариант надёжнее, если ваш внешний IP меняется.
5. Подождите одну-две минуты: настройки на сервере прокси применяются не мгновенно.
6. Повторите проверку через curl из шага 2.

Совет: если вы работаете из дома с динамическим IP, авторизация по логину и паролю избавит вас от этой проблемы навсегда. Белый список удобен для серверов со статическим адресом, а не для домашних компьютеров.

Проверяем состояние модема и ротацию

1. В личном кабинете найдите информацию о текущем IP прокси и времени последней смены.
2. Если у вас настроена автоматическая ротация каждые несколько минут, обратите внимание: в момент смены IP модем переподключается к сотовой сети, и на 5-20 секунд прокси действительно не отвечает. Это нормальное поведение, а не поломка.
3. Если ваши запросы регулярно ловят таймаут именно в момент ротации, увеличьте интервал ротации или переключитесь на смену IP по ссылке, чтобы контролировать момент переподключения самостоятельно.
4. Попробуйте принудительно сменить IP через ссылку из кабинета. Если после смены прокси заработал, проблема была в конкретном IP или в зависшем соединении модема.

Проверяем лимит одновременных соединений

У мобильных прокси есть ограничение на количество параллельных соединений с одного порта. Если ваш парсер открыл сто потоков, а лимит пятьдесят, лишние соединения будут висеть в очереди и отваливаться по таймауту.

1. Уточните лимит в описании тарифа или в кабинете.
2. Закройте все приложения, использующие прокси, и выполните одиночный запрос через curl. Если одиночный запрос проходит, а под нагрузкой начинаются таймауты, вы упираетесь в лимит.
3. Уменьшите число потоков в настройках парсера или антидетекта до значения ниже лимита. Для мобильных прокси разумный старт: 5-10 параллельных соединений на один порт.

Проверяем часовые пояса и сотовую сеть

Модем прокси физически находится в конкретном городе и подключён к конкретному оператору. В вечерние часы, когда сотовые сети перегружены, задержки растут в разы. Если таймауты появляются только с 19 до 23 часов по времени региона прокси, это сотовая сеть, а не ваша конфигурация. Решение: увеличить таймауты в это время или распределить нагрузку на другие часы.

Проверка: ваш текущий IP совпадает с белым списком или используется авторизация по паролю, модем в кабинете показывает статус "в сети", одиночный запрос через curl проходит, и число потоков в софте не превышает лимит. Если всё это выполнено, а прокси сервер не отвечает, время написать в поддержку провайдера с приложением результатов всех шести шагов.

Проверка результата: чек-лист стабильного соединения

Вы прошли все шаги. Теперь убедимся, что результат достигнут не случайно и не на одну минуту. Пройдитесь по чек-листу и отметьте каждый пункт.

Чек-лист

• Test-NetConnection или nc показывают успешное TCP-соединение с портом прокси при включённом брандмауэре и антивирусе.
• curl через прокси возвращает IP-адрес мобильного оператора за время не более 5 секунд в пяти попытках подряд.
• Таймаут соединения в вашем софте не меньше 10 секунд, таймаут чтения не меньше 30 секунд.
• Протокол в приложении (HTTP или SOCKS5) совпадает с портом, который прошёл проверку через curl.
• В брандмауэре создано точечное разрешающее правило, а не отключена защита целиком.
• Ваш внешний IP совпадает с белым списком или используется авторизация по паролю.
• Число параллельных соединений в приложении меньше лимита тарифа.
• Резервные копии настроек брандмауэра и роутера сохранены на случай отката.

Нагрузочный тест

Одиночный запрос это одно, а реальная работа это десятки запросов подряд. Проведём короткий тест.

1. Выполните в терминале цикл из 20 запросов. В macOS и Linux:

   for i in $(seq 1 20); do curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -w "%{http_code} %{time_total}\n" https://api.ipify.org; done

   В PowerShell используйте цикл 1..20 | ForEach-Object с той же командой curl внутри.
2. В выводе вы увидите 20 строк с кодом ответа и временем. Все коды должны быть 200, а время не должно превышать 5-6 секунд.
3. Если один-два запроса из двадцати заняли больше, это допустимо для мобильной сети. Если каждый третий запрос уходит в таймаут, вернитесь к шагу 6 и проверьте лимит соединений и ротацию.

Тест в реальном приложении

1. Откройте профиль антидетект-браузера с настроенным прокси и нажмите проверку соединения. Результат должен приходить за 2-4 секунды и показывать IP мобильного оператора.
2. Откройте тяжёлую страницу, например ленту социальной сети. Она должна полностью загрузиться за 10-15 секунд.
3. Оставьте вкладку открытой на 10 минут и обновите страницу. Если она загрузилась, соединение переживает паузы и не рвётся от бездействия.
4. Для скриптов: запустите рабочую задачу на 50-100 запросов и посмотрите на процент успешных. Показатель успеха: не менее 95 процентов без повторов.

Показатели успешного выполнения: порт доступен, время ответа предсказуемо, приложение не жалуется на таймауты в течение 30 минут работы, и вы точно знаете, какой из шести шагов был причиной проблемы. Последнее особенно ценно: в следующий раз вы начнёте диагностику именно с него.

Типичные ошибки и их решения

Здесь собраны ситуации, с которыми пользователи мобильных прокси сталкиваются чаще всего. Формат: что видите, почему так происходит, что делать.

Прокси работает с телефона, но не с компьютера

Причина: брандмауэр или антивирус на компьютере блокирует исходящее соединение на нестандартный порт, либо ваш домашний IP не совпадает с белым списком, а телефон авторизуется другим способом.

Решение: выполните быстрый тест с отключением брандмауэра из шага 4. Если не помогло, сверьте внешний IP компьютера с белым списком по инструкции шага 6.

Соединение устанавливается, но страница не загружается

Причина: вы указали HTTP-порт там, где приложение ожидает SOCKS5, или наоборот. Соединение открывается, но приложение и прокси говорят на разных языках, и данные не идут.

Решение: проверьте оба протокола через curl с ключами http:// и socks5:// и выставьте в приложении тот, что сработал.

Работало неделю, потом перестало без изменений с вашей стороны

Причина: сменился внешний IP вашего интернет-провайдера, а в кабинете прокси настроена авторизация по IP. Второй вариант: обновление антивируса добавило новое блокирующее правило.

Решение: обновите белый список или перейдите на авторизацию по паролю. Проверьте список блокирующих правил в брандмауэре по инструкции шага 4.

Таймауты только в вечернее время

Причина: перегрузка сотовой сети в регионе, где стоит модем прокси. Это особенность мобильного интернета, а не неисправность.

Решение: увеличьте таймаут чтения до 45-60 секунд на вечерние часы, добавьте повторы запросов и по возможности перенесите тяжёлые задачи на утро.

Каждый десятый запрос падает по таймауту

Причина: совпадение запросов с моментом автоматической ротации IP, либо превышение лимита параллельных соединений.

Решение: переключите ротацию на смену по ссылке и вызывайте её между пачками запросов. Снизьте число потоков до 5-10.

В офисе не работает, дома работает

Причина: корпоративный шлюз пропускает только порты 80 и 443.

Решение: запросите у администратора разрешение на конкретный IP и порт или получите у провайдера прокси порт из стандартного диапазона.

Test-NetConnection показывает True, а браузер всё равно висит

Причина: порт открыт, но в браузере настроен другой порт, другой адрес или включено системное исключение, из-за которого трафик идёт мимо прокси. Также возможно, что расширение для прокси конфликтует с системными настройками.

Решение: сверьте посимвольно адрес и порт в браузере с тем, что вы проверяли командой. Отключите все расширения, связанные с прокси, и настройте прокси одним способом.

Маленькие страницы открываются, большие зависают

Причина: неверный MTU на роутере или у провайдера. Крупные пакеты не проходят.

Решение: подберите MTU командой ping с флагом -f из шага 5 и установите его в роутере.

Дополнительные возможности для продвинутых пользователей

Если базовое соединение восстановлено и вам хочется большего контроля, этот раздел для вас. Здесь инструменты и подходы, которые превращают разовую диагностику в постоянный мониторинг.

Смотрим на пакеты: Wireshark и tcpdump

Когда команды из основных шагов не дают однозначного ответа, можно посмотреть на сетевой трафик напрямую.

1. В Linux или macOS выполните:

   sudo tcpdump -i any host 185.10.20.30 and port 30001 -nn

   В Windows установите Wireshark и в фильтре отображения введите ip.addr == 185.10.20.30 and tcp.port == 30001.
2. Запустите проверку порта из шага 2 и смотрите на захваченные пакеты.
3. Если вы видите исходящие пакеты с флагом SYN, но нет ответных SYN-ACK, ваши пакеты уходят, а ответ не возвращается. Блокировка где-то за пределами компьютера.
4. Если пакетов SYN нет вовсе, их отбрасывает локальный брандмауэр ещё до выхода в сеть.
5. Если в ответ приходит RST, порт на сервере закрыт или сервер отказывает именно вам.

Автоматические повторы с нарастающей паузой

Мобильная сеть по природе нестабильна. Вместо того чтобы падать на первом таймауте, настройте повторы с экспоненциальной задержкой: первая попытка через 1 секунду, вторая через 2, третья через 4. В Python это делается через адаптер с классом Retry из urllib3, в Node.js через пакет axios-retry. Три повтора с такой схемой снимают 90 процентов случайных таймаутов без потери данных.

Постоянные соединения и пулы

Каждое новое TCP-соединение через мобильный прокси стоит 100-500 миллисекунд на установку. Если ваш скрипт открывает новое соединение на каждый запрос, вы теряете время и быстрее упираетесь в лимит. Используйте сессии: в Python requests.Session, в Node.js агент с keepAlive: true. Одно соединение будет переиспользоваться для десятков запросов.

Мониторинг доступности

Настройте простую проверку раз в минуту: скрипт делает запрос через прокси и записывает время ответа и код. За неделю вы получите картину, в какие часы прокси быстрее, а когда ловит таймауты. Это позволит планировать нагрузку и заранее видеть деградацию, а не узнавать о ней от сломанных задач.

*/1 * * * * curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -m 20 -w "$(date +%H:%M) %{http_code} %{time_total}\n" https://api.ipify.org >> /var/log/proxy-check.log

DNS через прокси

По умолчанию некоторые приложения разрешают доменные имена локально, а не через прокси. Это может приводить к утечке информации и к ситуациям, когда локальный DNS отдаёт адрес, недоступный из мобильной сети. В настройках браузеров и антидетектов ищите опцию "DNS через прокси" или используйте протокол socks5h вместо socks5 в curl и Python: буква h означает, что имена будет разрешать сам прокси.

Смена порта на стандартный

Если вы часто работаете из разных сетей, уточните у провайдера возможность назначить прокси порт 443 или 8080. Такие порты открыты практически везде, и вам не придётся каждый раз воевать с корпоративными брандмауэрами.

Тонкая настройка ротации

Продвинутый сценарий: связать смену IP с логикой приложения. Перед началом новой пачки запросов скрипт дёргает ссылку смены IP, ждёт 10-15 секунд, проверяет через api.ipify.org, что адрес действительно поменялся, и только затем начинает работу. Так вы полностью исключаете таймауты из-за случайного совпадения запроса с ротацией.

Совет: добавьте в лог каждого запроса не только время, но и текущий IP прокси. Когда через месяц вы будете разбирать, почему просели показатели, корреляция между конкретными IP и таймаутами сразу подскажет, какие адреса оператора были проблемными.

FAQ: частые вопросы по диагностике

Прокси сервер не отвечает, но пинг проходит. Что это значит?

Ping проверяет только доступность IP по протоколу ICMP, а не открытость порта. Сервер может быть жив и отвечать на ping, но порт прокси при этом фильтруется брандмауэром или служба на нём не запущена. Всегда проверяйте именно TCP-порт командами из шага 2.

Сколько ждать, прежде чем считать, что прокси не отвечает?

Для установки соединения с мобильным прокси нормально до 1 секунды, предел 10 секунд. Для получения данных нормально до 5 секунд, предел 30-45 секунд. Если соединение не установилось за 10 секунд, дальше ждать бессмысленно: ответ не придёт.

Можно ли просто отключить брандмауэр и работать так?

Нет. Отключение защиты допустимо только на минуту для проверки гипотезы. После этого создайте точечное правило для конкретного приложения или порта, как описано в шаге 4, и включите брандмауэр обратно. Компьютер без защиты в сети это риск для ваших аккаунтов и данных.

Почему прокси работает в одном браузере и не работает в другом?

Обычно потому, что один браузер использует системные настройки прокси, а второй свои собственные, и в них указаны разные данные. Второй вариант: брандмауэр разрешил один исполняемый файл и не разрешил другой. Проверьте настройки обоих браузеров и список правил брандмауэра.

Как понять, что дело в ротации IP, а не в моих настройках?

Запишите время каждого таймаута в течение часа и сравните с интервалом ротации из кабинета. Если таймауты приходят с той же периодичностью, что и смена IP, это ротация. Переключитесь на смену по ссылке, и проблема исчезнет.

Обязательно ли использовать терминал? Нет ли графических инструментов?

Терминал быстрее и точнее, но есть альтернативы. В антидетект-браузерах встроена проверка прокси с выводом времени ответа. Есть настольные программы для проверки списков прокси с индикацией открытых портов. Однако для поиска причины именно у вас терминал незаменим: он показывает, на каком этапе остановилось соединение.

Что делать, если все шесть шагов пройдены, а проблема осталась?

Пишите в поддержку провайдера прокси и приложите: вывод Test-NetConnection или nc, вывод curl с ключом -v, результат трассировки, ваш внешний IP, время попыток и информацию о том, работает ли прокси из другой сети. С такими данными специалист найдёт причину за один ответ, а не за пять уточняющих вопросов.

Нужно ли перезагружать компьютер после изменения правил брандмауэра?

Нет, правила брандмауэра Windows, macOS и Linux применяются мгновенно. Перезагрузка нужна только роутеру после изменения MTU или профилей безопасности, и то не на всех моделях.

Можно ли использовать один и тот же подход для датацентровых прокси?

Да, шаги с 1 по 5 универсальны для любого типа прокси. Отличается шаг 3: датацентровые прокси отвечают быстрее, и таймауты можно ставить меньше. И шаг 6: у датацентровых нет ротации через переподключение модема, поэтому пауз в момент смены IP не будет.

Заключение

Давайте подведём итог. Вы научились не паниковать при сообщении о том, что прокси сервер не отвечает, а разбирать ситуацию по цепочке. Сначала вы определили, работает ли прокси хотя бы откуда-нибудь. Затем проверили, открыт ли порт именно с вашего устройства. Разобрались с таймаутами и поняли разницу между таймаутом соединения и таймаутом чтения. Проверили брандмауэр и антивирус и создали точечное правило вместо отключения защиты. Изучили роутер, MTU и корпоративный шлюз. И наконец, убедились, что сам прокси принимает именно вас: белый список, модем, ротация, лимиты.

Главный результат даже не в том, что соединение восстановлено. Он в том, что у вас теперь есть метод. В следующий раз, когда что-то зависнет, вы не будете гадать и перебирать настройки наугад. Вы откроете терминал, выполните две команды и за минуту узнаете, на каком участке цепочки обрыв.

Что делать дальше

1. Сохраните файл с рабочими командами и вашими данными прокси в удобном месте. Это ваш набор первой помощи.
2. Переведите авторизацию на логин и пароль, если ещё используете белый список с домашнего компьютера.
3. Проверьте таймауты во всех приложениях, которые работают через мобильные прокси, и приведите их к рекомендованным значениям.
4. Настройте минутный мониторинг из продвинутого раздела хотя бы на одном прокси, чтобы через неделю увидеть реальную картину стабильности.

Куда развиваться

Следующий уровень это автоматизация обработки сбоев: повторы с нарастающей паузой, управляемая ротация, пулы соединений и логирование каждого запроса с привязкой к IP. Освоив это, вы перестанете замечать единичные таймауты вообще: ваша система будет переживать их сама, а вы будете видеть лишь итоговые метрики. Удачи в работе, и пусть ваши прокси отвечают всегда с первого раза.