Un pot à cookies Scrapy appartient à une session, pas automatiquement à un proxy
Choisissez une identité explicite de pot à cookies lorsque plusieurs flux avec proxy partagent une araignée, et transportez cette identité vers les requêtes suivantes.
Changer de proxy ne change pas automatiquement les cookies de l’araignée. Cela peut être utile pour une session qui continue et surprenant lorsque plusieurs sessions indépendantes partagent l’araignée.
Le middleware de cookies de Scrapy prend en charge des pots distincts, sélectionnés par les métadonnées cookiejar de la requête. Donnez à cette clé l’identité que vous voulez réellement conserver :
yield scrapy.Request(
'https://example.com/start',
meta={'proxy': selected_proxy, 'cookiejar': 'workflow-17'},
)
Le point d’aboutissement et la clé du pot sont des choix indépendants. Un parcours public non authentifié peut prendre son point d’aboutissement HTTP choisi dans la liste de proxys HTTP là où cette route est autorisée ; le flux de travail reste propriétaire de la clé du pot. Une requête suivante qui doit rester dans cette session a besoin de la même clé de pot ; les métadonnées ne collent pas automatiquement à chaque nouvelle requête que vous créez. Propagez les champs précis exigés par le flux de travail au lieu de copier aveuglément toutes les métadonnées du middleware.
Utiliser l’adresse du proxy comme clé du pot n’est qu’une politique
Ce raccourci regroupe l’état par point d’aboutissement. Il ne le regroupe pas forcément par personne, compte ou sortie publique. Un point d’aboutissement de fournisseur peut faire tourner les sorties, et plusieurs comptes peuvent utiliser le même point d’aboutissement.
Pour un flux de travail autorisé qui a besoin d’un état stable, consignez séparément l’identifiant de compte/session, l’identifiant de pot et la route choisie. Si vous décidez de changer de route en cours de chemin, décidez aussi ce qui doit arriver à la session de l’application.
Des pots distincts empêchent le partage accidentel de cookies entre les groupes que vous avez définis. Ils ne promettent pas qu’une destination ne puisse pas relier deux requêtes par un compte ou d’autres données applicatives.
Si la mauvaise page persiste après un changement d’IP, examinez quel pot a envoyé la requête avant de supprimer tous les cookies ou de remplacer tout le pool de proxys. L’état conservé peut très bien expliquer la page.