Czym jest reputacja IP i scoring oszustw — mechanika IPQualityScore
Reputacja IP (ip reputation) to miara zaufania, jaką systemy antyfraudowe przypisują konkretnemu adresowi IP na podstawie jego historii, ASN, typu połączenia i wzorców ruchu. Scoring oszustw — popularnie ip fraud score — to numeryczna synteza tych sygnałów w skali 0–100, gdzie 0 oznacza czysty ruch, a 100 niemal pewne działanie złośliwe. IPQualityScore (IPQS) to jeden z najczęściej stosowanych silników tego typu, z którym zderzają się inżynierowie scrapingu i antyfraudu.
Dla inżynierów automatyzacji zrozumienie, jak działa wykrywanie proxy IPQualityScore (ipqualityscore proxy detection), nie jest ćwiczeniem akademickim. To różnica między ruchem, który przechodzi przez bramki logowania i checkoutu, a ruchem, który zostaje zablokowany na poziomie warstwy sieciowej. W 2026 roku detekcja opiera się nie tylko na czarnych listach — to wielowarstwowy system łączący klasyfikację ASN, analizę behawioralną, sygnatury TLS i modele uczenia maszynowego.
W tym artykule rozkładamy mechanikę scoringu na części, pokazujemy dlaczego wykrywanie proxy residentialnych (residential proxy detection) jest tak trudne, i podajemy runnable kod Python do testowania własnych adresów IP.
Dlaczego ten problem istnieje — kontekst techniczny
Każda platforma z ruchem transakcyjnym — e-commerce, fintech, social media, SaaS — musi odróżniać legitnych użytkowników od botów, kont farmowanych i ataków credential stuffing. Problem polega na tym, że atakujący dysponują dziś taną infrastrukturą: datacenter IP za $0,001/godz., rotujące proxy za $1–3/GB, a w niektórych przypadkach botnety urządzeń mobilnych. Systemy antyfraudowe odpowiadają warstwową klasyfikacją zaufania.
Fundamentem jest ASN — Autonomous System Number. Adresy z zakresów przypisanych do AWS, Google Cloud, Azure czy DigitalOcean mają od razu obniżony score, bo ruch z datacenter rzadko pochodzi od realnego konsumenta. Z kolei adresy z zakresów ISP (Comcast, Verizon, Deutsche Telekom) otrzymują wyższe zaufanie bazowe, bo pochodzą z gospodarstw domowych. To pierwszy i najważniejszy sygnał w ip reputation.
Drugą warstwę stanowią sygnatury behawioralne i sieciowe. Tu wchodzą w grę m.in. TLS 1.3 (RFC 8446) — kolejność szyfrów w ClientHello tworzy tzw. fingerprint JA3/JA4, który identyfikuje konkretną implementację TLS. Headless Chrome ma inną sygnaturę JA3 niż realny Chrome na Windows, co jest sygnałem automatyzacji. Do tego dochodzą sygnały z JavaScript: navigator.webdriver, canvas fingerprint, WebGL renderer, WebRTC leak lokalnego IP, i lista zainstalowanych fontów. Wszystko to składa się na decyzję: zablokować czy przepuścić.
Jak budowany jest wskaźnik oszustwa IP 0–100
IPQS i podobne systemy budują fraud score z kilku kategorii sygnałów. Oto dekompozycja:
Honeypoty i pułapki
Systemy antyfraudowe utrzymają sieci pułapek — adresy i formularze, które nie są nigdy publikowane w sposób organiczny. Jeśli ruch dociera do pułapki, oznacza to automatyczne skanowanie lub atak brute-force. IP, które trafiło w pułapkę, otrzymuje natychmiastowy boost w fraud score, często powyżej 75. Te dane są często współdzielone między dostawcami, więc jedno trafienie może oznaczać zablokowanie na wielu platformach.
Klasyfikacja ASN i zakresów
Każdy adres IP jest mapowany na ASN i typ połączenia. IPQS rozróżnia m.in.:
- Residential / ISP — adresy przypisane do dostawcy usług internetowych dla gospodarstw domowych.
- Mobile / Cellular — adresy z sieci komórkowych (T-Mobile, AT&T, Vodafone).
- Datacenter / Hosting — adresy z zakresów chmurowych (AWS, GCP, Azure, OVH, Hetzner).
- Business / Corporate — adresy firmowych łączy dedykowanych.
Typ ASN to najmocniejszy pojedynczy sygnał. Datacenter IP z czystą historią może otrzymać score 35–55, podczas gdy residential IP z tą samą historią dostaje 0–10. To asymetria, którą wykorzystują proxy residentialne.
Czarne listy i historia nadużyć
IPQS agreguje dane z kilkudziesięciu czarnych list (spam, botnet, malware C2, proxy open). Każde trafienie podbija score. Kluczowe jest pojęcie recent abuse — aktywność z ostatnich 24–168 godzin ma znacznie większą wagę niż starsze incydenty. Adres, który był czysty przez 30 dni, ale wczoraj pojawił się na liście botnetów, dostaje flagę recent_abuse = true, co typowo podbija score powyżej 80.
Uczenie maszynowe i analiza behawioralna
Modele ML analizują wzorce: tempo zapytań, dystrybucja User-Agent, rotacja adresów IP w sesji, paralelizm połączeń. Jeśli z jednego /24 przychodzi 1500 zapytań/minutę z 40 różnymi nagłówkami UA, model podnosi score — to klasyczny wzorzec scalable abuse. Modele te są trenowane na danych z partnerów e-commerce i fintech, więc reagują na aktualne wektory ataków.
Forensic checks na żywo
IPQS wykonuje również testy aktywne:
- Open port scan — sprawdza czy na IP są otwarte porty charakterystyczne dla proxy (3128, 8080, 1080, 8888, 9999).
- rDNS lookup — odwrotne DNS;
host-192-168-1-1.aws.comvscpe-72-183-12-34.tx.res.rr.com. - Geolocation mismatch — różnica między geolokalizacją IP a danymi z innych sygnałów (Accept-Language, timezone, WebRTC).
- VPN / Tor exit node — sprawdzenie znanych list węzłów wyjściowych sieci Tor i popularnych VPN.
Sygnały wykrywania proxy — co dokładnie jest testowane
IPQS i podobne systemy używają kilkunastu sygnałów do klasyfikacji, czy adres jest proxy, VPN lub węzłem Tor. Oto szczegółowa dekompozycja:
| Sygnał | Waga | Opis |
|---|---|---|
| ASN type | Bardzo wysoka | Hosting/DC vs ISP/Mobile — najmocniejszy pojedynczy sygnał |
| Open ports | Średnia | Porty 3128, 8080, 1080, 8889 typowe dla proxy open |
| rDNS pattern | Wysoka | Domeny zawierające „host”, „server”, „cloud”, „vps” = hosting |
| Geolocation mismatch | Średnia | IP deklaruje USA, ale TLS timezone = Europa Wschodnia |
| Connection type | Wysoka | Residential vs Corporate vs Datacenter vs Mobile |
| Recent abuse | Bardzo wysoka | Aktywność na czarnych listach w ciągu ostatnich 7 dni |
| VPN / Tor flag | Wysoka | Obecność na publicznych listach węzłów wyjściowych |
| Bot status | Wysoka | Detekcja headless browser, brak JS, brak canvas |
Dodatkowo, nowoczesne systemy sprawdzają sygnatury warstwy aplikacji. TLS fingerprinting (JA3/JA4) identyfikuje konkretnego klienta TLS po kolejności szyfrów i rozszerzeń w ClientHello. Headless Chromium generuje inny JA3 niż realny Chrome 120 na Windows 11 — to sygnał, który trudno sfałszować bez modyfikacji stosu TLS. Do tego dochodzi canvas fingerprint — hash renderowanego obrazu na elemencie <canvas>, który zależy od GPU, sterowników i systemu operacyjnego. Headless browser na serwerze bez GPU generuje odmienny hash niż realne urządzenie.
Progi i integracja — gdzie site'y stosują fraud score
IPQS zaleca blokowanie ruchu z fraud score ≥ 90 dla większości zastosowań. W praktyce progi są konfigurowane per-punkt-integracji:
- Logowanie (login): score ≥ 75 → MFA wymuszone; ≥ 90 → blokada.
- Rejestracja (signup): score ≥ 55 → CAPTCHA; ≥ 85 → odrzucenie.
- Checkout (płatność): score ≥ 70 → manual review; ≥ 90 → blokada transakcji.
Integracja jest zazwyczaj API-first: każde zapytanie do IPQS zwraca JSON z polami fraud_score, proxy, vpn, tor, recent_abuse, bot_status, ASN, connection_type. Platformy podejmują decyzję synchronicznie — typowo z opóźnieniem 50–200ms na zapytanie — lub asynchronicznie, flagując sesję do weryfikacji post-factum.
Ważne: progi nie są uniwersalne. E-commerce o niskiej marży może tolerować score do 75 na etapie rejestracji (koszt utraty klienta przeważa nad kosztem fraudu), podczas gdy krypto-giełda blokuje już od 50. Konfiguracja zależy od modelu ryzyka biznesowego.
Dlaczego proxy residentialne przechodzą tam, gdzie datacenter zawodzi
To jest sedno wyzwania detekcyjnego. Proxy residentialne korzystają z adresów IP przypisanych do realnych ISP — Comcast, AT&T, BT, Orange — i tych samych zakresów, z których korzystają miliony gospodarstw domowych. Klasyfikacja ASN zwraca Residential, a nie Hosting. rDNS pokazuje domenę typu cpe-72-183-12-34.tx.res.rr.com, a nie ec2-54-213-12-34.us-west-2.compute.amazonaws.com.
W konsekwencji:
- Bazowy fraud score jest niski — typowo 0–15 dla czystego residential IP, vs 35–55 dla datacenter.
- Geolocation jest spójna — ISP zgłasza adres w tym samym mieście, co deklaruje użytkownik.
- Brak otwartych portów proxy — adresy nie wystawiają 3128/8080/1080 na świat.
- Historia nadużyć jest czysta — jeśli adres był nieużywany w kontekście fraudu,
recent_abuse = false.
To nie znaczy, że residential proxy są niewidzialne. Jeśli ruch z jednego /24 przychodzi w nienaturalnym tempie (np. 500 zapytań/s z 20 różnych sesji), ML model to wykryje. Jeśli JA3 wskazuje na headless browser, a ASN mówi „residential”, to anomalia, która podnosi score. Dobra praktyka polega na łączeniu residential proxy z realnym browserem (Playwright z konfiguracją stealth), właściwym JA3 i ludzkim tempem zapytań.
Mobile proxy są analogicznie silne — ruch z sieci komórkowych (T-Mobile, Vodafone) ma typ połączenia Mobile, który IPQS traktuje z wysokim zaufaniem bazowym. Rotacja IP w sieci komórkowej jest naturalnym zjawiskiem (NAT carrier-grade), więc zmiana adresu w sesji nie jest flagowana tak agresywnie jak w przypadku datacenter.
Praktyczny test: IPQS API vs ProxyHat residential exit
Poniżej znajduje się runnable kod Python, który demonstruje, jak sprawdzić fraud score dla dwóch adresów: ProxyHat residential exit (przez gate.proxyhat.com:8080 z geo-targetingiem US) oraz porównawczego IP z datacenter. Kod zakłada posiadanie klucza API IPQS — możesz go uzyskać na dokumentacji IPQS Proxy Detection API.
import requests
import json
IPQS_API_KEY = "YOUR_IPQS_KEY"
def check_ip(ip_address):
"""Query IPQS proxy detection API for a given IP."""
url = f"https://www.ipqualityscore.com/api/json/ip/{IPQS_API_KEY}/{ip_address}"
params = {
"strictness": 0, # 0 = lenient, 3 = strict
"allow_public_access_points": "true",
"lighter_penalties_on_cloud_providers": "false",
}
resp = requests.get(url, params=params, timeout=10)
return resp.json()
# --- Step 1: Get your current external IP via ProxyHat residential proxy ---
proxyhat_http = "http://user-country-US:pass@gate.proxyhat.com:8080"
proxies = {"http": proxyhat_http, "https": proxyhat_http}
# Use a simple IP echo service through the proxy
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}")
# --- Step 2: Query IPQS for the residential IP ---
result_res = check_ip(residential_ip)
print("=== Residential IP (ProxyHat) ===")
print(json.dumps(result_res, indent=2))
# --- Step 3: Compare with a known datacenter IP ---
# Example: a public AWS IP range (for illustration)
datacenter_ip = "54.213.12.34" # Replace with your own DC IP
result_dc = check_ip(datacenter_ip)
print("=== Datacenter IP ===")
print(json.dumps(result_dc, indent=2))
# --- Step 4: Print comparison ---
print(f"\n--- Comparison ---")
print(f"Residential fraud_score: {result_res.get('fraud_score')}")
print(f"Residential connection_type: {result_res.get('connection_type')}")
print(f"Residential proxy flag: {result_res.get('proxy')}")
print(f"Datacenter fraud_score: {result_dc.get('fraud_score')}")
print(f"Datacenter connection_type: {result_dc.get('connection_type')}")
print(f"Datacenter proxy flag: {result_dc.get('proxy')}")
Typowy wynik dla ProxyHat residential exit w USA wygląda następująco:
{
"fraud_score": 0,
"country": "US",
"city": "Houston",
"ISP": "Comcast Cable Communications",
"ASN": 7922,
"connection_type": "Residential",
"proxy": false,
"vpn": false,
"tor": false,
"recent_abuse": false,
"bot_status": false
}
A dla datacenter IP:
{
"fraud_score": 55,
"country": "US",
"city": "Boardman",
"ISP": "Amazon.com Inc.",
"ASN": 16509,
"connection_type": "Datacenter",
"proxy": false,
"vpn": false,
"tor": false,
"recent_abuse": false,
"bot_status": false
}
Różnica jest dramatyczna: fraud_score 0 vs 55, connection_type Residential vs Datacenter. Przy progu rejestracji 55, datacenter IP zostanie zablokowany lub poproszony o CAPTCHA, podczas gdy residential IP przejdzie bez problemu.
Wersja curl — szybki test z linii poleceń
# Get residential exit IP through ProxyHat
curl -x http://user-country-US:pass@gate.proxyhat.com:8080 \
https://api.ipify.org
# Query IPQS for that IP (replace YOUR_IP and YOUR_IPQS_KEY)
curl "https://www.ipqualityscore.com/api/json/ip/YOUR_IPQS_KEY/YOUR_IP"
SOCKS5 — gdy potrzebujesz niższego poziomu
Dla aplikacji wymagających tunelowania na poziomie TCP (np. niestandardowe protokoły, gRPC, WebSocket), ProxyHat oferuje SOCKS5 na porcie 1080:
socks5://user-country-US:pass@gate.proxyhat.com:1080
SOCKS5 jest preferowany, gdy HTTP proxy może modyfikować nagłówki lub gdy potrzebujesz pełnej transparentności protokołu. W kontekście fraud scoringu nie ma to znaczenia dla IPQS — liczy się adres IP wyjściowy, nie protokół tunelu.
Sticky sessions i rotacja — strategie
ProxyHat obsługuje sesje sticky przez flagę w nazwie użytkownika:
# Sticky session — ten sam IP przez całą sesję
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080
# Rotacja per-request (domyślnie, bez flagi session)
http://user-country-US:pass@gate.proxyhat.com:8080
Dla scraping'u SERP, gdzie chcesz zachować spójność sesji przez np. 10–15 zapytań, sticky session jest kluczowa. Dla price monitoringu na wielu konkurentach, rotacja per-request rozprasza ruch i obniża ryzyko wykrycia wzorcem. Więcej o strategiach rotacji znajdziesz w naszym przewodniku web scraping oraz SERP tracking.
Geo-targeting — dlaczego kraj i miasto mają znaczenie
IPQS sprawdza zgodność geolokalizacji z innymi sygnałami. Jeśli Twój residential IP jest w Houston, TX, ale Accept-Language to ja-JP i timezone to Asia/Tokyo, to anomalia. ProxyHat pozwala precyzyjne targetowanie:
# Kraj
http://user-country-US:pass@gate.proxyhat.com:8080
# Kraj + miasto
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080
Pełną listę dostępnych lokalizacji znajdziesz na stronie lokalizacji ProxyHat. Dopasowanie geolokalizacji proxy do profilu Twojego docelowego użytkownika (timezone, język, Accept-Language) jest krytyczne dla utrzymania niskiego fraud score.
Najczęstsze błędy i przypadki brzegowe
1. Ignorowanie JA3/JA4
Nawet z idealnym residential IP, jeśli Twój HTTP client generuje JA3 typowy dla requests lub urllib3, systemy antyfraudowe to wykryją. requests używa OpenSSL z konkretną kolejnością szyfrów, różną od Chrome. Rozwiązanie: używaj Playwright/Puppeteer z konfiguracją stealth lub curl-impersonate, które modyfikują stos TLS do naśladowania realnych przeglądarek.
2. Zbyt agresywne tempo zapytań
Residential IP z 500 zapytań/minutę = anomalia. Realny użytkownik robi 1–5 zapytań na sesję. Utrzymuj ludzkie tempo (1–3 zapytania/sekundę z throttlingiem i jitterem). Jeśli potrzebujesz wysokiej przepustowości, używaj puli residential IP z rotacją, rozkładając ruch na wiele adresów.
3. Brak spójności nagłówków
Residential IP z Houston + UA Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) + Accept-Language ru-RU = natychmiastowa flaga. Każdy element musi być spójny: geolokalizacja, język, UA, timezone, screen resolution.
4. WebRTC leak
WebRTC może ujawnić lokalne IP urządzenia (np. 192.168.x.x) lub publiczne IP bez proxy. Headless browser bez konfiguracji WebRTC leakuje adres serwera. Zawsze wyłączaj WebRTC lub konfiguruj proxy jako ice candidate.
5. Zaufanie do pojedynczego testu
Fraud score zmienia się w czasie. IP, który dziś ma score 0, jutro może mieć 85, jeśli ktoś inny użył tego samego /24 do spamu. Testuj regularnie i monitoruj score na puli adresów, z których korzystasz.
Ramka etyczna i prawna
Testowanie fraud score własnych adresów IP i infrastruktury proxy jest w pełni legitne — to standardowa praktyka QA i security research. Sprawdzanie, czy Twój ruch automatyczny przechodzi przez systemy antyfraudowe, jest analogiczne do penetration testingu własnej aplikacji.
Granica przebiega tam, gdzie zaczyna się oszustwo:
- Legitne: testowanie jakości proxy dla scraping'u publicznych danych, SERP tracking, price monitoring, QA własnych endpointów.
- Nielegitne: omijanie fraud detection w celu payment fraud, account takeover, creation of fake accounts dla manipulacji (np. fake reviews, ballot stuffing).
W kontekście prawnym: w UE RODO (GDPR) reguluje przetwarzanie danych osobowych, w tym adresów IP jako danych identyfikujących. W USA Computer Fraud and Abuse Act (CFAA) kategoryzuje nieautoryzowany dostęp do systemów komputerowych jako przestępstwo federalne. Scraping publicznie dostępnych danych jest ogólnie chroniony (np. hiQ Labs v. LinkedIn), ale omijanie technicznych barier autoryzacji może wchodzić w konflikt z CFAA. Zawsze konsultuj z działem prawnym, jeśli Twój use-case jest w szarej strefie.
Szczegóły konfiguracji ProxyHat znajdziesz w dokumentacji ProxyHat, a cennik na stronie cennika ProxyHat.
Kluczowe wnioski
ASN type to najmocniejszy sygnał. Residential IP z czystą historią ma bazowy fraud score 0–15; datacenter IP z tą samą historią ma 35–55. To asymetria, która definiuje całe wyzwanie.
- Reputacja IP to suma wielu sygnałów — ASN, rDNS, open ports, geolocation, recent abuse, ML patterns, TLS fingerprint. Żaden pojedynczy sygnał nie decyduje; decyduje kombinacja.
- Progi są per-punkt-integracji. Login ≥ 90, signup ≥ 85, checkout ≥ 70 to typowe wartości, ale zależą od modelu biznesowego.
- Residential proxy przechodzą, bo ASN = ISP. To fundament. RDS, geolocation i historia są konsekwencją, nie przyczyną.
- Sam IP to nie wystarczy. JA3/JA4, canvas fingerprint, WebRTC leak, nagłówki i tempo zapytań mogą obalić residential IP, jeśli reszta stacku jest niespójna.
- Testuj regularnie. Fraud score jest dynamiczny — IP, które dziś jest czyste, jutro może być zanieczyszczone ruchem innego użytkownika.
