Torna al blog

Proxy "Germania": come funziona realmente la geolocalizzazione IP vedendo i Paesi Bassi

L'indirizzo IP non ha coordinate: il geo è l'opinione di un database specifico. Analizziamo le misurazioni fresche del 2026, perché MaxMind, IPinfo, IP2Location e DB-IP divergono tra loro, perché un sito dietro Cloudflare vede un paese, mentre il checker ne vede un altro, e cosa fare quando il proxy "viene identificato dal paese sbagliato".

📅20 settembre 2026
Proxy "Germania": come funziona realmente la geolocalizzazione IP vedendo i Paesi Bassi

Uno scenario che si ripete per chiunque lavori seriamente con i proxy. Prendi un IP residenziale con geo "Germania". Apri un checker — e lui scrive onestamente Germania, Francoforte. Accedi al sito target — e questo mostra la valuta olandese, l'output olandese e il banner dei cookie olandesi. Un secondo checker dice che l'IP è in Belgio. Chi sta mentendo?

Nessuno. Il problema è che un indirizzo IP non ha coordinate. La geo-localizzazione non è una caratteristica dell'indirizzo, ma un'opinione di un database specifico, che ha raccolto informazioni in modo indiretto. Ci sono diversi database, sono indipendenti e divergono — in modo sistematico e prevedibile. Di seguito analizzeremo da dove provengono questi dati, quanto è grande l'errore reale secondo le misurazioni recenti e cosa fare in pratica.

Un IP non ha geografia — ci sono solo stime

Nel pacchetto non c'è un campo "paese". Tutto ciò che internet sa riguardo all'indirizzo è a chi è assegnato secondo i documenti del registrar e dove portano i percorsi BGP. Da questo, i database commerciali (MaxMind, IPinfo, IP2Location, DB-IP e altri) raccolgono supposizioni, combinando cinque fonti:

  • Registrazioni RIR e whois. Il paese nella registrazione è la giurisdizione dell'organizzazione a cui è assegnato il blocco, non il luogo in cui si trovano fisicamente i server. Un provider tedesco può tranquillamente distribuire indirizzi ad Amsterdam.
  • Geofeed. Il formato dei dati geo-pubblicati è definito dall'RFC 8805 (2020), sostituito nel 2024 dall'RFC 9632 — con validazione e rilevamento tramite RDAP. L'operatore dichiara dove si trova la sua sottorete. Questa è l'unica fonte autorevole, ma la copertura è misera: entro la fine del 2023, i geofeed hanno pubblicato circa 2.800 sistemi autonomi — circa 34 milioni di indirizzi IPv4, ovvero lo 0,8% delle assegnazioni globali.
  • Routing e prefissi BGP. Se si sa dove si trova un indirizzo, il database estrae informazioni per l'intero prefisso. Da qui proviene la maggior parte degli errori.
  • Misurazioni di latenza. La triangolazione basata sul RTT da punti noti — funziona bene nelle città dell'Europa densa, ma fallisce dove ci sono pochi punti di misurazione.
  • Dati dei partner. Segnali provenienti da applicazioni e servizi che associano IP a coordinate GPS dei dispositivi.

Ogni fornitore mescola questi dati secondo le proprie proporzioni e regole. I risultati non devono necessariamente coincidere.

Quanto è grande l'errore: misurazioni del 2026

Il 21 maggio 2026, i ricercatori della Virginia Tech (Syed Tauhidun Nabi, Jocelyn Bliton, Tijay Chung, Shaddi Hasan) hanno pubblicato un lavoro intitolato "Lost in the Prefix: Revisiting IP Geolocation Accuracy Across Networks and Geographies". Hanno confrontato quattro database — MaxMind GeoLite2, IPinfo, IP2Location DB11 e DB-IP Lite — con un campione di 16.010 sonde RIPE Atlas in 175 paesi e 21.292 coppie "IP — scuola" dal progetto UNICEF Giga. In totale, 37.302 osservazioni, di cui il 74,7% IPv4 e il 25,3% IPv6.

Numeri chiave:

  • Reti fisse: errore mediano di 3–16 km a seconda del provider. Per internet domestico via cavo in un paese sviluppato, la geo-localizzazione funziona bene.
  • Reti mobili: errore mediano di 179–207 km. Questo è più di dieci volte il divario rispetto alle reti fisse, ed è lo stesso per tutti e quattro i database.
  • Percentuale di errori grossolani (oltre 100 km) per regione: Europa 9–20%, Americhe 8–22%, Asia 53–61%, Africa 66–72%.
  • Motivo: circa il 70% dei prefissi mobili si estende fisicamente per oltre 100 km. Più grande è il prefisso, maggiore è l'errore — indipendentemente dal fornitore, dal tipo di rete e dalla regione.

Un dettaglio importante: tutti e quattro i database commettono errori in modo abbastanza simile e negli stessi luoghi. Non si tratta di "fornitore cattivo contro fornitore buono" — è una limitazione comune del metodo. Nei paesi del Sud Globale, ci sono da 2 a 3 volte più prefissi "grossolani", quindi anche gli errori sono maggiori.

MaxMind stesso definisce i suoi limiti onestamente: 99,8% di accuratezza a livello di paese, circa 80% a livello di stato/regione negli Stati Uniti e 66% a livello di città — dove "città" significa rientrare in un raggio di 50 km. Si specifica inoltre che gli indirizzi nelle reti mobili sono utilizzati da telefoni a grande distanza, e nel caso di VPN o proxy il database geo-localizza il server, non l'utente finale.

Perché il checker e il sito vedono cose diverse

Qui si nasconde la chiave dello scenario iniziale. Il checker che hai aperto mostra i dati del suo database. Il sito target guarda nel suo. Queste sono risposte diverse alla stessa domanda, e entrambe sono "corrette" nel loro sistema di coordinate.

Tre meccanismi specifici di divergenza:

  • Diverse forniture. Un sito dietro Cloudflare ottiene il paese dall'intestazione CF-IPCountry — questi sono dati proprietari di Cloudflare, e spesso divergono da ciò che MaxMind restituisce nello stesso momento per lo stesso indirizzo. I servizi di streaming e i sistemi di pagamento mantengono liste proprie, arricchite dalla storia del comportamento.
  • Età dei dati diversa. I GeoLite2 City e Country gratuiti vengono aggiornati due volte a settimana — il martedì e il venerdì. I GeoIP2 commerciali vengono rilasciati ogni giorno lavorativo. Un sito basato su un database di un anno fa vedrà un quadro dell'anno precedente. Questo spiega anche perché nuove sottoreti "si stabilizzano" per settimane.
  • Differente livello di dettaglio. I fornitori hanno politiche diverse: alcuni forniscono la città, altri arrotondano consapevolmente a regione o paese se la certezza è bassa. L'assenza della città non è un errore, ma un rifiuto di indovinare.

Quattro situazioni in cui la divergenza è quasi garantita

  1. Proxy mobili. Il caso peggiore per definizione: CGNAT, un prefisso che copre metà paese, errore mediano vicino ai 200 km. Richiedere un'accuratezza cittadina da un IP mobile è inutile — la rete non è progettata in questo modo. È anche utile verificare se l'IP è effettivamente mobile e non un data center con un ASN falsificato: l'analisi della metodologia è nel materiale come distinguere un vero proxy 4G da un ASN falso.
  2. Blocchi rivenduti e trasferiti. Dopo il trasferimento di una sottorete IPv4 a un nuovo proprietario, il vecchio paese rimane nei database per mesi. Il mercato degli indirizzi secondari è attivo, quindi questo è un fenomeno comune, non un'eccezione.
  3. Anycast e cloud. Lo stesso prefisso viene annunciato da decine di punti nel mondo. Il database è costretto a ridurre tutto a una sola posizione — e qualsiasi scelta sarà errata per la maggior parte delle richieste.
  4. Registrazione presso la sede centrale. Il provider è registrato in un paese, ma mantiene l'infrastruttura in un altro. Il database utilizza i documenti, perché non ci sono altri dati.

Cosa fare in pratica

  1. Controlla dove è importante, non nel checker. L'unico test significativo è aprire il sito target e vedere quale paese e valuta mostra. Se l'obiettivo è l'output locale di Google o i prezzi regionali, il checker non è affatto un criterio di accettazione.
  2. Confronta almeno tre database. Se MaxMind, IPinfo e DB-IP sono d'accordo — è molto probabile che anche il sito target vedrà la stessa cosa. Una divergenza tra di loro è un segnale che l'indirizzo è discutibile e ci saranno problemi.
  3. Separa i requisiti "paese" e "città". Il paese presso un provider affidabile è sicuro (99,8% secondo MaxMind). La città è una grandezza probabilistica con un raggio di circa 50 km anche nel migliore dei casi. Costruire una logica aziendale sulla città è possibile solo con un margine di errore.
  4. Guarda al prefisso, non all'indirizzo. Controlla whois e la dimensione del blocco annunciato. Se l'IP è in /16, esteso su metà paese, non ci sarà un'accuratezza precisa per nessuno.
  5. Non confondere geo con reputazione. Un paese corretto non dice nulla riguardo al fatto che l'indirizzo non sia contrassegnato come proxy. Questa è una verifica separata su database distinti — trattata in dettaglio nel materiale riguardante i miti sul "clean" IP e i checker di reputazione.
  6. Chiedi al provider riguardo al geofeed. Se l'operatore della sottorete ha pubblicato un geofeed secondo l'RFC 9632, paese e città provengono da lui stesso, non da supposizioni. Questo è l'argomento più forte a favore di un pool specifico. Le correzioni tramite geofeed vengono importate e verificate da MaxMind una volta al giorno lavorativo, le correzioni singole — in 1–2 giorni lavorativi, dopo di che entrano nella prossima release del database.

Come questo influisce sulla scelta del tipo di proxy

Dalle misurazioni emerge una regola semplice. Se il compito richiede una geografia precisa — output locale del motore di ricerca, prezzi regionali, pubblicità geo-targetizzata — prendi proxy residenziali su linee fisse: qui l'errore mediano è misurato in unità di chilometri. Se il compito richiede fiducia nella piattaforma riguardo al tipo di rete — social media, messaggeri, applicazioni mobili — prendi proxy mobili, ma considera che il punto sulla mappa varierà all'interno della regione. Combinare entrambe le esigenze in un solo IP non sarà fisicamente possibile: è una limitazione dell'architettura delle reti mobili, non della qualità del pool.

Per le regioni con una alta percentuale di errori grossolani — Asia, Africa — pianifica a livello di paese, non di città. Qui, secondo i dati della ricerca, ogni secondo o terzo indirizzo si allontana dal luogo reale di oltre cento chilometri per qualsiasi fornitore.

Conclusione

"Il paese non è quello corretto" quasi mai significa che sei stato ingannato con il proxy. Più spesso significa che hai confrontato le risposte di due database diversi e ti sei sorpreso che non coincidessero. L'ordine corretto delle azioni: scoprire quale database legge la piattaforma target, controllare la geo proprio su di essa, confrontare indirizzi discutibili su più fonti e non richiedere dalle reti mobili un'accuratezza cittadina che non hanno e non avranno.

E tieni a mente il numero principale di quest'anno: 3–16 km su linee fisse contro 179–207 km su mobili. Questo spiega gran parte delle lamentele riguardo alla geo nei proxy ancora prima che tu apra un ticket di supporto.