Wie viele Proxys benötigen Sie?

Die optimale Anzahl der benötigten Proxys wird durch den spezifischen Anwendungsfall, die Anti-Bot-Maßnahmen der Zielwebsite, das gewünschte Anfragevolumen, gleichzeitige Verbindungen und die erforderliche IP-Rotationsfrequenz bestimmt.

Verständnis der Kernfaktoren

Die Bestimmung der erforderlichen Proxy-Anzahl erfordert die Bewertung mehrerer miteinander verbundener Variablen. Eine präzise Berechnung ist oft iterativ und wird durch Tests verfeinert, aber eine erste Schätzung kann durch die Analyse der folgenden Punkte abgeleitet werden:

Anti-Bot-Maßnahmen der Zielwebsite

Websites implementieren verschiedene Techniken, um automatisierte Anfragen zu erkennen und zu blockieren. Die Aggressivität dieser Maßnahmen wirkt sich direkt auf die Proxy-Anforderungen aus.
* Niedrige Sicherheit: Grundlegende Ratenbegrenzung, IP-Sperrung nach übermäßigen Anfragen.
* Mittlere Sicherheit: Anspruchsvollere Ratenbegrenzungen, CAPTCHA-Herausforderungen, grundlegendes Browser-Fingerprinting.
* Hohe Sicherheit: Fortschrittliche Bot-Erkennung, detailliertes Browser-Fingerprinting, Verhaltensanalyse, umfangreiche IP-Blacklisting, häufige CAPTCHAs, Honeypot-Fallen.

Hochgeschützte Ziele erfordern einen größeren und vielfältigeren Proxy-Pool, oft mit privaten oder mobilen IPs und häufiger Rotation.

Gewünschtes Anfragevolumen und Geschwindigkeit

Die Gesamtzahl der geplanten Anfragen innerhalb eines bestimmten Zeitrahmens (z. B. Anfragen pro Stunde, pro Tag) und die gewünschte Geschwindigkeit (Queries Per Second - QPS) sind grundlegend.
* Gesamtanfragen (TR): Die absolute Anzahl der zu stellenden HTTP/S-Anfragen.
* Gewünschte QPS (DQPS): Die Zielrate der Anfragen pro Sekunde.

Ein höheres TR oder DQPS erfordert im Allgemeinen mehr Proxys, um die Last zu verteilen und das Auslösen von Ratenbegrenzungen auf einzelnen IPs zu vermeiden.

Proxy-Rotation und Session Stickiness

• Rotationsfrequenz: Wie oft eine IP-Adresse gewechselt wird. Schnelle Rotation (z. B. bei jeder Anfrage, alle paar Sekunden) verbraucht im Laufe der Zeit mehr einzigartige IPs aus dem Pool, reduziert aber die Wahrscheinlichkeit, dass eine IP markiert wird.
• Session Stickiness (Sitzungshaftung): Die Anforderung, eine persistente Verbindung oder eine Reihe von Anfragen unter Verwendung derselben IP-Adresse für eine definierte Dauer aufrechtzuerhalten (z. B. Anmeldung, Navigation durch mehrseitige Formulare). Sticky Sessions binden eine IP länger, was die effektive Poolgröße für andere Aufgaben potenziell reduziert.

Abkühlphase

Nachdem eine IP verwendet wurde, insbesondere wenn sie auf eine Soft-Blockade oder ein CAPTCHA gestoßen ist, ist es ratsam, diese IP für eine „Abkühlphase“ ruhen zu lassen. Dies ermöglicht es den Erkennungssystemen der Zielwebsite, sich zurückzusetzen oder die Reputation der IP wiederherzustellen. Eine längere Abkühlphase bedeutet, dass zu einem bestimmten Zeitpunkt weniger IPs aktiv verfügbar sind, wodurch der Gesamtpoolbedarf steigt.

Geografische und Netzwerkvielfalt

Einige Aufgaben erfordern IPs von bestimmten geografischen Standorten (Länder, Regionen, Städte) oder von verschiedenen Netzwerktypen (z. B. verschiedene ISPs). Dies kann Ihren Proxy-Pool segmentieren, was bedeutet, dass selbst wenn Sie eine große Gesamtzahl von Proxys haben, der verfügbare Pool für ein bestimmtes Geo-Ziel kleiner sein könnte.

Schätzung des Proxy-Bedarfs: Ein praktisches Modell

Ein robustes Schätzmodell berücksichtigt die erforderlichen gleichzeitig aktiven Proxys und die zusätzlichen Proxys, die zur Erleichterung von Rotation und Abkühlung benötigt werden.

Variablen:

• DQPS: Gewünschte Anfragen pro Sekunde (Desired Queries Per Second).
• APQPS: Durchschnittliche QPS, die ein einzelner Proxy aufrechterhalten kann, bevor eine Rotation erforderlich ist oder eine Blockierung riskiert wird (konservativ schätzen, z. B. 0,1 bis 1 QPS).
• AUT: Durchschnittliche Nutzungszeit (in Sekunden), die ein einzelner Proxy aktiv Anfragen stellt, bevor er rotiert oder in den Cooldown versetzt wird (z. B. 30s bis 300s).
• CDT: Abkühlzeit (in Sekunden), die ein einzelner Proxy nach der Nutzung ruhen muss, bevor er wiederverwendet wird (z. B. 300s bis 3600s).
• BF: Pufferfaktor (z. B. 0,10 bis 0,25) zur Berücksichtigung von Proxy-Ausfällen, unerwarteten Blockierungen oder erhöhter Last.

Berechnungsschritte:

1. Berechnung der gleichzeitig aktiven Proxys (CAP):
   Dies ist die Mindestanzahl von Proxys, die gleichzeitig aktiv sein müssen, um Ihr DQPS-Ziel zu erreichen, vorausgesetzt, jeder Proxy leistet APQPS.
   CAP = DQPS / APQPS

2. Berechnung des Rotationsmultiplikators (RM):
   Dieser Faktor bestimmt, wie viele „Slots“ eine IP im Pool aufgrund ihrer aktiven Nutzung und der anschließenden Abkühlphase belegt.
   RM = (AUT + CDT) / AUT

   • Selbstkorrektur: Wenn AUT sehr kurz und CDT sehr lang ist, kann RM groß sein. Dies deutet auf einen hohen Bedarf an einzigartigen IPs hin. Wenn CDT 0 ist (keine Abkühlung), wird RM zu 1.

3. Berechnung des Basis-Proxy-Pools (BPP):
   Dies ist die theoretische Mindestanzahl von Proxys, die benötigt wird, um CAP aufrechtzuerhalten und gleichzeitig AUT und CDT zu berücksichtigen.
   BPP = CAP * RM

4. Puffer anwenden (BP):
   Fügen Sie einen Puffer für unvorhergesehene Umstände hinzu, z. B. wenn ein Prozentsatz der Proxys langsam, nicht reagierend oder vorzeitig blockiert wird.
   BP = BPP * BF

5. Geschätzte Gesamtanzahl der Proxys (TEP):
   TEP = BPP + BP

Beispielrechnung:

Angenommen, die folgenden Anforderungen und Schätzungen:
* DQPS: 20 Anfragen/Sekunde
* APQPS: 0,5 Anfragen/Sekunde (konservative Schätzung für ein hochsicheres Ziel)
* AUT: 60 Sekunden (jeder Proxy stellt 30 Anfragen vor der Rotation)
* CDT: 900 Sekunden (15 Minuten Abkühlzeit)
* BF: 0,20 (20% Puffer)

1. CAP-Berechnung:
   CAP = 20 QPS / 0,5 QPS/Proxy = 40 Proxys
   (Sie benötigen 40 Proxys, die zu jedem Zeitpunkt aktiv Anfragen stellen).

2. RM-Berechnung:
   RM = (60 Sekunden + 900 Sekunden) / 60 Sekunden = 960 / 60 = 16
   (Jeder aktive Proxy erfordert 15 zusätzliche Proxys in Abkühlung/Rotation für jeden aktiven Proxy).

3. BPP-Berechnung:
   BPP = 40 Proxys * 16 = 640 Proxys

4. BP-Berechnung:
   BP = 640 Proxys * 0,20 = 128 Proxys

5. TEP-Berechnung:
   TEP = 640 + 128 = 768 Proxys

In diesem Szenario wären etwa 768 Proxys erforderlich, um 20 QPS gegen ein moderat geschütztes Ziel mit einer 15-minütigen Abkühlphase aufrechtzuerhalten.

Code-Beispiel (Python-Funktion zur Schätzung):

def estimate_proxies(desired_qps, avg_qps_per_proxy, avg_usage_time_sec, cooldown_time_sec, buffer_factor):
    """
    Estimates the total number of proxies needed based on operational parameters.

    Args:
        desired_qps (float): Target requests per second.
        avg_qps_per_proxy (float): Average QPS a single proxy can sustain.
        avg_usage_time_sec (float): Time (seconds) a proxy is active before rotation/cooldown.
        cooldown_time_sec (float): Time (seconds) a proxy rests after usage.
        buffer_factor (float): Factor for additional proxies (e.g., 0.15 for 15%).

    Returns:
        int: Total estimated number of proxies.
    """
    if avg_qps_per_proxy <= 0 or avg_usage_time_sec <= 0:
        raise ValueError("avg_qps_per_proxy and avg_usage_time_sec must be positive.")

    # 1. Calculate Concurrent Active Proxies (CAP)
    concurrent_active_proxies = desired_qps / avg_qps_per_proxy

    # 2. Calculate Rotation Multiplier (RM)
    rotation_multiplier = (avg_usage_time_sec + cooldown_time_sec) / avg_usage_time_sec

    # 3. Calculate Base Proxy Pool (BPP)
    base_proxy_pool = concurrent_active_proxies * rotation_multiplier

    # 4. Apply Buffer (BP)
    buffered_proxies = base_proxy_pool * buffer_factor

    # 5. Total Estimated Proxies (TEP)
    total_estimated_proxies = base_proxy_pool + buffered_proxies

    return int(round(total_estimated_proxies))

# Example usage:
# total_proxies = estimate_proxies(
#     desired_qps=20,
#     avg_qps_per_proxy=0.5,
#     avg_usage_time_sec=60,
#     cooldown_time_sec=900,
#     buffer_factor=0.20
# )
# print(f"Estimated proxies: {total_proxies}") # Output: Estimated proxies: 768

Empfehlungen für Proxy-Typen

Die Wahl des Proxy-Typs hat erhebliche Auswirkungen auf Effektivität und Kosten.