Wie viele Proxies brauchen Sie für Scraping?

Warum Proxy Count Matters für Web Scraping

Eines der ersten Fragen ist jedes Abstreifprojekt Gesichter täuschlich einfach: Wie viele Proxies brauche ich eigentlich? Verwenden Sie zu wenige und Ihre IPs werden innerhalb von Minuten verboten. Verwenden Sie zu viele und Sie verschwenden Budget auf Kapazität, die Sie nie berühren. Die richtige Anzahl hängt von Ihren Zielorten, Anforderung Volumen, Rotationsstrategie und Toleranz für Blöcke ab.

Dieser Leitfaden bietet einen praktischen Berechnungsrahmen, so dass Sie Ihren Proxy-Pool mit Vertrauen, ob Sie schrotten zehn Seiten pro Tag oder zehn Millionen.

Wenn Sie neu sind, um Proxies zu kratzen, starten Sie mit unserer Kompletter Leitfaden für Web Scraping Proxies für Grundkonzepte.

Die Kernformel

Am einfachsten ist die Anzahl der gleichzeitigen IPs, die Sie benötigen:

required_ips = (requests_per_minute) / (safe_rpm_per_ip)

Ort Sicherheit rpm per ip ist die maximale Anforderungsrate, die ein einzelnes IP auf Ihrer Zielseite ohne Auslösen von Blöcken halten kann. Dies variiert dramatisch nach Ziel:

Beispiel Berechnung

Angenommen, Sie müssen 50.000 Produktseiten von einer E-Commerce-Website täglich abkratzen, den Job innerhalb eines 8-Stunden-Fensters abschließen:

# 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

In der Praxis sollten Sie ein 30-50 % Puffer für Retries, Fehler und Geschwindigkeitsbegrenzungs-Abklingungen. So ist der realistische Bedarf um 15-17 gleichzeitige IPs.

Faktoren, die Ihre Proxy Anforderungen erfüllen

1. Ziel-Site-Schwächung

Websites mit fortgeschrittenen Antibot-Systeme erfordern mehr IPs, da jede IP weniger Anfragen machen kann, bevor sie markiert werden. Google, Amazon und große soziale Plattformen investieren stark in Fingerabdrücke und Verhaltensanalysen. Budget für 3-5x mehr IPs als die Basis-Formel schlägt vor, diese Websites anzusprechen.

2. Volume und Häufigkeit anfordern

Kontinuierliche Abstreifung (24/7 Monitoring) benötigt mehr IPs als Batch-Jobs. Wenn Sie eine tägliche Charge ausführen, können Sie sich während des Fensters durch Ihren Pool aggressiv drehen, dann lassen Sie IPs abkühlen. Für die Echtzeitüberwachung bleibt jede IP länger aktiv und erhöht Ihre Gesamtanforderung.

3. Geographische Verteilung

Wenn Sie Daten aus mehreren Regionen benötigen (lokalisierte Preise, geospezifische Suchergebnisse), benötigen Sie IPs in jeder Zielgeographie. Ein Projekt, das die Preise in 10 Ländern verschrottet, könnte 15 IPs pro Land benötigen, was 150 insgesamt bedeutet. Überprüfen Sie die verfügbare ProxyHat Standorte Ihre Geoverteilung planen.

4. Sitzung gegen Rotierende Anforderungen

Einige Aufgaben (Loginflüsse, mehrseitige Checkout-Analyse) erfordern klebrigen Sitzungen wobei das gleiche IP für Minuten anhält. Dies verbindet IPs länger und reduziert die effektive Poolauslastung. Reine Datenerfassung ohne Session-Zustand kann auf jeder Anfrage mit jedem IP effizienter rotieren.

5. Wohngebiet vs Datacenter

Residential IPs haben höhere Treuhandpunkte und können mehr Anfragen vor Verboten machen, so dass Sie möglicherweise weniger von ihnen benötigen. Aber sie kosten mehr pro GB. Datacenter IPs sind billiger, werden aber schneller markiert, so dass Sie einen größeren Pool benötigen. Für einen tieferen Vergleich siehe Residential vs Datacenter vs Mobile Proxies.

Größentabellen nach Anwendungsfall

Gesamtbandbreite berechnen

Proxy-Gegenstand ist eine Dimension; Bandbreite ist die andere. Ihre gesamte Datenübertragung zu schätzen:

# 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

Dies hilft Ihnen, das Recht zu wählen ProxyHat Plan basierend auf IP- und Bandbreitenanforderungen.

Implementierung: Dynamic Pool Sizing

Anstatt statisch zu erraten, implementieren Sie dynamische Pool-Sizing, die sich an reale Weltbedingungen anpassen. Hier ein Beispiel mit dem ProxyHat Gateway mit adaptiver Koncurrenz:

Python Beispiel

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%}")

Für die Produktion, ProxyHat Python SDK behandelt die Verbindung Pooling und Rotation automatisch.

Node.js Beispiel

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)}%`);
  }
}

Häufige Fehler beim Sizing Proxy Pools

• Mit der gleichen Zählung für alle Ziele. Ein Pool, der für statische Blogs funktioniert, wird auf Amazon scheitern. Immer Benchmark pro Ziel.
• Ich ignoriere Retry Overhead. Verfehlte Anfragen verbrauchen Bandbreite und Zeit. Faktor in einer 20-40% Retry Rate für aggressive Ziele.
• Nicht Berücksichtigung der Sitzungsanforderungen. Wenn Sie klebrige Sitzungen für Login-Flows benötigen, bindet jede Sitzung eine IP. Berechnen Sie basierend auf gleichzeitigen Sitzungen, nicht nur Anfrage Rate.
• Vergessen Sie geographische Bedürfnisse. Zehn IPs in den USA helfen Ihnen nicht, lokalisierte Ergebnisse in Japan abzukratzen. Plan pro Geographie.
• Überprovision "nur für den Fall." Mit rotierenden Wohn-Proxien wie ProxyHat gelangen Sie automatisch auf einen großen Pool. Sie zahlen für Bandbreite, nicht für die Anzahl der IPs im Pool. Fokus auf Wahl des richtigen Proxytyps anstatt IPs zu schüren.

ProxyHat Vorteil: Pool Management vereinfacht

Mit ProxyHats rotierendem Wohn-Proxy-Gateway müssen Sie nicht manuell eine Liste von IPs verwalten. Jede Anfrage durch gate.proxyhat.com erhält automatisch ein frisches IP von einem Pool von Millionen. Das bedeutet:

• Keine manuelle IP-Listenverwaltung
• Automatische Rotation auf jeder Anfrage (oder klebrige Sitzungen bei Bedarf)
• Zugriff auf IPs in 190+ Länder
• Anzahl der verwendeten Bandbreiten, nicht pro IP-Gebühren

Ihr "proxy count" wird effektiv Ihr Koncurrency Level – wie viele gleichzeitige Verbindungen Sie durch das Gateway laufen. Beginnen Sie mit den obigen Formeln und lassen Sie den adaptiven Leimungscode in der Produktion feintun.

Für einen kompletten Spaziergang durch die Scraping-Architektur mit Proxies, sehen Sie unsere Kompletter Leitfaden für Web Scraping ProxiesUm über Rotationsstrategien zu lernen, die Ihr Pool-Sizing ergänzen, lesen Wie man Websites löscht, ohne blockiert zu werden.

Häufig gestellte Fragen

Wie viele Proxies brauche ich für kleine Schrott?

Für kleine Projekte unter 5.000 Anfragen pro Tag mit mäßig geschützten Standorten sind in der Regel 5-10 gleichzeitige Wohngebiete ausreichend. Mit einem rotierenden Gateway wie ProxyHat setzen Sie einfach Ihren Koncurrency Level auf 5-10 und das System übernimmt IP-Beauftragung.

Benötige ich mehr Proxies für JavaScript-heavy Seiten?

Ja. Headless Browser Scraping ist langsamer pro Anfrage (2-10 Sekunden vs 0.5-1 Sekunde für HTML-only), was bedeutet, dass jeder gleichzeitige Slot weniger Anfragen verarbeitet. Sie können 2-3x die Koncurrenz benötigen, um den gleichen Durchsatz zu erhalten. Sehen Sie unseren Führer auf Vermeidung von Blöcken für Optimierungstipps.

Sollte ich Wohn- oder Rechenzentrumsproxies verwenden?

Für die meisten Abstreifaufgaben bieten Wohnproxies höhere Erfolgsquoten und erfordern weniger gleichzeitige Verbindungen. Datacenter-Proxies sind billiger pro GB, werden aber schneller blockiert, erfordern einen größeren Pool. Lesen Sie unsere Proxytyp Vergleich zur detaillierten Anleitung.

Wie funktioniert der rotierende Pool von ProxyHat?

Jede Anfrage über ProxyHat's Gateway (gate.proxyhat.com:8080) wird automatisch eine andere Wohn-IP zugewiesen. Sie verwalten nicht einzelne IPs – Sie steuern Konkurrenz und das System übernimmt Rotation. Dies ist effizienter als eine statische IP-Liste.