De combien de proxies avez-vous besoin pour le scraping ?

Pourquoi le nombre de procurations compte pour le scraping Web

L'une des premières questions sur les visages des projets de démolition est faussement simple: Combien de proxies ai-je vraiment besoin ? Utilisez trop peu et vos IPs sont interdits en quelques minutes. Utilisez trop et vous gaspillez le budget sur la capacité que vous ne touchez jamais. Le bon nombre dépend de vos sites cibles, du volume des demandes, de la stratégie de rotation et de la tolérance pour les blocs.

Ce guide fournit un cadre de calcul pratique afin que vous puissiez tailler votre pool de proxy avec confiance, que vous racliez dix pages par jour ou dix millions.

Si vous êtes nouveau à gratter des proxies, commencez par notre Guide complet des produits de scraping Web pour les concepts fondamentaux.

La formule de base

À son plus simple, le nombre d'IP simultanés dont vous avez besoin est :

required_ips = (requests_per_minute) / (safe_rpm_per_ip)

où safe rpm per ip est le taux de requête maximal qu'une seule IP peut supporter sur votre site cible sans déclencher des blocs. Cela varie considérablement selon la cible:

Exemple de calcul

Supposons que vous ayez besoin de gratter 50 000 pages de produits d'un site de commerce électronique chaque jour, en remplissant le travail dans une fenêtre de 8 heures:

# Target: 50,000 pages in 8 hours
requests_per_minute = 50000 / (8 * 60)  # ≈ 104 RPM
safe_rpm_per_ip = 10                     # e-commerce average
required_ips = 104 / 10  # ≈ 11 concurrent IPs

Dans la pratique, vous devez ajouter un 30-50% tampon pour les récupérations, les échecs et les réductions de vitesse. Donc le besoin réaliste est autour 15-17 PI simultanées.

Facteurs qui influent sur vos exigences en matière de procuration

1. Sophistication des sites cibles

Sites avec avancé systèmes anti-bot nécessitent plus d'IP parce que chaque IP peut faire moins de requêtes avant d'être signalé. Google, Amazon et les grandes plateformes sociales investissent fortement dans l'analyse des empreintes digitales et du comportement. Budget pour 3-5x plus de IP que la formule de base suggère lors du ciblage de ces sites.

2. Volume et fréquence des demandes

Le grattage continu (24/7 monitoring) nécessite plus d'IP que de tâches de lot. Si vous exécutez un lot quotidien, vous pouvez tourner à travers votre piscine agressivement pendant la fenêtre, puis laisser les IP refroidir. Pour la surveillance en temps réel, chaque IP reste actif plus longtemps, augmentant votre besoin total.

3. Répartition géographique

Si vous avez besoin de données provenant de plusieurs régions (prix localisés, résultats de recherche géospécifique), vous avez besoin d'IP dans chaque région cible. Un projet de prix de démolition dans 10 pays pourrait nécessiter 15 PI par pays, soit 150 au total. Vérifiez la disponibilité Emplacements ProxyHat pour planifier votre géodistribution.

4. Exigences relatives aux séances et aux rotations

Certaines tâches (flux de connexion, analyse de caisse multipages) nécessitent sessions collantes où la même IP persiste pendant des minutes. Cela relie les IP plus longtemps, réduisant ainsi l'utilisation efficace de la piscine. La collecte de données pure sans état de session peut tourner sur chaque requête, en utilisant chaque IP plus efficacement.

5. Centre résidentiel et centre de données

Les IP résidentiels ont des scores de confiance plus élevés et peuvent faire plus de demandes avant les interdictions, donc vous pouvez avoir besoin de moins d'entre eux. Mais ils coûtent plus cher par GB. Les IP de Datacenter sont moins chers, mais sont signalés plus rapidement, donc vous avez besoin d'un plus grand bassin. Pour une comparaison plus approfondie, voir Résidentiel vs Datacenter vs Mobile Proxies.

Tableau des tailles par cas d'utilisation

Calcul de la largeur totale de bande

Le nombre de procurations est une dimension; la bande passante est l'autre. Estimez votre transfert total de données :

# Average page sizes
static_page = 50 KB      # HTML only
dynamic_page = 200 KB    # HTML + JSON/API responses
full_render = 2-5 MB     # with all assets (headless browser)
# Example: 50,000 pages/day × 200 KB average
daily_bandwidth = 50000 * 200 / 1024 / 1024  # ≈ 9.5 GB/day

Cela vous aide à choisir le bon Plan ProxyHat en fonction des besoins en IP et en bande passante.

Mise en œuvre : Taille dynamique du pool

Plutôt que de deviner statiquement, implémenter un pool dynamique qui s'adapte aux conditions du monde réel. Voici un exemple à l'aide de la passerelle ProxyHat avec une concordance adaptative :

Exemple de Python

import asyncio
import aiohttp
from dataclasses import dataclass, field
from time import time
@dataclass
class PoolSizer:
    """Dynamically adjusts concurrent proxy connections based on success rate."""
    min_concurrent: int = 5
    max_concurrent: int = 100
    target_success_rate: float = 0.95
    current_concurrent: int = 10
    results: list = field(default_factory=list)
    def record(self, success: bool):
        self.results.append((time(), success))
        # Keep only last 100 results
        self.results = self.results[-100:]
    @property
    def success_rate(self) -> float:
        if not self.results:
            return 1.0
        return sum(1 for _, s in self.results if s) / len(self.results)
    def adjust(self):
        rate = self.success_rate
        if rate >= self.target_success_rate and self.current_concurrent < self.max_concurrent:
            # Success rate is good — try more concurrency
            self.current_concurrent = min(self.current_concurrent + 2, self.max_concurrent)
        elif rate < self.target_success_rate * 0.9:
            # Success rate dropping — reduce concurrency
            self.current_concurrent = max(self.current_concurrent - 5, self.min_concurrent)
async def scrape_with_adaptive_pool(urls: list[str]):
    sizer = PoolSizer()
    proxy = "http://USERNAME:PASSWORD@gate.proxyhat.com:8080"
    semaphore = asyncio.Semaphore(sizer.current_concurrent)
    async with aiohttp.ClientSession() as session:
        async def fetch(url):
            async with semaphore:
                try:
                    async with session.get(url, proxy=proxy, timeout=aiohttp.ClientTimeout(total=30)) as resp:
                        success = resp.status == 200
                        sizer.record(success)
                        return await resp.text() if success else None
                except Exception:
                    sizer.record(False)
                    return None
        for batch_start in range(0, len(urls), sizer.current_concurrent):
            batch = urls[batch_start:batch_start + sizer.current_concurrent]
            await asyncio.gather(*[fetch(url) for url in batch])
            sizer.adjust()
            # Update semaphore for next batch
            semaphore = asyncio.Semaphore(sizer.current_concurrent)
            print(f"Concurrent IPs: {sizer.current_concurrent}, Success rate: {sizer.success_rate:.1%}")

Pour la production ProxyHat Python SDK gère la mise en commun et la rotation de la connexion automatiquement.

Exemple de Node.js

const HttpsProxyAgent = require('https-proxy-agent');
const fetch = require('node-fetch');
class AdaptivePoolSizer {
  constructor(min = 5, max = 100) {
    this.min = min;
    this.max = max;
    this.current = 10;
    this.results = [];
    this.targetRate = 0.95;
  }
  record(success) {
    this.results.push({ time: Date.now(), success });
    if (this.results.length > 100) this.results = this.results.slice(-100);
  }
  get successRate() {
    if (!this.results.length) return 1;
    return this.results.filter(r => r.success).length / this.results.length;
  }
  adjust() {
    if (this.successRate >= this.targetRate && this.current < this.max) {
      this.current = Math.min(this.current + 2, this.max);
    } else if (this.successRate < this.targetRate * 0.9) {
      this.current = Math.max(this.current - 5, this.min);
    }
  }
}
async function scrapeWithAdaptivePool(urls) {
  const sizer = new AdaptivePoolSizer();
  const agent = new HttpsProxyAgent('http://USERNAME:PASSWORD@gate.proxyhat.com:8080');
  for (let i = 0; i < urls.length; i += sizer.current) {
    const batch = urls.slice(i, i + sizer.current);
    const results = await Promise.allSettled(
      batch.map(url =>
        fetch(url, { agent, timeout: 30000 })
          .then(res => { sizer.record(res.ok); return res.text(); })
          .catch(() => { sizer.record(false); return null; })
      )
    );
    sizer.adjust();
    console.log(`Concurrent: ${sizer.current}, Success: ${(sizer.successRate * 100).toFixed(1)}%`);
  }
}

Erreurs courantes lors du calibrage des pools de proxy

• Utiliser le même nombre pour toutes les cibles. Une piscine qui fonctionne pour les blogs statiques échouera sur Amazon. Toujours référence par cible.
• Ignorer les frais généraux. Les demandes rejetées consomment de la bande passante et du temps. Facteur dans un taux de réessayer de 20 à 40 % pour les cibles agressives.
• Ne tient pas compte des besoins des sessions. Si vous avez besoin de sessions collantes pour les flux de connexion, chaque session relie une IP. Calculer sur la base de sessions simultanées, et pas seulement sur le tarif de demande.
• Oublier les besoins géographiques. Dix IP aux États-Unis ne vous aideront pas à gratter les résultats localisés au Japon. Plan par géographie.
• Sur-provisionnement "juste au cas où". Avec des procurations résidentielles tournantes comme ProxyHat, vous accédez automatiquement à une grande piscine. Vous payez pour la bande passante, pas pour le nombre d'IP dans la piscine. Accent sur choisir le bon type de proxy plutôt que de garder des IP.

Avantage ProxyHat: Gestion de piscine simplifiée

Avec la passerelle proxyHat, vous n'avez pas besoin de gérer manuellement une liste d'IP. Chaque demande gate.proxyhat.com reçoit automatiquement une nouvelle IP d'un pool de millions. Cela signifie:

• Pas de gestion manuelle des listes IP
• Rotation automatique sur chaque demande (ou sessions collantes au besoin)
• Accès aux IP dans 190 pays et plus
• Payer la bande passante utilisée, pas les frais par IP

Votre "compte de procuration" devient effectivement votre niveau de concordance — combien de connexions simultanées vous passez par la passerelle. Commencez par les formules ci-dessus, puis laissez le code de calibrage adaptatif l'affiner en production.

Pour un passage complet de l'architecture de grattage avec des proxies, voir notre Guide complet des produits de scraping Web. Pour en savoir plus sur les stratégies de rotation qui complètent votre taille de bassin, lisez Comment gratter les sites Web sans se faire bloquer.

Foire aux questions

Combien de proxies ai-je besoin pour le grattage à petite échelle ?

Pour les petits projets de moins de 5 000 demandes par jour visant des sites modérément protégés, 5 à 10 proxies résidentielles concurrentes sont généralement suffisantes. Avec une passerelle tournante comme ProxyHat, vous définissez simplement votre niveau de concordance à 5-10 et le système gère l'attribution IP.

Ai-je besoin de plus de proxies pour les sites JavaScript-lourds?

Oui. Le grattage du navigateur sans tête est plus lent par requête (2-10 secondes contre 0.5-1 secondes pour HTML seulement), ce qui signifie que chaque fente simultanée traite moins de requêtes. Il se peut que vous ayez besoin de 2-3x pour maintenir le même débit. Voir notre guide sur éviter les blocs pour des conseils d'optimisation.

Dois-je utiliser des proxys résidentiels ou datacenters?

Pour la plupart des tâches de grattage, les procurations résidentielles offrent des taux de succès plus élevés et nécessitent moins de connexions simultanées. Les datacenter proxies sont moins chers par GB mais se bloquent plus rapidement, nécessitant un plus grand bassin. Lisez notre Comparaison du type de proxy pour une orientation détaillée.

Comment fonctionne la piscine tournante de ProxyHat?

Chaque requête via la passerelle de ProxyHat (gate.proxyhat.com:8080) se voit attribuer automatiquement une IP résidentielle différente. Vous ne gérez pas les IP individuels — vous contrôlez la concordance et le système gère la rotation. Ceci est plus efficace que le maintien d'une liste IP statique.