# Sessions persistantes et rotation d’IP : IDs de session, TTL et réutilisation des connexions

> Comment fonctionnent les sessions persistantes et la rotation d’IP sur une passerelle proxy résidentielle : IDs de session, TTL, réutilisation des connexions selon la bibliothèque, et pool de sessions.

- URL: https://crawlrelay.com/fr/docs/sessions/
- Dernière mise à jour: 2026-10-13
- Publisher: CrawlRelay (https://crawlrelay.com)

La rotation se fait par connexion, la persistance par ID de session. Une fois que vous savez comment votre bibliothèque réutilise les connexions, vous pouvez décider exactement quand l’IP change.

**Réponse rapide — Comment fonctionnent les sessions persistantes et la rotation d’IP sur un proxy résidentiel ?**

Avec un proxy résidentiel **CrawlRelay**, un nom d’utilisateur sans ID de session obtient une IP du pool à chaque nouvelle connexion TCP, généralement différente, et `-session-<id>-ttl-<minutes>` conserve une IP pour cet ID pendant jusqu’à 30 minutes, même si l’IP peut changer plus tôt. La rotation suit les connexions, pas les requêtes HTTP, donc la persistance (keep-alive) détermine quand votre IP change vraiment. Le trafic résidentiel coûte 0,50 $US/GB dès 50 GB. Paiement en crypto, sans KYC.

## Règles des sessions en résumé

| Attribut | Valeur |
| --- | --- |
| Unité de rotation | Une IP du pool par nouvelle connexion TCP, généralement différente |
| Session persistante | `-session-<id>-ttl-<minutes>` ajouté au nom d’utilisateur |
| Durée de la session | jusqu’à 30 minutes |
| ID de session | 1 à 32 lettres ou chiffres ; un ID par flux |
| Ce qui met fin à une session prématurément | L’appareil résidentiel derrière passant hors ligne |
| Identifiants partagés | Les clients qui envoient le même ID partagent la même sortie |
| Coût | Aucun : les sessions et la rotation sont inclus dans le prix par GB |

## Que se passe-t-il à la passerelle lorsque j'envoie un ID de session ?

La passerelle lit le nom d'utilisateur à chaque nouvelle connexion. Sans partie session, elle choisit une sortie proxy résidentiel qui correspond à votre ciblage pour cette connexion uniquement. Avec une partie session, elle conserve la même sortie pour cet ID pendant la durée TTL que vous avez définie.

Une IP collante est une connexion résidentielle réelle, donc elle peut disparaître avant la fin du TTL : appareil éteint, perte de Wi-Fi ou changement de réseau. Les flux longs doivent gérer cela, en vérifiant l'IP de sortie à des points de contrôle et en redémarrant depuis un point de contrôle au lieu d'échouer complètement.

## Comment chaque bibliothèque réutilise-t-elle les connexions ?

Si une bibliothèque maintient une connexion active, chaque requête sur cette connexion partage une sortie unique. Voici comment obtenir chaque comportement volontairement.

| Bibliothèque | Par défaut | Nouvelle IP à chaque requête | Une IP pour un flux |
| --- | --- | --- | --- |
| Python requests | `Session` maintient les connexions actives | En-tête `Connection: close`, ou un nouveau `Session` par requête | Un `Session` avec un ID de session dans le nom d'utilisateur |
| httpx | Le client regroupe les connexions | `httpx.Limits(max_keepalive_connections=0)` | Un client par ID de session |
| aiohttp | `TCPConnector` regroupe les connexions | `TCPConnector(force_close=True)` | ID de session dans le nom d'utilisateur de l’URL du proxy |
| Scrapy | Groupes selon les identifiants et l’hôte du proxy | `meta={"proxy_session": "new"}` avec notre [middleware](https://crawlrelay.com/fr/docs/scrapy/) | Un `proxy_session` fixe pour le flux |
| Playwright / Puppeteer | Chrome groupe par contexte | Nouveau contexte par page | Un contexte par ID de session |
| Node.js undici, axios, got | Les agents gardent les sockets actifs | Nouveau agent par requête, ou keep-alive désactivé | Un agent par ID de session |
| curl | Une connexion par commande | Déjà le cas | Même ID de session dans chaque commande |

## Quelle stratégie de session convient à quel type de tâche de scraping ?

| Tâche | Stratégie | TTL suggéré |
| --- | --- | --- |
| Pages de produit, article ou listing indépendantes | Rotation : pas d'ID de session | — |
| Pagination dont la page suivante dépend d'un cookie ou d'un curseur | Une session sticky par annonce | 10–30 min |
| Recherche, puis résultats, puis pages détaillées | Une session sticky par recherche | 10–20 min |
| Navigateur headless affichant plusieurs pages d'un même site | Une session sticky par contexte de navigateur | Durée du contexte, jusqu'à 30 min |
| Vérifier ce qu'affiche une page dans plusieurs villes | Une courte session par vérification de ville | 5 min |
| Re-vérifier la même page toutes les heures | Rotation | — |

## Comment gérer un pool de sessions sticky en Python ?

Un petit pool répartit la charge sur quelques exits stables et retire chacun après un nombre défini de requêtes ou après un signe d'échec de l'exit, comme 502 ou 503. Notez ce qu’il **ne** fait pas : il ne change pas les IP pour contourner un 403 ou un 429. Ceux-ci signifient que le site veut que vous ralentissiez, donc le pool transmet cela à votre code.

*Python : un pool de sessions sticky*

```python
import random
import uuid

import requests

GATEWAY = "gw.crawlrelay.com:7777"
BASE_USER, PASSWORD = "USERNAME-country-us", "PASSWORD"


class SlowDown(Exception):
    """The target asked us to slow down (403 or 429): back off, do not rotate."""


class StickySession:
    def __init__(self, ttl=15, max_requests=50):
        self.id = uuid.uuid4().hex[:10]
        self.max_requests, self.used = max_requests, 0
        user = "%s-session-%s-ttl-%d" % (BASE_USER, self.id, ttl)
        proxy = "http://%s:%s@%s" % (user, PASSWORD, GATEWAY)
        self.http = requests.Session()
        self.http.proxies = {"http": proxy, "https": proxy}


class SessionPool:
    EXIT_PROBLEMS = {502, 503, 504}

    def __init__(self, size=5, **options):
        self.options = options
        self.sessions = [StickySession(**options) for _ in range(size)]

    def _replace(self, i):
        self.sessions[i].http.close()
        self.sessions[i] = StickySession(**self.options)

    def get(self, url, **kwargs):
        i = random.randrange(len(self.sessions))
        s = self.sessions[i]
        s.used += 1
        try:
            r = s.http.get(url, timeout=(10, 30), **kwargs)
        except requests.exceptions.RequestException:
            self._replace(i)  # dropped exit or timeout: start a fresh session
            raise
        if r.status_code in (403, 429):
            raise SlowDown("%s returned %d" % (url, r.status_code))
        if r.status_code in self.EXIT_PROBLEMS or s.used >= s.max_requests:
            self._replace(i)
        return r


pool = SessionPool(size=5, ttl=15, max_requests=50)
print(pool.get("https://api.ipify.org").text)
```

## Comment savoir quand une IP sticky a changé ?

Demandez. Faites appel à un service d'écho IP comme `https://api.ipify.org` via la même session au début d’un flux et à chaque point de contrôle, puis comparez les réponses. Un changement signifie que l’exit derrière la session a changé : redémarrez le flux depuis son dernier point de contrôle ou ouvrez une nouvelle session. Enregistrez-le avec l’ID de session pour distinguer les changements d’IP du comportement du site lors du débogage.

## Quelles erreurs de session coûtent le plus cher ?

- **Rotation à chaque requête d’un flux multi-étapes.** Le site voit un panier, un curseur ou un jeton de recherche changer de pays et réinitialise.
- **Un ID de session par travailleur.** Une session est prévue pour un seul flux ; donnez à chaque travailleur et à chaque flux son propre ID.
- **Sessions bien plus longues que la tâche.** Un TTL de 30 minutes pour un flux de 2 minutes immobilise inutilement une IP et complique les logs.
- **Prendre un 429 pour un problème IP.** Une nouvelle IP ne modifie pas la règle du site ; ralentir le fait. Voir [429 Too Many Requests](https://crawlrelay.com/fr/docs/errors/429-too-many-requests/).
- **Supposer une rotation à chaque requête.** Le keep-alive maintient l’exit ; consultez le tableau ci-dessus selon votre bibliothèque.

## Sessions et rotation : questions

### Combien de temps dure une session sticky ?

Les sessions Sticky gardent la même IP pendant la durée définie (ttl, en minutes), jusqu’à 30 minutes. L’IP peut changer avant, par exemple si l’appareil résidentiel se déconnecte. Choisissez un TTL légèrement supérieur au flux qu’elle sert, et vérifiez l’exit aux points de contrôle.

### Une session sticky coûte-t-elle plus cher que la rotation ?

Non. CrawlRelay facture le trafic par GB, et sessions, rotation et ciblage sont inclus dans ce prix. Une session sticky peut même économiser du trafic, car une connexion maintenue évite une nouvelle négociation TLS à chaque requête.

### Est-ce mieux de tourner à chaque requête pour le scraping ?

Pour des pages indépendantes, la rotation répartit la charge et évite de bombarder un site depuis une même IP pendant des heures. Pour tout ce qui a un état, comme une pagination liée à un cookie, cela casse le flux. La plupart des crawls mélangent les deux : rotation entre items, sticky dans un flux.

### Puis-je choisir l’IP exacte que j’obtiens ?

Non. Un proxy résidentiel attribue des exits depuis un pool qui change constamment, selon le ciblage dans votre nom d’utilisateur. Vous choisissez le pays, la ville, l’état US, le code postal ou l’ASN, et vous pouvez garder une IP avec une session ; vous ne pouvez pas réserver une adresse spécifique.

**La rotation et les sessions sont dans tous les plans** 1,50 $US pour 1 GB, 0,50 $US/GB à partir de 50 GB. [Voir les tarifs](https://crawlrelay.com/fr/pricing/) · [Guide de concurrence](https://crawlrelay.com/fr/docs/concurrency/)

---

CrawlRelay: CrawlRelay est un service de proxy résidentiel rotatif et proxy mobile 4G/5G pour développeurs, adapté aux scrapers et pipelines de données IA : trafic prépayé sans expiration à partir de 0,50 $US/GB, paiement en crypto, sans téléchargement d’ID. Sans KYC — pas d’ID, pas de selfie, pas de documents. Payer en crypto.