IP Geolocation Shows the Wrong Country? How to Fix It

A new IP address shows the wrong country because geolocation databases still hold data from the range’s previous holder or its original registration. They don’t reflect how you use it today. The fix? Publish your own location data in a geofeed, then ask the lookup services to refresh their records. So if you bought or leased addresses for one country and the lookup tools put them somewhere else, this guide covers why IP geolocation shows the wrong country, how to confirm it, how the geofeed fix works and what to do while you wait.

Why does a new IP address show the wrong country?

The registry doesn’t assign geolocation. Third-party databases work it out, and they always run a step behind when a range changes hands or gets used differently. The usual suspects:

• the previous holder’s location is still cached in the provider’s records,
• the registry country field shows the organisation’s address, not where the addresses actually live,
• the range was carved out of a bigger block registered somewhere else,
• the provider guessed a location from routing paths and infrastructure data.

Every lookup tool builds and maintains its own dataset. So two tools can disagree about the same address. And fixing one doesn’t fix the rest (people get tripped up by this all the time).

How to confirm an IP location mismatch before you change anything

Don’t touch anything yet. First check several independent lookup tools and the registry record, so you know whether the error sits in one outside database or in your own data. I’d go in this order:

1. Query the range in several lookup tools and note what each one returns.
2. Open the inetnum object in the RIR database and read its country, org and remarks fields.
3. Check whether a geofeed is already referenced, either as an attribute or as a remarks line.
4. Write down which tools are wrong and which country they report.

That list is your baseline. You’ll need it later. And next time, checking a clean IP range before you pay for it will surface location conflicts while you can still walk away. Cheaper that way, right?

What is a geofeed (RFC 8805) and why does it fix the problem?

A geofeed is a plain CSV file. The IP holder publishes it, and it states the intended location of each prefix in the format defined by RFC 8805. Each line opens with a prefix, then a country code, a region, a city and a postal code. The last fields can stay empty if you don’t want to go that granular. Geolocation providers can then read the holder’s own statement instead of guessing from routing or stale records. One catch, though. Only the IP holder, or whoever controls the registry object, can publish a geofeed that counts, because the link to it has to come from that object.

How to link a geofeed to your RIPE inetnum object

You point to the geofeed from the inetnum object. There are two ways: a dedicated geofeed: attribute or, where the registry doesn’t support one, a remarks: line starting with the case-sensitive token “Geofeed ” followed by an HTTPS URL. Case-sensitive means exactly that. According to the RFC 9632 geofeed specification, the URL must point to a single RFC 8805 geofeed file and must use HTTPS. In practice a RIPE inetnum geofeed comes down to three steps:

1. Host the CSV file at a stable HTTPS address.
2. Add the geofeed attribute or the remarks line to the inetnum object.
3. If you only lease the range, ask the IP holder or LIR to make the change for you.

Getting lookup services to pick up the IP geolocation database update

Once the geofeed is live, send a correction request to every geolocation provider that has it wrong, and point them to the geofeed and the registry object. But check first that both sources agree. If the inetnum country, the geofeed and your routing each tell a different story, the reviewer has to guess. And guessing slows corrections down. After that, recheck the range with the same tools you used during diagnosis and compare against your baseline. Still showing the old country? That tool gets its own follow-up request.

What to do while the location is still wrong

Databases take their time. Until they catch up, lean on signals you control, like page language, domain structure and hosting choice, not on IP location alone. Search engines weigh these together, and the trade-offs between a ccTLD, subfolder or hosting setup decide how clearly a site is tied to a market. Jalvo is an NGINX reverse proxy with IP addresses from the EU and the USA, plus geotargeting through a panel where you point your domains. If an origin server needs to appear from a specific region, geolocation targeting with proxy IPs is one way to handle it while the correction works its way through.

So, next step: open the inetnum record for your range, then publish a geofeed (or ask the holder to reference one) before you file a single correction request. Order matters here. Get it right and you fix an IP geolocation wrong country problem for good, not one lookup tool at a time.

FAQ