HTTPX пошёл через чужой прокси: разбираем trust_env и окружение

Локально клиент обращается к сервису напрямую, а на другой машине получает ошибку подключения к прокси. В коде proxy не задан. Причина может находиться в окружении процесса: HTTPX по умолчанию учитывает настройки прокси и некоторые настройки сертификатов из переменных окружения. Одинаковый исходный файл ещё не означает одинаковый маршрут запроса.

Для клиента с полностью явной сетевой конфигурацией можно поставить trust_env=False. Это отключает использование переменных окружения, поддерживаемых HTTPX. Важно понимать ширину изменения: речь не только о HTTP_PROXY, HTTPS_PROXY и ALL_PROXY, но также о SSL_CERT_FILE и SSL_CERT_DIR. Если корпоративный корневой сертификат был задан только через окружение, его нужно передать другим явным способом.

Сетевая политика процесса

Диагностику начните с окружения именно запущенного процесса. Терминал, IDE и служба могут наследовать разные значения. Не выводите полный URL прокси в общедоступный журнал: он может содержать учётные данные. Для проверки решения достаточно знать наличие переменной и выбранный режим клиента.

import os
import tempfile
from pathlib import Path
from unittest.mock import patch
import httpx

with tempfile.TemporaryDirectory() as directory:
    missing = str(Path(directory) / "missing-ca.pem")
    with patch.dict(os.environ, {"SSL_CERT_FILE": missing}):
        try:
            with httpx.Client(trust_env=True):
                pass
        except OSError:
            pass
        else:
            raise AssertionError("invalid certificate path must be noticed")
        with httpx.Client(trust_env=False) as client:
            assert not client.is_closed
    print("explicit environment policy")

Явная конфигурация клиента

Установите HTTPX командой python -m pip install httpx. Этот файл на Python 3.12 проверяет выбор окружения без сетевого запроса: путь к сертификату намеренно не существует. При trust_env=True создание HTTPS-контекста замечает неправильный SSL_CERT_FILE, при False клиент создаётся. Пример проверен с HTTPX 0.28.1. В прикладном интеграционном тесте дополнительно подтвердите реальный маршрут к контролируемому адресу.

Если прокси нужен, лучше настроить его явно там, где собирается клиент. Тогда настройки приложения показывают, откуда берётся маршрут, а тест может передать собственное значение. Для исключений используется NO_PROXY, но его правила стоит проверить на нужных адресах и доменах. Не исправляйте проблему маршрута отключением проверки TLS: verify=False решает другой вопрос и убирает проверку подлинности сервера.

Для переиспользуемой библиотеки не стоит без объяснения навязывать trust_env=False всем пользователям. Сетевую политику обычно выбирает приложение. Библиотека может принимать готовый Client либо явную настройку создания. Это позволяет запускать тот же код в окружении с обязательным корпоративным прокси и в изолированном процессе.

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

Когда локальный пример работает, полезно разобрать соседние механизмы языка и их взаимодействие. В курсе «Python для профессионалов» есть практика по итераторам, генераторам, декораторам, asyncio, метапрограммированию и профилированию. Эти темы помогают понимать время жизни объектов, управление выполнением и причины поведения прикладной программы.

Посмотреть программу и практику курса.

Документация: официальный источник по теме.

Другие задачи по теме: База, HTTP-клиенты и тесты API.