ScrapyのCookieジャーはセッションに属し、プロキシに自動で属するわけではない

プロキシを切り替えても、スパイダーのCookieが自動で切り替わるわけではありません。継続する1つのセッションには便利ですが、複数の独立したセッションが同じスパイダーを共有する場合は予想外の結果になります。

ScrapyのCookieミドルウェアは、リクエストのcookiejarメタデータで選択される別々のジャーをサポートします。そのキーには、実際に保持したい識別子を指定します。

yield scrapy.Request(
    'https://example.com/start',
    meta={'proxy': selected_proxy, 'cookiejar': 'workflow-17'},
)

エンドポイントとジャーのキーは独立した選択です。認証されていない公開クロールは、そのルートが許可されている場所でHTTPプロキシ一覧から選択したHTTPエンドポイントを使えますが、ジャーのキーは依然としてワークフローが所有します。このセッションに残すべき後続リクエストには同じジャーのキーが必要です。メタデータは、作成するすべての新しいリクエストに自動で付着するわけではありません。ミドルウェアのメタデータをすべて盲目的にコピーするのではなく、ワークフローが必要とする特定のフィールドを引き継いでください。

プロキシアドレスをジャーのキーにするのは1つの方針にすぎない

その省略方法は状態をエンドポイント単位でまとめるだけです。人、アカウント、公開出口ごとにまとめるとは限りません。1つのプロバイダーのエンドポイントが出口を切り替えることがあり、複数のアカウントが同じエンドポイントを使うこともあります。

安定した状態を必要とする許可されたワークフローでは、アカウント/セッション識別子、ジャー識別子、選択したルートを別々に記録してください。途中でルートを変更する場合は、アプリケーションのセッションをどうするかも決めてください。

ジャーを分けると、定義したグループ間でCookieが偶発的に共有されるのを防げます。ただし、宛先がアカウントや他のアプリケーションデータを通じて2つのリクエストを関連付けられないことは保証しません。

IPを変更した後も誤ったページが残る場合は、すべてのCookieを削除したりプロキシプール全体を交換したりする前に、どのジャーがリクエストを送ったかを確認してください。保持された状態がページを十分に説明できることがあります。