Проксі Session у Python Requests і пріоритет оточення

Зробіть маршрутизацію Python Requests передбачуваною під час взаємодії session.proxies, змінних оточення, параметрів запиту й trust_env.

Якщо session.proxies указує на один вузол, але скрипт використовує проксі оболонки, повторне присвоєння того самого словника не усуне конфлікт. Requests може об’єднувати налаштування так, що проксі оточення мають пріоритет над типовими значеннями Session. Вирішіть, чи має Session далі виявляти налаштування в оточенні.

Збережіть виявлення оточення, задавайте маршрути в запиті

Передавайте явні значення окремому виклику, як радить Requests для уникнення цього конфлікту між Session та оточенням:

proxies = {
    "http": "http://127.0.0.1:8080",
    "https": "http://127.0.0.1:8080",
}

with requests.Session() as session:
    response = session.get(
        "https://example.com/",
        proxies=proxies,
        timeout=(5, 15),
    )
    response.raise_for_status()

Замініть локальний слухач своїм. Порівнюючи загальнодоступні HTTP-вузли, обирайте кандидатів зі списку HTTP-проксі, не змінюючи політику Session. Це керує переданими записами відображення; свідомо оберіть налаштування й для інших схем чи хостів застосунку. Служба, IDE, контейнер або виконавець CI можуть успадкувати інше оточення, ніж термінал.

Нехай Session керує власними налаштуваннями

Якщо застосунок не має виявляти проксі в оточенні, задайте політику до першого запиту:

with requests.Session() as session:
    session.trust_env = False
    session.proxies = {
        "http": "http://127.0.0.1:8080",
        "https": "http://127.0.0.1:8080",
    }
    response = session.get(
        "https://example.com/",
        timeout=(5, 15),
    )
    response.raise_for_status()

trust_env=False також впливає на пов’язану з оточенням конфігурацію сертифікатів та автоматичну автентифікацію netrc. Перед вибором врахуйте ці залежності. Для схваленого приватного набору сертифікатів CA можна передати явний шлях:

response = session.get(
    "https://example.com/",
    timeout=(5, 15),
    verify="/path/to/approved-ca-bundle.pem",
)

Використовуйте справді схвалений набір і залишайте перевірку ввімкненою. Для кожної політики маршрутизації тримайте окрему Session замість зміни однієї, коли її використовують інші завдання.

Якщо жоден варіант не пояснює маршрут застосунку, порівняйте ізольовану Session із застосунком у тому самому середовищі виконання та з нешкідливим призначенням. Запишіть наявні змінні проксі, значення trust_env і чи передає виклик proxies; не додавайте URL з обліковими даними до спільних журналів. Успіх ізольованої Session спрямовує наступну перевірку на створення Session, адаптери, потоки підготовлених запитів чи власні транспорти. Тест оточення через curl не визначає власну поведінку об’єднання Requests.

Схожі статті