ログはプロキシを切り替える。リクエストはまだ古いものを使っている。

セレクタはプロキシ A を表示し、次にプロキシ B を表示します。しかしリクエストログはプロキシ A のままです。この矛盾を説明するのにネットワークサービスは不要です。呼び出し側がセレクタの戻り値を捨てている可能性があります。

その値を、リクエストを送信する呼び出しまで追跡してください:

endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)

この断片は、既存の Requests セッションと検証済みのプロキシ URL を前提としています。公開された仲介者を通じて許可される公開リクエストでは、無料プロキシリストが、同じ選択と送信の経路を通る候補 URL を提供します。サポートされるキーワードは proxies です。マッピングを表示するだけの、あるいは誰も代入しないマッピングを返すヘルパーは、ここで渡されるマッピングの代わりにはなりません。

選択したルートはその操作のローカルに保ってください。並行コードでは、共有の current_proxy フィールドがログ記録と送信の間で変わり得ます。すると別のワーカーの選択が、誤った結果の隣に現れることがあります。

選択、送信設定、結果を結び付けるには試行 ID を使います。資格情報を含む場合は、完全な URL ではなく安全なエンドポイント識別子をログに記録してください。

これらの値が一致しているのに観測される公開 IP が変わらないなら、別の問いに到達しています。選択したエンドポイントが異なる出口を提供しているのか、それとも回転するゲートウェイが接続を保持しているのか。まず、アプリケーションが選択したと主張するルートを実際に送ったかを確定してください。そうでなければ、プロバイダ側の推測が単純な古い変数を何時間も隠すことがあります。