Warum Proxy-Preisgestaltung so verwirrend ist
Du vergleichst Proxy-Anbieter, und jeder rechnet anders. Einer verlangt $3/GB, ein anderer $2/IP/Monat, der nächste $5 pro 1.000 Requests. Am Ende weißt du nicht, was dein Projekt wirklich kosten wird. Dieser Leitfaden bringt Licht ins Dunkel — mit konkreten Rechenbeispielen, versteckten Kosten und klaren Empfehlungen.
Die drei dominanten Abrechnungsmodelle am Markt sind per GB (Bandbreite), per IP oder Port (flatrate) und per Request (API-Call). Welches für dich das richtige ist, hängt von deinem Traffic-Profil, deinen Latenzanforderungen und deinem Budget ab.
Die drei Abrechnungsmodelle im Detail
1. Per-GB-Modell: Der Standard bei Residential Proxies
Bei Residential und Mobile Proxies dominiert die bandbreitenbasierte Abrechnung. Du zahlst für jedes Gigabyte, das durch den Proxy fließt — unabhängig davon, wie viele IPs du nutzt oder wie lange eine Session dauert.
- Typischer Preisbereich: $1–$15/GB, je nach Qualität und Anbieter
- Bestens für: Web-Scraping, SERP-Monitoring, Preisüberwachung — alles mit hohem Datenvolumen pro Request
- Nachteil: Große HTML-Seiten oder Bilder treiben die Kosten schnell in die Höhe
ProxyHat nutzt dieses Modell für Residential Proxies — transparent, ohne versteckte Per-Request-Gebühren.
2. Per-IP/Per-Port-Modell: Datacenter- und ISP-Domäne
Hier zahlst du einen festen monatlichen Betrag pro IP-Adresse oder Port. Egal ob du 1 MB oder 500 GB über diese IP schickst — der Preis bleibt gleich.
- Typischer Preisbereich: $0,50–$5/IP/Monat (Datacenter), $5–$30/IP/Monat (ISP/Residential Static)
- Bestens für: Langlaufende Sessions, Account-Verwaltung, hohe Bandbreite pro IP
- Nachteil: Du zahlst für ungenutzte IPs, wenn du nur kurz scrapst
3. Per-Request-Modell: SERP-APIs und Nischen
Einige SERP-APIs und spezialisierte Proxy-Dienste rechnen pro Request ab. Die Bandbreite ist im Preis enthalten.
- Typischer Preisbereich: $2–$10 pro 1.000 Requests
- Bestens für: Reine SERP-Daten, strukturierte API-Responses
- Nachteil: Bei großen HTML-Seiten extrem teuer; kaum Flexibilität
Reale Kosten berechnen: Das Rechenbeispiel
Die meisten Teams unterschätzen ihr Bandbreitenbedarf. Hier ein konkretes Beispiel:
Szenario: Du scrapst 10 Millionen Produktseiten pro Monat.
- Durchschnittliche Seitengröße: 100 KB (HTML + Headers)
- Bandbreite pro Monat: 10.000.000 × 100 KB = 1.000.000.000 KB ≈ 1.000 GB = 1 TB
- Korrektur für Response-Overhead: +15% = ≈ 1.150 GB
Bei einem Residential-Proxy-Anbieter mit $3/GB:
1.150 GB × $3/GB = $3.450/Monat
Hier ein Calculator für verschiedene Use-Cases:
| Use-Case | Requests/Monat | KB/Request | GB/Monat | Kosten bei $3/GB |
|---|---|---|---|---|
| Produkt-Scraping | 10.000.000 | 100 | ~1.150 | $3.450 |
| SERP-Monitoring | 500.000 | 30 | ~17 | $51 |
| Social-Media-Research | 2.000.000 | 80 | ~184 | $552 |
| Ad-Verification | 1.000.000 | 50 | ~57 | $171 |
Die Formel, die du immer parat haben solltest:
GB/Monat = (Requests × KB_pro_Request × 1,15) / 1.000.000
Gesamtkosten = GB/Monat × Preis_pro_GB
Versteckte Kosten: Was Anbieter dir nicht auf die Website schreiben
Sticky-Session-Aufschläge
Einige Anbieter verlangen Aufschläge für Sticky Sessions (z. B. +20–50%), weil diese IPs länger gebunden werden und weniger rotieren. Wenn du Login-Flows oder Multi-Step-Forms scrapst, brauchst du Sticky Sessions — also plane diesen Aufschlag ein.
Geo-Premium-Preise
US- und EU-IPs kosten oft 2–5× mehr als IPs aus Südostasien oder Lateinamerika. Warum? Weil Nachfrage und Infrastruktur-Kosten höher sind.
| Region | Typischer Aufschlag vs. Basis |
|---|---|
| USA | +50% bis +200% |
| Westeuropa (DE, UK, FR) | +30% bis +150% |
| Osteuropa | Basis bis +20% |
| Südostasien | Basis (oft günstigste Region) |
| Lateinamerika | Basis bis +10% |
Wenn dein Use-Case nicht zwingend US-IPs erfordert, kann die Wahl einer günstigeren Region Hunderte Dollar sparen. ProxyHat bietet standortbasierte Targeting-Optionen ohne versteckte Geo-Aufschläge.
Per-Request-Overhead
Manche Per-GB-Anbieter berechnen zusätzlich pro Request — oft $0,001 bis $0,01 pro Call. Bei 10 Mio. Requests sind das schnell $10.000 bis $100.000 extra. Lies die AGB, bevor du dich anmeldest.
Connection-Overhead und Header-Bloat
HTTP-Header, TLS-Handshakes und Redirects fügen 10–30% zum nominalen Payload hinzu. Manche Anbieter messen nur den Payload, andere die gesamte Verbindung. Frage explizit, wie Bandbreite gemessen wird.
Budget-Tier vs. Premium-Tier: Wo das extra $/GB hingeht
Warum zahlt man bei Provider A $1,50/GB und bei Provider B $8/GB? Hier die Unterschiede:
| Kriterium | Budget-Tier ($1–3/GB) | Premium-Tier ($5–15/GB) |
|---|---|---|
| Subnet-Diversität | Niedrig — viele IPs in wenigen Subnets | Hoch — IPs über Hunderte von Subnets verteilt |
| ASN-Diversität | Wenige ISPs, oft Rechenzentren | Hunderte echter ISPs weltweit |
| Erfolgsrate | 70–85% | 92–99% |
| Bot-Detection-Umgehung | Mäßig — IPs schnell geblockt | Hoch — frische Pools, schnelle Rotation |
| Betriebsqualität (Ops) | Langsamer Support, manuelle Eskalation | 24/7-Support, automatisches IP-Recycling |
| SLA | Kein oder 95%-SLA | 99,5%+ SLA mit Credits |
Wann Budget reicht: Einfaches Scraping ohne Anti-Bot-Schutz, Bulk-Datensammlung wo 80% Erfolgsrate akzeptabel ist.
Wann Premium nötig ist: SERP-Scraping (Google, Amazon), Social-Media-Plattformen, Ticketing-Websites — überall wo Anti-Bot-Systeme aktiv sind und jede fehlgeschlagene Request Geld kostet.
Verhandeln: Wann Custom-Pricing realistisch ist
Commitment-Rabatte
Die meisten Anbieter gewähren Rabatte ab bestimmten Volumina:
- Monatliches Commitment: 5–15% Rabatt ab $500/Monat
- Annual Prepaid: 15–30% Rabatt
- Enterprise-Verträge: Custom-Pricing ab ~$2.000–5.000/Monat
SLA-Tiers
Wenn Uptime und Erfolgsrate kritisch sind, verhandle SLA-Tiers mit Service Credits. Premium-Anbieter bieten oft:
- 99,5% Uptime-Garantie
- Erfolgsrate-Garantie (z. B. ≥95%)
- Ersetzungs-Credits bei SLA-Verletzung
Tipps für die Verhandlung
- Zeige Volumen: Teile dein monatliches GB-Volumen — das öffnet Rabatt-Tiers
- Frage nach Geo-Split: Wenn du 80% US-Traffic hast, verhandle US-Raten separat
- Teste zuerst: Nutze Test-Kontingente, um echte Erfolgsraten zu messen — dann verhandelst du mit Daten, nicht mit Vermutungen
- Multi-Year: 2-Jahres-Verträge bringen oft die besten Raten
Wann du das Preismodell wechseln solltest
High-Bandwidth-per-IP → Per-Port-Modell
Wenn du über eine einzelne IP Hunderte von GB an Daten schickst (z. B. Video-Streaming, Large-File-Downloads, langlaufende API-Sessions), wird Per-GB schnell teuer. In diesem Fall ist ein statischer Residential oder ISP-Proxy mit Per-Port-Preisstellung günstiger.
Beispiel:
- 10 statische IPs × $15/IP/Monat = $150/Monat (Per-Port)
- Gleicher Traffic bei $3/GB × 500 GB = $1.500/Monat (Per-GB)
Die Ersparnis: $1.350/Monat.
Low-Bandwidth-per-Request → Per-Request-Modell
Wenn deine Requests klein sind (z. B. SERP-Responses mit 20–50 KB), aber du viele davon brauchst, kann Per-Request günstiger sein — besonders bei SERP-APIs, die nur den relevanten Teil der Seite liefern.
Entscheidungsmatrix
| Dein Profil | Bestes Modell | Warum |
|---|---|---|
| Hohe Request-Zahl, kleine Responses | Per GB | Bandbreite bleibt niedrig, Kosten vorhersehbar |
| Wenige IPs, viel Traffic pro IP | Per IP/Port | Flatrate nutzt hohe Bandbreite aus |
| Nur SERP-Daten benötigt | Per Request (SERP API) | Kein Overhead, strukturierte Daten |
| Gemischtes Profil | Hybrid (Per GB + statische IPs) | Rotierende IPs für Scraping, statische für Accounts |
Praktische Implementierung mit ProxyHat
Um die Kosten zu kontrollieren, solltest du Bandbreite und Erfolgsraten in deinem Code messen. Hier ein einfaches Beispiel:
Python: Bandbreite tracken
import requests
PROXY = "http://user-country-US:pass@gate.proxyhat.com:8080"
proxies = {"http": PROXY, "https": PROXY}
response = requests.get(
"https://example.com/product/123",
proxies=proxies,
timeout=30
)
# Bytes received (approximate bandwidth)
bandwidth_kb = len(response.content) / 1024
print(f"Response size: {bandwidth_kb:.1f} KB")
# At $3/GB, cost per request:
cost_per_request = (bandwidth_kb / 1_048_576) * 3.0
print(f"Estimated cost: ${cost_per_request:.6f}")
Node.js: Sticky Session mit Bandbreiten-Messung
const axios = require('axios');
const HttpsProxyAgent = require('https-proxy-agent');
const agent = new HttpsProxyAgent(
'http://user-country-DE-session-abc123:pass@gate.proxyhat.com:8080'
);
async function scrapeWithCostTracking(url) {
const res = await axios.get(url, {
httpsAgent: agent,
timeout: 30000
});
const kb = Buffer.byteLength(res.data) / 1024;
const costPerGB = 3.0;
const cost = (kb / 1048576) * costPerGB;
console.log(`Size: ${kb.toFixed(1)} KB, Est. cost: $${cost.toFixed(6)}`);
return res.data;
}
scrapeWithCostTracking('https://example.com/product/456');
curl: Schneller Test
curl -x http://user-country-US:pass@gate.proxyhat.com:8080 \
-w "Size: %{size_download} bytes\n" \
-o /dev/null -s \
https://example.com/product/789
Wann du NICHT zu ProxyHat wechseln solltest
Ehrlichkeit ist wichtig. ProxyHat ist nicht für jeden Use-Case die beste Wahl:
- Reine Datacenter-IPs in Bulk: Wenn du 10.000+ DC-IPs für nicht-blockierbares Scraping brauchst, sind spezialisierte DC-Anbieter günstiger
- SERP-APIs: Wenn du nur strukturierte Google/Bing-Ergebnisse brauchst, sind dedizierte SERP-APIs einfacher als Proxy + HTML-Parsing
- Extrem niedrige Latenz-Pfade: Für High-Frequency-Trading brauchst du Co-Located Proxies mit <5ms Latenz — das ist ein anderer Markt
Key Takeaways
- Kenne dein Traffic-Profil: Berechne GB/Monat bevor du Anbieter vergleichst — die Formel ist simpel
- Per-GB dominiert bei Residential: Das ist der Branchenstandard, aber versteckte Aufschläge können die Kosten verdoppeln
- Geo-Pricing ist real: US- und EU-Traffic kostet deutlich mehr — wähle Regionen bewusst
- Premium zahlt sich bei Anti-Bot aus: Subnet- und ASN-Diversität ist kein Luxus, sondern eine Erfolgsrate-Verbesserung von 15–25%
- Wechsle das Modell bei hohem Bandwidth-per-IP: Per-Port spart massiv, wenn du wenige IPs mit viel Traffic nutzt
- Verhandle mit Daten: Teste erst, messe Erfolgsraten, dann verhandeln
Bereit, deine Proxy-Kosten zu optimieren? Schau dir die ProxyHat-Preise an oder starte mit einem Test-Kontingent. Für tiefere Einblicke in spezifische Use-Cases, sieh dir unseren Leitfaden zum Web-Scraping-Best-Practices an.






