Sie starten einen Parser oder wärmen Konten über einen Proxy auf, kalkulieren den Verbrauch anhand der Seitengröße – und erhalten eine Rechnung, die 2-3 Mal höher ist als erwartet. Das liegt nicht an einem Betrug des Anbieters: In den Traffic fließt alles ein, was tatsächlich durch den Kanal gegangen ist – die Header der Anfragen, der TLS-Handshake, Wiederholungsversuche der Verbindungen und Steuerpakete. Wir analysieren, woraus sich die „Rechnung“ für den Traffic zusammensetzt und wie man den Verbrauch ohne Qualitätsverlust reduzieren kann.
Was der Anbieter tatsächlich als Traffic zählt
Wenn Sie den Verbrauch „aus dem Bauch heraus“ einschätzen, haben Sie normalerweise die Formel im Kopf: Größe der HTML-Seite plus Bilder. Aber der Proxy-Anbieter zählt das gesamte Datenvolumen, das durch beide Richtungen des Kanals gegangen ist – ausgehend (Anfrage) und eingehend (Antwort). Dieses Volumen umfasst nicht nur die Nutzlast, sondern auch den gesamten Steuertraffic: Protokoll-Header, TLS-Metadaten, TCP-ACK-Pakete, Wiederholungsversuche bei Zeitüberschreitungen.
Bei einer Anfrage an eine normale Seite kann das Verhältnis von „nützlichen Daten“ zu „Steuerdaten“ 80/20 betragen. Wenn Sie jedoch mit einer API arbeiten, bei der die Antworten klein sind (ein paar Kilobyte JSON) und viele Header und Handshakes vorhanden sind, kann sich das Verhältnis leicht umkehren. Genau deshalb sind Arbitrageure, die zehntausende kleine Anfragen an Werbe-APIs oder Marktplätze senden, oft über die Rechnung überrascht: Jede Anfrage trägt eine feste „Steuer“, unabhängig von der Größe der Nutzlast.
Ein weiterer wichtiger Punkt: Der Anbieter zählt den Traffic auf der Ebene des Proxy-Servers, das heißt, gesamten Traffic, der tatsächlich durch die IP gegangen ist – einschließlich fehlgeschlagener Versuche, Weiterleitungen, erneuten Ladeversuchen von Ressourcen auf der Seite (Styles, Skripte, Tracker), die Ihr Skript oder Browser automatisch angefordert hat, selbst wenn Sie nur den Text benötigten.
HTTP/HTTPS-Header: das versteckte Gewicht jeder Anfrage
Jede HTTP-Anfrage und jede Antwort trägt eine Reihe von Headern: User-Agent, Cookie, Accept-Language, Referer, Content-Type und Dutzende andere. In modernen Browsern und Anti-Detect-Tools (Dolphin Anty, AdsPower, Multilogin) kann die Menge der Header zwischen 500 Byte und 2-3 KB pro Anfrage betragen – insbesondere wenn in den Cookies eine Sitzung mit Dutzenden von Werten angesammelt wurde.
Beispiel: Wenn Sie 10.000 Anfragen an die API eines Marktplatzes mit Sitzungscookies von 1,5 KB stellen, werden allein für die Header etwa 15 MB Traffic benötigt – und das ohne den Body der Antwort. Bei der Skalierung auf mehrere Konten und Profile steigt diese Zahl linear.
| Header-Typ | Durchschnittliche Größe | Einfluss auf den Traffic |
|---|---|---|
| User-Agent | 100-150 Byte | Niedrig, aber summiert sich bei großem Umfang |
| Cookie (Sitzung) | 500-2000 Byte | Hoch bei langen Sitzungen |
| Referer / Origin | 50-200 Byte | Niedrig |
| Accept-* Header | 150-300 Byte | Niedrig |
| Server-Antwort-Header | 300-800 Byte | Mittel, unabhängig von Ihnen |
Praktische Schlussfolgerung: Wenn Sie ein Skript zur Preisüberwachung auf Wildberries oder Ozon schreiben, reinigen Sie die Cookies von nicht verwendeten Werten und ziehen Sie keine überflüssigen Header in die Anfrage, die „für alle Fälle“ aus den DevTools des Browsers kopiert wurden.
TLS-Handshake: wie viel Traffic die Verschlüsselung frisst
Praktisch das gesamte moderne Web funktioniert über HTTPS, was bedeutet, dass jede neue Verbindung mit einem TLS-Handshake beginnt – dem Austausch von Zertifikaten, Verschlüsselungsschlüsseln und Protokollparametern. Ein vollständiger TLS-Handshake (TLS 1.2 oder 1.3) wiegt je nach Größe des Website-Zertifikats und den verwendeten Protokollerweiterungen zwischen 4 und 8 KB.
Wenn Sie für jede Anfrage eine neue Verbindung öffnen (und keine permanente Verbindung verwenden), wird der TLS-Handshake jedes Mal wiederholt. Bei 10.000 Anfragen ohne Wiederverwendung der Verbindung erhalten Sie zusätzlich 40-80 MB Traffic nur für die Verschlüsselung – das kann mehr sein als der eigentliche nützliche Inhalt.
TLS 1.3 ist etwas leichter als TLS 1.2 aufgrund der reduzierten Anzahl von Round-Trips, aber der Unterschied ist nur bei einer großen Anzahl von Verbindungen spürbar. Für mobile Proxys, bei denen das Netzwerk des Anbieters eigene Latenzen und Sitzungsneustarts hinzufügt, ist der TLS-Overhead besonders spürbar – das sollte bei der Auswahl von mobilen Proxys für Aufgaben mit häufigen kurzen Anfragen berücksichtigt werden.
Retries: wie wiederholte Anfragen den Verbrauch verdoppeln
Retries sind der unauffälligste und teuerste Posten im Trafficverbrauch. Wenn Ihr Parser oder Skript so eingestellt ist, dass es bei einer Zeitüberschreitung oder einem Fehler 429/503 automatisch wiederholt, hat jede fehlgeschlagene Anfrage bereits Traffic für die Verbindungsherstellung, den TLS-Handshake und die Header verbraucht – und dann wird dieser gesamte Prozess erneut wiederholt.
Ein häufiger Fehler in der Automatisierung von SMM und beim Parsen von Marktplätzen ist eine aggressive Retry-Politik ohne exponentielle Verzögerung: Das Skript macht 5 Versuche hintereinander mit einem Intervall von einer Sekunde beim ersten Anzeichen einer IP-Sperre. Infolgedessen wird für eine „nützliche“ Antwort der Traffic von fünf fehlgeschlagenen Versuchen plus der finalen erfolgreichen Anfrage verbraucht.
Besonders kritisch ist dies bei der Verwendung von Rechenzentrums-Proxys auf Websites mit aggressivem Schutz (z. B. Avito oder große Marktplätze), die möglicherweise Captchas oder Sperren für die meisten Anfragen von einer „heißen“ IP zurückgeben. In diesem Fall lohnt es sich, sich residential Proxys anzusehen – sie werden seltener beim ersten Versuch blockiert, was die Anzahl der Retries und damit den tatsächlichen Trafficverbrauch reduziert.
Keep-Alive vs neue Verbindungen
HTTP Keep-Alive ermöglicht es, eine TCP/TLS-Verbindung für mehrere aufeinanderfolgende Anfragen wiederzuverwenden und so den wiederholten Handshake zu vermeiden. Dies ist eine der effektivsten Traffic-Optimierungen, die in fast allen HTTP-Clients und Anti-Detect-Browsern verfügbar ist.
Wenn Sie Bibliotheken zum Parsen (requests, httpx, axios) verwenden, ohne eine Sitzung mit einer permanenten Verbindung explizit anzugeben, kann jede Anfrage standardmäßig eine neue TCP-Verbindung öffnen. In Verbindung mit Proxys bedeutet dies: eine neue Verbindung zum Proxy-Server, ein neuer TLS zu der Zielwebsite, und der gesamte Overhead wird bei jedem Aufruf wiederholt.
| Verbindungsmodus | Overhead für 1000 Anfragen |
|---|---|
| Neue Verbindung für jede Anfrage | 4-8 MB (nur TLS) |
| Keep-Alive, eine Sitzung für 50 Anfragen | 0.1-0.2 MB (ein Handshake für die Gruppe) |
Der Unterschied ist enorm – und das ist eine reine Traffic-Einsparung ohne jegliche Veränderung der Nutzlast der Anfragen.
Wie verschiedene Proxy-Typen Traffic zählen
Das Abrechnungsmodell für Traffic hängt vom Typ des Proxys ab. Bei Rechenzentrums-Proxys ist häufig eine Abrechnung nach Traffic-Volumen oder nach Anzahl der IPs/Ports zu finden – die Infrastruktur ist schneller und fügt nur minimalen Overhead für die Routenführung hinzu. Bei residential und mobilen Proxys wird der Traffic normalerweise strenger abgerechnet, da die echten IPs der Nutzer eine teurere und begrenzte Ressource sind, und die Route über den Anbieter oder den Heimprovider zusätzliche Hops hinzufügt und somit etwas mehr Steuerdaten erzeugt.
Mobile Proxys sind in dieser Hinsicht die „teuersten“ in Bezug auf Traffic: Mobilfunknetze fügen eigene Mechanismen für Sitzungsneustarts, NAT-Übersetzungen und manchmal Kompression/Dekompression des Traffics auf Anbieterebene hinzu, was den Zähler der durchgeführten Daten im Vergleich zu derselben Anfrage über ein Festnetz erhöht.
Wenn die Aufgabe ein stabil hoher Anfragenumfang mit minimalem Overhead ist (z. B. massenhaftes Parsen von Preisen auf Wildberries oder Ozon), sind Rechenzentrums-Proxys am besten geeignet – sie sind schneller und vorhersehbarer im Trafficverbrauch bei ähnlichen Aufgaben.
Wie man den Trafficverbrauch in der Praxis senkt
Lassen Sie uns konkrete Schritte durchgehen, die den tatsächlichen Trafficverbrauch ohne Verlust der Funktionalität des Parsers, der Automatisierung oder des Multi-Accountings senken.
1. Deaktivieren Sie das Laden unnötiger Ressourcen. Wenn Sie nur den Text der Seite oder die JSON-Antwort der API benötigen, deaktivieren Sie das Laden von Bildern, Schriftarten, Analyse-Skripten und Werbetrackern in den Einstellungen des Anti-Detect-Browsers oder des Headless-Tools. Dies reduziert oft den Trafficverbrauch um 60-80% für Parsing-Aufgaben.
2. Verwenden Sie Keep-Alive und einen Verbindungs-Pool. Konfigurieren Sie den HTTP-Client so, dass er die Sitzung für eine Gruppe von Anfragen an einen Host wiederverwendet – das reduziert die Anzahl der TLS-Handshakes erheblich.
3. Stellen Sie eine vernünftige Retry-Politik ein. Exponentielle Verzögerung (1s → 2s → 4s) mit einer Begrenzung auf 3 Versuche anstelle aggressiver 5-10 Versuche hintereinander reduziert den nutzlosen Traffic von fehlgeschlagenen Anfragen und verringert gleichzeitig das Risiko einer zusätzlichen IP-Sperre.
4. Reinigen Sie Cookies und Header der Sitzung. Löschen Sie regelmäßig angesammelte Cookie-Werte, die von der Zielwebsite nicht verwendet werden – besonders wichtig für lange Sitzungen zur Aufwärmung von Konten in Instagram oder TikTok über Anti-Detect-Browser.
5. Cachen Sie statische Antworten. Wenn sich die Daten (z. B. Produktkatalog) nicht jede Minute ändern, cachen Sie die Antwort lokal, anstatt bei jedem Überwachungszyklus eine neue Anfrage über den Proxy zu stellen.
6. Verwenden Sie Kompression. Stellen Sie sicher, dass der Header Accept-Encoding: gzip übermittelt wird und der Server tatsächlich eine komprimierte Antwort zurückgibt – das reduziert das Volumen des eingehenden Traffics auf Seiten mit viel Text oder JSON.
Tools zur Trafficüberwachung
Um zu verstehen, wohin der Traffic tatsächlich fließt, ist es nützlich, nicht nur auf den Zähler des Anbieters zu schauen, sondern auch auf die detaillierte Aufschlüsselung der Anfragen. Dafür eignen sich:
- Charles Proxy / Fiddler – zeigen die Größe jeder Anfrage und Antwort, einschließlich der Header, was hilft, „schwere“ Cookies oder überflüssige Ressourcen zu finden.
- Wireshark – für eine tiefgehende Analyse des TCP/TLS-Overheads auf Paketebene, wenn Sie das tatsächliche Gewicht des Handshakes bewerten müssen.
- Integrierte Traffic-Zähler in Anti-Detect-Browsern (Dolphin Anty, AdsPower, GoLogin) – viele zeigen den Verbrauch für jedes Profil separat an, was praktisch für die Budgetverteilung zwischen Konten ist.
- Logging auf HTTP-Client-Ebene – beim Schreiben eigener Parsing-Skripte ist es nützlich, die Größe der Anfrage/Ausgabe für jeden Aufruf zu protokollieren, um Anomalien zu finden.
Der Vergleich der Messwerte Ihrer Tools mit dem Zähler des Proxy-Anbieters hilft schnell zu verstehen, wo der Traffic verloren geht – bei Retries, TLS oder beim Laden überflüssiger Ressourcen.
Checkliste zur Optimierung vor dem Start
Vor dem großflächigen Start des Parsers, der Automatisierung von SMM oder der Aufwärmung von Werbekonten sollten Sie eine kurze Liste abarbeiten:
- Das Laden von Bildern, Schriftarten und Analysen ist dort deaktiviert, wo sie nicht benötigt werden;
- Keep-Alive / Wiederverwendung der Sitzung für eine Serie von Anfragen an einen Host ist eingerichtet;
- Die Retry-Politik ist auf 2-3 Versuche mit Verzögerung begrenzt und nicht auf unendliche Wiederholungen;
- Cookies der Sitzung werden regelmäßig von nicht verwendeten Werten gereinigt;
- Die Kompression von Antworten (gzip/deflate/br) ist aktiviert;
- Es gibt ein lokales Caching für wiederkehrende statische Anfragen;
- Der Proxy-Typ ist passend zur Aufgabe gewählt: Rechenzentrum für Geschwindigkeit und Volumen, residential für Umgehung von Sperren, mobile für soziale Netzwerke und Werbeplattformen.
Fazit
Der Trafficverbrauch über Proxys besteht nicht nur aus den nützlichen Daten der Seite, sondern auch aus dem gesamten Steuer-Overhead: Header, TLS-Handshakes, Wiederholungsversuche bei Fehlern. Das Verständnis dieser Mechanik ermöglicht eine genauere Planung des Budgets für Proxys und hilft, unangenehme Überraschungen in der Rechnung zu vermeiden, insbesondere bei der Skalierung des Parsings von Marktplätzen, der Automatisierung von SMM oder der Aufwärmung von Werbekonten.
Wenn Ihre Aufgabe ein stabiler Parsing-Prozess mit vorhersehbarem Trafficverbrauch ist, sollten Sie auf Rechenzentrums-Proxys achten. Für die Arbeit mit sozialen Netzwerken und Werbeplattformen, bei denen eine niedrige Sperrhäufigkeit wichtig ist, sind mobile Proxys besser geeignet. Und wenn ein Gleichgewicht zwischen Anonymität und Stabilität zur Umgehung des Schutzes von Websites erforderlich ist, sollten Sie sich residential Proxys ansehen, die die Anzahl der Retries durch selteneren Blockierungen reduzieren.