Proxies mobiles 4G/5G rotatifs pour scraper des cibles difficiles

Pourquoi les sites bloquent-ils moins souvent les IP mobiles ?

Parce qu'une IP mobile représente généralement plusieurs personnes réelles. Les opérateurs utilisent le carrier-grade NAT : des milliers de téléphones partagent un petit nombre d'adresses publiques, et la RFC 6598 réserve même la plage 100.64.0.0/10 à l'intérieur de ces réseaux. Un site qui bloque une IP mobile peut exclure tous les abonnés derrière celle-ci, donc la plupart des sites bloquent les plages mobiles avec précaution.

Ce partage a un coût pour vous. Une IP mobile peut arriver avec un historique créé par d'autres utilisateurs de l'opérateur, et sa vitesse dépend du signal et de la charge de la cellule. C'est pourquoi le trafic mobile est un outil pour des cibles spécifiques, pas un usage par défaut.

Le mobile vaut-il le prix plus élevé par GB ?

Seulement là où le résidentiel échoue. Le trafic résidentiel CrawlRelay coûte 0,50 $US/GB à partir de 50 GB ; le mobile coûte 1,50 $US/GB. Dans l'étude Proxy Market Research 2026 de Proxyway, le taux de réussite médian sur des cibles réelles était de 75,26 % pour les proxies mobiles et de 74,43 % pour les proxies résidentiels : en moyenne, le mobile n'était pas beaucoup mieux.

Le gain dépend de la cible. Mesurez-le avant de payer :

1. Lancez de 200 à 500 URL d'une cible via résidentiel puis mobile.
2. Comptez les réponses exploitables, pas les HTTP 200 : une page de blocage peut renvoyer 200.
3. Divisez le coût du trafic de chaque test par le nombre de réponses exploitables.
4. Orientez un domaine vers le mobile uniquement si son coût par réponse exploitable y est moindre.

Comment orienter seulement certains domaines vers des IP mobiles ?

Gardez deux ensembles d’identifiants, un par forfait, et choisissez à la requête. Le reste de votre scraper reste identique : même passerelle, même syntaxe de nom d’utilisateur, même logique de retry.

from urllib.parse import urlsplit

import requests

GATEWAY = "gw.crawlrelay.com:7777"
RESIDENTIAL = ("RES_USERNAME-country-us", "RES_PASSWORD")
MOBILE = ("MOB_USERNAME-country-us", "MOB_PASSWORD")
MOBILE_HOSTS = {"m.example.com", "app.example.org"}  # hosts where residential measured worse


def proxies_for(url):
    user, password = MOBILE if urlsplit(url).hostname in MOBILE_HOSTS else RESIDENTIAL
    proxy = "http://%s:%s@%s" % (user, password, GATEWAY)
    return {"http": proxy, "https": proxy}


for url in ["https://www.example.com/item/1", "https://m.example.com/item/1"]:
    r = requests.get(url, proxies=proxies_for(url), timeout=(10, 45))
    print(url, r.status_code, len(r.content))

Comment fonctionne la rotation sur la pool mobile ?

De la même façon que pour le résidentiel : un nom d’utilisateur sans ID de session obtient une nouvelle IP opérateur à chaque nouvelle connexion, et -session-<id>-ttl-<minutes> conserve une IP sur plusieurs connexions. Deux différences importent en pratique :

• Les opérateurs changent les IPs eux-mêmes. Une session mobile sticky peut perdre son IP avant son TTL si l’appareil se reconnecte au réseau.
• La latence est plus variable. Donnez aux requêtes mobiles un timeout de lecture plus long, environ 45 à 60 secondes, et retentez sur une nouvelle connexion au lieu d’attendre plus longtemps.