직접 요청이 리디렉션에 도달하고 다음 교환이 프록시에서 실패하면 그 전환을 살펴보세요. Requests는 리디렉션을 위해 프록시 관련 설정을 다시 구성하며 Session이 이를 신뢰할 때 환경을 다시 참조할 수 있습니다.

매핑 값병합 중에 일어나는 일
None키가 제거되어 나중 단계가 환경에서 채울 수 있는 누락된 항목이 남습니다.
빈 문자열명시적 값이 남아 있으며 해당 스킴의 직접 라우팅 의도를 보존할 수 있습니다.

기존 Session의 경우 직접 작업에 관련된 대상 스킴을 지정하세요:

response = session.get(
    'https://example.com/start',
    proxies={'http': '', 'https': ''},
    timeout=15,
)

애플리케이션이 제공한다면 추가 호스트별 매핑과 사용자 정의 어댑터를 확인하세요. 이 라우팅 입력이 해당 구성 요소가 구현하는 모든 가능한 정책을 덮어쓰지는 않습니다.

진단에서 모든 URL을 유지하세요

원래 URL, 각 리디렉션 위치, 응답 상태, 실패한 단계를 기록하세요. HTTP에서 HTTPS로의 변경은 관련 스킴 키를 바꿉니다. 새 호스트는 첫 호스트의 우회 규칙 밖에 있을 수 있습니다. 초기 URL만 담은 보고서는 두 전환을 모두 감춥니다.

리디렉션 따라가기를 끈 상태에서 응답 하나를 관찰하면 경계가 드러날 수 있습니다. 요청할지 결정하기 전에 그 위치를 데이터로 살펴보세요. 원래 자격 증명을 새 대상으로 무분별하게 보내지 마세요.

애플리케이션이 모든 라우팅과 신뢰 입력을 의도적으로 소유한다면 환경 탐색을 끈 전용 Session도 선택지입니다. 이는 자격 증명과 CA 자동 탐색 에도 영향을 주므로 일상적인 리디렉션 수리가 아니라 애플리케이션 정책으로 선택하세요.

관련 글