Как использовать и переключать прокси-сервер в Python (2026)
Краткое содержание
requests направляет трафик через прокси с помощью простого словаря. Передайте proxies={"http": "...", "https": "..."} в любой запрос или установите session.proxies один раз в requests.Session(), и каждый вызов в этой сессии унаследует его.
Один прокси быстро исчерпывает возможности. Один IP-адрес сталкивается с ограничениями по количеству запросов или блокировкой после нескольких запросов к большинству сайтов; ротация между несколькими выходными IP — списком, который вы поддерживаете, или управляемыми провайдером шлюзами — позволяет скрипту продолжать работать после этого момента.
SOCKS5 требует одной дополнительной библиотеки, но не другого подхода. Установка requests[socks] (PySocks в фоновом режиме) позволяет использовать тот же словарь proxies с URL socks5h:// вместо http://.
urllib3.util.Retry превращает временные сбои прокси в автоматические повторные попытки. Установка политики Retry(total=3, backoff_factor=0.3, status_forcelist=[502, 503, 504]) на HTTPAdapter означает, что прерванное соединение или ошибка 503 будут повторены с экспоненциальной задержкой, вместо того чтобы немедленно возникать.
aiohttp использует тот же формат строки прокси, что и requests. Переход на с позволяет скрипту одновременно работать с ротационным пулом прокси, что сокращает общее время для любой массовой задачи.
Попробуйте Nstproxy - Начните бесплатный тест сегодня
aiohttp.ClientSession
asyncio.gather
Ротационный шлюз полностью устраняет проблему обслуживания списка. Провайдеры, такие как Nstproxy, предлагают один фиксированный адрес:порт и ротацию выходного IP на стороне сервера на основе значения сессии или времени, закодированного в имени пользователя прокси, так что клиентскому коду больше не нужно отслеживать, какие IP активны.
Введение: подключение Python к серверу прокси
Python-скрипт, который общается с сервером прокси, — это просто скрипт, чей вызов requests или aiohttp направлен на промежуточный адрес вместо непосредственного обращения к целевому сайту — прокси пересылает запрос, и ответ возвращается через тот же промежуточный узел. Это одно архитектурное изменение является причиной, по которой прокси появляются почти в каждом проекте Python, который выполняет длительные HTTP-работы: мониторинг публичной страницы цен конкурента с фиксированного IP блокируется за считанные минуты, но та же работа, выполненная с ротацией IP, продолжает возвращать 200.
Этот гид охватывает те части рабочего потока, которые конкурирующие учебные материалы часто пропускают: проверка того, что логика повторных попыток на самом деле восстанавливает соединение после его прерывания, выполнение того же шаблона ротации параллельно с aiohttp и разница между самостоятельно поддерживаемым списком IP и управляемым провайдером ротационным шлюзом. Каждый блок кода ниже был выполнен против реального локального прокси перед тем, как его записали — см. примечания по проверке внутри, если шаг зависит от учетных данных, которые этот гид не может предоставить.
Быстрый обзор
Поддержание и проверка работоспособности вашего собственного списка прокси становится отдельным побочным проектом, как только скрипту нужно больше чем несколько запросов в минуту — шлюз Residential Lite от Nstproxy берет на себя эту ротацию на стороне сервера, так что ваш код на Python просто указывает на один адрес:порт.
Установите requests, aiohttp и дополнительный пакет SOCKS
Три пакета охватывают все шаблоны в этом руководстве: requests для синхронных вызовов, requests[socks] для поддержки SOCKS5 и aiohttp для параллельной ротации.
pip install requests "requests[socks]" aiohttp
requests[socks] подтаскивает PySocks, который на самом деле реализует рукопожатие SOCKS4/SOCKS5 — сам requests знает только, как передать соединение ему. Пропуск этой дополнительной библиотеки и использование URL socks5:// напрямую вызовет ошибку MissingSchema или ошибку зависимости, а не сбой соединения с прокси, что является распространенной точкой путаницы, когда скрипт "не может найти" работающий SOCKS-прокси.
Настройка прокси для одного запроса или для всей сессии
Прокси в requests — это словарь, который сопоставляет каждую схему URL с адресом прокси, и самый чистый способ повторного использования заключается в установке этого словаря один раз в Session, а не в передаче его в каждый вызов.
import requests
PROXY_URL ="http://username:password@proxy-host:proxy-port"proxies ={"http": PROXY_URL,"https": PROXY_URL}resp = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)# только для одного запросаsession = requests.Session()session.proxies = proxies
resp = session.get("https://httpbin.org/ip", timeout=15)# каждый вызов в этой сессии повторно использует его
Встраивание учетных данных в формате username:password@host:port является тем же форматом аутентифицированного прокси, который используется в requests, curl и в документации большинства провайдеров прокси. Если пароль содержит @, : или другие зарезервированные символы URL, пропустите его через urllib.parse.quote(), прежде чем строить строку — неэкранированный специальный символ является частой причиной ProxyError, который выглядит как неверный пароль, но на самом деле является неправильно оформленным URL.
Этот паттерн сессии, плюс адаптер с включенной повторной попыткой и пул ротации из следующего раздела, был протестирован на локальном аутентифицированном прокси (proxy.py, базовая аутентификация) с разрешенным HTTPS-адресом: два последовательных запроса на одной и той же сессии оба вернули 200, и тот же запрос с намеренно неверными учетными данными завершился неудачей с ожидаемым 407 Proxy Authentication Required, что было подтверждено через requests.exceptions.ProxyError.
requests также автоматически считывает переменные окружения HTTP_PROXY, HTTPS_PROXY и NO_PROXY, когда session.trust_env равно True (по умолчанию), что документировано в справочнике по прокси для requests — это важно знать, потому что прокси, установленный в окружении оболочки, бесшумно заменяет прокси, установленный в коде, если trust_env отключен.
Базовая реализация: повторные попытки и ротационный список IP
Session сам по себе не делает никаких повторных попыток — это поведение возникает из монтирования политики Retry на HTTPAdapter, а ротация сверху означает просто выбор другого прокси-строки перед каждым вызовом.
backoff_factor=0.3 означает, что urllib3 засыпает на 0.3 * (2 ** (retries - 1)) секунд между попытками — примерно 0.3с, 0.6с, 1.2с — ограничено backoff_max (120 секунд по умолчанию), согласно справочнику по Retry в urllib3. status_forcelist заставляет выполнять повторную попытку при статусе 503 автоматически вместо немедленного возврата; без него Retry реагирует только на сбои на уровне соединения, а не на коды состояния HTTP.
Проверка: этот точный паттерн сессии с повторными попытками и четырехзапросным циклом ротации через два локальных прокси-экземпляра работал в реальном времени на разрешенной цели, возвращая 200 на каждом вызове и чередуя между двумя конечными точками прокси, как и ожидалось от random.choice().
Расширенные паттерны: ротация шлюзов, липкие сессии и асинхронность
Паттерн ротации выше предполагает, что скрипт Python управляет и обновляет PROXY_POOL — ротация шлюза, управляемая провайдером, устраняет эту ответственность, предоставляя клиенту один фиксированный адрес и перемещая логику ротации на серверную сторону.
Резидентный шлюз Nstproxy является документированным примером этой схемы: клиент подключается к одному host:port, сгенерированному на странице Канала в панели управления, и выходной IP-адрес меняется в зависимости от параметров, закодированных непосредственно в имени пользователя прокси, а не в коде приложения. Блок ниже является иллюстративным, пока не будут предоставлены реальные учетные данные — GATEWAY_HOST, GATEWAY_PORT, CHANNEL_ID и PASSWORD поступают все с этой страницы Канала, а не из этого руководства.
Сегмент r_10m устанавливает окно временной ротации — Nstproxy документирует настраиваемый диапазон от 1 до 120 минут — и замена идентификатора сессии (s_session123) на новое значение принуждает немедленное изменение выходного IP, что является паттерном липкой сессии для процесса входа или оформления заказа, который требует один и тот же IP на нескольких этапах, но новый для следующего вызова. Установка r_10m для ротации по запросу вместо этого возвращает новый IP при каждом вызове без необходимости в метке сессии вообще.
Попробуйте Nstproxy бесплатно →
Nstproxy — это провайдер прокси-инфраструктуры, созданный на основе этой модели шлюза, ориентированный на разработчиков Python и Node.js, которым необходима ротация без ведения списка. Его линия Residential Lite является точкой входа для такого рода работы: предоплаченные пакеты от 10 ГБ, цена от 1,00 $/ГБ без автоматического продления подписки, поддерживаемая пулом, который провайдер заявляет в 50M+ жилых IP-адресов в более чем 200 странах и регионах с заявленным уровнем успеха 99,5%. Существуют компромиссы, о которых стоит знать заранее: Residential Lite имеет цену для скриптов, которые могут смириться с периодически более медленными маршрутизаторами в обмен на более низкую стоимость, а не для чувствительного к задержкам реального времени.
Ротация на основе шлюза — один host:port для всего пула; провайдер ротация выходных IP-адресов на стороне сервера, поэтому код для ведения списка PROXY_POOL становится ненужным.
Целевое назначение по стране и сессии в имени пользователя — параметры страны и сессии устанавливаются путем редактирования строки имени пользователя, без необходимости отдельного API-запроса на каждое обращение.
HTTP, HTTPS и SOCKS5 на одном канале — задокументированный шлюз поддерживает все три протокола, так что паттерн requests[socks] из предыдущего примера работает с тем же хостом, изменяя только URL-схему.
Для одновременной ротации aiohttp принимает ключевое слово proxy для каждого запроса вместо словаря proxies, и asyncio.gather выполняет партию из них сразу:
asyncio.gather планирует каждую корутину, переданную ему, и выполняет их одновременно, а не одну за другой, что является задокументированным поведением в справочнике по задачам Python asyncio. Проверка: шесть параллельных запросов через этот точный шаблон, распределенные по локальному пулу из двух прокси, все вернулись с 200, и назначения попеременно менялись между обоими конечными прокси.
SOCKS5 использует ту же структуру словаря прокси, что и HTTP, только с схемой socks5h:// (окончание h означает, что разрешение DNS происходит через прокси, а не локально, что важно для скрытия имени целевого хоста от сети клиента):
Этот блок выполнялся в режиме реального времени против локального сервера SOCKS5 (pproxy, с аутентификацией) и вернул 200. SOCKS5 определяется в RFC 1928 как универсальный протокол, который пересылает TCP-трафик, не проверяя его, поэтому тот же конечный точка SOCKS5 может передавать HTTP, HTTPS или другой трафик на основе TCP без специфической обработки протокола на стороне клиента — смотрите собственное объяснение Nstproxy о SOCKS5 и HTTP прокси, чтобы понять, как это работает для парсинга и автоматизации.
Честные ограничения проксирования на уровне requests/aiohttp
Все вышеперечисленное изменяет, с какого IP-адреса выполняется запрос — это не изменяет то, что возвращается, и эта граница вызывает большинство сюрпризов в производственных скриптах.
Прокси не влияет на содержимое, отображаемое с помощью JavaScript: requests и aiohttp возвращают необработанный HTML, который отправляет сервер, поэтому страница, на которой контент формируется на стороне клиента, требует безголового браузера (Playwright или Selenium, оба из которых принимают одинаковый формат строки прокси) независимо от того, насколько хорошо настроен ротация. Задержка прокси также накапливается при параллельной работе — жилые IP обычно добавляют десятки до нескольких сотен миллисекунд на каждом переходе по сравнению с прямым подключением, поэтому выполнение задания с тысячею URL при высокой параллельности ограничивается временем отклика прокси так же, как и временем отклика целевого сайта. Ротация IP не отменяет условия обслуживания или директивы роботов целевого сайта; проверьте, что позволяет политика конкретного сайта, прежде чем направлять на него скрипт ротации, и поддерживайте объем запросов пропорционально тому, что сгенерирует обычный пользователь этого сайта. Наконец, Retry с status_forcelist автоматически повторяет сбои на уровне HTTP, но не сможет отличить действительно "мертвый" прокси от целевого сайта, который ограничивает скорость для этого конкретного IP — производственный код все равно должен исключать постоянно сбивающиеся прокси из ротации, а не пытаться повторять их навсегда.
Устранение распространенных ошибок прокси в Python
Ошибка 407 Proxy Authentication Required, вызываемая как requests.exceptions.ProxyError, означает, что прокси отклонил имя пользователя или пароль в URL — это было подтверждено выше, намеренно отправив неправильные учетные данные и наблюдая ту же ошибку. Обычная ProxyError с Connection refused вместо этого означает, что хост или порт неверны, или служба прокси не работает; ConnectTimeout при том же вызове обычно означает, что брандмауэр или маршрут сети тихо сбрасывают соединение, а не отвергают его полностью, что по-разному регистрируется в логах, хотя оба случая выглядят как "запрос никогда не завершился." SSLError через прокси почти всегда связан с тем, что прокси выполняет TLS-перехват, которому он не настроен доверять, или прокси socks5h://, где сертификат целевого сайта не совпадает с тем, что вернул резолвер — переключение на socks5:// для проверки, изменяет ли локальное разрешение DNS режим ошибки, помогает отделить это от самого сертификата. Если прокси постоянно возвращает 200 с страницей, которая говорит "доступ запрещен" или CAPTCHA, вместо того, чтобы вызывать ошибку HTTP, это вообще не проблема соединения — это целевой сайт, выявляющий автоматизированный трафик, несмотря на работающий прокси, что логика повторов не исправит.
Заключение
Настройка прокси в Python начинается с одинакового словаря proxies для каждого запроса или сессии, и все, что идет дальше этого — повторы, ротация, SOCKS5, асинхронная параллельность — добавляется сверху этого одного паттерна, а не является другим подходом. То, где скрипт оказывается в вопросе о списке, который поддерживается самостоятельно, и управляющем шлюзе, в основном сводится к тому, сколько обслуживания списка IP стоит избежать для объемов запросов, которые имеются.
В: Нужно ли мне устанавливать прокси для каждого вызова requests, или я могу установить его один раз?
Установите его один раз на requests.Session() через session.proxies = {...}; каждый вызов, сделанный на этом объекте сессии, повторно использует тот же прокси и соединительный пул без повторения словаря.
В: Почему мой код прокси вызывает ошибку 407?
Ошибка 407 Proxy Authentication Required означает, что прокси отклонил имя пользователя или пароль, встроенные в URL прокси — сначала проверьте на наличие неэкранированных специальных символов в пароле, так как именно они являются самой распространенной причиной наличия учетных данных, которые выглядят правильно, но парсятся неверно.
В: Могу ли я использовать ту же логику ротации с aiohttp, заменив requests?
Да — aiohttp.ClientSession.get() принимает аргумент proxy вместо словаря proxies, и выполнение нескольких таких вызовов через asyncio.gather() позволяет вращать пул прокси одновременно, а не по одному запросу за раз.
В: Является ли SOCKS5 лучше, чем HTTP-прокси для скриптов на Python?
Ни один из них не является строго лучшим; SOCKS5 является протокол-независимым и пересылает любой TCP-трафик без его проверки, что подходит для протоколов, отличных от HTTP, или разрешения DNS через прокси (socks5h://), в то время как HTTP-прокси проще настроить и достаточно для простых HTTP/HTTPS запросов.
В: В чем разница между ротацией списка IP самостоятельно и использованием ротационного шлюза?
Список, поддерживаемый самостоятельно, требует обеспечения, проверки работоспособности и обновления IP в вашем собственном коде, в то время как ротационный шлюз (один фиксированный хост:порт) переносит эту логику ротации на сервер, в ущерб зависимости от времени работы шлюза поставщика вместо вашего собственного списка.
В: Исправляет ли добавление повторов с помощью urllib3.util.Retry заблокированный или запрещенный прокси?
Нет — Повторить восстанавливается после временных сбоев, таких как сбросы соединений или ответы 502/503/504, но прокси, который заблокирован по IP целевым сайтом, будет продолжать возвращать ту же ошибку при каждой попытке, поэтому производственный код требует отдельной логики для исключения постоянно сбивающихся прокси из ротации.
Marcus Chen
Aug. 6th 2026
110M+ реальных IP с 99.9% успешных доступов
Средний отклик ~0.5с для задач высокой конкуренции
Всего от $0.1/GB
Мгновенный доступ к премиальным residential, datacenter, IPv6 и ISP пулам.
