La règle en une phrase#
Rotation lorsque chaque demande est indépendante ; coller lorsque la cible lie les demandes entre elles (une connexion, un panier, une recherche paginée, un formulaire en plusieurs étapes) ou lorsqu'elle surveille la cohérence.
Table de décision#
| Emploi | Mode | Nom d'utilisateur |
|---|---|---|
| Collecter les pages produits par URL | Rotation | UTILISATEUR-cc-de |
| Recherchez, puis ouvrez trois pages de résultats | Collant, 5 min | USER-cc-de-sid-q17-ttl-5m |
| Ajouter au panier, paiement, confirmation | Collant, 30 min | USER-cc-us-sid-order42-ttl-30m |
| Connectez-vous et agissez comme un seul utilisateur pendant une journée | Collant, 24 h | USER-cc-gb-sid-acct9-ttl-24h |
| Gardez une adresse pendant des semaines | Pas une session : proxy du FAI | ip:8000 de votre liste |
| Échantillonnage SERP de nombreuses villes | Rotation, ville par demande | UTILISATEUR-cc-us-city-chicago |
Comment la passerelle décide#
- Une nouvelle connexion TCP est une nouvelle connexion de transport, et non la preuve d'une nouvelle sortie. Le mode de rotation attribué à la passerelle décide de la manière dont cette connexion est acheminée.
- Utilisez un identifiant de session distinct pour chaque flux de travail indépendant, lorsque la passerelle attribuée le prend en charge. Confirmez la durée autorisée et les paramètres de localisation dans les détails de votre connexion. Un appareil résidentiel peut se déconnecter avant la durée demandée ; une session persistante n'est pas une garantie de la même IP pendant des jours. Pour une adresse fixe, comparez un produit statique dédié.
- La modification d'un identifiant de session demande une session de routage distincte lorsque cela est pris en charge ; cela ne garantit pas une IP inutilisée ou différente. Mesurez les adresses renvoyées au lieu de les déduire du nom d'utilisateur.
- Un délai d'inactivité peut provenir du client, de la passerelle, de la sortie ou de la destination. Enregistrez le temps écoulé et comparez les limites de connexion/lecture du client avec les paramètres de service attribués. Une réinitialisation de la connexion ne prouve pas en soi que la sortie résidentielle s'est déconnectée ; reproduisez l'erreur avec une petite requête avant de modifier la configuration.
Le piège du maintien en vie#
La réutilisation des connexions et l'attribution des adresses IP sont des contrôles différents. Une session client réutilise les sockets ; seule la passerelle attribuée détermine le comportement de rotation et de session persistante. Utilisez les paramètres de session fournis avec votre service et vérifiez la sortie sur plusieurs requêtes. La fermeture d'un socket ou l'envoi de Connection: close ne garantit pas une IP différente.
Nouvelles tentatives#
Classez la réponse avant de réessayer. Un 403 peut indiquer une règle d'accès qu'une autre IP ne résoudra pas. Pour 429, respectez Retry-After et réduisez le taux de requêtes ; utilisez une interruption limitée en cas de connexion temporaire ou de pannes de serveur. Réessayez les opérations de changement d'état uniquement lorsque vous pouvez empêcher les actions en double.
Parallélisme#
Des identifiants de session distincts isolent les préférences de routage, et non les cookies du navigateur ou l'état de l'application. Commencez avec un petit nombre de travailleurs, mesurez les erreurs et le trafic, et augmentez progressivement dans les limites confirmées pour votre commande et la destination. Une sélection étroite de villes ou de opérateurs peut réduire la capacité disponible.
Les questions que les gens posent#
Une séance collante est-elle plus chère ?
Non. Le trafic coûte le même prix par Go, que la sortie tourne ou non ; un identifiant de session change le routage, pas le prix.
Puis-je faire durer une séance plus de 24 heures ?
Pas sur la piscine résidentielle. Pour les adresses qui doivent rester fixes pendant des semaines, louez un proxy FAI : trafic statique, dédié et illimité.