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

Формат строки подключения с авторизацией

Прокси-адрес для подключения из кода собирается по единой схеме: protocol://login:password@host:port. Протокол задаёт режим работы (http, https, socks5), логин и пароль идут через двоеточие перед символом @, дальше хост и порт. Библиотеки HTTP-клиентов и большинство браузерных драйверов принимают такую строку целиком, без отдельной передачи логина и пароля.

Пароль не должен содержать символ @ и другие зарезервированные для URL символы без процентного экранирования — иначе парсер обрежет строку на первом спецсимволе, и подключение уйдёт с неверными кредами. Автосгенерированные логин и пароль стоит кодировать функцией url-кодирования до подстановки.

Разница между HTTP- и SOCKS-режимом

HTTP-режим работает на уровне протокола: сервер понимает HTTP-запрос и умеет читать заголовки. Для HTTPS-трафика он ничего не расшифровывает, а пробрасывает зашифрованное TLS-соединение методом CONNECT, поэтому HTTP-режим одинаково пригоден и для http, и для https адресов, несмотря на название.

SOCKS-режим (практически всегда SOCKS5) работает уровнем ниже — не разбирает протокол приложения, а передаёт байты между клиентом и адресатом. SOCKS5 прозрачен для HTTP и произвольных TCP-соединений и, в отличие от HTTP-режима, поддерживает UDP — важно для DNS и части сетевых библиотек. Резолвинг имён можно поручить этому же серверу, тогда имя хоста не уходит в открытом виде через локальный DNS, что критично для гео-чувствительных сайтов. Для скрапинга обычно хватает HTTP-режима, для сетевых утилит и приложений с собственным протоколом нужен SOCKS5.

Настройка на уровне клиента, сессии и браузерного драйвера

Задавать адрес можно на трёх уровнях, и они не взаимозаменяемы. Уровень запроса — параметр передаётся в каждый вызов клиента заново; подходит, когда каждый запрос идёт через свой адрес, например при ротации IP на каждой странице. Уровень сессии — адрес задаётся один раз при создании сессии или коннекшн-пула, и все запросы внутри неё используют один выход и keep-alive соединение. Это снижает расходы на TLS-хендшейк и держит консистентный IP на протяжении сценария — важно для сайтов, сверяющих совпадение адреса между шагами авторизации.

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

Обработка ошибок соединения

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

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

Проверка того, что запрос реально ушёл через прокси

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

Второй момент — заголовки прозрачного узла: X-Forwarded-For или Via с оригинальным адресом клиента внутри. Такой сервер принимает соединение, но раскрывает реальный IP, поэтому для задач с требованием анонимности нужен непрозрачный режим без этих заголовков. При смене адреса на каждой сессии проверку стоит встроить в сам сценарий — подробнее в статье о ротации IP по API.

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

Частые вопросы

Можно ли использовать один и тот же прокси одновременно для HTTP-клиента и для браузерного драйвера?

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

Почему прокси работает в одном HTTP-клиенте и не работает в другом при одинаковой строке подключения?

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

Нужно ли закрывать соединение с прокси вручную после каждого запроса?

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

Готовые прокси с логином и паролем для HTTP- и SOCKS5-режима и документацией по подключению — в разделе прокси. Формат запросов и лимиты для программной интеграции — в API прокси.