Réponse rapide
Comment garder la même IP de ville pour plusieurs requêtes ?
Les sessions sticky EuroCity Proxies conservent une seule IP de sortie jusqu'à 30 minutes (l'IP peut changer plus tôt, par exemple si l'appareil résidentiel passe hors ligne). Ajoutez -session-<id>-ttl-<minutes> à un nom d'utilisateur de ville, par exemple USERNAME-country-fr-city-lyon-session-lyon1-ttl-10. Depuis octobre 2026, le ttl peut être réglé jusqu'à 30. Utilisez un session id par ville et par tâche.
Quelle est la différence entre les noms d'utilisateur rotatifs et sticky ?
| Mode | Exemple de nom d'utilisateur | Comportement de l'IP de sortie | Idéal pour |
|---|---|---|---|
| Rotatif | USERNAME-country-pl-city-krakow | Une nouvelle connexion obtient généralement une IP différente dans la ville | Chargements de pages indépendants, un par connexion |
| Sticky, 10 minutes | USERNAME-country-pl-city-krakow-session-krk1-ttl-10 | Même IP jusqu'à 10 minutes, même entre de nouvelles connexions | Une courte vérification : une page, deux clics, une capture d'écran |
| Sticky, 30 minutes | USERNAME-country-pl-city-krakow-session-krk2-ttl-30 | Même IP jusqu'à 30 minutes | Un test plus long de votre propre site, comme un paiement en mode test |
À quoi sert une session sticky ?
Une session sticky associe un identifiant de session à une seule IP de sortie pendant une durée définie. Chaque connexion qui utilise le même nom d'utilisateur, y compris le même identifiant, sort par cette IP jusqu'à expiration du ttl. L'IP peut changer avant, par exemple quand l'appareil domestique derrière elle se déconnecte.
Sans identifiant de session, la passerelle fonctionne en mode rotatif. Chaque nouvelle connexion reçoit une IP du pool, généralement différente ; pour obtenir une nouvelle IP à chaque requête, envoyez une requête par connexion (désactivez le keep-alive). La rotation convient aux requêtes indépendantes. Une session sticky convient à une séquence vue comme un seul visiteur depuis un même endroit. Exemple : une boutique qui conserve votre zone de livraison dans un cookie.
Les sessions conservent la ville choisie sur la liste des villes ; combinez-les avec le ciblage ASN et vérifiez la sortie avec le vérificateur de ville proxy. Les offres sont sur la page tarifs.
Pourquoi utiliser une session par ville et par tâche ?
Parce que chaque tâche a alors un début clair, une sortie connue et une fin propre. Nommez l'identifiant d'après la ville et la tâche : lyon1 pour le premier contrôle Lyon, krk2 pour le second contrôle Kraków. Les identifiants de session acceptent de 1 à 32 lettres ou chiffres.
Les résultats restent ainsi lisibles. Quand une page Lyon semble incorrecte, vous savez quelle sortie l'a servie et pouvez vérifier cette IP. Cela évite aussi qu'une session longue durée mélange plusieurs contrôles, cookies et paniers sur la même adresse. Quand une tâche se termine, fermez son client et démarrez la suivante avec un nouvel identifiant.
Dois-je choisir ttl-10 ou ttl-30 ?
Choisissez le ttl le plus court qui couvre la tâche : ttl-10 pour la plupart des contrôles, ttl-30 uniquement pour les flux longs. Un contrôle d'une page de ville, d'un produit et d'un créneau de livraison tient généralement en dix minutes. Un test de votre propre paiement, avec formulaires et étape de paiement en mode test, peut nécessiter trente minutes.
Ne comptez pas sur le ttl complet. Relevez l'IP de sortie au début et à la fin de la tâche. Si elle a changé, l'appareil s'est déconnecté ; répétez la tâche une fois avec un nouvel identifiant. Le maximum est de 30 minutes, donc découpez le travail plus long en plusieurs tâches.
Comment le keep-alive modifie-t-il l'IP de sortie ?
Le keep-alive maintient une connexion ouverte, et une connexion garde une seule sortie. Les connexions HTTP/1.1 sont persistantes par défaut selon la RFC 9112, donc les clients les réutilisent sauf instruction de fermeture.
- requests : une
Sessionréutilise les connexions de son pool. La documentation Requests décrit le keep-alive comme automatique au sein d'une session. - httpx : un
Clientgarde ses connexions ouvertes de la même façon. - undici (Node.js) : un socket inactif reste ouvert 4 secondes par défaut (
keepAliveTimeout), plus longtemps si le serveur envoie une indication keep-alive.
Avec une session sticky, cela n'a pas d'importance : l'identifiant conserve l'IP même sur une nouvelle connexion. Avec un nom d'utilisateur rotatif, si. Les requêtes envoyées sur une même connexion ouverte partagent une seule sortie. Pour une nouvelle IP à chaque requête, fermez la connexion ou ouvrez un nouveau client à chaque fois.
# pip install requests
from urllib.parse import quote
import requests
HOST = "gw.eurocityproxies.com"
PORT = 7777
PASSWORD = quote("PASSWORD", safe="")
def session_for(country: str, city: str, task: str, ttl: int = 10) -> requests.Session:
user = f"USERNAME-country-{country}-city-{city}-session-{task}-ttl-{ttl}"
proxy = f"http://{user}:{PASSWORD}@{HOST}:{PORT}"
s = requests.Session()
s.trust_env = False # ignore HTTP_PROXY / HTTPS_PROXY set on your machine
s.proxies = {"http": proxy, "https": proxy}
return s
def exit_ip(s: requests.Session) -> str:
return s.get("https://ipinfo.io/json", timeout=30).json()["ip"]
tasks = [("fr", "lyon", "lyon1"), ("pl", "krakow", "krk1"), ("nl", "the_hague", "hag1")]
for country, city, task in tasks:
with session_for(country, city, task) as s:
start = exit_ip(s)
page = s.get("https://YOUR-SITE.example/", timeout=30)
end = exit_ip(s)
note = "same exit" if start == end else "exit changed: repeat once with a new id"
print(city, start, page.status_code, note)Les sessions permettent-elles de contourner les limites de débit d'un site ?
Non. Les sessions et la rotation choisissent l'origine de vos requêtes ; elles ne changent pas ce qu'un site autorise. Lancez une session par ville et par exécution, à un rythme modéré. La rotation n'est pas un moyen de contourner les limites de débit d'un site.
Si une page échoue, attendez et réessayez une fois plus tard. Si le site refuse toujours, arrêtez et passez par sa voie officielle, comme une API ou un partenaire de données. La politique d'utilisation acceptable liste les usages interdits du service.
Quel trafic consomment les sessions sticky ?
Une session ne coûte rien en soi : vous payez uniquement les données envoyées et reçues. L'usage compte toutes les données envoyées et reçues via le proxy (upload et download, en-têtes inclus). 1 GB = 1 000 000 000 octets. Les tentatives de connexion qui échouent avant d'atteindre la cible ne sont pas comptées. Un contrôle de ville court avec une page et deux recherches d'IP utilise généralement quelques mégaoctets ou moins, selon la page.
Le trafic est partagé entre toutes les villes et sessions de votre compte. Le trafic prépayé résidentiel et mobile rotatif n'expire jamais : les GB non utilisés restent sur votre compte jusqu'à leur utilisation. Les offres commencent à 0,95 $US pour 1 GB sur la page tarifs.
Sessions sticky : questions
Quelle est la durée maximale d'une session sticky ?
Trente minutes. Définissez -ttl-30 dans le nom d'utilisateur. L'IP peut toutefois changer avant si l'appareil domestique derrière elle se déconnecte. Relevez l'IP de sortie au début et à la fin de chaque tâche.
Comment obtenir une nouvelle IP dans la même ville ?
Changez l'identifiant de session, par exemple de lyon1 à lyon2, et gardez le reste du nom d'utilisateur. Avec un nom d'utilisateur rotatif, ouvrez plutôt une nouvelle connexion.
Deux scripts peuvent-ils partager une même session ?
Une session est identifiée par son nom d'utilisateur, son identifiant et son ttl, donc deux scripts qui envoient exactement les mêmes valeurs demandent la même session sticky. Vérifiez l'IP de sortie dans chaque script avant de vous y fier, et utilisez des identifiants distincts pour des tâches distinctes.
Une session sticky conserve-t-elle la même ville ?
Oui. La ville fait partie du nom d'utilisateur, et la session conserve une seule IP de sortie issue du ciblage de cette ville. La disponibilité des villes varie ; le paiement indique ce qui est en ligne.
Pourquoi mon IP a-t-elle changé après deux minutes avec ttl-10 ?
Les connexions domestiques se déconnectent : un routeur redémarre, un appareil se met en veille, un fournisseur réattribue une adresse. La session obtient alors une nouvelle sortie. Répétez la tâche une fois avec un nouvel identifiant ; si cela arrive à chaque tâche, écrivez au support avec les horaires et les IP.
Les sessions sticky coûtent-elles plus cher que les rotatives ?
Non. Les deux utilisent le même tarif au GB. Ciblage par pays et par ville sur tous les plans ; aux États-Unis également par État et code ZIP ; ciblage par ASN sans surcoût. La disponibilité des villes varie.
Sources (5)
- RFC 9112 HTTP/1.1, section 9.3 Persistence — IETF (June 2022, checked 2026-10-18)
- Requests : Advanced Usage, Session Objects et Keep-Alive — Requests (checked 2026-10-18)
- undici Client : keepAliveTimeout (4e3 ms par défaut) — Node.js project (checked 2026-10-18)
- HTTPX : Proxies — Encode (checked 2026-10-18)
- Point de terminaison JSON IPinfo — IPinfo (checked 2026-10-18)