Диагностика ошибок прокси: 407, 502, 504 и tunnel connection failed — пошаговый гайд

Ошибки прокси пугают своей внезапностью. Только что запрос работал, а теперь вы видите загадочное 407, 502 или сообщение tunnel connection failed. Хорошая новость: за каждой такой ошибкой стоит понятная и логичная причина. Этот гайд научит вас читать эти сообщения как открытую книгу.

Введение: зачем вам этот гайд и что вы получите

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

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

• Умение мгновенно отличать ошибку прокси от ошибки целевого сайта.
• Понимание, что означают коды 407, 502, 504, 403 и сообщение tunnel connection failed.
• Навык чтения вывода команды curl -v построчно с чётким разделением участков клиент-прокси-сервер.
• Готовые примеры диагностики на curl, Python requests и Node.js с реальными текстами ошибок.
• Таблицу быстрой диагностики симптом-причина-проверка, которую можно распечатать и держать под рукой.

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

Что нужно знать заранее. Достаточно базового понимания того, что такое URL, порт и HTTP-запрос. Никаких глубоких знаний сетей не требуется. Все термины мы объясним простыми словами по ходу дела.

Сколько времени потребуется. На первое прочтение уйдёт около 30-40 минут. Отработка примеров на своём проекте займёт ещё 20-30 минут. После этого диагностика типовой ошибки будет занимать у вас одну-две минуты.

Важное уточнение по теме. В этом гайде мы разбираем только ошибки самого прокси-слоя. Код 429 (слишком много запросов) и стратегии повторных попыток здесь не рассматриваются, потому что это большая отдельная тема со своей логикой и подходами. Для 429 нужен отдельный материал про ретраи и лимиты. Здесь мы концентрируемся строго на диагностике сбоев прокси-соединения.

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

Прежде чем начать диагностику, соберём набор инструментов. Все они бесплатны и работают на любой операционной системе.

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

1. Установите curl. На большинстве систем Linux и macOS он уже есть. Проверьте командой curl --version. Если увидите номер версии, всё готово.
2. На Windows curl входит в состав системы начиная с современных версий. Откройте PowerShell и введите ту же команду проверки.
3. Установите Python версии 3.10 или новее, если планируете примеры на requests. Проверьте командой python --version.
4. Установите библиотеку requests командой pip install requests в терминале.
5. Установите Node.js версии 20 или новее для примеров на JavaScript. Проверьте командой node --version.

Что нужно подготовить

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

Совет: Заведите отдельный текстовый файл под название diagnostic-notes. Записывайте туда каждую команду и её результат. Это спасёт вас, когда через полчаса вы забудете, что уже проверяли.

⚠️ Внимание: Никогда не сохраняйте логин и пароль от прокси в общих чатах, публичных репозиториях или скриншотах. Утечка этих данных даёт посторонним доступ к вашему трафику. Храните их в защищённом менеджере паролей.

✅ Проверка: На этом этапе у вас должны успешно выполняться три команды проверки версий: curl, python и node. Если хотя бы одна не работает, вернитесь к установке нужного инструмента.

Базовые понятия простым языком

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

Что такое прокси на самом деле

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

Главное разделение: клиент, прокси, сервер

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

HTTP-коды в двух словах

Сайты и прокси отвечают числовыми кодами. Коды на 4 (например, 407, 403) обычно означают проблему на стороне запроса или доступа. Коды на 5 (502, 504) означают проблему на стороне сервера или посредника. Но здесь есть коварная тонкость: код 502 может прислать как целевой сайт, так и сам прокси. Научиться их различать — одна из главных целей гайда.

Разница между HTTP и HTTPS через прокси

Когда вы идёте на обычный сайт по HTTP, прокси видит весь запрос целиком. Когда вы идёте на защищённый сайт по HTTPS, прокси не может прочитать содержимое. Вместо этого клиент просит прокси создать защищённый туннель специальной командой CONNECT. Именно поэтому ошибка tunnel connection failed появляется только на HTTPS. Мы подробно разберём это отдельно.

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

Шаг 1: Как отличить ошибку прокси от ошибки целевого сайта

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

Главный принцип разделения

Ключевой вопрос звучит так: дошёл ли ваш запрос до целевого сайта или застрял на прокси? Если запрос застрял на прокси, виноват прокси-слой. Если запрос дошёл до сайта и сайт ответил, значит проблема на стороне сайта.

1. Посмотрите на код ошибки и текст сообщения.
2. Определите, кто прислал этот ответ: прокси или сервер. Об этом расскажет заголовок ответа и содержимое.
3. Если в тексте ошибки прямо упоминается слово proxy, tunnel или название прокси-программы, почти наверняка виноват прокси-слой.
4. Если ответ содержит привычную HTML-страницу целевого сайта с его логотипом и оформлением, значит запрос дошёл до сайта.

Три быстрых признака ошибки именно прокси

• Код 407. Этот код существует только у прокси. Целевой сайт никогда его не присылает. Увидели 407 — значит вы точно на прокси-слое.
• Текст tunnel connection failed или Received HTTP code от прокси. Такие формулировки генерирует именно посредник.
• Мгновенный отказ соединения. Если запрос падает практически сразу, ещё до того как мог бы дойти до сайта, скорее всего проблема между клиентом и прокси.

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

Пример на curl для быстрой проверки

Выполните запрос через прокси с флагом подробного вывода. Команда выглядит так: curl -v -x http://логин:пароль@хост:порт https://пример-сайта. Флаг -v показывает весь диалог. Флаг -x задаёт прокси. Смотрите на строки, начинающиеся со стрелок и звёздочек. О них подробно во отдельном шаге про чтение логов.

⚠️ Внимание: Никогда не делайте выводы по одному запросу к нестабильному сайту. Повторите запрос два-три раза. Разовый сбой сети может выглядеть как ошибка прокси, хотя прокси тут ни при чём.

✅ Проверка: Вы должны уметь для любого сообщения об ошибке ответить на вопрос: это прислал прокси или сайт? Если можете — переходите дальше. Если пока сомневаетесь, вернитесь к трём быстрым признакам выше.

Шаг 2: Ошибка 407 Proxy Authentication Required

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

Что означает 407 и чем он отличается от 401

Код 407 говорит буквально следующее: прокси требует, чтобы вы представились логином и паролем, но вы этого не сделали или сделали неправильно. Ключевое отличие от 401: код 401 присылает целевой сайт, когда авторизации требует он сам. А код 407 присылает именно прокси. Если вы видите 407, значит вы даже не дошли до сайта — вас остановил посредник на входе.

Где именно теряется логин и пароль

Чаще всего данные теряются в трёх местах.

1. Логин и пароль вообще не переданы в команде. Клиент постучался к прокси анонимно, и прокси его развернул.
2. Данные переданы, но с опечаткой. Один лишний пробел или неверная раскладка — и авторизация не проходит.
3. Данные переданы правильно, но пароль содержит специальные символы, которые ломают структуру строки подключения. Это самая коварная причина.

Спецсимволы в пароле и URL-кодирование

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

Решение называется URL-кодирование. Специальные символы заменяются на код из знака процента и двух цифр или букв. Например, собака превращается в процент сорок, двоеточие превращается в процент три А, слэш превращается в процент два F, пробел превращается в процент двадцать.

1. Найдите в своём пароле все спецсимволы.
2. Замените каждый на его URL-код.
3. Соберите строку подключения заново с закодированным паролем.
4. Повторите запрос.

Совет: Не кодируйте пароль вручную, если он сложный. В Python есть функция для кодирования из модуля urllib.parse под названием quote. Передайте ей пароль, и она вернёт безопасную версию. Это исключает ошибки ручного набора.

Пример на curl

Реальный текст ошибки при неверной авторизации выглядит так: curl (56) Received HTTP code 407 from proxy after CONNECT. Или на HTTP-сайте: HTTP 407 Proxy Authentication Required. Правильная команда с авторизацией: curl -v --proxy-user логин:пароль -x http://хост:порт https://пример-сайта. Использование флага --proxy-user часто надёжнее, чем вписывание данных прямо в адрес, потому что curl сам корректно обработает символы.

Пример на Python requests

В requests прокси задаётся через словарь. Ключи http и https, значения — строки подключения. Если пароль содержит спецсимволы, оберните его в функцию quote. Типичная ошибка в ответе объекта: response.status_code вернёт 407, а в тексте будет упоминание Proxy Authentication Required. Проверяйте именно статус-код, а не только текст.

Пример на Node.js

В Node при использовании популярных клиентов прокси задаётся через специальный агент. Реальная ошибка выглядит как объект с полем statusCode равным 407 или как отклонённое обещание с сообщением об ошибке авторизации туннеля. Убедитесь, что вы передаёте заголовок авторизации прокси, а не заголовок авторизации сайта — это разные вещи.

⚠️ Внимание: Заголовок авторизации для прокси и заголовок авторизации для сайта — это два разных заголовка. Один называется Proxy-Authorization, другой Authorization. Если перепутать, получите либо 407 от прокси, либо 401 от сайта. Проверяйте, какой именно заголовок отправляет ваша библиотека.

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

Шаг 3: Ошибка 502 от прокси

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

Что означает 502

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

Когда виноват целевой хост

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

1. Сделайте тот же запрос напрямую без прокси.
2. Если напрямую сайт тоже отвечает 502 или зависает, значит виноват сайт, а не прокси.
3. В этом случае менять прокси бесполезно. Проблема на стороне цели.

Когда виноват сам канал

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

1. Сделайте запрос через тот же прокси к заведомо стабильному сайту.
2. Если и стабильный сайт возвращает 502, значит проблема в прокси-канале.
3. Попробуйте другой прокси или другой узел, если он у вас есть.

Совет: Метод перекрёстной проверки работает безотказно. Меняйте по одной переменной за раз. Сначала фиксируйте прокси и меняйте сайт. Потом фиксируйте сайт и меняйте прокси. Пересечение результатов покажет виновника.

Реальные тексты ошибок

На curl вы увидите HTTP-ответ с кодом 502 и часто HTML-страницу с надписью Bad Gateway. Иногда в заголовках ответа виден признак, какой сервер прислал ответ. В Python requests это response.status_code равный 502. В Node это поле statusCode равное 502. Обратите внимание на тело ответа: оформленная страница целевого сайта указывает, что запрос дошёл до сайта, а лаконичная техническая страница часто исходит от прокси.

⚠️ Внимание: Не спешите винить прокси при первом же 502. Целевые сайты возвращают 502 очень часто, особенно под нагрузкой. Всегда делайте контрольный запрос напрямую, прежде чем менять настройки прокси.

✅ Проверка: Вы должны уметь по результатам двух перекрёстных запросов уверенно сказать: этот 502 от сайта или от прокси. Если пока не получается, повторите оба контрольных запроса и сравните результаты.

Шаг 4: Ошибка 504 и таймауты

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

Что означает 504

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

Connect timeout против read timeout

Есть два совершенно разных момента ожидания.

• Connect timeout — это время на установку самого соединения. Клиент пытается дозвониться до прокси или прокси до сайта. Если соединение не устанавливается за отведённое время, срабатывает connect timeout. Обычно это признак того, что адрес недоступен или порт закрыт.
• Read timeout — это время ожидания ответа после того, как соединение уже установлено. Соединение есть, запрос ушёл, но данные не приходят. Обычно это признак того, что сайт долго думает или завис на обработке.

Как разделять их в клиенте

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

1. В curl используйте флаг --connect-timeout для ограничения времени установки соединения. Отдельно флаг --max-time ограничивает общее время всей операции.
2. В Python requests параметр timeout можно передать кортежем из двух чисел. Первое число — connect timeout, второе — read timeout. Например, timeout из пяти и тридцати секунд.
3. В Node в большинстве клиентов есть отдельные настройки для времени соединения и для времени ожидания ответа. Задайте их разными значениями, чтобы видеть, какой именно сработал.

Как читать результат

Если сработал connect timeout, значит вы даже не установили соединение. Проверяйте доступность прокси и правильность порта. Если сработал read timeout, значит соединение было, но ответ не пришёл вовремя. Проверяйте, не перегружен ли сайт и не слишком ли тяжёлый запрос вы делаете.

Совет: Ставьте connect timeout небольшим, около пяти секунд. Установка соединения либо происходит быстро, либо не происходит вообще. А read timeout ставьте с запасом, потому что некоторые страницы честно готовят ответ дольше.

⚠️ Внимание: Слишком маленький read timeout приводит к ложным ошибкам. Вы будете обрывать нормальные, но медленные ответы и думать, что прокси сломан. Всегда проверяйте, не сами ли вы поставили слишком строгий лимит.

Реальные тексты ошибок

В curl connect timeout выглядит как сообщение Connection timed out после stderr. В Python requests это исключение ConnectTimeout для соединения и ReadTimeout для ответа. Именно название исключения сразу говорит вам, какой этап провалился. В Node вы увидите ошибку с кодом ETIMEDOUT или отдельное сообщение о превышении времени ответа.

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

Шаг 5: Ошибка tunnel connection failed и метод CONNECT

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

Почему ошибка приходит только на HTTPS

Когда вы идёте на обычный HTTP-сайт, прокси просто пересылает ваш запрос. Но когда вы идёте на HTTPS-сайт, содержимое зашифровано, и прокси не может его прочитать. Поэтому клиент сначала отправляет прокси специальную команду CONNECT с адресом сайта. Эта команда означает просьбу: пожалуйста, построй мне защищённый туннель до этого адреса, я буду общаться с сайтом напрямую через тебя.

Если прокси по какой-то причине не смог построить туннель, он возвращает ошибку tunnel connection failed. На обычном HTTP такой команды нет, поэтому и ошибки этой на HTTP не бывает. Это ваш главный опознавательный признак.

Основные причины провала туннеля

• Прокси не смог соединиться с целевым адресом. Возможно, сайт недоступен или порт закрыт.
• Прокси запрещает метод CONNECT к этому адресу или порту. Некоторые прокси разрешают только определённые порты.
• Авторизация не прошла. В этом случае вы часто увидите комбинацию: сначала попытка CONNECT, затем код 407.
• Прокси перегружен или его вышестоящий канал оборвался в момент построения туннеля.

Как диагностировать

1. Выполните curl -v к HTTPS-адресу и найдите в выводе строку с CONNECT. Она показывает момент запроса туннеля.
2. Посмотрите, какой ответ пришёл на CONNECT. Ответ с кодом 200 означает, что туннель построен. Любой другой код означает провал.
3. Если рядом видите 407, значит проблема в авторизации, а не в самом туннеле. Возвращайтесь к шагу про 407.
4. Если видите отказ соединения, значит прокси не смог достучаться до сайта.

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

Реальные тексты ошибок

В curl это сообщение вида curl (56) Received HTTP code от proxy after CONNECT или прямое tunnel connection failed. В Python requests это исключение ProxyError с вложенным сообщением о неудачном туннеле. В Node это ошибка с текстом о том, что туннельное соединение не удалось установить, часто с указанием кода статуса от прокси.

⚠️ Внимание: Не путайте провал туннеля с ошибкой сертификата. Если туннель построен, но потом ругается на защищённый сертификат сайта — это уже другая проблема, не связанная с прокси-слоем. Смотрите, на каком этапе именно возникла ошибка: до ответа на CONNECT или после.

✅ Проверка: Вы должны находить в выводе curl строку с ответом на CONNECT и понимать по её коду, построился туннель или нет. Ответ 200 — туннель есть. Другой код — ищите причину провала.

Шаг 6: Ошибка 403 от прокси

Цель этапа: научиться распознавать, когда 403 присылает прокси из-за лимитов, географии или запрещённого порта.

Что означает 403 в контексте прокси

Код 403 называется Forbidden, то есть запрещено. Обычно этот код присылает целевой сайт, когда закрывает доступ. Но прокси тоже может прислать 403, когда сам решает не пропускать ваш запрос. Задача — понять, кто именно поставил запрет.

Три причины 403 от прокси

• Лимиты. Прокси может ограничивать количество запросов, объём трафика или число одновременных соединений. При превышении он возвращает 403 как отказ обслуживать.
• Географическое ограничение. Некоторые прокси разрешают обращение только к определённым регионам или, наоборот, запрещают определённые направления. Запрос в закрытое направление получает 403.
• Запрещённый порт. Прокси может разрешать только стандартные порты. Обращение к нестандартному порту оборачивается отказом.

Как отличить 403 прокси от 403 сайта

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

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

⚠️ Внимание: Не пытайтесь обойти лимиты прокси хитрыми приёмами. Если вы упёрлись в ограничение тарифа, правильное решение — расширить тариф или оптимизировать количество запросов. Обход технических ограничений сервиса нарушает условия использования.

Реальные тексты ошибок

В curl это HTTP-ответ 403 Forbidden с телом, которое подскажет источник. В Python requests это response.status_code равный 403. В Node это statusCode равный 403. Всегда анализируйте тело ответа вместе с кодом, потому что именно тело раскрывает истинного автора запрета.

✅ Проверка: Вы должны по телу ответа и результату прямого запроса определить, кто прислал 403. Если это прокси — проверяйте лимиты, гео и порт. Если сайт — причина не в прокси-слое.

Шаг 7: Разрыв соединения без ответа — connection reset и EOF

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

Что это за ошибки

Иногда вы не получаете никакого HTTP-кода. Вместо этого соединение внезапно обрывается. Есть два типичных проявления.

• Connection reset. Дословно — соединение сброшено. Одна из сторон резко закрыла канал, не завершив обмен. Как будто собеседник бросил трубку на полуслове.
• EOF, unexpected end of file. Дословно — неожиданный конец данных. Клиент ждал продолжения ответа, но поток данных внезапно закончился.

Что смотреть в первую очередь

1. Определите момент обрыва. Он произошёл до ответа на CONNECT, во время передачи запроса или во время получения ответа? Вывод curl -v покажет последнюю успешную строку перед обрывом.
2. Если обрыв случился в самом начале, при подключении к прокси, скорее всего проблема в самом прокси или сетевом пути до него.
3. Если обрыв произошёл после установки туннеля, во время общения с сайтом, вероятнее проблема со стороны сайта или нестабильного канала.
4. Повторите запрос несколько раз. Стабильно повторяющийся обрыв говорит о системной причине. Случайный — о временной нестабильности сети.

Частые причины

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

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

Реальные тексты ошибок

В curl это Connection reset by peer или Empty reply from server. В Python requests это исключение ConnectionError с вложенным сообщением о сбросе соединения. В Node это ошибка с кодом ECONNRESET. Эти сообщения не содержат HTTP-кода именно потому, что HTTP-обмен не завершился нормально.

⚠️ Внимание: Обрыв без ответа легко спутать с таймаутом. Разница в том, что при таймауте клиент сам прекращает ожидание, а при сбросе другая сторона активно закрывает канал. Смотрите на текст ошибки: слово reset указывает на активный сброс, слово timeout — на истечение ожидания.

✅ Проверка: Вы должны по последней строке вывода curl определять, на каком этапе оборвалось соединение. Это сразу сужает круг подозреваемых до одного-двух звеньев.

Шаг 8: Практика — читаем curl -v построчно

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

Что означают символы в начале строк

Вывод curl -v использует специальные символы в начале каждой строки, и это ваш главный ключ к пониманию.

• Звёздочка в начале строки означает информационное сообщение самого curl. Это комментарии клиента о том, что он делает: устанавливает соединение, строит туннель, проверяет сертификат.
• Стрелка вправо означает данные, которые клиент отправляет прокси или серверу. Это исходящий запрос.
• Стрелка влево означает данные, которые клиент получает в ответ. Это входящий ответ.

Где проходит граница клиент-прокси-сервер

Разберём типичный путь на защищённый сайт через прокси. Сначала curl сообщает звёздочкой, что соединяется с прокси по указанному адресу и порту. Это участок клиент-прокси. Затем идёт исходящая стрелка с командой CONNECT — клиент просит прокси построить туннель. Дальше входящая стрелка с ответом на CONNECT — это ответ прокси. Если код 200, туннель построен, и граница смещается: дальше весь обмен идёт уже клиент-сервер через туннель.

Разбор реального лога

Представим, что вы видите такую последовательность. Строка со звёздочкой: соединяюсь с адресом прокси и портом. Это значит, клиент нашёл прокси. Следующая строка со звёздочкой: соединение с прокси установлено. Отлично, первый участок пройден. Дальше исходящая стрелка: CONNECT к адресу целевого сайта. Клиент попросил туннель. Затем входящая стрелка: ответ на CONNECT с кодом. Здесь ключевая развилка.

1. Если код ответа на CONNECT 200, туннель построен. Читаем дальше.
2. Если код 407, прокси требует авторизацию. Проблема на прокси-слое, участок клиент-прокси. Идите к шагу про 407.
3. Если строка гласит tunnel connection failed, прокси не смог построить туннель. Причина между прокси и сайтом.

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

Как это применять для диагностики

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

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

⚠️ Внимание: Флаг -v показывает заголовки, включая строку авторизации прокси. Если вы делитесь логом с кем-то для помощи, обязательно затрите строку с авторизационными данными. Иначе вы раскроете свой логин и пароль.

✅ Проверка: Возьмите любой свой лог curl -v и разметьте его: где участок клиент-прокси, где ответ на CONNECT, где начинается зона сайта. Если вы уверенно проводите эти границы, вы освоили главный навык диагностики.

Шаг 9: Таблица быстрой диагностики симптом-причина-проверка

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

Как пользоваться таблицей

Найдите свой симптом в первом столбце. Прочитайте вероятную причину. Выполните действие из третьего столбца в первую очередь — оно с наибольшей вероятностью подтвердит или опровергнет причину.

Симптом: код 407

Вероятная причина: не переданы или неверны данные авторизации прокси, либо спецсимволы в пароле сломали строку подключения. Что проверить первым: правильность логина и пароля, а также URL-кодирование спецсимволов в пароле.

Симптом: tunnel connection failed на HTTPS

Вероятная причина: прокси не смог построить туннель к сайту, возможно из-за запрещённого порта или недоступности сайта. Что проверить первым: ответ на CONNECT в выводе curl -v и разрешённость целевого порта.

Симптом: код 502

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

Симптом: код 504

Вероятная причина: истекло время ожидания, надо понять — соединения или ответа. Что проверить первым: раздельные connect timeout и read timeout, чтобы увидеть, какой этап затянулся.

Симптом: код 403 через прокси

Вероятная причина: лимиты прокси, географическое ограничение или запрещённый порт. Что проверить первым: тело ответа на источник запрета и панель управления прокси на предмет исчерпанных лимитов.

Симптом: connection reset или ECONNRESET

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

Симптом: EOF, empty reply

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

Симптом: connect timeout

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

Симптом: read timeout

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

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

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

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

Убедитесь, что вы освоили все ключевые навыки. Пройдитесь по чек-листу.

• Вы умеете за секунды отвечать, кто прислал ошибку — прокси или сайт.
• Вы понимаете разницу между 407 и 401 и умеете исправлять авторизацию, включая спецсимволы в пароле.
• Вы различаете 502 от сайта и 502 от прокси через перекрёстную проверку.
• Вы разделяете connect timeout и read timeout и знаете, что означает каждый.
• Вы понимаете, почему tunnel connection failed бывает только на HTTPS, и умеете читать ответ на CONNECT.
• Вы распознаёте три причины 403 от прокси: лимиты, гео и порт.
• Вы диагностируете обрывы соединения по этапу, на котором они произошли.
• Вы читаете вывод curl -v построчно и проводите границы клиент-прокси-сервер.

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

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

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

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

Проблема: сразу меняю прокси при любой ошибке

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

Проблема: пароль с собакой ломает подключение

Причина: спецсимвол не закодирован и разрывает строку. Решение: примените URL-кодирование к паролю или используйте отдельный параметр авторизации вместо вписывания в адрес.

Проблема: путаю 407 и 401

Причина: не различаю авторизацию прокси и авторизацию сайта. Решение: запомните — 407 всегда от прокси, 401 всегда от сайта. Проверяйте, какой заголовок отправляете: Proxy-Authorization или Authorization.

Проблема: слишком строгий таймаут рвёт нормальные запросы

Причина: read timeout поставлен слишком маленьким. Решение: разделите connect и read таймауты, дайте read с запасом на медленные страницы.

Проблема: tunnel connection failed на нестандартном порту

Причина: прокси запрещает CONNECT к этому порту. Решение: используйте стандартный порт для защищённых соединений или уточните список разрешённых портов у прокси.

Проблема: вижу 502 и думаю, что прокси мёртв

Причина: не проверил, кто прислал 502. Решение: перекрёстная проверка. Часто 502 приходит от перегруженного целевого сайта, а прокси исправен.

Проблема: раскрыл логин и пароль в логе

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

Проблема: считаю обрыв соединения таймаутом

Причина: не различаю reset и timeout. Решение: смотрите текст ошибки. Reset — активное закрытие другой стороной, timeout — истечение вашего ожидания. Это разные причины.

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

Логирование на постоянной основе

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

Автоматическая классификация ошибок

В коде можно завести функцию, которая по типу исключения и коду ответа сразу относит ошибку к нужному звену. Например, ConnectTimeout — участок соединения, ReadTimeout — участок ответа, ProxyError с туннелем — прокси-слой. Это ускоряет реакцию в автоматизированных системах.

Сбор статистики стабильности

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

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

⚠️ Внимание: При построении автоматической обработки не превращайте её в бесконечные повторы одного и того же запроса. Логика повторных попыток — отдельная большая тема со своими правилами, связанная в том числе с кодом 429. Ей посвящён отдельный материал, и её стоит изучить отдельно.

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

Как быстро понять, что виноват именно прокси, а не мой код?

Сделайте тот же запрос напрямую без прокси. Если напрямую всё работает, а через прокси нет, проблема в прокси-слое или его взаимодействии с сайтом. Это отсекает половину гипотез за минуту.

Почему я получаю 407, хотя ввёл правильный пароль?

Скорее всего в пароле есть специальные символы, которые ломают строку подключения. Примените URL-кодирование к паролю или передайте данные через отдельный параметр авторизации, а не в адресе.

Код 502 всегда означает, что прокси сломан?

Нет. 502 может прислать и целевой сайт, если он сам плохо ответил. Сделайте перекрёстную проверку: тот же сайт напрямую и тот же прокси к стабильному сайту. Пересечение результатов покажет виновника.

Чем отличается connect timeout от read timeout?

Connect timeout — это ожидание установки соединения. Read timeout — ожидание ответа после того, как соединение уже установлено. Разделите их в клиенте, и вы сразу увидите, какой этап затянулся.

Почему tunnel connection failed бывает только на HTTPS?

Потому что для защищённых сайтов клиент просит прокси построить туннель командой CONNECT. На обычном HTTP такой команды нет. Если туннель не построился, приходит эта ошибка, и она возможна только на HTTPS.

Как отличить 403 от прокси от 403 от сайта?

Посмотрите тело ответа. Оформленная страница сайта означает запрет сайта. Техническая страница или упоминание прокси означают запрет посредника. Подтвердите прямым запросом к сайту.

Что делать при случайных обрывах соединения?

Сначала определите повторяемость: сделайте серию запросов и посчитайте долю обрывов. Единичные обрывы — терпимая нестабильность сети. Массовые обрывы — системная проблема прокси или канала.

Как безопасно делиться логом curl -v для помощи?

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

Почему мои нормальные запросы иногда обрываются по таймауту?

Вероятно, read timeout поставлен слишком строго, и вы обрываете медленные, но исправные ответы. Увеличьте read timeout с запасом, а connect timeout оставьте небольшим.

Где почитать про код 429 и повторные попытки?

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

Заключение: что вы освоили и куда двигаться дальше

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

Резюме выполненных действий. Вы научились разделять цепочку на три звена — клиент, прокси и сервер — и определять, где именно возникла ошибка. Вы разобрались с кодом 407 и авторизацией прокси, включая коварные спецсимволы в пароле. Вы поняли двойственную природу 502 и метод перекрёстной проверки. Вы освоили разделение connect и read таймаутов при 504. Вы разобрались с методом CONNECT и ошибкой tunnel connection failed на HTTPS. Вы научились распознавать три причины 403 от прокси и диагностировать обрывы соединения по этапу. И, наконец, вы освоили главный навык — чтение вывода curl -v построчно с точным проведением границ между звеньями.

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

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

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