Перейти до змістуПроксі стоїть між вашим Python-скриптом і цільовим сайтом. Ваш код спершу надсилає запит до проксі, а той пересилає його далі. Цей додатковий крок може мати значення для тестування, контролю доступу або простого мережевого маршрутизації. Якщо ви коли-небудь запитували, як використовувати проксі з Python requests, відповідь починається саме з цієї проміжної ланки.
У цьому немає магії. Це маршрутизація. Скрипт на вашому ноутбуці може поводитися так, ніби він виходить з іншої мережі, і це змінює те, що повертають деякі сервіси. Один запит може пройти, інший — бути заблокованим, а третій може виглядати інакше, тому що IP-адреса проксі тепер є публічним обличчям з’єднання.
1. Що робить проксі в Python Requests
У requests проксі не живе всередині самого виклику сайту. Його додають до запиту як інформацію про маршрутизацію, після чого бібліотека надсилає трафік через цю адресу. Для HTTP-запитів проксі може бачити повний шлях запиту; для HTTPS проксі зазвичай обробляє тунель і передає далі зашифрований трафік, тому конфігурація має відповідати протоколу.
Швидко трапляються три поширені сценарії. Тестування з іншого регіону — один із них. Перевірка того, чи поводиться сайт інакше за корпоративним шлюзом, — інший. Мережна маршрутизація в лабораторії чи офісі — третій. Невелика деталь, велика різниця.
Проксі — не панацея. Деякі сайти блокують відомі діапазони IP-адрес проксі, а деякі проксі-сервіси ведуть журнали трафіку так, що це може суперечити вашій політиці. Якщо важливі конфіденційність або відповідність вимогам, спершу прочитайте про логи проксі та відповідність вимогам приватності, перш ніж спрямовувати автоматизацію на живу систему.
2. Передумови: встановіть Requests і зберіть дані проксі
Почніть із Python і бібліотеки requests. Якщо requests не встановлено, спершу додайте її командою pip install requests. Потім зберіть дані проксі у простий список: схема, хост, порт і, якщо потрібно, ім’я користувача та пароль.
Схема важлива, бо http і https не взаємозамінні в кожній конфігурації. Хост — це адреса проксі. Порт — це номер прослуховування, наприклад 8080 або інше значення, надане вашим провайдером. Облікові дані можуть бути необов’язковими, але якщо вони є, запишіть їх точно так, як видано. Одна неправильна літера може зламати весь ланцюг.
Якщо у вашій команді різні терміни для проксі використовують доволі вільно, глосарій VPN і проксі стане корисною довідкою. Він заощаджує час, коли одна людина каже «forward proxy», а інша має на увазі «автентифікований шлюз». Двоє людей — один збій.
3. Налаштуйте базовий проксі в requests
Найпростіше налаштування використовує словник proxies, який передається в requests.get(). Ви також можете прив’язати словник до Session, якщо хочете повторно використовувати ті самі параметри для кількох викликів. Додавайте до словника і http, і https, навіть якщо вважаєте, що буде використовуватися лише один протокол.
Приклад:
import requests |
|---|
proxies = { |
"http": "http://proxy.example.com:8080", |
"https": "http://proxy.example.com:8080", |
} |
response = requests.get("https://example.com", proxies=proxies, timeout=10) |
Ключ https часто дивує початківців. Значення все одно може починатися з http://, бо воно вказує requests, як спілкуватися з проксі, а не з кінцевим сайтом. Один рядок, два маршрути.
Для повторних викликів сесія допомагає підтримувати порядок:
session = requests.Session() |
|---|
session.proxies.update(proxies) |
response = session.get("https://example.com", timeout=10) |
Сесія може допомогти з повторним використанням cookie та зменшити кількість повторних налаштувань. Вона також робить код легшим для читання після десятого запиту — саме тоді неприбрані скрипти зазвичай починають хитатися.
4. Додайте автентифікацію до URL проксі
Деякі проксі вимагають облікові дані прямо в URL. Формат простий: http://username:password@host:port. Якщо пароль містить символи на кшталт @, : або #, їх потрібно безпечно закодувати, щоб парсер URL не сприйняв їх як роздільники.
Приклад із закодованими обліковими даними:
proxies = { |
|---|
"http": "http://user:pa%[email protected]:8080", |
"https": "http://user:pa%[email protected]:8080", |
} |
Ніколи не вставляйте сирі облікові дані в код, який плануєте комітити. Зберігайте їх у змінних середовища, сховищі секретів або іншому захищеному місці. Один витік пароля може розкрити не один скрипт.
Кодування безпечніше, ніж здогадки. У Python часто використовують urllib.parse.quote для імен користувача або паролів, що містять зарезервовані символи. Це зберігає URL проксі валідним і дозволяє уникнути тихих збоїв, які особливо дратують, бо виглядають як проблеми мережі, хоча справжня причина — одна літера.
5. Використовуйте змінні середовища для повторно придатних налаштувань проксі
Для локальної розробки змінні середовища часто зручніші за жорстке прописування значень у коді. Встановіть HTTP_PROXY і HTTPS_PROXY у вашій оболонці, і requests зможе підхопити їх автоматично. Це зручно в скриптах, ноутбуках і CI-завданнях, де одна й та сама конфігурація проксі повторюється між запусками. Якщо ви шукаєте налаштування проксі для Python requests, цей підхід часто найпростіший для підтримки. Якщо вам потрібно знати, як встановити HTTP_PROXY і HTTPS_PROXY, приклади нижче показують базовий шаблон.
Приклад для Unix-подібної оболонки:
export HTTP_PROXY="http://user:[email protected]:8080" |
|---|
export HTTPS_PROXY="http://user:[email protected]:8080" |
У Windows назви змінних ті самі, навіть якщо синтаксис команд інший. Суть одна: тримайте проксі поза вихідним файлом. На один файл менше для редагування.
requests також враховує налаштування проксі з середовища, якщо ви не перевизначите їх у коді. Це дає вам чисте значення за замовчуванням для робочої станції та інший варіант для спеціального скрипта. Якщо у вашому стеку автоматизації є більше ніж один інструмент, перегляньте як обрати VPN — там є саме той тип планування середовища, який допомагає уникнути сюрпризів пізніше.
6. Перевірте, чи проксі працює
Не довіряйте конфігурації сліпо. Перевірте вихідну IP-адресу простим запитом до сервісу, який повертає вашу публічну адресу. Якщо відповідь показує IP проксі замість вашого локального, трафік іде через проксі. Це перше підтвердження.
Також можна перевірити поведінку відповіді. Деякі сайти повертають іншу мовну версію сторінки, інший регіональний банер або іншу сторінку згоди, коли трафік приходить з іншого діапазону IP. Самі по собі ці зміни не є доказом, але вони додають підказку. Дві підказки кращі за одну.
Швидкий тестовий endpoint може допомогти:
import requests |
|---|
proxies = { |
"http": "http://proxy.example.com:8080", |
"https": "http://proxy.example.com:8080", |
} |
r = requests.get("https://api.ipify.org?format=json", proxies=proxies, timeout=10) |
Якщо endpoint повертає IP проксі, налаштування працює. Якщо час очікування спливає, проксі може бути недосяжним, або цільовий сайт може відхиляти тунель. Робочий тест важливіший за гарно оформлений конфігураційний файл.
7. Обробляйте поширені помилки проксі
Збої з’єднання зазвичай означають, що хост, порт або схема вказані неправильно. Спершу перевірте адресу. Якщо проксі очікує https://, а ви надсилаєте http://, з’єднання може зірватися ще до того, як запит дійде до сайту. Така невідповідність трапляється часто.
Помилки автентифікації вказують на ім’я користувача, пароль або кодування. Якщо облікові дані містять спеціальні символи, закодуйте їх і протестуйте ще раз. Відповідь 407 зазвичай означає, що проксі хоче автентифікацію. Не сайт. Проксі.
Тайм-аути можуть виникати через повільний проксі, заблоковану ціль або занадто коротке значення тайм-ауту в скрипті. Збільште тайм-аут трохи й спробуйте ще раз. Одна секунда часто замало для переходу між мережами, особливо якщо проксі перевантажений або цільовий сервіс того дня працює повільно.
Проблеми з SSL часто з’являються, коли проксі перехоплює HTTPS-трафік або коли перевірка сертифіката не проходить. У деяких контрольованих середовищах проксі представляє власний ланцюжок сертифікатів, тож клієнт має довіряти цьому ланцюжку. Не вимикайте перевірку легковажно. Це швидке й небезпечне рішення.
Ось практичні виправлення одним списком:
- Переконайтеся, що схема проксі відповідає сервісу проксі.
- Перевірте хост і порт за даними провайдера.
- Кодуйте імена користувача та паролі, що містять зарезервовані символи.
- Збільшіть тайм-аут із короткого значення за замовчуванням до реалістичного.
- Перевірте, чи не вимагає проксі довіреного набору сертифікатів.
- Протестуйте проксі на простому URL перед використанням у більшому робочому процесі.
8. Найкращі практики для надійного використання проксі
Використовуйте тайм-аути для кожного запиту. Без них мертвий проксі може заморозити скрипт довше, ніж ви очікуєте. Значення на кшталт timeout=10 — поширена стартова точка, а далі ви коригуєте її після кількох реальних тестів.
Повтори допомагають при тимчасових збоях, але їх кількість має бути обмеженою. Цикл, який без кінця б’є по зламаному проксі, може зробити погану хвилину ще гіршою. Тримайте кількість повторів невеликою й зупиняйтеся, коли помилка явно постійна. Зазвичай трьох спроб достатньо, щоб виявити мертвий шлях.
Повторно використовуйте сесії, де це можливо. Сесія зменшує повторне налаштування і може тримати з’єднання впорядкованими між кількома викликами. Це важливо в процесі, що робить 20, 50 або 100 запитів. Це також полегшує читання коду, що допомагає під час налагодження о 2-й ночі.
Захищайте секрети так, ніби вони чутливі, бо так і є. Не записуйте облікові дані проксі в логи, ноутбуки чи історію git. Якщо вам потрібні командні поради щодо патернів автентифікації, Посібник із найкращих практик автентифікації проксі стане розумним наступним читанням, особливо якщо над одним і тим самим скриптом працюють кілька людей.
Обирайте джерела проксі відповідно до завдання та правил, яких ви маєте дотримуватися. Особистий тест, корпоративне мережеве правило й публічне завдання зі збору даних не повинні бути в одній категорії. Якщо ви працюєте з регіональною інфраструктурою або зі змінами в поведінці провайдера, останні зміни в інфраструктурі проксі допоможуть зрозуміти, що змінилося і чому деякі старі скрипти тепер не працюють.
І ще одне. Зробіть налаштування проксі нудним. Нудне — це добре. Проксі, яке задокументоване, протестоване, закодоване й контрольоване, приносить менше сюрпризів, ніж хитрий скрипт, який працює лише на одному комп’ютері з одним кешованим обліковим даними і одним вдалим маршрутом.