1つのウェブサイト用に Requests のプロキシを選ぶ

宛先ホスト名の1つに Requests で別のプロキシを割り当て、一致の境界とフォールバックの順序を理解します。

1つのウェブサイトだけ、残りの 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 が既定値と環境由来の設定をどう統合するかも考慮してください。これら2つの明示的なエントリをリクエストとともに渡すと、意図した経路は明確になりますが、他のすべての宛先スキームに対するポリシーを定義するわけではありません。

リダイレクトは別のホスト名を持ち込むことがあります。その新しい宛先でもプロキシの選択が関係します。ルールは最初のページに付随する固定経路ではなく、要求される各 URL についての判断として読んでください。

関連記事