Un decennio e mezzo di protezione dei siti si è basato su un'assunzione: un indirizzo IP è un'unica entità che può essere punita. Gli ingegneri di Cloudflare hanno misurato quanto questa assunzione sia stata infranta e hanno pubblicato i dati. Il dato principale è inaspettato: gli indirizzi che ospitano centinaia di persone reali ricevono limitazioni di velocità tre volte più frequentemente rispetto agli altri. Analizziamo cos'è il CGNAT, perché i proxy mobili sono più resistenti degli altri e perché l'"effetto folla" ha smesso di essere un'indulgenza.
Perché "bannare semplicemente un IP" ha smesso di essere una soluzione economica
Qualsiasi protezione contro l'automazione — blacklist, rate limit, anomalie — presuppone che dietro l'indirizzo ci sia un risponditore comprensibile. Se si blocca l'indirizzo, si punisce il trasgressore. Il costo dell'errore è considerato nullo: beh, non si è lasciato passare un bot.
Questa aritmetica è valida finché dietro l'indirizzo c'è effettivamente un solo utente. Un IP di un data center ha proprio questo: un indirizzo — un'entità affittata, il ban costa zero al sito. Con un provider domestico — una sola famiglia, quasi zero anche lì. Ma con un operatore mobile, dietro un unico indirizzo pubblico può esserci un intero quartiere della città. E lì il ban diventa improvvisamente un'operazione costosa: insieme allo scraper, il sito disattiva centinaia di clienti reali che non hanno infranto alcuna regola.
È proprio questa asimmetria di costo — e non la "magia degli IP mobili" — a determinare chi viene bannato severamente e chi viene risparmiato. E ha un nome tecnico specifico.
Cos'è il CGNAT e perché è totale tra gli operatori
CGNAT (Carrier-Grade NAT, noto anche come LSN — Large Scale NAT) è la traduzione degli indirizzi a livello di operatore, non di router domestico. Formalmente, la base è documentata in RFC 6598 (aprile 2012): per le esigenze dei traduttori degli operatori è stato riservato l'intervallo 100.64.0.0/10 — 4.194.304 indirizzi che non vengono instradati nella rete globale e non devono oltrepassare il confine della rete del provider.
La motivazione nel testo RFC è formulata chiaramente: lo spazio degli indirizzi IPv4 è quasi esaurito, ma i provider devono sostenere la crescita dei clienti IPv4 fino a quando l'IPv6 non sarà completamente implementato. Il blocco /10 è stato scelto come dimensione minima per consentire l'implementazione del CGN a livello regionale, senza costruire traduttori annidati.
Per gli operatori mobili, la carenza di indirizzi è particolarmente acuta: gli abbonati sono milioni, gli IPv4 pubblici sono decine di migliaia. Pertanto, il CGNAT non è un'opzione, ma la norma per impostazione predefinita. Un indirizzo pubblico gestisce centinaia, e durante le ore di punta anche migliaia di sessioni, e l'indirizzo dell'abbonato cambia continuamente — durante il passaggio tra torri, durante la riconnessione della sessione, durante la gestione della larghezza di banda.
Da qui deriva tutto il valore pratico dei proxy mobili: non si ottiene un IP "pulito", si ottiene un indirizzo che il sito non può disattivare senza danni collaterali.
Cosa ha misurato esattamente Cloudflare
Nello studio "One IP address, many users: detecting CGNAT to reduce collateral effects" (Vasilis Giotas e Marwan Fayed, pubblicato il 29 ottobre 2025, aggiornato il 15 luglio 2026) Cloudflare affronta un problema inverso: imparare a distinguere gli indirizzi dietro la traduzione dell'operatore, per applicare misure più miti.
La metodologia è stata raccolta da diverse fonti indipendenti:
- Traceroute distribuiti da oltre 9000 nodi RIPE Atlas — per catturare gli indirizzi da 100.64.0.0/10 lungo il percorso;
- Record WHOIS e PTR — ricerca di marcatori
cgnat,cgn,lsnnei nomi e nelle descrizioni; - Cataloghi pubblici di anonymizer — per raccogliere indirizzi VPN e proxy;
- Modello XGBoost basato su segnali dei clienti, comportamento a livello di trasporto, volume di traffico e varietà di direzioni, con aggregazione sia per singolo IP che per sottorete /24.
Dimensione del campione di addestramento: 200.000 indirizzi CGNAT, 180.000 indirizzi VPN e proxy, 900.000 indirizzi normali, suddivisione 70/30, validazione incrociata dieci volte. La qualità dichiarata — accuratezza 0,98, F1 pesato 0,97, log loss 0,04, macro-AUC 0,9946.
Un dettaglio separato, di cui si parla poco nell'industria: il rapporto tra il numero di user-agent e il numero di indirizzi è notevolmente più alto in Africa rispetto ad altre regioni. La distribuzione storica dei grandi blocchi IPv4 è andata a Nord America ed Europa decenni fa — e oggi questo si traduce nel fatto che gli utenti delle regioni in via di sviluppo sono più frequentemente soggetti a punizioni collettive. Cloudflare chiama questo uno spostamento socioeconomico.
Il dato principale: limitazione della velocità tre volte più frequente
Il risultato chiave dello studio suona controintuitivo per tutti coloro che sono abituati a considerare l'IP mobile "intoccabile": gli utenti dietro il CGNAT affrontano limitazioni di velocità tre volte più frequentemente rispetto agli utenti al di fuori del CGNAT.
Non c'è contraddizione qui — c'è una divisione delle misure in base al costo. Il ban severo di un indirizzo è costoso, perché colpisce gli abbonati reali. Mentre il rate limit, la sfida e il captcha sono economici e reversibili. Pertanto, la protezione non disattiva tale indirizzo, lo soffoca. Inoltre, il meccanismo stesso scatta più frequentemente per una ragione aritmetica: sullo stesso indirizzo si somma il traffico di molte persone indipendenti, e le soglie vengono superate più rapidamente.
Una seconda coppia di dati spiega perché i siti siano disposti a tollerare tali indirizzi. La percentuale di bot sugli indirizzi CGNAT: mediana 4,8% contro 4,7% per gli altri — quindi, per mediana, la differenza è praticamente inesistente. Ma per la media, la situazione cambia: 7% per CGNAT contro 13,1% per non-CGNAT. Questo si legge così: tra gli indirizzi normali c'è una lunga coda di quasi completamente automatizzati — un tipico intervallo di data center, dove non ci sono persone reali, e questo tira su la media. Dietro la traduzione dell'operatore non può esserci una tale coda: ci sono sempre abbonati reali che diluiscono qualsiasi automazione.
Per il pratico, la conclusione è diretta: il proxy mobile viene acquistato non per la velocità, ma per la resistenza. La larghezza di banda per un indirizzo sarà probabilmente peggiore rispetto a quella di un data center — ma l'indirizzo non si esaurisce per sempre dopo il primo errore.
Brutte notizie: CGNAT e proxy hanno imparato a distinguersi
La tentazione di concludere "poiché dietro un indirizzo comune ci sono molte persone, fingiamo di essere un indirizzo comune" si scontra con la formulazione del problema nello studio stesso. Si noti la composizione del campione: gli indirizzi CGNAT e gli indirizzi VPN/proxy sono due classi diverse, e il modello è stato addestrato a distinguerli, non a raggrupparli in un'unica categoria di "molti utenti dietro un IP".
Si differenziano per caratteristiche che l'affittuario dell'indirizzo non controlla:
- Topologia. La traduzione dell'operatore è visibile nel percorso e nei registri di servizio — per l'intervallo 100.64.0.0/10, per PTR e WHOIS.
- Varietà di direzioni. Un vero quartiere della città si connette a migliaia di servizi diversi; un nodo per lo scraping — a decine, spesso a uno solo.
- Profilo per sottorete. L'aggregazione per /24 mostra se il blocco di indirizzi adiacente si comporta come un abbonato o come un pool affittato.
- Segnali dei clienti. Il set di dispositivi dietro un indirizzo comune deve apparire come una popolazione reale, non come lo stesso stack riprodotto cento volte.
Inoltre, questo non è esclusivo di Cloudflare: i fornitori di intelligence IP da tempo non forniscono un flag binario "proxy o no", ma una valutazione numerica — e la distinzione tra "indirizzo abbonato comune" e "pool affittato" è già incorporata in essa.
Tre conclusioni pratiche
- Riducete il carico sull'indirizzo, invece di aumentare la parallelità. Poiché un indirizzo comune è per definizione più vicino alla soglia del rate limit, la strategia "estrarre il massimo RPS da un IP" su di esso fallisce più rapidamente. Distribuite il compito nel tempo e su più indirizzi, non su flussi all'interno di uno solo.
- Proteggete la sessione. La resistenza di un indirizzo è una risorsa che si perde con un cambio aggressivo di IP: ogni nuovo indirizzo deve ripassare il controllo di fiducia. Per compiti con autorizzazione e carrello, una sessione sticky è quasi sempre più vantaggiosa della rotazione — dove passa il confine, è stato discusso nella guida sulle sessioni sticky.
- Contate non gli indirizzi, ma le risposte riuscite. Il pool di data center è più economico per indirizzo e quasi sempre più costoso per richiesta riuscita dove c'è una protezione seria. Ha senso confrontare i tipi solo in base al costo del risultato: gli indirizzi residenziali e mobili si ripagano proprio dove i data center non arrivano alla risposta.
Dove l'"effetto folla" non aiuta affatto
È importante non estendere la logica oltre i suoi limiti. La protezione contro le punizioni collettive funziona solo a livello dell'indirizzo di rete. Non appena la piattaforma passa ad altri identificatori, il vantaggio svanisce:
- Ban dell'account. Se l'azione è legata a un account, la qualità dell'IP non ha relazione con la decisione.
- Impronta del dispositivo e del browser. La coerenza dello stack viene verificata indipendentemente dall'indirizzo — e di solito si rompe prima che scatti il filtro IP.
- Collegamento degli account. Le piattaforme cercano sovrapposizioni tra sottoreti e corrispondenze comportamentali, non solo in base all'indirizzo esatto.
Un fattore separato del 2026 è l'offerta. Nel mese, il mercato ha subito due colpi alle fonti di indirizzi residenziali: a luglio LG ha annunciato il divieto degli SDK proxy, scoprendo che circa il 42% delle applicazioni nel suo negozio coinvolgevano la TV in una rete proxy, e il 3 agosto 2026 Samsung ha introdotto un divieto di piattaforma sugli SDK proxy residenziali e ha già limitato la registrazione di nuove applicazioni con tale funzionalità. La scoperta è stata descritta da Harrison Sand di Mnemonic in Norvegia; alcune applicazioni hanno dichiarato installazioni su centinaia di milioni di televisori. Un'analisi dettagliata della prima ondata è nel materiale riguardante il divieto degli SDK proxy sui televisori LG. Meno fonti di IP residenziali — maggiore è il prezzo, e tanto più evidente è il divario tra un indirizzo economico e uno che arriva effettivamente alla risposta.
Conclusione
Il CGNAT ha infranto la più basilare assunzione della protezione web — "un indirizzo equivale a un risponditore" — e la protezione lo ha riconosciuto e digitalizzato. Ma il riconoscimento non ha portato a un'amnistia, ma a una ristrutturazione delle misure: gli indirizzi dietro la traduzione dell'operatore vengono disattivati meno frequentemente e soffocati tre volte più spesso con limiti, e la loro differenza dai pool di proxy è stata portata a un compito di classificazione separato.
Il significato pratico per chi lavora tramite proxy è semplice: il tipo di indirizzo non determina se "passerete o meno", ma qual è il costo con cui il sito può fermarvi. Organizzate il lavoro attorno a misure più morbide — ritmo moderato, sessioni lunghe, calcolo onesto del costo di una richiesta riuscita — e scegliete il tipo di IP in base al costo dell'errore, non al costo del gigabyte.
```