Se hai mai visto un checkout bloccato o un login fallito senza motivo apparente, molto probabilmente dietro c'è un sistema di reputazione IP e punteggio anti-frode (IPQualityScore). IPQualityScore (IPQS) è uno dei provider più usati di IP fraud scoring e proxy detection: assegna a ogni indirizzo IP un punteggio da 0 a 100, dove 0 significa traffico pulito e 100 indica quasi certamente frode. Siti di e-commerce, piattaforme SaaS e servizi finanziari integrano questo punteggio nei flussi di signup, login e pagamento per decidere in millisecondi se accettare, sfidare con CAPTCHA o bloccare una richiesta.
Per chi costruisce automazione legittima — scraping SERP, monitoraggio prezzi, QA distribuita, ricerca di sicurezza autorizzata — la reputazione IP è il fattore singolo che determina se la pipeline funzionerà o morirà sotto una muraglia di 403. In questo articolo analizziamo come IPQS costruisce il punteggio, quali segnali usa per la residential proxy detection, perché i proxy datacenter falliscono e come i residential passano, con codice Python pronto da eseguire per testare un exit node ProxyHat.
Come IPQualityScore costruisce il punteggio di frode 0-100
Il punteggio IPQS non è una singola euristica: è un modello composito che fonde dati storici, classificazione di rete, blacklist globali e controlli forensi in tempo reale. Capire ogni componente è essenziale per chi vuole passare i controlli in modo legittimo.
Honeypot e trap network
IPQS opera una rete di honeypot — server, form falsi e endpoint trappola — che registrano ogni IP che tenta accesso non autorizzato, credential stuffing o scanning. Un IP che ha colpito un honeypot negli ultimi 30 giorni riceve un boost significativo nel punteggio. Questi dati sono preziosi perché catturano comportamento attivo di abuso, non solo classificazione statica.
Classificazione ASN e range
Ogni blocco IP appartiene a un Autonomous System Number (ASN). IPQS classifica ogni ASN come ISP (residenziale/mobile), hosting/datacenter, business o educational. Un IP in un ASN di hosting (es. AS14061 DigitalOcean, AS16509 Amazon AWS) riceve automaticamente un punteggio più alto perché storicamente associato a bot e automazione. Un IP in un ASN ISP (es. AS7922 Comcast) parte con un punteggio basso perché associato a traffico umano reale.
Blacklist e feed di abuso
IPQS aggrega dati da decine di blacklist pubbliche e private, feed di spam, database di botnet e segnalazioni di abuse@. Un IP presente in 3 o più blacklist riceve un punteggio grave. La Spamhaus Block List (SBL) e il AbuseIPDB sono due delle fonti pubbliche più note; IPQS ne integra molte di più, inclusi feed proprietari.
Machine learning e pattern di abuso scalabile
Il modello ML di IPQS analizza pattern temporali: un IP che genera 500 richieste in 2 minuti da un ASN datacenter è un segnale classico di scalable abuse. Il modello rileva anche velocità di signup impossibili per un umano, rotazione di user-agent sospetta e correlazione tra IP che condividono comportamento identico (tipico di botnet e proxy pool commerciali).
Controlli forensi live: proxy, VPN, Tor
Oltre ai dati storici, IPQS esegue controlli in tempo reale: scanning di porte aperte (es. 1080, 3128, 8080 tipiche di proxy), verifica del reverse DNS, confronto geolocalizzazione dichiarata vs reale, e tentativo di identificare tunnel Tor. Questi flag diventano metadati nel response API: proxy, vpn, tor, active_vpn, active_tor.
I segnali di proxy detection: cosa cerca esattamente IPQS
La ipqualityscore proxy detection si basa su un insieme di segnali che, combinati, rendono quasi impossibile per un IP datacenter passare inosservato. Ecco i principali:
| Segnale | Cosa rileva | Peso tipico |
|---|---|---|
| Tipo ASN | Hosting vs ISP vs mobile | Alto — determina il punteggio base |
| Porte aperte | 1080, 3128, 8080, 8888 (proxy comuni) | Medio — conferma infrastruttura proxy |
| Reverse DNS (rDNS) | Hostname con keyword come "proxy", "vps", "hosted" | Medio |
| Geolocalizzazione mismatch | IP dichiarato US, ma ASN e rDNS indicano altro | Alto |
| Tipo connessione | Residential vs corporate vs datacenter | Alto |
| Recent abuse | Segnalazioni negli ultimi 1-90 giorni | Molto alto |
| Bot status | Pattern di traffico automatizzato | Alto |
Un IP datacenter tipico fallisce almeno 3 di questi segnali: ASN di hosting, porte aperte, rDNS con nome del provider cloud e recent abuse (perché i blocchi datacenter sono condivisi e ruotati). Un IP residenziale genuino passa tutti: ASN ISP, niente porte proxy aperte, rDNS del ISP locale, geolocalizzazione coerente e storico pulito.
Perché le soglie matter: ≥90 da bloccare, ≥75 da sfidare
IPQS raccomanda soglie specifiche per contesti diversi. Nella documentazione ufficiale, un punteggio ≥ 90 indica frode quasi certa e andrebbe bloccato su login, checkout e signup. Un punteggio tra 75 e 89 suggerisce sfidare con CAPTCHA o step-up authentication (2FA, email verification). Sotto 75, il traffico è considerato a basso rischio.
Queste soglie non sono arbitrarie: IPQS le ha calibrate su miliardi di transazioni. Un sito che blocca a ≥ 90 riduce il chargeback rate del 40-60% tipicamente, senza impattare falsi positivi su utenti legittimi. Ma un sito che blocca a ≥ 50 distrugge la conversione, perché molti IP residenziali con storico marginale ricevono punteggi 50-70.
Come i siti integrano il punteggio
L'integrazione tipica avviene lato server, in punti chiave:
- Signup: punteggio ≥ 90 → blocco; 75-89 → email verification obbligatoria.
- Login: punteggio ≥ 90 → blocco; 75-89 → 2FA challenge.
- Checkout: punteggio ≥ 90 → blocco o review manuale; 75-89 → 3DSecure o CVV aggiuntivo.
- API rate limiting: punteggio alto → rate limit più aggressivo o ban temporaneo.
Alcuni siti aggiungono anche segnali lato client: fingerprint del browser (canvas, WebGL, font list), fingerprint TLS (JA3/JA4) e analisi comportamentale (mouse movement, typing cadence). Questi layer si combinano con il punteggio IP per una decisione finale.
Perché i proxy residenziali passano dove i datacenter falliscono
La residential proxy detection è il problema aperto dell'anti-frode moderno. Un proxy residenziale genuino usa un IP assegnato a un vero nucle familiare da un ISP legittimo (Comcast, AT&T, Vodafone, Telecom Italia). Questo significa:
- ASN classificato come ISP, non hosting — il segnale più importante, pesa sul punteggio base.
- Geolocalizzazione residenziale coerente con il rDNS e l'ASN.
- Storico di abuso basso — l'IP non è condiviso con migliaia di altri bot.
- Niente porte proxy aperte — il router domestico non espone 1080 o 3128.
- rDNS tipico ISP, tipo
cpe-72-183-xx-xx.tx.res.rr.com, nonec2-54-xx.eu-west-1.amazonaws.com.
Il risultato: un IP residenziale con questi attributi riceve tipicamente un punteggio IPQS tra 0 e 20, ben sotto la soglia di sfida. Un IP datacenter riceve quasi sempre 75+ per il solo fatto di essere in un ASN di hosting, anche senza storico di abuso.
Key insight: l'intera sfida della residential proxy detection è che, a livello di segnali di rete, un proxy residenziale ben gestito è indistinguibile da un utente reale. L'anti-frode deve ricorrere a segnali comportamentali e fingerprinting lato client per distinguere — e anche quelli si possono mitigare con browser stealth adeguati.
Fingerprinting avanzato: JA3/JA4 e canvas
Oltre al punteggio IP, i sistemi anti-bot moderni analizzano il fingerprint TLS. JA3 e la sua evoluzione JA4 hashano l'ordine delle cipher suite e le estensioni TLS del ClientHello. Un client Python con requests produce un JA3 diverso da Chrome 120, e questo è un segnale forte di automazione. Per passare, serve un client che emuli il fingerprint TLS di un browser reale (es. cycletls, curl-impersonate o browser headless con patch stealth).
Il canvas fingerprint usa le differenze nella rendering GPU per identificare un dispositivo. Un headless browser senza GPU produce un canvas hash anomalo. Browser stealth come Playwright con playwright-stealth o browser commerciali come Camoufox mitigano questo segnale iniettando valori canvas realistici.
L'analisi comportamentale rileva pattern non umani: nessun movimento del mouse, click istantanei, navigazione lineare. Per automazione legittima, aggiungere delay realistici e simulare interazione umana riduce il rischio di blocco comportamentale.
Test pratico: IPQS proxy detection API su un exit ProxyHat
Vediamo come testare la qualità di un IP usando l'API IPQS. Useremo un exit node residenziale ProxyHat con geolocalizzazione US e lo confronteremo con un IP datacenter. L'endpoint IPQS è https://www.ipqualityscore.com/api/json/ip/{API_KEY}/{IP}.
Prima, impostiamo il proxy ProxyHat. Per un exit residenziale US:
# Proxy HTTP residenziale US
export PROXY_URL="http://user-country-US:PASSWORD@gate.proxyhat.com:8080"
# Testa l'IP di uscita
curl -x "$PROXY_URL" https://api.ipify.org
Ora lo script Python completo che confronta i punteggi:
import requests
import json
IPQS_KEY = "YOUR_IPQS_API_KEY"
PROXYHAT_PROXY = "http://user-country-US:PASSWORD@gate.proxyhat.com:8080"
def get_exit_ip(proxy_url):
"""Ottiene l'IP di uscita tramite il proxy."""
proxies = {"http": proxy_url, "https": proxy_url}
r = requests.get("https://api.ipify.org", proxies=proxies, timeout=15)
return r.text.strip()
def ipqs_lookup(ip, api_key):
"""Interroga l'API IPQS proxy detection."""
url = f"https://www.ipqualityscore.com/api/json/ip/{api_key}/{ip}"
params = {"strictness": 1, "allow_public_access_points": "true"}
r = requests.get(url, params=params, timeout=15)
return r.json()
# 1. Ottieni IP di uscita residenziale ProxyHat
residential_ip = get_exit_ip(PROXYHAT_PROXY)
print(f"Exit IP residenziale: {residential_ip}")
# 2. Lookup IPQS per il residenziale
res_result = ipqs_lookup(residential_ip, IPQS_KEY)
print("--- Risultato IP residenziale ---")
print(json.dumps(res_result, indent=2))
# 3. Confronto con un IP datacenter noto (es. 8.8.8.8 è Google DNS, ma per test
# usa un IP del tuo VPS reale)
datacenter_ip = "8.8.8.8" # sostituisci con un IP datacenter reale
dc_result = ipqs_lookup(datacenter_ip, IPQS_KEY)
print("--- Risultato IP datacenter ---")
print(json.dumps(dc_result, indent=2))
# 4. Analisi comparativa
print("\n=== CONFRONTO ===")
print(f"Residenziale - fraud_score: {res_result.get('fraud_score')}, proxy: {res_result.get('proxy')}, ASN: {res_result.get('ASN')}, ISP: {res_result.get('ISP')}")
print(f"Datacenter - fraud_score: {dc_result.get('fraud_score')}, proxy: {dc_result.get('proxy')}, ASN: {dc_result.get('ASN')}, ISP: {dc_result.get('ISP')}")
Output tipico atteso (i numeri reali variano per IP specifico):
Exit IP residenziale: 72.183.42.10
--- Risultato IP residenziale ---
{
"fraud_score": 12,
"proxy": false,
"vpn": false,
"tor": false,
"active_vpn": false,
"active_tor": false,
"recent_abuse": false,
"bot_status": false,
"connection_type": "Residential",
"ISP": "Comcast Cable Communications",
"ASN": 7922
}
--- Risultato IP datacenter ---
{
"fraud_score": 88,
"proxy": true,
"vpn": false,
"tor": false,
"recent_abuse": true,
"bot_status": true,
"connection_type": "Datacenter",
"ISP": "DigitalOcean LLC",
"ASN": 14061
}
La differenza è drammatica: il residenziale ProxyHat passa con 12 punti, il datacenter fallisce con 88 e proxy: true. Questo è il motivo per cui l'automazione seria usa residential.
Rotazione e sessioni sticky con ProxyHat
Per evitare pattern di abuso scalabile, ProxyHat supporta rotazione per-request e sessioni sticky. Per rotazione automatica, basta non specificare un session ID:
# Ogni richiesta usa un IP diverso
curl -x "http://user-country-US:PASSWORD@gate.proxyhat.com:8080" https://api.ipify.org
curl -x "http://user-country-US:PASSWORD@gate.proxyhat.com:8080" https://api.ipify.org
Per una sessione sticky (stesso IP per N minuti), aggiungi un session ID:
# Sessione sticky con ID custom
curl -x "http://user-session-mytask123-country-US:PASSWORD@gate.proxyhat.com:8080" https://api.ipify.org
Per SOCKS5, usa la porta 1080:
curl --socks5-hostname "user-country-US:PASSWORD@gate.proxyhat.com:1080" https://api.ipify.org
Consulta la documentazione ufficiale ProxyHat per tutti i parametri di geo-targeting (paese, città, ASN).
Errori comuni e edge case
1. Usare un solo IP per tutto
Anche un IP residenziale perfetto, se fa 2000 richieste/min allo stesso endpoint, triggerà il rilevamento comportamentale. La rotazione per-request è essenziale per scraping ad alto volume.
2. Ignorare il fingerprint TLS
Un IP residenziale con un JA3 da Python requests è ancora sospetto. Combina residential proxy con un client che emuli il JA3 di un browser reale.
3. Geolocalizzazione incoerente
Se il tuo proxy è US ma il browser ha timezone Europe/Rome e lingua it-IT, il mismatch è un segnale. Allinea sempre timezone, lingua e geolocalizzazione del proxy.
4. Non testare la qualità IP prima della produzione
Esegui un lookup IPQS su un campione dei tuoi exit IP prima di lanciare la pipeline. Se il 5% ha punteggio ≥ 75, rotali fuori o cambia provider.
5. Usare proxy datacenter per login o checkout
I datacenter sono accettabili per scraping pubblico ad alto volume dove l'anti-bot è debole. Per qualsiasi flusso che tocca login, pagamento o account creation, usa sempre residential.
Setup ProxyHat e best practice
ProxyHat offre residential, mobile e datacenter proxy. Per automazione che deve passare sistemi anti-frode come IPQS, i residential sono la scelta corretta. Alcune best practice:
- Usa
user-country-USo il paese target per coerenza geografica. - Per task che richiedono continuità di sessione (login, checkout multi-step), usa
user-session-{id}. - Per scraping alto volume, lascia la rotazione automatica (nessun session ID).
- Monitora il success rate: se scende sotto 95%, investiga la qualità IP.
- Rispetta
robots.txte i ToS del target.
Esplora le tariffe ProxyHat o consulta le locazioni disponibili per geo-targeting preciso. Per use case specifici, vedi web scraping e SERP tracking.
Considerazioni etiche e legali
Testare la qualità IP del proprio range o della propria infrastruttura di automazione è legittimo e raccomandato. Autorizzare penetration test con consenso scritto del target è legittimo. Automazione che rispetta robots.txt, rate limit ragionevoli e ToS è legittima.
Non è legittimo usare proxy e anti-detection per commettere payment fraud, account takeover, credential stuffing o evasione di ban legali. Il Computer Fraud and Abuse Act (CFAA) negli USA e il GDPR in Europa penalizzano accesso non autorizzato e trattamento illecito di dati personali. Usare proxy per frode non è un "test di sicurezza": è un reato.
Il confine tra automazione aggressiva e abuso è spesso definito dai ToS del target e dalla normativa locale. Quando in dubbio, consulta un legale. ProxyHat fornisce infrastruttura; l'uso responsabile spetta all'utente.
Key takeaways
- Il punteggio IPQS 0-100 è composito: honeypot, ASN, blacklist, ML e controlli forensi live. Nessun segnale isolato basta; è la combinazione che decide.
- L'ASN è il segnale più pesante: ISP vs hosting determina il punteggio base. Qui risiede la differenza tra residential e datacenter.
- Soglie: ≥ 90 blocca, 75-89 sfida. Integrare nei punti giusti (login, checkout, signup) riduce chargeback del 40-60%.
- I residential passano perché hanno ASN ISP, geolocalizzazione coerente, storico pulito e niente porte proxy aperte. I datacenter falliscono su almeno 3 segnali.
- Fingerprint TLS (JA3/JA4) e canvas sono layer aggiuntivi: anche con IP perfetto, un client non-browser è rilevabile. Combina residential + browser stealth.
- Testa prima di produrre: esegui lookup IPQS sui tuoi exit IP. Se > 5% ha punteggio alto, cambia rotazione o provider.
- Etica: testare la propria qualità IP è legittimo; payment fraud e account takeover sono reati sotto CFAA e GDPR.
FAQ
Che cos'è la reputazione IP e il punteggio anti-frode IPQualityScore?
È un sistema che assegna a ogni indirizzo IP un punteggio da 0 a 100 basato su dati di honeypot, classificazione ASN, blacklist, machine learning e controlli forensi in tempo reale. Un punteggio alto indica attività fraudolenta o uso di proxy/VPN/Tor. IPQS raccomanda di bloccare i punteggi ≥ 90 su login, checkout e signup.
Perché la reputazione IP conta per chi usa i proxy?
I sistemi anti-frode distinguono gli IP datacenter (ASN di hosting) dagli IP residenziali assegnati da ISP reali. Un IP datacenter con punteggio alto viene bloccato o sfidato con CAPTCHA, mentre un IP residenziale con ASN pulito passa. La qualità della reputazione IP determina il successo o il fallimento dell'automazione legittima.
Quale tipo di proxy funziona meglio con il punteggio anti-frode IPQS?
I proxy residenziali sono i migliori perché usano IP assegnati a veri nuclei familiari da ISP legittimi, con ASN classificato come ISP (non hosting), geolocalizzazione residenziale e storico di abuso basso. I proxy datacenter falliscono quasi sempre per ASN di hosting e pattern di abuso scalabile. I proxy mobili sono una valida alternativa per ASN mobile.
Come evitare i blocchi quando si implementa automazione con proxy?
Usa proxy residenziali con ASN ISP, mantieni sessioni sticky quando serve continuità, ruota IP per richiesta per evitare pattern di abuso, rispetta robots.txt e i ToS, e testa la qualità IP tramite API come IPQualityScore prima di andare in produzione. Non tentare mai di bypassare sistemi anti-frode per payment fraud: è illegale.
Quali segnali usa IPQualityScore per rilevare i proxy?
IPQS analizza tipo ASN (hosting vs ISP), porte aperte, reverse DNS, mismatch di geolocalizzazione, tipo di connessione, storico di abuso recente e pattern di abuso scalabile. Combina questi segnali con dati di honeypot e modelli ML per produrre un punteggio di frode 0-100 e flag proxy/VPN/Tor.
Conclusione
La reputazione IP e il punteggio anti-frode IPQualityScore non sono magia: sono un sistema composito dove l'ASN è il segnale dominante. I proxy residenziali passano perché nascono con il segnale giusto — un IP assegnato a una vera famiglia da un ISP reale. I datacenter falliscono perché il loro ASN li tradisce prima ancora che il traffico parta. Per chi costruisce automazione legittima, la scelta del proxy non è un dettaglio: è l'infrastruttura che decide se la pipeline vive o muore. Testa, ruota, rispetta i limiti e usa residential quando il punteggio conta.
