直接リクエストがリダイレクトに到達し、次のやり取りがプロキシで失敗する場合は、その遷移を調べます。Requests はリダイレクトのためにプロキシ関連の設定を再構築し、Session がそれを信頼している場合には環境を再び参照することがあります。

マッピングの値マージ中に何が起こるか
Noneキーが削除され、後続のパスが環境から埋める可能性のある欠落した項目が残ります。
空の文字列明示的な値が残り、そのスキームに対する直接ルーティングの意図を保持できます。

既存の Session では、直接操作に関係する送信先スキームを指定します:

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

アプリケーションが提供する場合は、追加のホスト固有のマッピングとカスタムアダプタを確認してください。このルーティング入力は、それらのコンポーネントが実装するすべてのポリシーを上書きするものではありません。

診断では各 URL を残す

元の URL、各リダイレクト先、応答ステータス、失敗した段階を記録します。HTTP から HTTPS への変更は該当するスキームキーを変えます。新しいホストは最初のホストのバイパス規則の外側になることがあります。最初の URL だけを含む報告では、両方の遷移が隠れます。

リダイレクト追跡を無効にして 1 つの応答を観察すると、境界が明らかになることがあります。要求するか決める前に、その location をデータとして調べます。元の認証情報を新しい送信先へ無差別に送らないでください。

アプリケーションがすべてのルーティングと信頼の入力を意図的に所有する場合、環境探索を無効にした専用の Session も選択肢になります。これは 認証情報と CA の自動探索 にも影響するため、日常的なリダイレクト修理ではなくアプリケーションのポリシーとして選んでください。

関連記事