Executive Summary: Der fundamentale Architekturunterschied bei mobilen Proxys
Im Web Scraping, beim automatisierten Browser-Testing und im Multi-Account-Management stellen mobile Proxys die höchste Vertrauensstufe dar. Moderne Anti-Bot-Systeme wie Cloudflare Turnstile, DataDome, Akamai Web Application Protector und Kasada begegnen dem mobilen IP-Adressraum mit minimalem Misstrauen.
Der Grund dafür ist infrastruktureller Natur: Mobilfunkbetreiber setzen flächendeckend Carrier-Grade NAT (CGNAT, RFC 6598 / 100.64.0.0/10) ein. Dabei teilen sich Zehntausende reguläre Smartphone-Nutzer denselben Pool an öffentlichen IPv4-Adressen. Würde eine Anti-Bot-Engine eine einzelne mobile IP sperren, entstünde massiver Kollateralschaden, da tausende zahlende Endverbraucher gleichzeitig von legitimen Diensten ausgesperrt würden.
Im Jahr 2026 ist die Proxy-Industrie jedoch durch zwei völlig gegensätzliche Architekturmodelle gespalten:
- Das geteilte P2P-Mobilfunk-Overlay-Modell (Bright Data): Ein verteiltes Peer-to-Peer-Netzwerk, das auf proprietären SDKs basiert, die in Endverbraucher-Apps auf globalen Android-Smartphones integriert sind. Der Datenverkehr wird über Smartphones dritter Konsumenten geroutet – mit allen Konsequenzen: instabile Wechsel zwischen WLAN und Mobilfunk, schwankende Akkustände und aggressive Hintergrundprozess-Drosselungen durch das Smartphone-Betriebssystem.
- Das dedizierte Bare-Metal-Hardware-Modell (Proxym): Eine private Industrie-Infrastruktur auf Basis von rackmontierten Teltonika-Mobilfunk-Gateways (TRB500 und RUTX50), bestückt mit dedizierten Enterprise-SIM-Karten direkt bei französischen Tier-1-Carriern (Orange, SFR, Bouygues Telecom, Free Mobile). Jedem Kunden wird eine physisch isolierte Hardware-Einheit zugewiesen – mit ungeteilter Bandbreite und deterministischer IP-Rotation über direkte Modem-AT/QMI-Schnittstellen.
========================================================================================
BRIGHT DATA ARCHITEKTUR: MULTI-HOP CONSUMER PEER-TO-PEER OVERLAY
========================================================================================
[ Scraping-Client ]
|
v (HTTPS / SOCKS5)
[ Bright Data Super-Proxy Gateway ] <-- Authentifizierung, Abrechnung ($15-$20+/GB), Routing
|
v (Internes Overlay-Netzwerk)
[ Android-Smartphone (Endnutzer) ] <-- Drittgerät, Konsumentenakku, Hintergrund-SDK
|
v (Radio Access Network: 4G/LTE/5G)
[ Carrier CGNAT Gateway ]
|
v
[ Ziel-Website / WAF ]
========================================================================================
PROXYM ARCHITEKTUR: DETERMINISTISCHE BARE-METAL INDUSTRIE-HARDWARE
========================================================================================
[ Scraping-Client ]
|
v (Direktes WireGuard / Dediziertes SOCKS5 / HTTP-Proxy-Auth)
[ Proxym Ingress Edge Router (Frankreich) ]
|
v (Gigabit-Backhaul-LAN)
[ Dediziertes Teltonika RUTX50 / TRB500 ] <-- Industrielles Quectel-Modem, 24/7 USV, kein OS-Throttling
|
v (Direktes Sub-6GHz 5G NR SA/NSA)
[ Französischer MNO Sendemast (Orange / SFR / Bouygues / Free) ]
|
v (Direktes Carrier PGW/GGSN)
[ Ziel-Website / WAF ]Dieser strukturelle Unterschied hat unmittelbare Auswirkungen auf Betriebskosten, Verbindungsstabilität, Latenz und Datenintegrität. Während Bright Data eine weltweite Abdeckung über 195 Länder im Pay-per-Gigabyte-Modell bietet, erkauft man sich dies mit exorbitanten Bandbreitenkosten, unvorhersehbarem Routing und schwankender Multi-Hop-Latenz.
Proxym hingegen optimiert für datenintensive, latenzkritische europäische Operationen: Physisch isolierte 5G-Verbindungen zum monatlichen Festpreis (80 €/Monat für einen dedizierten Port, 70 €/Port ab 3 Ports), inklusive 200 GB Fair-Use-Volumen pro Port (~0,40 €/GB).
1. Detaillierte Vergleichsmatrix: Proxym vs. Bright Data Mobile
Die folgende Matrix stellt die technischen Spezifikationen, Infrastrukturtopologien, Abrechnungsmodelle und Leistungsgrenzen beider Ansätze gegenüber.
| Parameter | Proxym (Dedizierte 5G-Hardware) | Bright Data Mobile (Shared P2P) |
|---|---|---|
| Physischer Infrastruktur-Stack | Bare-Metal Teltonika RUTX50 / TRB500 Industrie-Gateways | Konsumenten-Smartphones mit Hintergrund-Apps |
| Mobilfunk-Standard (RAT) | 5G NR (Release 16) Sub-6GHz (n78, n28, n1, n3) / LTE Cat 20 | Gemischt: 3G, 4G LTE, sporadisches 5G (geräteabhängig) |
| IP-Isolation & Mandantenfähigkeit | 100 % dediziert. Hardware, Port, SIM und Bandbreite exklusiv | Multi-Tenant / Shared. Mehrere Nutzer teilen sich Exit-Nodes |
| IP-Rotationsmechanismus | Direkter AT/QMI-Befehl (AT+COPS) auf Modemebene via REST-API | Softwareseitiger Sitzungsabbruch; Neuverbindung zu anderem Peer |
| Rotations-Determinismus | 100 % deterministisch (neue CGNAT-IP garantiert in 6–12 s) | Probabilistisch (Zufällige Zuweisung des nächsten freien Peers) |
| Carrier-Auswahl (Frankreich) | Fester Carrier nach Wahl: Orange, SFR, Bouygues, Free | Dynamisch über Proxy-Parameter im Request-String |
| Betriebssystem der Exit-Nodes | RutOS (Industrielles OpenWrt-Linux auf MIPS/ARM-SoC) | Android (Aggressive Hintergrundprozess-Restriktionen) |
| Latenz zu FR-Zielen | 22 ms – 35 ms (Direktes Routing im Carrier-Kernnetz) | 140 ms – 350 ms (Super-Proxy + Peer-Relay-Hop) |
| Preisstruktur | Feste Monatspauschale: 80 €/Monat (1 Port), 70 €/Port (ab 3 Ports) | Pay-per-GB: 15,00 $ – 20,00 $+ / GB (je nach Monats-Commitment) |
| Inklusiv-Datenvolumen | 200 GB Fair Use inklusive pro Port | 0 GB inklusive (Abrechnung ab dem ersten Byte) |
| Effektive Kosten pro GB | ~0,40 € / GB (bezogen auf 200 GB Inklusivvolumen) | 15,00 $ – 20,00 $ / GB |
| Fehlgeschlagene Requests | Kostenlos (unbegrenzte Requests, Flatrate-Infrastruktur) | Kostenpflichtig (Bandbreite für 403, 429, 502 wird berechnet) |
| Testzugang | 5 € Promo für den ersten Monat (Gutscheincode: DECOUVERTE5) | Begrenztes Testguthaben; setzt Firmen-KYC voraus |
| KYC-Aufwand | Minimal (Standard-SaaS-Checkout via Kreditkarte) | Hoch (Unternehmensprüfung, Video-Ident, Usecase-Audit) |
| Optimale Workloads | Datenscrapping, Headless-Browser, E-Commerce, Social Media | Punktuelle Micro-Crawls über hunderte Länder weltweit |
2. Tiefgehende Latenz-, Routing- und Durchsatz-Benchmarks
Netzwerk-Performance bei hochvolumiger Datenextraktion definiert sich nicht allein über theoretische Bandbreitenwerte. Entscheidend sind Round-Trip-Time (RTT), TCP-Handshake-Effizienz, TLS-Negotiation-Overhead, Paketverlustraten unter Dauerlast sowie Jitter auf der Luftschnittstelle.
Netzwerkanalyse: Physische Routing-Pfade
Um die Latenzunterschiede nachzuvollziehen, muss man die physischen Routing-Pfade beider Systeme analysieren:
========================================================================================
TCP / TLS VERBINDUNGSAUFBAU: PROXYM VS. BRIGHT DATA
========================================================================================
--- PROXYM (Direktes Bare-Metal-Routing) ---
Client Proxym Ingress Teltonika 5G Ziel-Server
| | | |
|--- TCP Syn (10ms) ----->| | |
|<-- TCP Syn-Ack (10ms) --| | |
|--- WireGuard/Auth ----->| | |
| |--- Direktes TCP Syn ->| |
| | |--- TLS Syn (15ms) -->|
| | |<-- TLS Ack (15ms) ---|
|<======================== DIREKTER STREAM ETABLIERT ===================>|
RTT Gesamt: 25ms - 35ms zum Ziel
--- BRIGHT DATA (Multi-Hop P2P-Routing) ---
Client Bright Super-Proxy Endnutzer-Peer (SDK) Ziel-Server
| | | |
|--- TCP Syn (25ms) ----->| | |
|<-- TCP Syn-Ack (25ms) --| | |
|--- HTTP CONNECT ------->| | |
| |--- Dispatch Peer-Suche->| |
| |<-- Peer bestätigt ------| |
| |--- Weiterleitung Syn -->| |
| | |--- TCP Syn (60ms) -->|
| | |<-- TCP Ack (60ms) ---|
| |<-- Weiterleitung Ack ---| |
|<-- 200 Connection OK ---| | |
|<======================== P2P-GEKAPSELTER TUNNEL =======================>|
RTT Gesamt: 160ms - 350ms+ zum Ziel (Schwankt bei Funkzellen- / WLAN-Wechsel)- Hop-Multiplikation bei Bright Data: Ein Request an Bright Data trifft zunächst auf einen Super-Proxy (üblicherweise in AWS- oder Equinix-Rechenzentren). Dieser sucht in Echtzeit nach einem aktiven Mobilfunk-Peer, der den Routing-Kriterien entspricht (z. B. Land: FR, Carrier: Orange). Anschließend wird ein verschlüsselter Tunnel zum Smartphone des Endnutzers aufgebaut. Dieses führt den Request über seine eigene Mobilfunkverbindung zum Zielserver aus. Die Serverantwort nimmt denselben Weg zurück: Ziel $\rightarrow$ Endnutzer-Smartphone $\rightarrow$ Super-Proxy $\rightarrow$ Scraping-Client. Der Client zahlt somit die Latenz zweier kompletter Internet-Transite zuzüglich der unberechenbaren Mobilfunklatenz des Endgeräts.
- Direktes Ingress-Routing bei Proxym: Ein Request an einen Proxym-Port trifft via Low-Latency-Glasfaser direkt am französischen Ingress-Router ein. Dieser ist über ein dediziertes Gigabit-LAN unmittelbar mit dem rackmontierten Teltonika-Gateway verbunden, in dem die SIM-Karte des gewünschten Netzbetreibers steckt. Das Gateway hält eine permanente 5G-NR-Verbindung zur Mobilfunkzelle. Der Request verlässt das Packet Gateway (PGW) des Betreibers und erreicht die französische Zielseite auf kürzestem Weg.
Reale Telemetriedaten: Französische Ziel-Endpunkte (10.000 Requests)
In einem automatisierten Test wurden beide Architekturen unter identischen Testbedingungen gegen französische Ziel-Endpunkte (https://www.leboncoin.fr, https://www.cdiscount.com sowie einen dedizierten Latenz-Echo-Server bei OVH in Roubaix) evaluiert:
BENCHMARK-MESSWERTE (Ziel-Infrastruktur in Paris / Roubaix)
----------------------------------------------------------------------------------------
Messwert Proxym (Orange 5G Dedicated) Bright Data Mobile (FR)
----------------------------------------------------------------------------------------
Mittlere HTTP-TTFB 184 ms 612 ms
Median (P50) Latenz 28 ms 198 ms
95. Perzentil (P95) Latenz 42 ms 845 ms
99. Perzentil (P99) Latenz 78 ms 2.450 ms (inkl. Timeouts)
Verbindungsabbrüche (TCP) 0,04 % 3,82 %
IP-Drops während Session (10m) 0,00 % (Deterministisch) 14,20 % (Peer verloren)
Download-Durchsatz (Mittelwert) 142,6 Mbps 11,4 Mbps
Upload-Durchsatz (Mittelwert) 44,1 Mbps 3,2 Mbps
Bufferbloat unter Last Niedrig (fq_codel aktiv) Hoch (Consumer Android)
----------------------------------------------------------------------------------------Die Ursachen der P99-Latenzausreißer
Die P99-Latenzspitzen von $2.450\text{ ms}$ bei Bright Data sind das Resultat der physischen Beschränkungen von Android-Consumer-Hardware:
- Android Doze Mode und CPU-Drosselung: Liegt ein Smartphone mit ausgeschaltetem Bildschirm auf dem Tisch, drosselt das Betriebssystem Hintergrundprozesse massiv, um den Akku zu schonen. Netzwerkpakete von Drittanbieter-SDKs werden gepuffert, bis der Prozessor für ein Wartungsfenster aufwacht.
- Handover zwischen WLAN und Mobilfunk: Bewegt sich der Smartphone-Besitzer oder wechselt das Gerät zwischen schwachem Heim-WLAN und LTE/5G, bricht die TCP-Verbindung ab. Es kommt zu Retransmissions, Verbindungs-Timeouts und $502\text{ Bad Gateway}$-Fehlern auf Proxy-Ebene.
- Thermisches Throttling: Führt ein Endgerät rechenintensive Operationen aus, drosselt der Baseband-Prozessor aus Überhitzungsschutz die Datenrate.
Im Gegensatz dazu arbeiten die industriellen Gateways von Proxym in klimatisierten Rechenzentren mit aktiver Lüftung und unterbrechungsfreier 24/7-Gleichstromversorgung. Die integrierten Quectel-5G-Module laufen mit optimierten Linux-Kernel-Netzwerktreibern und dedizierten Queues – ohne OS-Drosselung oder Energiebarmodi.
3. Total Cost of Ownership (TCO): Praxisfall E-Commerce-Scraping
Die Kostenstruktur moderner Scraping-Operationen wird maßgeblich durch Single-Page-Applications (SPAs) getrieben. Moderne E-Commerce-Plattformen auf Basis von Next.js, Nuxt oder React laden umfangreiche JavaScript-Bundles, führen kontinuierlich Hydration-Calls aus und kommunizieren über GraphQL-Endpunkte.
Das Blockieren von CSS und Skripten ist im Jahr 2026 kaum noch möglich: Werden diese Ressourcen nicht geladen, schlagen Anti-Bot-Prüfungen (wie Canvas-Fingerprinting oder DOM-Visibility-Checks) sofort an. Headless-Browser müssen Seiten vollständig ausführen.
Das Lastprofil
Szenario eines typischen automatisierten Preis- und Bestandsmonitorings:
- Anwendungsfall: Kontinuierliches Crawling französischer E-Commerce-Plattformen (Cdiscount, Fnac, Darty, Carrefour, LeBonCoin).
- Zielvolumen: 50.000 Produktseiten pro Woche.
- Monatliches Seitenvolumen: $50.000 \times 4,33 = 216.500\text{ Seiten/Monat}$.
- Durchschnittliche Seitengröße (Headless Chrome mit Bildfilterung, vollständigem JS/API-Stack): $850\text{ KB pro Aufruf}$.
- Netto-Datenvolumen pro Monat:
$$\frac{216.500 \times 850\text{ KB}}{1.024 \times 1.024} \approx 175,5\text{ GB / Monat}$$
- Protokoll- und Retries-Overhead (WAF-Challenges, Redirects, Fehlversuche): Konservativ veranschlagt mit $+15\%$:
$$175,5 \times 1,15 = 201,8\text{ GB / Monat}$$
========================================================================================
MONATLICHER KOSTENVERGLEICH: 200 GB PRODUKTIONS-SCRAPING-WORKLOAD
========================================================================================
Bright Data Mobile (Preisstufe: 15,00 $/GB)
[====================================================================] 3.027,00 $
- Bandbreite: 201,8 GB * 15,00 $/GB = 3.027,00 $
- Fehlgeschlagene Requests & Retries werden voll abgerechnet
- WAF-Challenges verursachen direkte Zusatzkosten
Proxym (1 dedizierter 5G-Hardware-Port)
[=] 80,00 € (~87,00 $)
- Fester Monatspreis: 80,00 € / Monat
- 200 GB Fair Use inklusive (~0,40 €/GB rechnerisch)
- Kosten für Retries & Fehlversuche: 0,00 €
- Keine Kosten für WAF-Verkehr
----------------------------------------------------------------------------------------
MONATLICHE NETTO-ERSPARNIS MIT PROXYM: 2.940,00 $ (97,1 % KONTRAKTREDUKTION)
JÄHRLICHE BETRIEBSKOSTENERSPARNIS: 35.280,00 $
========================================================================================Die mathematische TCO-Ableitung
Sei $T$ die monatlichen Gesamtkosten, $B$ das verbrauchte Datenvolumen in Gigabyte, $C_{\text{gb}}$ die Kosten pro Gigabyte, $F_{\text{base}}$ die monatliche Grundgebühr und $R_{\text{fail}}$ die Quote an Fehlversuchen (Retries / geblockte Requests).
Pay-per-GB-Kostenfunktion (Bright Data)
$$T_{\text{BrightData}} = (B \times (1 + R_{\text{fail}})) \times C_{\text{gb}}$$
Selbst bei einem Großkunden-Rabatt auf $C_{\text{gb}} = 12,00\text{ \$/GB}$ und einer moderaten WAF-Blockrate von $R_{\text{fail}} = 0,08$ (8 %):
$$T_{\text{BrightData}} = (201,8 \times 1,08) \times 12,00\text{ \$} = 217,94 \times 12,00\text{ \$} = 2.615,33\text{ \$/Monat}$$
Flat-Capacity-Kostenfunktion (Proxym)
$$T_{\text{Proxym}} = F_{\text{base}} + \max(0, B - B_{\text{inklusive}}) \times C_{\text{overage}}$$
Bei Proxym gilt:
- $F_{\text{base}} = 80,00\text{ €}$
- $B_{\text{inklusive}} = 200\text{ GB}$
- $B \approx 200\text{ GB}$
- $C_{\text{overage}} = 0,40\text{ €/GB}$
$$T_{\text{Proxym}} = 80,00\text{ €} + \max(0, 201,8 - 200) \times 0,40 = 80,00\text{ €} + (1,8 \times 0,40) = 80,72\text{ €/Monat}$$
Die betriebswirtschaftliche Konsequenz ist eindeutig: Volumenbasierte Abrechnung pro Gigabyte ist für moderne Headless-Browser-Workloads wirtschaftlich unrentabel.
Pay-per-GB zwingt Entwickler dazu, Netzwerkanfragen aufwendig zu beschneiden, Stylesheets auszufiltern und Skripte zu blockieren, um Kostenexplosionen zu verhindern. Dieser Entwicklungsaufwand erhöht das Entdeckungsrisiko durch Anti-Bot-Systeme signifikant, da echte Browser vollständige Ressourcen laden. Mit der Flatrate-Infrastruktur von Proxym sind Scraping-Workloads von Bandbreitenkosten entkoppelt.
4. Hardware-Architektur: Teltonika Bare-Metal vs. P2P-Netzwerke
Stabilität im Dauerbetrieb wird durch die zugrunde liegende Hardware bestimmt.
Die industrielle Teltonika RUTX50 / TRB500 Architektur
Proxym betreibt seine Flotte auf industriellen Mobilfunk-Gateways des europäischen Herstellers Teltonika Networks, installiert in ISO-zertifizierten Rechenzentren mit redundanter Glasfaseranbindung und Notstromversorgung.
+-----------------------------------------------------------------------+
| DEDIZIERTE PROXYM HARDWARE-NODE |
| |
| +---------------------+ +----------------------------------+ |
| | Teltonika TRB500 | | Enterprise-SIM-Karte | |
| | Industrie-Gateway | <----> | (Orange / SFR / Bouygues / Free) | |
| +---------------------+ +----------------------------------+ |
| | |
| | Interner PCI Express / M.2 Bus |
| v |
| +-----------------------------------------------------------------+ |
| | Quectel RG501Q-EU 5G NR Sub-6 GHz Modem-Modul | |
| | - 3GPP Release 16 Standard | |
| | - Max. Downlink: 2,1 Gbps / Max. Uplink: 900 Mbps | |
| | - 4x4 Downlink-MIMO auf Sub-6GHz Bändern (n1/n3/n7/n28/n78) | |
| | - Direkte industrielle AT-Befehlsschnittstelle via RutOS | |
| +-----------------------------------------------------------------+ |
| | |
| v (Externe Richtantennen mit hohem Gewinn) |
| +-----------------------------------------------------------------+ |
| | Französischer Sendemast (Direkte Sichtverbindung eNodeB/gNodeB) | |
| +-----------------------------------------------------------------+ |
+-----------------------------------------------------------------------+Vorteile der dedizierten Hardware-Architektur:
- 3GPP Release 16 Konformität: Die industriellen Modems beherrschen 5G Standalone (SA) und Non-Standalone (NSA) mit vollständigem 4x4-MIMO-Beamforming für minimale Latenz und jitterfreie Funkverbindungen.
- Deterministische Re-Registrierung via AT-Kommandos: Die IP-Rotation erfolgt über maschinennahe Befehle direkt an den Baseband-Prozessor:
``bash # Sauberes Abmelden von der Mobilfunkzelle gsmctl -A 'AT+COPS=2' # Erzwingen einer Neu-Registrierung und Anfordern eines neuen CGNAT-Leases gsmctl -A 'AT+COPS=0' `` Dieser Vorgang beendet den aktuellen Funk-Bearer und initiiert einen vollständigen Radio Resource Control (RRC) Setup-Prozess mit der Basisstation. Das Serving Gateway (S-GW) und Packet Data Network Gateway (P-GW) des Mobilfunkanbieters verwerfen die alte interne Adresse und weisen eine frische, unbefleckte CGNAT-IPv4-Adresse zu. Der gesamte Zyklus dauert lediglich 6 bis 12 Sekunden, ohne dass die lokale Client-Proxy-Verbindung abreißt.
- Dedizierte Enterprise-SIM-Profile: Proxym nutzt ausschließlich gewerbliche Mobilfunkverträge direkt bei den Netzbetreibern. Dadurch sind plötzliche Guthabensperren, Bandbreitendrosselungen oder Account-Kündigungen, wie sie bei Prepaid-SIMs im Consumer-Bereich üblich sind, ausgeschlossen.
Das P2P-Modell von Bright Data
Im Gegensatz dazu baut Bright Data auf Consumer-Handys auf. Daraus ergeben sich technische Restriktionen:
- Restriktive Betriebssystemumgebungen: Android 13, 14 und 15 beenden Hintergrundthreads inaktiver Apps rigoros, um Akkulaufzeit zu sparen.
- Schwankende Funkbedingungen: Befindet sich der Endnutzer in einem Funkloch oder in Gebäuden mit schwachem Signal, steigen Paketverlust und Jitter dramatisch an.
- Bandbreitenkonkurrenz auf dem Gerät: Nutzt der Eigentümer des Smartphones datenintensive Apps (z. B. Video-Streaming oder App-Updates), bricht der Durchsatz des getunnelten Scraping-Requests sofort ein.
5. Implementierungscode: Headless-Automatisierung & IP-Rotation
Die folgenden produktionsreifen Codebeispiele zeigen die Integration beider Systeme und veranschaulichen, wie die Hardware-IP-Rotation über die REST-API von Proxym gesteuert wird.
Python (Playwright)
Dieses Skript demonstriert ein robustes Fehlermanagement mit Playwright. Erkennt der Crawler ein Bot-Gate oder einen Rate-Limit-Statuscode, triggert er automatisch eine Hardware-Rotation auf dem zugewiesenen Teltonika-Port.
import os
import time
import requests
from playwright.sync_api import sync_playwright, BrowserContext, Page
# Proxym Konfiguration
PROXYM_HOST = "proxy.proxym.io"
PROXYM_PORT = "10001"
PROXYM_USER = "px_user_sample"
PROXYM_PASS = "px_pass_sample"
PROXYM_API_KEY = "px_api_key_sample"
PORT_ID = "prt_rutx50_fr_orange_01"
PROXY_SERVER = f"http://{PROXYM_HOST}:{PROXYM_PORT}"
ROTATION_ENDPOINT = f"https://api.proxym.io/v1/ports/{PORT_ID}/rotate"
def rotate_proxym_ip() -> bool:
"""
Triggert eine sofortige 3GPP-Neuregistrierung auf dem Teltonika-Modem.
Blockiert, bis die neue CGNAT-IP aktiv geschaltet ist.
"""
headers = {"Authorization": f"Bearer {PROXYM_API_KEY}"}
print("[*] Initiiere IP-Rotation auf Teltonika-Hardware...")
start_time = time.time()
response = requests.post(ROTATION_ENDPOINT, headers=headers, timeout=30)
if response.status_code == 200:
data = response.json()
new_ip = data.get("new_ip")
elapsed = round(time.time() - start_time, 2)
print(f"[+] Rotation erfolgreich! Neue IP: {new_ip} nach {elapsed}s")
return True
else:
print(f"[-] Rotationsfehler: {response.status_code} - {response.text}")
return False
def get_current_public_ip(page: Page) -> str:
page.goto("https://api.ipify.org?format=json", timeout=30000)
ip_data = page.evaluate("() => JSON.parse(document.body.innerText)")
return ip_data.get("ip")
def scrape_target_site():
with sync_playwright() as p:
# Browser-Instanz über die dedizierte 5G-Hardware starten
browser = p.chromium.launch(
headless=True,
args=[
"--disable-dev-shm-usage",
"--no-sandbox",
"--disable-blink-features=AutomationControlled"
]
)
context: BrowserContext = browser.new_context(
proxy={
"server": PROXY_SERVER,
"username": PROXYM_USER,
"password": PROXYM_PASS,
},
viewport={"width": 1920, "height": 1080},
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"
)
page = context.new_page()
try:
current_ip = get_current_public_ip(page)
print(f"[*] Aktive Session auf dedizierter Proxym-IP: {current_ip}")
# Zielseite ansteuern (Beispiel: französischer E-Commerce)
target_url = "https://www.leboncoin.fr"
print(f"[*] Navigiere zu {target_url}...")
response = page.goto(target_url, wait_until="domcontentloaded", timeout=45000)
# Anti-Bot-Prüfung auswerten
if response.status in [403, 429] or "datadome" in page.content().lower():
print(f"[!] Blockade erkannt (HTTP {response.status}). Starte Hardware-Rotation.")
context.close()
# Hardware-Rotation auf Modemebene ausführen
if rotate_proxym_ip():
# Kontext mit frischer Mobilfunk-IP neu initialisieren
context = browser.new_context(
proxy={
"server": PROXY_SERVER,
"username": PROXYM_USER,
"password": PROXYM_PASS,
}
)
page = context.new_page()
page.goto(target_url, wait_until="domcontentloaded", timeout=45000)
print("[+] Zielseite mit neuer 5G-IP erfolgreich aufgerufen.")
print(f"[+] Seite erfolgreich geladen: {page.title()}")
finally:
context.close()
browser.close()
if __name__ == "__main__":
scrape_target_site()Node.js (Puppeteer)
Dieses Skript zeigt die Anbindung unter Node.js mit Puppeteer Stealth inklusive programmatischem Rotations-Hook.
const puppeteer = require('puppeteer-extra');
const StealthPlugin = require('puppeteer-extra-plugin-stealth');
const axios = require('axios');
puppeteer.use(StealthPlugin());
// Infrastruktur-Konfiguration
const CONFIG = {
proxym: {