IP-Reputation und Betrugserkennung (IPQualityScore) bestimmen heute, ob Ihre automatisierten Requests durchkommen oder blockiert werden. Wenn Ihr Scraper trotz korrekter Headers und realistischer Browser-Fingerabdrücke scheitert, liegt das Problem meist nicht am Code — es liegt an der IP-Adresse. Ein 0-100 Fraud Score entscheidet in Millisekunden über Zugang oder Ausschluss. Dieser Leitfaden erklärt, wie IPQS diesen Score aufbaut, welche Signale Proxy-Erkennung auslösen, und warum residential Proxys die einzige zuverlässige Methode sind, um saubere IP-Reputation für legitime Automatisierung zu gewährleisten.
Wie IP-Reputation und Betrugserkennung (IPQualityScore) den Fraud Score aufbauen
IPQualityScore (IPQS) ist einer der am weitesten verbreiteten Fraud-Scoring-Dienste und wird von Tausenden Websites in Login-, Checkout- und Signup-Flows integriert. Der Kern des Systems ist ein 0-100 Fraud Score, der für jede IP-Adresse in Echtzeit berechnet wird. Je höher der Score, desto wahrscheinlicher ist es, dass die IP mit automatisiertem Missbrauch, Proxys, VPNs oder Betrug in Verbindung steht. IPQS empfiehlt explizit, IPs mit einem Score von >= 90 zu blockieren und Scores zwischen 75 und 89 mit zusätzlichen Verifikationsschritten wie CAPTCHA oder E-Mail-Bestätigung zu belegen.
Der Score wird aus mehreren Datenquellen zusammengesetzt, die gewichtet und mit Machine-Learning-Modellen kombiniert werden:
- Honeypots und Traps: IPQS betreibt ein globales Netzwerk aus Honeypot-Endpunkten — gefälschte Formulare, offene Ports und gefälschte Login-Seiten, die nur von automatisierten Bots oder Angreifern angesprochen werden. Jede IP, die einen Honeypot kontaktiert, wird mit einem Missbrauchs-Flag markiert. Diese Daten fließen direkt in den Score ein und können über Wochen bis Monate persistieren.
- ASN- und IP-Range-Klassifizierung: Jede IP wird anhand ihrer ASN (Autonomous System Number) kategorisiert. IPs aus Hosting-ASNs (z. B. DigitalOcean, AWS, Hetzner) erhalten ein höheres Risiko-Profil als IPs aus ISP-ASNs (z. B. Comcast, Deutsche Telekom, Vodafone). Die Klassifizierung unterscheidet zwischen residential, datacenter, mobile und corporate.
- Blacklists: IPQS aggregiert Dutzende öffentliche und private Blacklists (Spamhaus, CBL, eigenes Honeypot-Netzwerk). Ein Eintrag auf mehreren Blacklists erhöht den Score drastisch. Besonders recent abuse — gemeldete bösartige Aktivität in den letzten 1–30 Tagen — hat einen starken Einfluss.
- Machine Learning: Historische Verhaltensmuster wie Request-Frequenz, fehlgeschlagene Login-Versuche, Chargeback-Raten und Bot-Signaturen werden trainiert, um anomale IPs zu identifizieren. Das Modell wird kontinuierlich mit neuen Daten aktualisiert.
- Live forensic checks: Bei jeder API-Abfrage führt IPQS Echtzeit-Checks durch: offene Ports (z. B. SOCKS-Port 1080, HTTP-Proxy-Port 8080/3128), Tor-Exit-Node-Listen, VPN-Provider-IP-Bereiche und aktive Proxy-Detection-Signaturen. Diese Checks laufen typischerweise in unter 50 ms.
Das Ergebnis ist ein zusammengesetzter Score, der sowohl statische (ASN, Geolocation) als auch dynamische (Honeypot-Hits, Recent Abuse) Signale kombiniert. Eine IP kann heute einen Score von 12 haben und morgen 85, wenn sie in der Nacht einen Honeypot ausgelöst hat.
Proxy-Detection-Signale: Was IPQS tatsächlich misst
Die ipqualityscore proxy detection beruht auf einer Reihe konkreter, überprüfbarer Signale. Wenn Sie verstehen, welche Signale IPQS sammelt, können Sie gezielt Maßnahmen ergreifen, um legitime Automatisierung sauber durchzuführen. Die wichtigsten Signale:
ASN-Typ: Hosting vs. ISP
Das stärkste Einzel-Signal. IPQS klassifiziert jede ASN als ISP (residential/mobile), hosting (datacenter/cloud) oder corporate. Eine IP aus AS14061 (DigitalOcean) wird sofort als hosting markiert, was den Fraud Score um 20–40 Punkte erhöhen kann. Eine IP aus AS7922 (Comcast) wird als ISP eingestuft und erhält ein niedriges Basisrisiko. Diese Klassifizierung basiert auf BGP-Daten und WHOIS-Records, die öffentlich verfügbar sind — siehe Wikipedia: Autonomous System (Internet).
Offene Ports und Proxy-Signaturen
IPQS scannt häufig genutzte Proxy-Ports: 8080, 3128, 1080, 8888, 80, 443. Wenn auf einer IP einer dieser Ports offen ist und auf Proxy-Traffic reagiert, wird die IP als aktiver Proxy markiert. Auch SOCKS5-Server auf ungewöhnlichen Ports werden durch Fingerprinting erkannt.
Reverse DNS (rDNS)
Der PTR-Record einer IP liefert starke Hinweise auf ihren Typ. Ein rDNS-Eintrag wie ip-192-168-1-50.digitalocean.com signalisiert Datacenter. Ein Eintrag wie cpe-72-178-34-12.kc.rr.com signalisiert residential ISP (Road Runner/Charter). IPQS nutzt rDNS-Mustererkennung, um den Verbindungstyp zu verifizieren.
Geolocation-Mismatch
Wenn die IP-Geolocation (BGP-basiert) nicht mit der im Browser gemeldeten Zeitzone oder Sprache übereinstimmt, erhöht das den Score. IPQS vergleicht die ASN-Geolocation mit den vom Client gesendeten Headers und Time-Zone-Offsets. Eine IP in Frankfurt mit einer Browser-Zeitzone von America/New_York ist ein klares Mismatch-Signal.
Connection Type und Recent-Abuse-Historie
IPQS gibt den Verbindungstyp als residential, corporate, education, mobile oder datacenter zurück. Zusätzlich gibt es ein recent_abuse Boolean-Feld, das anzeigt, ob die IP in den letzten Tagen auf Blacklists gelandet ist oder Honeypots ausgelöst hat. Eine Datacenter-IP mit recent_abuse: true erreicht schnell Scores über 95.
Warum Thresholds entscheidend sind — und wie Sites sie einsetzen
Der ip fraud score allein ist nutzlos ohne klare Schwellenwerte. IPQS empfiehlt eine dreistufige Strategie, die viele E-Commerce- und SaaS-Plattformen übernehmen:
| Fraud Score | Empfohlene Aktion | Typische Anwendung |
|---|---|---|
| 0–74 | Zulassen | Normale User, residential ISP-IPs |
| 75–89 | Verifikation erforderlich (CAPTCHA, E-Mail, SMS) | Suspicious IPs, VPN-Verbindungen |
| 90–100 | Blockieren | Datacenter-IPs, Tor, bekannte Proxy-Netzwerke |
In der Praxis wird dies folgendermaßen implementiert:
- Login-Flow: Bei jedem Login-Versuch wird die IP über die IPQS-API geprüft. Score >= 90 führt zu sofortiger Blockierung. Score 75–89 löst eine CAPTCHA-Challenge aus. Dies verhindert Credential-Stuffing-Angriffe, die typischerweise von Datacenter-IPs ausgehen.
- Checkout-Flow: Vor der Zahlungsabwicklung wird die IP geprüft. Ein Score >= 85 kann zu einer 3D-Secure-Verifikation oder manuellen Review führen. Dies reduziert Chargeback-Raten — laut Studien kosten Chargebacks Händler durchschnittlich $3.75 pro Transaktion plus Gebühren.
- Signup-Flow: Bei der Kontoerstellung blockiert Score >= 90 die Registrierung. Score 75–89 erfordert E-Mail-Verifikation. Dies verhindert Massenregistrierungen durch Botfarmen, die fast ausschließlich Datacenter-IPs verwenden.
Die IPQS-API liefert alle relevanten Felder in einer einzigen JSON-Antwort: fraud_score, proxy, vpn, tor, recent_abuse, bot_status, connection_type, ASN, ISP und country_code. Die Integration erfolgt typischerweise serverseitig mit einer Latenz von unter 100 ms. Detaillierte Feldbeschreibungen finden sich in der offiziellen IPQS Proxy Detection API Dokumentation.
Warum residential Proxys den Fraud Score bestehen
Der Kern der residential proxy detection ist paradox: Ein residential Proxy ist schwer zu erkennen, weil er genau so aussieht wie ein echter Nutzer. Das ist kein Bug — es ist das grundlegende Design-Problem der IP-Reputation. Hier ist die Aufschlüsselung, warum eine echte ISP-assigned household IP einen niedrigen Fraud Score erhält:
- Saubere ASN: Die IP stammt aus einer ISP-ASN (z. B. Comcast, AT&T, Vodafone), die IPQS als
residentialklassifiziert. Es gibt kein Hosting-Flag, kein Datacenter-Signal. Die Basis-Risikobewertung startet niedrig. - Residential Geolocation: Die IP ist mit einer physischen Adresse in einer Stadt verknüpft. Die Geolocation stimmt mit der Zeitzone und Sprache des Browsers überein, wenn korrekt konfiguriert. Kein Mismatch-Signal.
- Niedriger Fraud Score: Da die IP nie einen Honeypot kontaktiert hat, nicht auf Blacklists steht und aus einem ISP-Bereich stammt, bleibt der Score typischerweise unter 30. Das ist im grünen Bereich.
- Keine offenen Proxy-Ports: Eine echte Residential-IP hat keine offenen SOCKS- oder HTTP-Proxy-Ports. Port-Scans finden nichts Verdächtiges.
Im Gegensatz dazu hat eine Datacenter-IP von Anfang an mehrere Nachteile: Die ASN ist als hosting markiert, was den Score um 20–40 Punkte erhöht. Die IP teilt sich oft mit Hunderten anderer Kunden, von denen einige Honeypots ausgelöst haben könnten. Der rDNS-Eintrag enthält Hosting-Keywords. Das Ergebnis: Ein Fraud Score von 80–95, der in fast jedem Login- oder Checkout-Flow blockiert wird.
Die detection challenge in einem Satz: IPQS kann einen residential Proxy nur erkennen, wenn er sich verhält wie ein Bot — nicht, wenn er sich wie ein echter Nutzer verhält. Die IP-Ebene liefert keinen Angriffsvektor; erst die Verhaltensanalyse (Request-Frequenz, Navigation patterns) kann residential Proxys entlarven.
Praktische Implementierung: IPQS API mit ProxyHat abfragen
Hier ist ein vollständiges, ausführbares Python-Skript, das die IPQS Proxy Detection API für zwei IPs abfragt: eine über ProxyHat geroutete residential IP und eine Datacenter-IP. Dies ist nützlich, um Ihre eigene IP-Qualität zu verifizieren, bevor Sie Automatisierung in Produktion schicken.
Zuerst richten wir eine Anfrage über den ProxyHat residential Proxy ein und ermitteln die Exit-IP:
import requests
import json
# --- Schritt 1: Exit-IP über ProxyHat residential Proxy ermitteln ---
proxyhat_http = "http://user-country-US:pass@gate.proxyhat.com:8080"
proxies = {"http": proxyhat_http, "https": proxyhat_http}
resp = requests.get("https://api.ipify.org?format=json", proxies=proxies, timeout=15)
residential_ip = resp.json()["ip"]
print(f"ProxyHat residential exit IP: {residential_ip}")
# --- Schritt 2: Datacenter-Exit-IP ermitteln (ohne Proxy) ---
resp_dc = requests.get("https://api.ipify.org?format=json", timeout=10)
datacenter_ip = resp_dc.json()["ip"]
print(f"Datacenter IP: {datacenter_ip}")
# --- Schritt 3: IPQS Proxy Detection API abfragen ---
IPQS_API_KEY = "IHR_IPQS_API_KEY"
def check_ip_reputation(ip_address):
url = f"https://ipqualityscore.com/api/json/ip/{IPQS_API_KEY}/{ip_address}"
params = {
"strictness": 1, # 0=relaxed, 1=standard, 2=strict
"allow_public_access_points": "true",
"fast": "true",
}
r = requests.get(url, params=params, timeout=10)
return r.json()
print("\n=== Residential IP (ProxyHat) ===")
res_result = check_ip_reputation(residential_ip)
print(json.dumps(res_result, indent=2))
print("\n=== Datacenter IP ===")
dc_result = check_ip_reputation(datacenter_ip)
print(json.dumps(dc_result, indent=2))
# --- Schritt 4: Vergleich ausgeben ---
print("\n=== Vergleich ===")
print(f"Residential fraud_score: {res_result.get('fraud_score')}")
print(f"Residential connection_type: {res_result.get('connection_type')}")
print(f"Residential proxy: {res_result.get('proxy')}")
print(f"Residential vpn: {res_result.get('vpn')}")
print(f"Residential recent_abuse: {res_result.get('recent_abuse')}")
print()
print(f"Datacenter fraud_score: {dc_result.get('fraud_score')}")
print(f"Datacenter connection_type: {dc_result.get('connection_type')}")
print(f"Datacenter proxy: {dc_result.get('proxy')}")
print(f"Datacenter vpn: {dc_result.get('vpn')}")
print(f"Datacenter recent_abuse: {dc_result.get('recent_abuse')}")
Typische Ausgabe für eine ProxyHat residential IP (US):
ProxyHat residential exit IP: 73.142.218.94
=== Residential IP (ProxyHat) ===
{
"fraud_score": 12,
"proxy": false,
"vpn": false,
"tor": false,
"recent_abuse": false,
"bot_status": false,
"connection_type": "residential",
"ISP": "Comcast Cable Communications",
"ASN": 7922,
"country_code": "US"
}
=== Datacenter IP ===
{
"fraud_score": 88,
"proxy": true,
"vpn": false,
"tor": false,
"recent_abuse": true,
"bot_status": true,
"connection_type": "datacenter",
"ISP": "DigitalOcean LLC",
"ASN": 14061,
"country_code": "US"
}
Der Unterschied ist drastisch: Die residential IP erhält einen Score von 12 mit connection_type: residential und proxy: false. Die Datacenter-IP erhält einen Score von 88 mit proxy: true, bot_status: true und recent_abuse: true. Bei einer IPQS-Schwelle von 90 würde die Datacenter-IP in den meisten Login-Flows blockiert; die residential IP würde problemlos durchkommen.
Mit curl testen
# Exit-IP über ProxyHat residential Proxy abrufen
curl -x http://user-country-US:pass@gate.proxyhat.com:8080 \
https://api.ipify.org
# IPQS API für die ermittelte IP abfragen
curl "https://ipqualityscore.com/api/json/ip/IHR_IPQS_API_KEY/IP_ADRESSE?strictness=1"
Weitere Konfigurationsoptionen für ProxyHat finden Sie in der ProxyHat Dokumentation. Eine Übersicht aller verfügbaren Standorte finden Sie auf der ProxyHat Locations-Seite.
Erweiterte Detection: JA3/JA4 und Verhaltensanalyse
IP-Reputation ist die erste Verteidigungslinie, aber moderne Anti-Bot-Systeme gehen weiter. Zwei fortgeschrittene Detection-Ebenen, die Sie verstehen sollten:
JA3/JA4 TLS-Fingerprinting
Beim TLS-Handshake sendet der Client eine ClientHello-Nachricht, die die unterstützten Cipher Suites, Extensions und elliptischen Kurven enthält. Die Reihenfolge und Auswahl dieser Werte erzeugt einen einzigartigen Hash — den JA3- oder JA4-Fingerprint. Ein echter Chrome-Browser auf Windows erzeugt einen anderen JA3-Hash als ein Python-requests-Skript. Wenn Ihre IP einen residential Score von 12 hat, aber der JA3-Hash auf einen Headless-Browser hinweist, kann das System trotzdem Alarm schlagen. Die Lösung: Verwenden Sie Browser-Automatisierungs-Tools wie Playwright oder Puppeteer mit stealth-Plugins, die den TLS-Fingerprint anpassen.
Canvas- und WebGL-Fingerprinting
JavaScript-basierte Fingerabdrücke erfennen Canvas-Rendering-Unterschiede zwischen echten Browsern und Headless-Umgebungen. Ein Headless-Chrome rendert Canvas-Elemente subtil anders als ein Desktop-Chrome mit GPU. Anti-Bot-Systeme vergleichen den Canvas-Hash mit bekannten Bot-Signaturen. Dies funktioniert unabhängig von der IP-Reputation — aber viele Systeme kombinieren IP-Score und Canvas-Signal: Ein Score von 12 mit einem sauberen Canvas-Hash ist unauffällig; ein Score von 12 mit einem Bot-Canvas-Hash löst eine Challenge aus.
Verhaltensanalyse und Request-Frequenz
Selbst mit perfekter IP-Reputation und sauberem TLS-Fingerprint kann eine zu hohe Request-Frequenz auffallen. Wenn eine einzelne residential IP 500 Requests pro Minute an einen Server sendet, wird das als anomales Verhalten markiert — unabhängig vom Fraud Score. Die Lösung ist IP-Rotation: ProxyHat bietet pro-Request-Rotation, bei der jede Anfrage über eine andere residential Exit-IP läuft. Mit Sticky Sessions können Sie eine IP für einen konfigurierbaren Zeitraum halten (z. B. 10 Minuten) und dann rotieren.
Häufige Fehler und Edge Cases
Fehler 1: Datacenter-IPs für Login-Flows verwenden
Der häufigste Fehler: Entwickler verwenden Datacenter-Proxys für Account-Automatisierung oder Login-Testing. IPQS markiert diese IPs sofort mit connection_type: datacenter und Scores von 80+. Die Lösung: Verwenden Sie residential Proxys für alle Interaktionen, die einen Login oder Checkout beinhalten.
Fehler 2: Geolocation-Mismatch ignorieren
Wenn Sie über eine US-residential IP surfen, aber die Browser-Zeitzone auf Europe/Berlin steht, erzeugt das ein Mismatch. IPQS kombiniert IP-Geolocation mit Browser-Signalen. Setzen Sie die Zeitzone und Sprache des Browsers konsistent zur Proxy-Geolocation: user-country-US → America/New_York, user-country-DE → Europe/Berlin.
Fehler 3: Zu viele Requests über eine einzelne IP
Auch residential IPs haben Limits. Wenn Sie 1.000 Requests über eine einzige residential IP senden, kann das System die IP temporär flaggen. Verwenden Sie Rotation mit user-session-abc123 für Sticky Sessions oder lassen Sie ProxyHat automatisch rotieren. Ein guter Richtwert: maximal 50–100 Requests pro IP pro Stunde für sensible Endpunkte.
Edge Case: Shared residential IPs
Residential Proxy-IPs werden manchmal von mehreren Kunden gleichzeitig genutzt. Wenn ein anderer Kunde mit derselben IP Honeypots auslöst, kann der Score steigen. ProxyHat minimiert dies durch ein großes IP-Pool, aber es ist ein inherentes Risiko des Shared-Modells. Für kritische Anwendungen können Sie dedizierte residential IPs in Betracht ziehen.
ProxyHat-spezifische Einrichtung
Um residential Proxys mit niedrigen Fraud Scores zu nutzen, konfigurieren Sie ProxyHat mit den folgenden Parametern:
| Parameter | Wert |
|---|---|
| Gateway | gate.proxyhat.com |
| HTTP Port | 8080 |
| SOCKS5 Port | 1080 |
| Geo-Targeting | user-country-US (oder DE, GB, etc.) |
| City-Targeting | user-country-US-city-newyork |
| Sticky Session | user-session-abc123 |
Beispiel mit City-Level-Geo-Targeting für maximale Geolocation-Konsistenz:
# HTTP Proxy mit US, New York Geo-Targeting
http://user-country-US-city-newyork:pass@gate.proxyhat.com:8080
# SOCKS5 Proxy mit US, New York Geo-Targeting
socks5://user-country-US-city-newyork:pass@gate.proxyhat.com:1080
Weitere Details zu Preisen und Paketen finden Sie auf der ProxyHat Pricing-Seite. Anwendungsfälle für Web-Scraping und SERP-Tracking werden auf den Seiten Web Scraping und SERP Tracking beschrieben.
Ethischer Rahmen und rechtliche Hinweise
Dieser Leitfaden richtet sich an Anti-Fraud-Engineers, Security Researcher und legitime Automatisierungs-Teams, die ihre eigene IP-Qualität testen oder autorisierte Datenextraktion durchführen. Die hier beschriebenen Techniken sollen Ihnen helfen, sicherzustellen, dass Ihre legitimen Requests nicht fälschlicherweise blockiert werden — nicht, um Betrug zu begehen.
Was legitim ist:
- Testen Ihrer eigenen IP-Adresse oder Ihrer Proxy-Infrastruktur gegen IPQS, um die Qualität zu verifizieren.
- Autorisierte Web-Scraping unter Einhaltung der robots.txt und der Nutzungsbedingungen der Zielwebsite.
- QA-Automatisierung für Ihre eigenen Anwendungen und Login-Flows.
- Security Research mit ausdrücklicher Genehmigung des Zielbetreibers.
Was nicht legitim ist:
- Verwendung von Proxys zur Verschleierung von Zahlungsbetrug, Credential-Stuffing oder Account-Takeover-Angriffen.
- Umgehung von Anti-Bot-Maßnahmen, um Nutzungsbedingungen aktiv zu verletzen.
- Scraping von personenbezogenen Daten ohne Rechtsgrundlage.
Rechtlicher Hinweis: In der EU unterliegt die Verarbeitung von IP-Adressen der DSGVO (Art. 4 — personenbezogene Daten), da IP-Adressen als personenbezogene Daten gelten. In den USA kann unbefugter Zugriff auf Computersysteme nach dem Computer Fraud and Abuse Act (CFAA) strafbar sein. Stellen Sie sicher, dass Ihre Automatisierung innerhalb der rechtlichen Rahmenbedingungen Ihres Betriebslandes erfolgt und dass Sie eine Rechtsgrundlage für die Verarbeitung haben.
Key Takeaways
- IP-Reputation ist die erste Verteidigungslinie: IPQS berechnet einen 0-100 Fraud Score aus ASN-Klassifizierung, Honeypot-Daten, Blacklists, ML-Modellen und Live-Checks. Scores >= 90 werden blockiert, 75–89 erfordern Verifikation.
- ASN-Typ ist das stärkste Signal: Hosting-ASNs (DigitalOcean, AWS, Hetzner) erhalten automatisch höhere Scores. ISP-ASNs (Comcast, Vodafone) erhalten niedrige Basis-Scores.
- Residential Proxys bestehen, weil sie wie echte Nutzer aussehen: Saubere ASN, residential Geolocation, keine offenen Proxy-Ports, keine Honeypot-Hits — der Score bleibt unter 30.
- Datacenter-IPs scheitern systematisch: Hosting-ASN + rDNS-Muster + oft shared mit Missbrauchshistorie = Score 80–95.
- Testen Sie Ihre IPs vor Produktion: Verwenden Sie das Python-Skript oben, um Ihre Proxy-Exit-IPs gegen IPQS zu prüfen, bevor Sie Automatisierung live schalten.
- IP ist nur die erste Ebene: JA3/JA4-TLS-Fingerabdrücke, Canvas-Fingerprinting und Verhaltensanalyse ergänzen IP-Reputation. Saubere IP + sauberer Browser = bestmögliche Erfolgsquote.
FAQ
Was ist IP-Reputation und Betrugserkennung (IPQualityScore)?
IPQualityScore (IPQS) ist ein Dienst, der jeder IP-Adresse einen 0-100 Fraud Score zuweist, basierend auf ASN-Klassifizierung, Honeypot-Daten, Blacklists, Machine Learning und Live-Checks (offene Ports, Tor, VPN). Scores >= 90 werden von vielen Websites blockiert, Scores 75–89 erfordern zusätzliche Verifikation. IPQS wird in Login-, Checkout- und Signup-Flows integriert, um Bot- und Betrugsversuche abzuwehren.
Warum ist IP-Reputation für Proxy-Nutzer wichtig?
Der IP-Reputations-Score bestimmt, ob Ihre Requests durch Anti-Bot-Systeme kommen oder blockiert werden. Datacenter-IPs erhalten typischerweise Scores von 80–95 und werden in fast allen Login-Flows blockiert. Residential Proxys mit ISP-ASNs erhalten Scores unter 30 und kommen problemlos durch. Wenn Sie Automatisierung betreiben, ist die IP-Qualität der wichtigste einzelne Erfolgsfaktor.
Welcher Proxy-Typ funktioniert am besten für niedrige Fraud Scores?
Residential Proxys sind die beste Wahl. Sie nutzen echte ISP-assigned IP-Adressen aus ASNs wie Comcast oder Vodafone, die IPQS als connection_type: residential klassifiziert. Mobile Proxys sind ähnlich stark, können aber teurer sein. Datacenter-Proxys sind für Login- oder Checkout-Flows ungeeignet, da sie automatisch hohe Scores erhalten. Für reine Web-Scraping-Aufgaben ohne Login können Datacenter-Proxys ausreichen, aber residential Proxys bieten deutlich höhere Erfolgsquoten.
Wie vermeide ich Blocks bei der Verwendung von Proxys?
Verwenden Sie residential Proxys mit korrektem Geo-Targeting (z. B. user-country-US), setzen Sie die Browser-Zeitzone konsistent zur Proxy-Geolocation, rotieren Sie IPs für hohe Request-Volumen, und nutzen Sie Browser-Automatisierung mit Stealth-Plugins, um JA3/JA4- und Canvas-Fingerabdrücke anzupassen. Testen Sie Ihre Exit-IPs vorab gegen IPQS, um den Fraud Score zu verifizieren. Halten Sie die Request-Frequenz pro IP moderat (50–100 Requests pro Stunde für sensible Endpunkte).
Kann IPQS residential Proxys erkennen?
IPQS kann residential Proxys auf IP-Ebene nur schwer erkennen, da sie wie echte Nutzer-IPs aussehen. Die Erkennung erfolgt stattdessen über Verhaltensanalyse: Request-Frequenz, Navigationsmuster, TLS-Fingerabdrücke (JA3/JA4) und Canvas-Rendering. Wenn ein residential Proxy einen sauberen IP-Score hat, aber Bot-Verhalten zeigt, kann das System trotzdem Alarm schlagen. Die Lösung ist eine Kombination aus residential IPs, realistischen Browser-Fingerabdrücken und moderaten Request-Raten.
