Ошибка прокси-сервера 407, 502, 504 и tunnel failed: пошаговая диагностика для начинающих

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

Если вы работаете с мобильными прокси, рано или поздно вы увидите в логах парсера, в консоли антидетект-браузера или прямо в окне рекламного кабинета строку вроде «407 Proxy Authentication Required», «502 Bad Gateway», «504 Gateway Timeout» или короткое и пугающее «tunnel failed». Ошибка прокси сервера в такой момент похожа на черный ящик: непонятно, виноват ли сам прокси, ваш софт, целевой сайт или просто устаревший пароль. Этот гайд превращает черный ящик в понятную схему действий.

Мы сознательно ограничиваем тему: разбираем только коды и сообщения, которые возвращает прокси-слой. Сетевые таймауты уровня соединения (когда ответа нет вообще и клиент сам обрывает ожидание) в блоге разобраны отдельно, и здесь мы их не дублируем. Если у вас в логе стоит именно код или фраза о туннеле, вы по адресу.

Что вы получите в итоге

• Поймете, что означает каждая из четырех ошибок и в каком именно месте цепочки «ваш софт — прокси — целевой сайт» она рождается.
• Научитесь за две-три минуты определять источник проблемы с помощью встроенной в любую систему утилиты curl.
• Получите готовые последовательности действий для 407, 502, 504 и tunnel failed, которые можно выполнять как чек-лист.
• Настроите свой софт так, чтобы он правильно реагировал на каждый код: одни ошибки нужно повторять, другие повторять бессмысленно.
• Соберете личный журнал инцидентов, который сэкономит часы при следующем сбое.

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

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

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

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

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

Полное прочтение и первая диагностика займут от 60 до 120 минут. Если у вас сейчас горит конкретная ошибка, переходите к нужному шагу: на каждую отдельную ошибку заложено 15-25 минут вместе с проверками.

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

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

Необходимые инструменты

1. Терминал или командная строка. В Windows 10 и 11 откройте меню «Пуск», введите «cmd» или «PowerShell» и нажмите Enter. В macOS откройте «Программы», затем «Утилиты», затем «Терминал». В Linux терминал обычно вызывается сочетанием Ctrl+Alt+T.
2. Утилита curl. Она встроена в Windows начиная с версии 10 (сборка 1803), в macOS и в большинство дистрибутивов Linux. Проверьте: введите в терминале curl --version и нажмите Enter. Должна появиться строка с номером версии, например «curl 8.x.x». Если вместо этого написано, что команда не найдена, установите curl через менеджер пакетов вашей системы.
3. Обычный браузер с инструментами разработчика. Подойдет любой современный браузер, где по клавише F12 открывается панель с вкладкой «Network» (Сеть).
4. Текстовый редактор для ведения журнала инцидентов. Хватит Блокнота, но удобнее что-то с подсветкой, чтобы видеть структуру логов.
5. Ваш рабочий софт: антидетект-браузер, парсер, менеджер рекламных кабинетов или собственный скрипт. Нам понадобится доступ к его настройкам прокси и к его логам.

Необходимые доступы

• Вход в личный кабинет поставщика прокси. Для пользователей mobileproxy.space это страница управления вашими каналами, где видны хост, порт, логин, пароль, тип авторизации и ссылка для смены IP.
• Актуальные реквизиты хотя бы одного прокси: адрес (хост), порт, логин и пароль или подтвержденный IP для авторизации по адресу.
• Понимание того, какой протокол вы используете: HTTP(S)-прокси или SOCKS5. Эту информацию тоже покажет кабинет.

Системные требования

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

Резервные копии

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

1. В антидетект-браузере экспортируйте список профилей вместе с настройками прокси. Обычно функция экспорта лежит в меню профилей и создает файл CSV или JSON.
2. В парсере или скрипте скопируйте файл конфигурации в отдельную папку с датой в названии, например «config_backup_2026-03-14».
3. Из личного кабинета скопируйте в текстовый файл реквизиты всех каналов. Храните этот файл там, где к нему нет доступа посторонним.
4. Запишите, какой IP у вашего компьютера или сервера сейчас. Он понадобится, если вы используете авторизацию по IP-адресу.

Совет: заведите один текстовый файл «Журнал прокси» и записывайте туда каждую ошибку в формате «дата, время, код, хост прокси, целевой сайт, что сделал, что помогло». Через месяц у вас будет личная база знаний, которая полезнее любой статьи.

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

Базовые понятия: как устроен прокси-слой и откуда берутся коды

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

Три участка пути запроса

• Клиент — прокси. Ваш браузер, парсер или скрипт подключается к хосту и порту прокси. На этом участке проверяется авторизация. Здесь рождается ошибка 407 и часть случаев tunnel failed.
• Прокси — мобильная сеть — целевой сайт. Прокси-сервер, получив ваш запрос, открывает от своего имени соединение через модем с SIM-картой оператора к нужному сайту. Здесь возникают 502 и 504.
• Целевой сайт — обратный путь. Ответ сайта идет назад через те же узлы. Если сайт вернул свой собственный код, например 403 или 429, это уже не ошибка прокси-слоя, и важно научиться их различать.

Классы кодов простым языком

Код ответа — это трехзначное число, которое сервер отправляет первой строкой ответа. Первая цифра говорит о классе. Коды 4xx означают «проблема на вашей стороне, исправьте запрос». Коды 5xx означают «проблема на стороне сервера или за ним». Для прокси-слоя это работает так:

• 407 Proxy Authentication Required — прокси говорит: «Я не знаю, кто ты, или твои данные неверны». Класс 4xx: чинить нужно у себя.
• 502 Bad Gateway — прокси говорит: «Я попробовал достучаться дальше, но получил обрыв или мусор вместо ответа». Класс 5xx: проблема за прокси или в самом прокси.
• 504 Gateway Timeout — прокси говорит: «Я ждал ответа от следующего узла положенное время и не дождался». Это тоже 5xx.

Чем код 504 отличается от сетевого таймаута

Это ключевое разграничение для всей статьи. Когда вы видите код 504, значит прокси-сервер жив, принял ваш запрос, сам ждал ответ сайта и сам сообщил вам о неудаче. Соединение между вами и прокси при этом работало идеально. Когда же ваш клиент пишет «connection timed out» или «operation timed out» без кода, значит ответа не было вовсе, и обрыв инициировал ваш софт. Первое — предмет этого гайда. Второе — другая тема, разобранная в смежных материалах блога. Простой признак: есть трехзначное число в ответе — читайте дальше здесь.

Что такое туннель и почему он «падает»

Когда вы открываете сайт по HTTPS через HTTP-прокси, браузер сначала отправляет прокси особую команду CONNECT с адресом и портом назначения. Прокси открывает соединение с сайтом и отвечает «200 Connection established». После этого через прокси идет зашифрованный поток, который сам прокси уже не читает. Такое соединение называется туннелем. Если на команду CONNECT прокси ответил чем-то, кроме 200, клиент пишет «tunnel failed» и рядом обычно указывает, какой именно код пришел. То есть tunnel failed — не самостоятельная ошибка, а обертка над одним из кодов.

Два способа авторизации

• Логин и пароль. Клиент передает их в заголовке Proxy-Authorization. Самый распространенный способ, и самый частый источник 407.
• Авторизация по IP. Вы заранее указываете в кабинете адрес своего компьютера или сервера, и прокси пускает все запросы с этого адреса без пароля. Удобно, но ломается, когда ваш IP меняется.

Служебные заголовки, по которым видно автора ответа

Прокси часто добавляет к своим ответам заголовки Via, Proxy-Agent или X-Proxy. Целевые сайты их не ставят. Если в ответе с кодом 502 есть заголовок Proxy-Agent, вы точно знаете, что ответил прокси. Если заголовков нет, а есть Server с названием веб-сервера сайта, это ответ самого сайта. Мы будем активно использовать этот признак.

Совет: запомните мнемоническое правило: «четверка — ищи у себя, пятерка — ищи за прокси, туннель — смотри, какое число рядом». Оно решает половину случаев без дальнейшего чтения.

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

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

Инструкция

1. Откройте личный кабинет и скопируйте реквизиты проблемного прокси: хост, порт, логин, пароль. Для примера будем считать, что хост — proxy.example.net, порт — 8080, логин — user1, пароль — pass1. Подставляйте свои значения.
2. Откройте терминал.
3. Введите команду, заменив реквизиты и целевой адрес на свои, и нажмите Enter: curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Ключ -v включает подробный вывод, ключ -x задает прокси.
4. Дождитесь завершения команды. Обычно это одна-три секунды. Если команда «висит» дольше 30 секунд, нажмите Ctrl+C: скорее всего, у вас сетевой таймаут, а не код, и это не наша тема.
5. Найдите в выводе строки, начинающиеся с символа «больше» (это то, что отправил curl) и с символа «меньше» (это то, что пришло в ответ). Первая строка ответа будет вида «HTTP/1.1 407 Proxy Authentication Required» или «HTTP/1.1 200 Connection established».
6. Посмотрите на строку с надписью CONNECT. Если сразу после нее пришел код, отличный от 200, значит ошибку вернул прокси на стадии туннеля. Если CONNECT получил 200, а код ошибки пришел позже, после строк о TLS-рукопожатии, значит ответил уже целевой сайт.
7. Найдите заголовки ответа. Наличие Proxy-Agent, Via или похожих служебных заголовков однозначно указывает на прокси. Заголовок Server с названием веб-сервера и заголовок Set-Cookie указывают на целевой сайт.
8. Повторите ту же команду без ключа -x, то есть напрямую: curl -v https://example.com/. Если сайт отвечает 200, а через прокси приходит 5xx, проблема локализована на участке за прокси.
9. Повторите команду через прокси, но к другому сайту, например к любому стабильному крупному ресурсу. Если второй сайт открывается, проблема связана с конкретным направлением, а не с прокси в целом.
10. Скопируйте весь вывод в журнал прокси вместе с датой и временем. Вам понадобится он на следующих шагах.

Альтернативный путь через браузер

Если работать в терминале неудобно, откройте браузер с настроенным прокси, нажмите F12, перейдите на вкладку «Network», поставьте галочку «Preserve log» (Сохранять журнал), обновите страницу. В списке запросов найдите строку с красным кодом, кликните по ней и на вкладке «Headers» изучите блок «Response Headers». Логика та же: ищите служебные заголовки прокси. Недостаток способа в том, что браузер часто скрывает детали стадии CONNECT, поэтому для tunnel failed терминал предпочтительнее.

Внимание: команда с ключом -v выводит логин и пароль прокси в открытом виде. Не вставляйте этот вывод в общие чаты, тикеты поддержки и скриншоты без замены пароля на звездочки.

Совет: добавьте к команде ключ -sS вместе с -o и указанием пустого устройства, чтобы не засорять экран телом ответа: curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. В Windows вместо /dev/null используйте NUL.

Ожидаемый результат

В журнале появилась запись с полным ответом, и вы можете уверенно сказать одно из трех: «ответил прокси на стадии авторизации», «ответил прокси на стадии обращения к сайту» или «ответил сам сайт». Это направляет вас к шагу 2, 3-4 или вовсе за пределы этой статьи.

Возможные проблемы

• Команда пишет «Could not resolve proxy». Опечатка в хосте. Сверьте с кабинетом посимвольно.
• Команда пишет «Failed to connect to proxy». Порт закрыт или неверен. Это транспортная проблема, не код, проверьте порт и попробуйте другой канал.
• Вывод обрывается на строке TLS без кода. Значит туннель установлен, но сайт не ответил в отведенное время вашего клиента. Не путайте с 504: кода нет, значит это не наш случай.

Проверка: вы можете назвать автора ответа и точный код или фразу, а строка вывода curl сохранена в журнале.

Шаг 2: Устраняем ошибку 407 Proxy Authentication Required

Цель этапа: добиться того, чтобы на команду CONNECT прокси отвечал «200 Connection established», а не 407, и понять причину, чтобы ошибка не вернулась.

Почему возникает 407

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

Инструкция

1. Откройте личный кабинет и найдите проблемный канал. Убедитесь, что срок его действия не истек и статус активный. Если срок вышел, продлите его и повторите запрос через минуту; в этом случае дальше идти не нужно.
2. Проверьте, какой тип авторизации включен для канала: логин и пароль или по IP-адресу. Многие панели позволяют включить оба одновременно.
3. Если включена авторизация по IP, узнайте текущий внешний адрес вашего компьютера или сервера. Откройте в браузере без прокси любой сервис, показывающий ваш IP, и сравните с адресом, который записан в кабинете. Домашние провайдеры и мобильные операторы часто меняют адрес после перезагрузки роутера. Если адреса разошлись, обновите его в кабинете и подождите одну-две минуты: изменения применяются не мгновенно.
4. Если используются логин и пароль, скопируйте их из кабинета заново, не перепечатывая руками. Вставьте в команду curl из шага 1 и запустите. Половина случаев 407 заканчивается здесь.
5. Посмотрите на пароль. Если в нем есть символы @, :, /, #, ?, % или пробел, при передаче в строке адреса их нужно кодировать. Символ @ превращается в %40, двоеточие в %3A, решетка в %23, знак процента в %25. Например, пароль p@ss:1 в URL записывается как p%40ss%3A1. Чтобы не кодировать, передайте данные отдельным ключом: curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Здесь curl сам разберется с символами.
6. Если curl проходит, а ваш рабочий софт по-прежнему получает 407, проблема в самом софте. Откройте его настройки прокси. Проверьте, что логин и пароль введены в отдельные поля, а не приклеены к адресу, если программа этого не ожидает. Проверьте, нет ли пробела в конце пароля: он часто появляется при копировании.
7. В антидетект-браузере откройте настройки конкретного профиля, а не глобальные настройки. Многие пользователи меняют пароль в общем списке прокси, но профиль продолжает хранить старую копию. Пересохраните прокси в профиле и перезапустите профиль.
8. Если браузер запомнил старые данные и не спрашивает новые, очистите сохраненные пароли для этого хоста в настройках браузера или создайте новый профиль для теста.
9. Обратите внимание на заголовок Proxy-Authenticate в ответе 407. Если там написано «Basic», значит прокси ждет обычную пару логин-пароль. Если указана другая схема, ваш софт должен ее поддерживать; для мобильных прокси почти всегда используется Basic, и несоответствие означает ошибку в настройках типа прокси.
10. Повторите запрос curl и убедитесь, что теперь на CONNECT приходит 200.

Внимание: не пытайтесь «решить» 407 массовым повтором запросов. Некоторые прокси-серверы временно блокируют адрес после серии неверных авторизаций, и вы получите дополнительную проблему поверх исходной. Одна проверка, одно исправление, одна проверка.

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

Ожидаемый результат

В выводе curl строка ответа на CONNECT стала «HTTP/1.1 200 Connection established», сайт отдал контент. В рабочем софте запросы проходят. В журнале записана причина: опечатка, кодирование, смена IP, истечение срока или кеш.

Возможные проблемы

• Код 407 приходит дважды: сначала на CONNECT, потом внутри туннеля. Это признак того, что софт отправляет данные только на одну из стадий. Обновите программу или включите в ней опцию передачи авторизации при CONNECT.
• Кабинет говорит, что IP добавлен, а 407 остается. Вы, вероятно, работаете через корпоративную сеть или сервер с несколькими исходящими адресами. Проверьте адрес именно с той машины, откуда идут запросы.
• Работает у вас, не работает у коллеги с теми же данными. При авторизации по IP это ожидаемо: у коллеги другой адрес. Переключитесь на логин и пароль или добавьте второй IP.

Проверка: три запроса подряд через curl и через рабочий софт прошли без 407, причина записана в журнал.

Шаг 3: Разбираемся с ошибкой 502 Bad Gateway от прокси

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

Почему прокси возвращает 502

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

Инструкция

1. Зафиксируйте точное время появления 502 с секундами. Это важно для следующего пункта.
2. Откройте в кабинете историю смены IP по этому каналу или вспомните, включена ли у вас автоматическая ротация по расписанию. Если ротация сработала в те же секунды, что и ошибка, вы столкнулись с нормальным поведением: во время переключения адреса запросы на две-десять секунд получают 502. Решение — повторить запрос через паузу.
3. Подождите десять секунд и повторите команду curl из шага 1. Если ответ стал 200, запишите в журнал «502 в момент ротации» и переходите к настройке повторов на шаге 6.
4. Если 502 повторяется устойчиво, проверьте другой сайт через тот же прокси. Открылся — проблема в направлении. Не открылся — проблема в канале.
5. Для проблемы в направлении: откройте целевой сайт напрямую без прокси. Если он и напрямую недоступен или отдает 5xx, прокси ни при чем: сайт лежит. Если напрямую все работает, сайт, вероятно, разрывает соединения с адресов данного оператора. Смените IP по ссылке из кабинета и повторите. Если не помогло, попробуйте канал другого оператора или региона.
6. Для проблемы в канале: проверьте в кабинете статус оборудования. У многих поставщиков есть индикатор состояния модема. Красный или желтый статус означает, что канал восстанавливается, и остается только дождаться или переключиться на резервный.
7. Проверьте нагрузку. Посмотрите в своем софте, сколько одновременных потоков идет через этот канал. Мобильный канал имеет ограниченную пропускную способность, и при десятках параллельных соединений прокси начинает отклонять часть запросов именно с 502. Снизьте параллельность вдвое и повторите тест.
8. Проверьте, не связано ли с DNS. Выполните запрос к сайту по IP-адресу вместо домена, если сайт это позволяет, либо переключитесь на схему socks5h, при которой имена разрешает прокси, и сравните результат. Если по имени 502, а по IP все работает, дело в разрешении имен на стороне прокси; сообщите поставщику точное имя домена.
9. Если ничего не помогло в течение 15 минут, соберите вывод curl -v, время, хост канала, целевой домен и отправьте в поддержку поставщика. Правильно собранная информация сокращает решение с суток до часа.

Совет: при работе с ротацией по расписанию заранее синхронизируйте паузы в софте с интервалом смены IP. Если адрес меняется каждые 5 минут, пусть парсер делает паузу на 15 секунд в начале каждой пятиминутки. Число 502 упадет почти до нуля без единой строчки сложного кода.

Ожидаемый результат

Вы точно знаете, к какой из категорий относится ваша 502: момент ротации, конкретное направление, перегрузка канала, сбой оборудования или недоступность сайта. Для первых трех у вас есть исправление, для последних двух — понимание, что ждать и кому писать.

Возможные проблемы

• 502 приходит только на большие файлы. Сайт закрывает соединение из-за медленной скорости отдачи. Уменьшите размер запрашиваемых данных или используйте канал с лучшим покрытием.
• 502 приходит от сайта, а не от прокси. Проверьте заголовки: если там Server сайта и нет Proxy-Agent, это внутренний сбой сайта, повторите позже.
• 502 чередуется с 200 без видимой логики. Классический признак перегрузки канала. Снижайте параллельность до стабильного результата.

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

Шаг 4: Работаем с кодом 504 Gateway Timeout

Цель этапа: понять, на каком участке за прокси теряется время, и сократить долю 504 до приемлемого уровня, не путая код с сетевым таймаутом клиента.

Что именно означает 504 от прокси

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

Инструкция

1. Проверьте лимит ожидания в своем софте. В большинстве программ он называется timeout, «время ожидания ответа» или «Read timeout». Если он меньше 30 секунд, временно поставьте 60. Это диагностический шаг: вам нужно дождаться именно кода от прокси.
2. Измерьте время до ответа через прокси. Выполните: curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Ключ -w выводит четыре числа: код, время до соединения, время до первого байта и общее время в секундах.
3. Выполните ту же команду без ключа -x. Сравните время до первого байта. Если напрямую сайт отвечает за 0,4 секунды, а через прокси за 8 секунд, задержка на участке «прокси — сайт» велика, и 504 будет появляться при любых колебаниях мобильной сети.
4. Проверьте, на каком запросе появляется 504. Сделайте запрос методом HEAD, который не загружает тело страницы: curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Если HEAD проходит, а GET страницы дает 504, проблема в размере или медленной генерации страницы, а не в соединении как таковом.
5. Смените IP канала по ссылке из кабинета. Мобильная сеть неоднородна: один адрес может выйти на перегруженную базовую станцию, другой на свободную. Повторите измерение. Если время упало в несколько раз, добавьте в софт правило: при 504 сначала менять IP, затем повторять запрос.
6. Проверьте тяжесть целевой страницы. Некоторые сайты отдают ответ только после выполнения долгих серверных операций. Если ваша цель — конкретные данные, попробуйте обращаться к более легкому адресу на том же сайте: к API, к мобильной версии, к странице без параметров сортировки.
7. Если 504 приходит только на определенный домен и только через каналы одного оператора, зафиксируйте это в журнале и перераспределите работу с этим доменом на каналы другого оператора.
8. Верните лимит ожидания в софте к рабочему значению, но теперь осознанно: он должен быть немного больше типичного времени ответа через прокси и меньше, чем вы готовы ждать в рамках задачи. Для большинства сценариев это 30-45 секунд.

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

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

Ожидаемый результат

Вы знаете типичное время ответа через каждый канал, установили лимит в софте выше лимита прокси, и 504 стали редким событием, на которое настроена автоматическая реакция.

Возможные проблемы

• Вы увеличили лимит, а вместо 504 стали получать сетевой таймаут. Значит прокси ждет дольше, чем вы думали, либо соединение с самим прокси нестабильно. Это уже за пределами кодов, смотрите смежные материалы о таймаутах.
• 504 только в определенные часы. Вечерний пик нагрузки на мобильные сети. Перенесите тяжелые задачи на ночь или утро.
• 504 на первом запросе к новому сайту, потом все быстро. Первичное разрешение имени и установка соединения на стороне прокси. Добавьте один прогревающий запрос перед основной серией.

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

Шаг 5: Исправляем ошибку tunnel failed

Цель этапа: научиться читать число рядом с фразой tunnel failed, сопоставлять его с реальной причиной и исправлять настройки протокола, порта и типа прокси.

Как выглядит и что означает

В curl сообщение выглядит так: «CONNECT tunnel failed, response 407». В браузерах и антидетект-решениях это могут быть фразы «Proxy tunnel failed», «Unable to establish tunnel» или «Tunnel connection failed». Общее одно: клиент отправил команду CONNECT, а прокси ответил не 200. Число рядом — тот самый код, и работа с ним сводится к предыдущим шагам плюс несколько особых случаев, которые проявляются только на стадии туннеля.

Инструкция

1. Запустите curl с ключом -v к HTTPS-адресу и найдите строку с tunnel failed. Запишите число после слова response.
2. Если это 407, вернитесь к шагу 2. Отличие только в одном: убедитесь, что софт передает авторизацию именно на стадии CONNECT. В старых версиях некоторых программ галочка «Авторизация прокси» действует только на HTTP-запросы, а туннель уходит без пароля.
3. Если это 502 или 504, вернитесь к шагам 3 и 4. Прокси не смог открыть соединение с портом 443 сайта или не дождался его.
4. Если это 403, прокси отказался открывать туннель к указанному порту или хосту. Проверьте, к какому порту вы подключаетесь. Мобильные прокси обычно разрешают туннели на 443 и несколько распространенных портов. Если ваш сервис слушает нестандартный порт, уточните в кабинете или у поставщика, разрешен ли он.
5. Если это 400, прокси не понял команду. Самая частая причина — вы указали SOCKS5-прокси как HTTP или наоборот. Откройте кабинет и посмотрите, какой протокол и порт выдан. У многих поставщиков для HTTP и SOCKS5 разные порты одного и того же канала.
6. Исправьте схему в команде. Для SOCKS5 используйте: curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. Буква h в socks5h означает, что доменные имена разрешает прокси, а не ваш компьютер. Для мобильных прокси это предпочтительный вариант.
7. Если вы в антидетект-браузере, откройте настройки прокси профиля и найдите выпадающий список типа: HTTP, HTTPS, SOCKS5. Выберите тот, что указан в кабинете, и проверьте порт. После сохранения перезапустите профиль полностью, а не просто обновите вкладку.
8. Если число рядом с tunnel failed отсутствует, а есть только фраза, включите в софте расширенное логирование или воспроизведите ситуацию через curl, чтобы получить код.
9. Проверьте, не пытается ли ваш софт установить TLS-соединение с самим прокси. Некоторые программы при выборе типа «HTTPS» шифруют не только трафик к сайту, но и подключение к прокси. Если прокси этого не поддерживает, вы получите tunnel failed или ошибку рукопожатия. Переключитесь на тип «HTTP» для подключения к прокси: трафик к сайту при этом все равно остается зашифрованным внутри туннеля.
10. Повторите тест и убедитесь, что CONNECT получает 200 и страница загружается.

Совет: сделайте два коротких тестовых запроса частью ежедневной рутины: один к адресу по HTTP, второй к тому же адресу по HTTPS. Если первый проходит, а второй падает с tunnel failed, вы за секунду понимаете, что дело в туннеле, а не в авторизации или канале.

Ожидаемый результат

Фраза tunnel failed исчезла из логов, для каждого канала записан верный тип и порт, а в софте не включено лишнее шифрование подключения к прокси.

Возможные проблемы

• Туннель устанавливается, но затем ошибка сертификата. Это уже не прокси-слой: сайт или ваш системный набор сертификатов. Проверьте дату и время на компьютере.
• Работает в curl, не работает в софте при тех же данных. Софт применяет другую схему или добавляет свой префикс. Изучите его документацию по формату строки прокси.
• tunnel failed только для одного сайта. Сайт использует нестандартный порт, вернитесь к пункту про 403.

Проверка: HTTPS-запрос через curl и через рабочий софт дает 200 на CONNECT, тип и порт для всех каналов записаны в таблице.

Шаг 6: Настраиваем правильную реакцию софта на каждый код

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

Принцип: не все ошибки одинаковы

Повторять запрос при 407 бессмысленно: пароль не станет верным от повтора. Повторять при 502 в момент ротации необходимо: через пять секунд все заработает. Повторять при 504 лучше после смены IP. Эти три правила составляют основу здоровой обработки ошибок.

Инструкция для готового софта

1. Откройте настройки парсера или менеджера аккаунтов и найдите раздел, отвечающий за повторы. Он может называться «Retries», «Повторные попытки», «Обработка ошибок».
2. Установите число повторов для 5xx на 3, а начальную паузу между ними на 5 секунд с увеличением в два раза: 5, 10, 20 секунд. Такой рост пауз называется экспоненциальной задержкой и не дает вашему софту добить перегруженный канал.
3. Если софт позволяет задавать список кодов для повтора, укажите 502 и 504. Не включайте туда 407.
4. Найдите настройку действия при 407. Если ее нет, установите число повторов в общем разделе на минимум и включите уведомление о неудачных запросах. Ваша цель — увидеть 407 в первые минуты, а не через сутки простоя.
5. Найдите поле для ссылки смены IP, если оно есть. Вставьте туда ссылку из кабинета для соответствующего канала и включите опцию «Менять IP при ошибке» либо «Ротация при неудаче».
6. Ограничьте число одновременных потоков на один мобильный канал. Начните с 3-5 и повышайте, пока доля 502 остается ниже одного процента.
7. Включите подробный лог с сохранением кода ответа и заголовков. Убедитесь, что в логе видна разница между кодом от прокси и кодом от сайта: многие программы это показывают в отдельном столбце «Proxy status».
8. Сохраните настройки, перезапустите софт и проведите тестовую серию из 50 запросов.

Инструкция для собственного скрипта

Если вы пишете код, логика та же. В псевдокоде на Python с библиотекой requests это выглядит так:

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Обратите внимание на три момента. Первый: при 407 мы выходим из цикла сразу и отправляем уведомление. Второй: при 502 и 504 мы сначала меняем IP, затем ждем растущую паузу. Третий: значение timeout выбрано так, чтобы дождаться кода от прокси, а не обрывать соединение раньше.

Внимание: в некоторых библиотеках ошибка на стадии CONNECT приходит не как ответ с кодом, а как исключение с текстом, содержащим tunnel failed и число. Ловите такие исключения отдельно и извлекайте код из текста, иначе ваша логика повторов не сработает.

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

Ожидаемый результат

Софт автоматически повторяет запросы при 502 и 504 с растущей паузой и сменой IP, немедленно сообщает о 407, ограничивает число потоков и ведет лог с разделением кодов прокси и сайта.

Возможные проблемы

• Софт повторяет и 407 тоже, из-за чего прокси временно блокирует адрес. Отключите повторы для 4xx полностью или снизьте общее число повторов до одного.
• После включения ротации при ошибке IP меняется слишком часто. Введите минимальный интервал между сменами, например 60 секунд, чтобы одна серия 502 не вызывала пять ротаций подряд.
• Лог разрастается до гигабайтов. Пишите заголовки только для ответов с кодами ошибок, а для 200 сохраняйте одну строку.

Проверка: тестовая серия из 50 запросов завершилась без ручного вмешательства, в логе видны повторы с паузами 5, 10, 20 секунд для 5xx, а при подстановке неверного пароля софт остановился и вывел уведомление о 407.

Проверка результата: чек-лист и тесты

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

Чек-лист

• Команда curl с ключом -v выполняется, и вы умеете находить в выводе строку ответа на CONNECT и служебные заголовки прокси.
• Для каждого канала в таблице записаны хост, порт, тип протокола, способ авторизации и закодированный пароль.
• При авторизации по IP текущий адрес вашей машины совпадает с адресом в кабинете.
• HTTPS-запрос через каждый канал получает 200 на CONNECT.
• Измерено типичное время до первого байта через каждый канал, и лимит ожидания в софте превышает его с запасом.
• В софте настроены повторы только для 502 и 504, с паузами 5, 10, 20 секунд и смене IP перед повтором.
• При 407 софт останавливается и уведомляет.
• Число потоков на канал ограничено, и доля 5xx за тестовую серию ниже одного процента.
• Журнал инцидентов ведется и содержит хотя бы одну полностью разобранную запись.

Как протестировать

1. Намеренно введите неверный пароль и запустите один запрос. Ожидаемо: 407 в curl и уведомление в софте без серии повторов.
2. Верните верный пароль и запустите 30 запросов к стабильному сайту с паузой одна секунда. Ожидаемо: все 200 либо не более одного 5xx с успешным повтором.
3. Во время серии нажмите ссылку смены IP в кабинете. Ожидаемо: один-два 502 в логе, затем автоматический повтор и продолжение серии.
4. Укажите в настройках тип SOCKS5 для канала, который выдан как HTTP, и сделайте запрос. Ожидаемо: tunnel failed или ошибка протокола, которую вы узнаете за секунду. Верните верный тип.

Показатели успешного выполнения

Доля ошибок прокси-слоя в рабочих сериях не превышает одного-двух процентов, каждая ошибка классифицирована по коду, и ни одна не требует ручного вмешательства, кроме 407. Время реакции на 407 — минуты, а не часы.

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

Проблема: 407 после каждой перезагрузки роутера

Причина: авторизация по IP, а провайдер выдает динамический адрес.

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

Проблема: пароль верный, но 407 в браузере, хотя curl проходит

Причина: браузер или профиль антидетект-браузера закешировал старые данные.

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

Проблема: 502 ровно каждые N минут

Причина: совпадает с интервалом автоматической ротации IP.

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

Проблема: 502 при большом числе потоков, при малом все хорошо

Причина: перегрузка мобильного канала.

Решение: снизьте параллельность до 3-5 потоков на канал и распределите нагрузку по нескольким каналам.

Проблема: 504 только на одном сайте, остальные быстрые

Причина: сайт медленно генерирует страницу или ограничивает адреса мобильных операторов.

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

Проблема: вместо 504 стал приходить обрыв без кода

Причина: лимит ожидания в софте меньше внутреннего лимита прокси.

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

Проблема: tunnel failed, response 400

Причина: SOCKS5-порт указан как HTTP-прокси или наоборот.

Решение: сверьте тип и порт с кабинетом, для SOCKS5 используйте схему socks5h, для HTTP — http.

Проблема: tunnel failed, response 403 на нестандартный порт

Причина: прокси не разрешает туннели на этот порт.

Решение: уточните список разрешенных портов у поставщика и по возможности перенастройте целевой сервис на порт 443.

Проблема: код 502 или 504 приходит с заголовком Server от сайта

Причина: это ответ самого сайта, а не прокси-слоя: у сайта проблемы с его собственными внутренними сервисами.

Решение: подождите и повторите позже; смена прокси не поможет.

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

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

Ручная передача заголовка авторизации

Иногда полезно проверить, как прокси реагирует на конкретный заголовок. Закодируйте пару логин:пароль в Base64 любым локальным инструментом и передайте заголовок сами: curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. Этот способ работает для обычных HTTP-запросов и помогает понять, принимает ли прокси данные вообще, независимо от того, как их формирует ваш софт. Для CONNECT используйте ключ --proxy-header вместо -H.

Разрешение имен на стороне прокси

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

Автоматизация через API поставщика

У mobileproxy.space есть программный интерфейс для смены IP и получения статуса каналов. Встройте вызов смены IP в обработчик 504, а проверку статуса канала — в обработчик устойчивых 502. Тогда скрипт сам решит, повторять запрос через тот же канал или переключиться на резервный. Простой алгоритм: три 502 подряд за минуту — запросить статус, если канал в норме, сменить IP, если нет — пометить канал недоступным на пять минут и перейти к следующему.

Разделение метрик прокси и сайта

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

Пул каналов с весами

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

Экспорт HAR из браузера

Для сложных случаев в антидетект-браузере откройте вкладку Network, воспроизведите ошибку и выберите «Save all as HAR». Файл содержит все заголовки запросов и ответов, включая стадии, которые не видны в обычном логе программы. Перед отправкой в поддержку удалите из файла значения Proxy-Authorization и куки.

Оптимизация лимитов ожидания

Соберите статистику времени до первого байта по каждому каналу и направлению за неделю. Установите лимит ожидания в софте на уровне 95-го процентиля плюс 10 секунд. Такой лимит редко обрывает живые запросы и одновременно быстро освобождает потоки при реальных зависаниях.

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

Как понять, что 502 вернул прокси, а не сайт?

Посмотрите на заголовки ответа. Если есть Proxy-Agent, Via или другие служебные заголовки прокси и нет Set-Cookie и Server сайта, ответ от прокси. Дополнительно: если код пришел сразу в ответ на CONNECT, это точно прокси.

Стоит ли повторять запрос при 407?

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

Почему в curl все работает, а в моем софте нет?

Чаще всего софт иначе формирует строку прокси, не кодирует спецсимволы пароля, применяет другой тип протокола или не передает авторизацию при CONNECT. Сравните точную строку из настроек софта с рабочей командой curl посимвольно.

Как правильно записать пароль со спецсимволами?

В строке адреса кодируйте: @ как %40, : как %3A, # как %23, % как %25, пробел как %20. В отдельных полях логина и пароля вводите пароль как есть, без кодирования.

Чем 504 отличается от таймаута, о котором пишут в других статьях?

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

Сколько потоков можно пускать через один мобильный канал?

Универсального числа нет. Начните с 3-5 и повышайте, пока доля 502 остается ниже одного процента. Для тяжелых страниц число будет меньше, для легких API-запросов больше.

Нужно ли менять IP при каждой ошибке?

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

Что отправлять в поддержку, чтобы решить вопрос быстрее?

Полный вывод curl -v с замененным на звездочки паролем, точное время с секундами и часовым поясом, хост и порт канала, целевой домен, тип авторизации и результат прямого запроса без прокси. С таким набором поддержка обычно отвечает в первом же сообщении.

Можно ли использовать HTTPS для подключения к самому прокси?

Только если поставщик это явно поддерживает. В большинстве случаев для мобильных прокси подключение к прокси идет по обычному HTTP или SOCKS5, а шифрование трафика к сайту обеспечивает туннель. Включение лишнего шифрования к прокси дает tunnel failed или ошибку рукопожатия.

Заключение

Вы прошли путь от непонятной красной строки в логе до полной системы диагностики. Теперь вы умеете определять, кто именно вернул ответ, читаете 407 как сигнал проверить учетные данные и способ авторизации, 502 как признак сбоя за прокси или в момент ротации, 504 как честный отчет прокси о медленном сайте, а tunnel failed как обертку над одним из этих кодов с подсказкой в виде числа. Ваш софт больше не повторяет бессмысленное и не сдается на временном.

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

1. Ведите журнал инцидентов минимум месяц. Уже через две недели вы заметите повторяющиеся паттерны и уберете их причины.
2. Раз в неделю пересматривайте доли кодов по каналам и перераспределяйте нагрузку.
3. Автоматизируйте смену IP и проверку статуса через API поставщика, чтобы рутинные 5xx решались без вас.
4. Изучите смежные материалы блога о сетевых таймаутах и о поведении целевых сайтов, чтобы закрыть оставшиеся два участка пути запроса.

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

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