Ihren monatlichen Residential-Proxy-Bandbreitenbedarf schätzen

Bei einem Pro-GB-Residential-Proxy-Tarif ist Bandbreite die Einheit, die Sie kaufen, also läuft die Wahl des richtigen Tarifs auf eine Frage hinaus: wie viele Gigabyte werden Sie in einem Monat tatsächlich nutzen? Schätzen Sie zu niedrig, treffen Sie mitten im Monat auf Overage oder Throttling; schätzen Sie zu hoch, zahlen Sie zu viel für Spielraum, den Sie nie berühren. Die gute Nachricht: Bandbreite ist schätzbar, kein Mysterium. Mit einer Formel, ein paar realistischen Seitengrößen und einer Fünf-Minuten-Messung können Sie einen Tarif mit Zuversicht dimensionieren.

Dieser Leitfaden ist für Teams, die die Proxy-Nutzung planen. Wir bauen die Schätzung Schritt für Schritt auf, verankern sie in einer echten Messung, und gehen durchgerechnete Beispiele für gängige Workloads durch.

Die Formel

Alles reduziert sich hierauf:

Monatliche GB  ≈  (Anfragen pro Monat  ×  durchschn. Antwortgröße  ×  Overhead-Faktor)  /  Bytes pro GB

Vier Eingaben, und eine davon dominiert. Nehmen wir sie in der Reihenfolge der Wirkung.

Schritt 1: durchschnittliche Antwortgröße (der große Treiber)

Wie viele Bytes pro Anfrage zurückkommen, ist es, wo Schätzungen leben oder sterben, und es schwankt um mehr als das 10-fache, je nachdem, wie Sie abrufen. Typische Bereiche:

Der größte einzelne Faktor Ihrer Rechnung ist, ob Sie einen vollständigen Browser rendern oder HTML/JSON direkt abrufen. Ein Browser lädt alles auf der Seite herunter; eine schlichte HTTP-Anfrage zieht einen Bruchteil davon. Wenn Sie Ihre Daten aus dem HTML oder einer API bekommen, sinkt Ihre Größe pro Anfrage, und Ihre Bandbreite, um eine Größenordnung. (Das, plus Asset-Blockieren, ist der Kern von wie man Proxy-Bandbreitenkosten senkt.)

Raten Sie diese Zahl nicht, wenn Sie sie messen können, siehe Schritt 4.

Schritt 2: Anfragen pro Monat

Das sind meist Seiten (oder Datensätze) mal Frequenz:

Anfragen pro Monat  =  Items  ×  Prüfungen pro Tag  ×  30

Ein Preismonitor, der 10.000 Produkte einmal täglich verfolgt, sind 10.000 × 1 × 30 = 300.000 Anfragen im Monat. Ein einmaliger Datensatzaufbau ist nur die Gesamt-Seitenzahl, kein Frequenz-Multiplikator. Beziehen Sie die Paginierung ein: wenn jedes “Item” drei Ergebnisseiten umfasst, multiplizieren Sie entsprechend.

Schritt 3: der Overhead-Faktor

Echte Crawls sind nicht 100% effizient. Retries, Weiterleitungen und fehlgeschlagene Versuche überqueren alle den Proxy und kosten alle Bandbreite, eine blockierte oder abgelaufene Anfrage hat trotzdem Bytes verbraucht. Fügen Sie einen Overhead-Faktor auf Ihre saubere Schätzung:

• Einfache, offene Ziele: ~1,1 (10% Overhead)
• Typische Seiten: ~1,2 (20%)
• Gut verteidigte Ziele (häufige Blocks/Retries): ~1,3 oder höher

Je schwerer das Ziel, desto mehr Retries, also desto höher der Faktor. Ihre Block-Rate zu senken (bessere IP-Qualität, vernünftiges Tempo) verkleinert das direkt, siehe wie man Blocks vermeidet.

Schritt 4: messen Sie Ihre echte Seitengröße (nicht raten)

Der schnellste Weg zu einer vertrauenswürdigen Schätzung ist, eine repräsentative Stichprobe Ihres echten Ziels über den Proxy abzurufen und die Bytes zu messen. Die Antwortgröße in Bytes ist len(response.content):

import os, requests, statistics

USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]
proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"
proxies = {"http": proxy_url, "https": proxy_url}

sample_urls = [ ... ]   # 20-50 repräsentative Ziel-URLs
sizes_kb = []
for url in sample_urls:
    r = requests.get(url, proxies=proxies, timeout=30)
    sizes_kb.append(len(r.content) / 1024)

avg_kb = statistics.mean(sizes_kb)
print(f"avg {avg_kb:.0f} KB/request  (n={len(sizes_kb)})")

Führen Sie es gegen 20 bis 50 echte URLs aus, und Sie haben eine fundierte Durchschnittsgröße statt einer Vermutung. Beachten Sie, dass dies die komprimierten Bytes misst, die tatsächlich den Proxy überqueren (lassen Sie Accept-Encoding an), was Ihnen berechnet wird. Das vollständige Client-Setup steht in Residential Proxies mit Python.

Durchgerechnete Beispiele

Mit Monatliche GB = Anfragen × durchschn_Größe × Overhead / 1.000.000 (KB zu GB, dezimal):

Preisüberwachung, nur HTML. 10.000 Produkte, täglich, ~200 KB/Seite, Overhead 1,15. 300.000 × 200 KB × 1,15 = 69.000.000 KB ≈ 69 GB/Monat.

Derselbe Job, aber mit vollständigem Browser-Rendering. ~2 MB/Seite statt 200 KB. 300.000 × 2.000 KB × 1,15 = 690.000.000 KB ≈ 690 GB/Monat. Dieselben Daten, 10x die Bandbreite, das sind die Kosten des Renderns, wenn Sie es nicht brauchten (siehe mit Playwright zum Blockieren von Assets, falls Sie rendern müssen).

Such-/Ranking-Überwachung, schlanke Antworten. 500 Anfragen, 4x/Tag, ~30 KB je, Overhead 1,2. 500 × 4 × 30 × 30 KB × 1,2 = 2.160.000 KB ≈ 2,2 GB/Monat. Klein und günstig.

Einmaliger Datensatzaufbau. 2.000.000 Seiten, ~300 KB HTML, Overhead 1,2. 2.000.000 × 300 KB × 1,2 = 720.000.000 KB ≈ 720 GB, einmalig, nicht monatlich.

Das Muster ist klar: Antwortgröße und Rendering-Wahl dominieren; die Anfragezahl skaliert linear; der Overhead ist ein bescheidener Multiplikator.

Von der Schätzung zum Tarif

Verwandeln Sie die Zahl mit etwas Disziplin in einen Tarif:

• Fügen Sie einen Puffer hinzu. Dimensionieren Sie den Tarif auf Ihre Schätzung plus 20 bis 30%, für Wachstum innerhalb des Monats und Schätzfehler. Mitten im Zyklus leerzulaufen, ist störender als etwas Spielraum.
• Kennen Sie die Overage-Bedingungen. Prüfen Sie, wie Ihr Anbieter das Überschreiten handhabt, extra pro GB, Throttling, oder ein harter Stopp, damit ein geschäftiger Monat Sie nicht überrascht.
• Reconcilen Sie wöchentlich. Vergleichen Sie die tatsächliche Nutzung früh im Zyklus mit Ihrer Schätzung und passen Sie an. Echte Nutzung lehrt Sie Ihre wahre Seitengröße und Block-Rate schneller als jede Vermutung.
• Schrumpfen Sie die Zahl, bevor Sie mehr kaufen. Oft ist das billigste Gigabyte das, das Sie nicht ausgeben, überspringen Sie das Rendern, blockieren Sie Assets, und holen Sie unveränderte Seiten nicht erneut (Proxy-Bandbreitenkosten senken), bevor Sie den Tarif vergrößern. Das ist das Pro-GB-Modell, das Effizienz auszahlt (die Pro-Port-Ära ist vorbei).

FAQ

Wie schätze ich Bandbreite, wenn ich den Job nie ausgeführt habe? Messen Sie eine repräsentative Stichprobe Ihrer Zielseiten über den Proxy (Schritt 4), um eine echte Größe pro Anfrage zu bekommen, und setzen Sie sie in die Formel mit Ihrer Anfragezahl und einem Overhead-Faktor ein. Eine gemessene Stichprobe schlägt jede generische Schätzung.

Was verbraucht die meiste Bandbreite? Vollständiges Browser-Rendering, mit weitem Abstand, es lädt jedes Bild, jede Schrift und jedes Skript herunter. HTML oder eine JSON-API direkt abzurufen, kann die Größe pro Anfrage um das 10-fache senken. Die Rendering-Wahl ist der größte Hebel auf Ihrer Rechnung.

Zählen fehlgeschlagene und wiederholte Anfragen zu meiner Bandbreite? Ja. Jede Anfrage, die den Proxy überquert, nutzt Bandbreite, einschließlich Blocks, Weiterleitungen und Retries. Deshalb enthält die Schätzung einen Overhead-Faktor, und deshalb senkt eine niedrigere Block-Rate die Kosten.

Ist 1 GB 1.000 MB oder 1.024 MB? Es hängt von der Abrechnungsdefinition des Anbieters ab, dezimal (1.000) oder binär (1.024). Der Unterschied beträgt etwa 7%, in Ordnung fürs Schätzen, aber bestätigen Sie, welche Ihr Anbieter nutzt, wenn Sie nahe an einer Tarifgrenze dimensionieren.

Wie viel Puffer sollte ich hinzufügen? Planen Sie für Ihre Schätzung plus 20 bis 30%, um Wachstum und Schätzfehler innerhalb des Monats aufzufangen. Dann reconcilen Sie gegen die echte Nutzung und passen an, statt im Voraus zu viel zu kaufen.

Fazit

Residential-Proxy-Bandbreite zu schätzen ist keine Raterei: multiplizieren Sie Anfragen mit einer gemessenen durchschnittlichen Antwortgröße und einem Overhead-Faktor, wandeln Sie in GB um, und fügen Sie einen Puffer hinzu. Die zwei Dinge, die die Zahl am meisten bewegen, sind, wie Sie abrufen (HTML/JSON schlägt den vollständigen Browser um rund das 10-fache) und wie oft Sie retryen (bessere IP-Qualität bedeutet weniger verschwendete Bytes), also messen Sie eine echte Stichprobe, bevor Sie sich festlegen, und senken Sie die Zahl, bevor Sie mehr kaufen.

Sobald Sie eine Schätzung haben, legt die Preisseite die Pro-GB-Tarife dar, damit Sie eine Stufe an Ihre Zahl plus Puffer anpassen können, und richten Sie einen gut abgestimmten Scraper auf das Residential-Gateway, um die tatsächliche Nutzung nahe am Tarif zu halten.