Как использовать прокси с Python Requests: пошаговое руководство
TL;DR
Python Requests принимает сопоставление proxies с отдельными ключами http и https; схема URL прокси описывает соединение прокси, а не пункт назначения.
Используйте Session с trust_env = False, когда вам нужно предотвратить изменение маршрута окружающими переменными среды прокси.
Учетные данные прокси должны быть в URL прокси или конфигурации с поддержкой секрета, а не в requests.get(auth=...), который аутентифицирует к пункту назначения.
Установите тайм-ауты на подключение и чтение, вызовите raise_for_status() и проверьте возвращаемый контент. Успешное соединение с прокси не является действительным скрейпингом.
Сгенерированный URL прокси Nstdata предоставляет фактические параметры Host, Port, Username, Password и product; не угадывайте значения шлюза.
Что вам нужно перед тем, как использовать прокси с Python Requests?
Вам нужен Python, Requests, разрешенный тестовый URL и активная конфигурация прокси, содержащая Протокол, Хост, Порт, Имя пользователя и Пароль. Для Nstdata создайте Канал, активируйте Генерацию прокси, настройте его параметры и скопируйте сгенерированный URL прокси из официального рабочего процесса Канала. Руководство по прокси Nstdata документирует Канал имени пользователя шлюза, тип прокси, страну, продолжительность сессии и компоненты идентификатора сессии. Храните пароль в менеджере секретов и никогда не публикуйте полный URL прокси.
Установите Requests в виртуальной среде с помощью python -m pip install requests. Если ваш фактический прокси - SOCKS5, установите ; различает DNS на стороне клиента от DNS на стороне прокси. Выберите схему, которую документирует провайдер. Примеры ниже предполагают URL прокси HTTP, скопированный в с помощью инъекции секрета вашего времени выполнения. Их нельзя выполнять против Nstdata без ваших учетных данных, поэтому проверки вывода представлены в виде инструкций, а не вымышленных результатов.
Как Requests маршрутизирует HTTP и HTTPS через прокси?
Requests маршрутизирует пункт назначения через прокси, выбранный по ключу сопоставления http или https. Для HTTPS-пункта назначения значение все еще может начинаться с http://, если шлюз является HTTP-прокси. Клиент сначала подключается к шлюзу, а затем устанавливает туннель к пункту назначения. Ответ 407 - это отказ аутентификации прокси; 401 на пункте назначения обычно касается целевой учетной записи.
Requests также может наследовать HTTP_PROXY, HTTPS_PROXY и NO_PROXY из среды. В собственной документации предупреждается, что сопоставление Session.proxies может быть перезаписано настройками среды. Явные прокси на уровне запроса или trust_env = False упрощают воспроизведение решения по маршрутизации. Корпоративный прокси или VPN все еще могут повлиять на сетевое поведение вне Python, поэтому проверьте наблюдаемый выходной IP.
Метод 1: Как установить прокси для одного запроса?
Сопоставление на уровне запроса является ясным выбором для одной авторизованной проверки, так как маршрут виден на месте вызова.
Шаг 1: Получите сгенерированный URL из секрета
Прочитайте PROXY_URL во время выполнения. Он должен иметь задокументированный протокол и сгенерированный Host, Port, Username и Password. Переменная окружения является примером транспорта; управляемое хранилище секретов предпочтительнее для продакшена.
Шаг 2: Передайте обе схемы назначения
import os
import requests
proxy_url = os.environ["PROXY_URL"]# например, http://<user>:<password>@<host>:<port>proxies ={"http": proxy_url,"https": proxy_url}response = requests.get("https://api.ipapi.is/", proxies=proxies, timeout=(5,20),)response.raise_for_status()print(response.text[:300])# Проверьте возвращаемый выходной IP и местоположение.
Целью является конечная точка проверки IP, использованная в документации Nstdata. Замените ее на URL, доступ к которому вам разрешен после проверки маршрута.
Шаг 3: Проверьте выход и контент
Подтвердите, что наблюдаемый выходной IP и местоположение соответствуют требованиям работы. Для страницы с контентом проверьте ожидаемый заголовок или поля, а не только HTTP 200. Остановитесь, если ответ является вызовом, неверной локализацией или неожиданным перенаправлением.
Метод 2: Как повторно использовать прокси в пределах сессии?
Session в Requests повторно использует состояние соединения для связанных вызовов; он не гарантирует, что провайдер сохранит один выходной IP, если политика сессии прокси этого не сделает.
Шаг 1: Создайте сессию без окружающих прокси
Установите trust_env = False, если задача должна использовать только предоставленный прокси. Это также отключает конфигурацию на основе среды, такую как .netrc; используйте явную аутентификацию целевого доступа, если это необходимо.
Шаг 2: Передайте сопоставление прокси при каждом вызове
Примерные URL-адреса являются заполнителями; используйте утвержденные конечные точки. Явное указание proxies при каждом вызове избегает неожиданностей с приоритетом среды.
Шаг 3: Проверьте, требуется ли непрерывность
Если эти вызовы формируют один состоящий рабочий процесс, настройте поддерживаемую «липкую» сессию в сгенерированном пользователем имени Nstdata и проверьте выходной IP-адрес. Одна только Session в Requests управляет только подключениями и cookies на стороне клиента.
Метод 3: Как вы переключаетесь между независимыми запросами?
Смена прокси подходит для независимых, разрешенных запросов, когда нужно новое окончание в соответствии с дизайном работы. С использованием Nstdata воспользуйтесь сгенерированным форматом прокси и задокументированным новым идентификатором сессии или выберите опцию ротации от поставщика; не выдумывайте URL шлюза.
Шаг 1: Определите ограниченную рабочую нагрузку
Выберите небольшой набор авторизованных URL-адресов, потолок скорости и проверку приемлемости. Отделите независимые запросы от многошаговых потоков, которые нуждаются в «липком» выходе.
Используйте Channel → Генерация прокси для предполагаемой страны и продолжительности сессии. Если ваше приложение создает имена пользователей программно, следуйте точному документированному порядку параметров и кодируйте учетные данные для URL; URL-адреса, сгенерированные поставщиком, менее подвержены ошибкам.
Шаг 3: Запишите и проверьте каждый результат
Запишите зарезервированный идентификатор сессии, пункт назначения, HTTP статус, время, прошедшее с момента запроса, и принятый/отклоненный результат. Не записывайте пароли или полные URL-адреса прокси. Если много запросов завершаются неудачей, остановитесь и проведите диагностику, а не увеличивайте частоту ротации.
Ошибки прокси должны отделяться от ошибок цели и контента. Статус 407 указывает на неправильные учетные данные прокси, неподтвержденный IP-адрес источника, если используется белый список IP, или неактивный канал. Тайм-аут соединения указывает на неправильный хост или порт, заблокированный выход или проблему со шлюзом. Целевой статус 403 или 429 требует пересмотра политики источника и скорости запросов. Ответ 200 с неправильной страницей является ошибкой проверки контента.
Руководство по устранению неполадок Nstdata охватывает 407 и проблемы с подключением. Держите повторные попытки ограниченными и проверяйте тело ответа, прежде чем считать любой запрос принятым. Для получения большего контроля маршрутизации по приложениям Менеджер прокси Nstdata является отдельным уровнем операций; он не изменяет API Requests.
Что делать дальше?
Начните с метода 1 против конечной точки проверки IP, а затем перейдите к небольшому авторизованному образцу страницы. Используйте метод 2 для связанных запросов и метод 3 только тогда, когда независимые запросы оправдывают ротацию. Отслеживайте стоимость за принятую страницу, а не только успех подключения прокси. Если задача состоит в обнаружении сайтов и преобразовании Markdown, а не в создании пользовательского клиента Requests, Nstdata Crawl является отдельным API для веб-сканирования, готовым к LLM.
В: Должно ли значение https начинаться с https://?
Необязательно. Используйте схему прокси-шлюза; proxy-URL HTTP может туннелировать HTTPS назначение.
В: Устраняет ли auth=(user, password) аутентификацию прокси?
Нет. Аргумент auth в Requests, как правило, применяется к назначению. Укажите учетные данные прокси в URL-адресе прокси, предоставленном через proxies.
В: Почему Session.proxies игнорируется?
Requests могут применять настройки прокси окружения к Session.proxies. Явно передавайте proxies или используйте сессию с trust_env = False, когда это целесообразно.
В: Поддерживает ли Requests SOCKS5?
Да, с необязательной зависимостью requests[socks]. Выберите socks5h, если требует и поддерживает резолвинг DNS на стороне прокси.
В: Является ли этот код настоящим тестом Nstdata?
Нет. Для этого требуется реальный учетные данные канала Nstdata; данный фрагмент использует заполнители и должен быть выполнен в вашем авторизованном окружении.
Сравните аутентификацию с использованием прокси username-password и IP-адресов в белом списке, настройте каждый метод, диагностируйте ошибки 407 и выберите безопасный рабочий процесс Nstdata.
Kai Watanabe
Nov. 5th 2026
Более 110 млн реальных IP с успешностью доступа 99,9%
Среднее время ответа ~0,5 с для задач с высокой параллельностью
Всего от $0.1/GB
Получите мгновенный доступ к премиальным пулам резидентных, серверных, IPv6- и ISP-прокси.