Перенаправления в Python Requests: None против пустых значений proxy
Сохраняйте намерение прямого маршрута явным на протяжении перенаправлений вместо того, чтобы полагаться на значение None, которое удаляет запись сопоставления.
Если прямой запрос доходит до перенаправления, а следующий обмен завершается ошибкой на proxy, изучите переход. Requests заново строит настройки, связанные с proxy, для перенаправлений и может снова обратиться к окружению, когда Session ему доверяет.
| Значение сопоставления | Что происходит при слиянии |
|---|---|
None | Ключ удаляется, и остаётся отсутствующая запись, которую последующий проход может заполнить из окружения. |
| Пустая строка | Явное значение сохраняется; оно может сохранить намерение прямого маршрута для этой схемы. |
Для существующей Session укажите схемы назначения, участвующие в прямой операции:
response = session.get(
'https://example.com/start',
proxies={'http': '', 'https': ''},
timeout=15,
)Проверьте дополнительные сопоставления для конкретных хостов и пользовательские адаптеры, если приложение их предоставляет. Этот вход маршрутизации не переопределяет все возможные политики, которые реализуют эти компоненты.
Сохраняйте каждый URL в диагностике
Записывайте исходный URL, каждое место перенаправления, статус ответа и этап, на котором происходит сбой. Переход с HTTP на HTTPS меняет соответствующий ключ схемы; новый хост может оказаться вне правила обхода первого хоста. Отчёт, содержащий только начальный URL, скрывает оба перехода.
Наблюдение одного ответа с отключённым следованием перенаправлениям может выявить границу. Изучите его расположение как данные, прежде чем решать запрашивать его; не отправляйте исходные учётные данные на новый адрес без разбора.
Отдельная Session с отключённым обнаружением окружения — ещё один вариант, когда приложение намеренно владеет всеми входами маршрутизации и доверия. Это также влияет на автоматическое обнаружение учётных данных и CA, поэтому выбирайте это как политику приложения, а не как рутинный ремонт перенаправления.