Passer au contenuComment corriger 429 Trop de Requêtes lors du scraping
Un 429 est une limite de taux, pas une interdiction — le serveur vous demande de ralentir. La solution durable combine un retour en arrière, le respect de Retry-After, et la répartition de la charge sur un pool d'IP. Voici comment, avec un Python fonctionnel.
429 est une limite de vitesse, pas un mur
HTTP 429 Trop de demandes signifie que vous avez envoyé trop de demandes dans une fenêtre donnée et que le serveur vous limite. C'est délibérément temporaire — contrairement à un blocage total, un 429 se résout généralement une fois que vous ralentissez. De nombreux serveurs incluent un Retry-After en-tête vous indiquant exactement combien de secondes attendre ; le respecter est la solution la plus efficace, car cela vous aligne sur la limite du serveur au lieu de deviner.
Il y a deux leviers. Le premier est le taux : envoyez moins de demandes par seconde par IP, ajoutez des délais, limitez la concurrence et réduisez exponentiellement lorsque un 429 apparaît. Le second est la distribution : répartissez les demandes sur plusieurs IP afin que chacune reste sous la limite par IP. Le contrôle du taux est là où vous devriez commencer — un pool de proxy multiplie votre débit mais n'excuse pas de frapper un site. s4m fournit des proxies de datacenter authentifiés (SOCKS5 1080, HTTP 3128, USER:PASS) pour répartir la charge, et cela s'associe directement avec le guide de rotation de proxy et le scraping avec des demandes.
Respectez Retry-After, reculez, puis faites tourner
Une boucle de récupération qui respecte Retry-After, se retire de manière exponentielle avec du jitter, et se répartit sur un pool de proxys. Remplacez USER:PASS.
import random, time
import requests
USER, PASS, HOST = "USER", "PASS", "proxy.s4m.online"
POOL = [
f"socks5h://{USER}:{PASS}@{HOST}:1080",
f"http://{USER}:{PASS}@{HOST}:3128",
]
def polite_get(url, max_tries=6):
for attempt in range(1, max_tries + 1):
proxy = random.choice(POOL)
r = requests.get(url, proxies={"http": proxy, "https": proxy},
timeout=(5, 20))
if r.status_code != 429:
r.raise_for_status()
return r
# 429: prefer the server's Retry-After, else exponential backoff
retry_after = r.headers.get("Retry-After")
if retry_after and retry_after.isdigit():
wait = int(retry_after)
else:
wait = min(2 ** attempt, 60) + random.random() # cap + jitter
print(f"[{attempt}/{max_tries}] 429; waiting {wait:.1f}s")
time.sleep(wait)
raise SystemExit(f"still rate-limited after {max_tries} tries")
# Global throttle: cap how fast you fire, independent of retries.
MIN_INTERVAL = 0.5 # seconds between requests per worker
_last = 0.0
def throttled_get(url):
global _last
delta = time.time() - _last
if delta < MIN_INTERVAL:
time.sleep(MIN_INTERVAL - delta)
_last = time.time()
return polite_get(url)
print(throttled_get("https://httpbin.org/status/200").status_code)L'ordre pour corriger un 429
Les solutions les moins chères et les plus respectueuses d'abord.
Honorer Retry-After
Si la réponse 429 inclut un en-tête Retry-After, attendez exactement ce temps avant de réessayer. C'est le serveur qui vous indique sa limite — le suivre efface la plupart des 429 immédiatement.
Ajoutez un backoff exponentiel avec jitter
Lorsqu'il n'y a pas de Retry-After, attendez 2, 4, 8… secondes (plafonné) plus un petit jitter aléatoire entre les tentatives, afin d'arrêter de frapper et d'éviter les tentatives synchronisées.
Limitez votre taux de demande
Limitez les demandes par seconde et la concurrence afin de rester en dessous de la limite en premier lieu. Un crawl régulier et plus lent se termine de manière plus fiable qu'une rafale qui est constamment limitée.
Répartir la charge entre les IP
Une fois que votre comportement par demande est poli, faites tourner un pool de proxies afin que chaque IP reste sous la limite par IP. Cela multiplie le débit sûr sans augmenter le taux sur une seule adresse.
Pourquoi la rotation seule n'est pas la solution
Il est tentant de considérer les proxies comme un moyen d'ignorer les limites de taux — il suffit d'ajouter plus d'IP et de continuer à tirer. Cela se retourne contre vous. Un site qui renvoie 429 surveille les modèles de requêtes, et un afflux d'une série d'adresses changeantes frappant les mêmes points de terminaison au même instant est lui-même une signature détectable qui peut entraîner des interdictions sévères. La rotation multiplie le débit poli ; elle ne remplace pas la politesse. Combinez toujours un pool de proxies avec un temps d'attente, Retry-After, un rythme réaliste et une concurrence sensée.
Honnêtement, certaines limites sont faites pour être respectées — vérifiez si une API officielle ou un taux documenté existe avant de vous développer autour d'un 429, et lisez les conditions d'utilisation de chaque site. Lorsque vous avez besoin de distribution, les proxies datacenter authentifiés de s4m répartissent la charge et sont mesurés, donc élargir le pool est peu coûteux ; pour les mécanismes, consultez le guide de rotation. N'oubliez pas que les IP de datacenter peuvent toujours être signalées en gros, et la rotation ne fait rien contre les empreintes digitales. Prototypage à bas coût avec la liste de proxies gratuits et validez les sorties avec les outils.
Questions, réponses
Un 429 est-il un bannissement permanent ?
Non. HTTP 429 Trop de demandes est une limite de taux temporaire — elle se dissipe généralement une fois que vous ralentissez. Respectez tout en-tête Retry-After, ajoutez un temps d'attente et réduisez votre taux de demande, et l'accès reprend généralement.
Quelle est la solution la plus efficace pour un 429 ?
Respecter l'en-tête Retry-After lorsque le serveur en envoie un. Cela vous indique exactement combien de temps attendre, afin que vous vous réaligniez avec la limite du serveur au lieu de deviner et d'être à nouveau limité.
Les proxies rotatifs arrêteront-ils les erreurs 429 ?
Cela aide en maintenant chaque IP sous la limite par IP, mais seulement avec un retour en arrière et un ralentissement. La rotation sans un rythme poli produit un déluge détectable qui s'intensifie en blocages plus difficiles, donc combinez les deux.
Les proxys s4m sont-ils suffisants pour contourner toute limite de taux ?
Aucun outil honnête ne peut promettre cela. Les proxys de datacenter s4m répartissent la charge entre les IP, mais vous devez toujours appliquer un backoff et un throttling, les plages de datacenter peuvent être signalées, et certaines limites doivent simplement être respectées via une API officielle.
Répartissez la charge de manière honnête
Combinez le backoff et le throttling avec des proxies de datacenter authentifiés sur proxy.s4m.online pour garder chaque IP sous la limite. Paiement à l'utilisation, IP dédiée en option.
Les gens ont trouvé cette page en recherchant
- comment corriger 429 trop de requêtes lors du scraping
- proxys résidentiels
- frais liste de proxies gratuits
- liste de proxies gratuits
- comment openvpn fonctionne
- adresse IP
- wireguard
- proxy http abonnement
- configuration du proxy
- Tinyproxy vs 3proxy vs Squid
- proxy socks5
- interrupteur d'arrêt VPN pour android
- UDP sur SOCKS5
- adresse IP pour windows
- openvpn
- contourner le DPI
- interrupteur d'arrêt VPN
- proxy pour le scraping
Vraies phrases de recherche auxquelles cette page répond — les liens ouvrent la page qui les couvre en profondeur.