웹사이트 하나를 위한 Requests 프록시 선택

Requests에서 대상 호스트 이름 하나에 다른 프록시를 지정하고 일치 경계와 대체 순서를 이해합니다.

웹사이트 하나가 나머지 HTTPS 요청과 다른 프록시를 필요로 할 수 있습니다. Requests는 그 선택을 프록시 딕셔너리 자체에서 표현할 수 있습니다:

routes = {
    "https://reports.example": "http://reports-proxy.example:8080",
    "https": "http://default-proxy.example:8080",
}
response = requests.get(
    "https://reports.example/monthly",
    proxies=routes,
    timeout=(5, 20),
)
response.raise_for_status()

그 대상에는 호스트 이름별 키가 우선합니다. 다른 HTTPS 호스트 이름은 스킴 전체 항목을 사용합니다. 값은 프록시 연결을 설명하므로 HTTPS 대상이 HTTP 프록시 URL에 올바르게 매핑될 수 있습니다. 이것이 프록시 계정 없는 허용된 공개 사이트 경로라면 HTTP 프록시 목록에서 그 값의 후보를 얻을 수 있습니다. 대상별 규칙은 명시적으로 유지하세요.

리소스 URL이 아니라 호스트 이름을 일치시킵니다

Requests 2.32.5에서 특정 키는 대상의 스킴과 파싱된 호스트 이름으로 만들어집니다. 경로, 쿼리, 포트는 포함되지 않습니다.

딕셔너리 키에 /monthly을 추가해도 규칙이 그 경로로 제한되지 않습니다. 마찬가지로 https://reports.example:8443는 이 선택기가 인식하는 포트별 키가 아닙니다. 대상 URL이 다른 포트를 사용할 때도 호스트 이름 규칙이 적용됩니다.

이 조회에는 와일드카드 확장이 없습니다. reports.example에 대한 규칙이 하위 도메인을 자동으로 덮지 않습니다. 정책에 경로, 포트, 접미사 일치가 필요하면 이 단순한 딕셔너리 밖에서 명시적 라우팅 결정을 사용하세요.

다음에 오는 대체 항목 알기

구현은 키를 이 순서로 확인합니다: scheme://hostname, scheme, all://hostname, 그다음 all. 따라서 스킴 전체 HTTPS 항목이 모든 스킴의 호스트 이름 항목보다 우선합니다. 그것이 의도한 예외라면 설계에서 스킴별 호스트 이름 규칙을 가장 먼저 두세요.

Session이 기본값과 환경에서 파생된 설정을 어떻게 병합하는지도 고려하세요. 이 두 가지 명시적 항목을 요청과 함께 전달하면 의도한 경로가 분명해지지만 다른 어떤 대상 스킴에 대한 정책도 정의하지 않습니다.

리다이렉트는 다른 호스트 이름을 끌어들일 수 있으며, 그 새 대상에도 프록시 선택이 관련됩니다. 규칙은 첫 페이지에 붙은 고정 경로가 아니라 요청되는 각 URL에 대한 결정으로 읽으세요.

관련 글