What Is IP Geolocation and Why Can It Be Wrong?

IP geolocation is the process of estimating the geographic location associated with an IP address. It can often identify a likely country, region or city, but an IP address does not inherently contain physical location information, and geolocation results should not automatically be treated as an exact description of where a person or device is located.

An IP address may appear to be in Singapore while the user is in Malaysia.

A newly transferred IPv4 block may still appear to be located in the country where it was previously used.

A mobile user may appear hundreds of kilometres away from their actual position.

Two IP geolocation databases may even return different cities for exactly the same address.

None of these situations necessarily means that the IP address itself is incorrect.

The difference exists because several distinct layers are involved:

IP addressing

registry records

BGP routing

network deployment

and:

third-party geolocation data

These systems describe different aspects of Internet infrastructure.

Understanding those differences explains why IP geolocation can be useful while still being imperfect.

What Is IP Geolocation?

IP geolocation is a method of associating an IPv4 or IPv6 address with an estimated geographic location.

A geolocation service may return information such as:

• country;
• region or state;
• city;
• time zone;
• latitude and longitude estimates;
• Internet service provider;
• organisation;
• network type; or
• Autonomous System Number.

Different providers offer different levels of detail.

The important word is estimated.

An IP address is fundamentally part of the Internet's addressing and routing architecture.

It was not designed as a GPS coordinate.

LARUS Foundation explains the underlying addressing system in What Is an IP Address and How Does It Work?.

Does an IP Address Contain a Physical Location?

No.

An IPv4 address such as:

203.0.113.25

does not contain a country code, city code or latitude.

Likewise, an IPv6 address does not inherently encode the physical address of its user.

The Internet Protocol uses addresses to help networks identify interfaces and route packets.

Geographic information is added by other systems that attempt to determine where those addresses are being used.

That distinction is fundamental:

An IP address is a network identifier. Geographic location is an interpretation associated with that identifier.

This is why the same IP address can be associated with a different geographic location over time without the numeric address itself changing.

How Does IP Geolocation Work?

There is no single universal global database that determines the physical location of every IP address.

Instead, geolocation providers can combine multiple sources of information.

Depending on the provider, these may include:

• Internet registry information;
• routing data;
• ISP information;
• network measurements;
• latency measurements;
• commercial datasets;
• user-supplied information;
• Wi-Fi or device observations;
• network topology;
• historical observations; and
• operator-published geolocation feeds.

Different companies use different methodologies.

That is one reason two databases can disagree.

Registry Data Is Not the Same as Geolocation Data

One common misunderstanding is that WHOIS or RDAP tells you where an IP address physically exists.

That is not necessarily true.

Regional Internet Registries maintain information associated with Internet number resources.

Depending on the registry and resource, this information can include:

• address range;
• registered organisation;
• administrative contacts;
• technical contacts;
• abuse contacts;
• resource status;
• and registration information.

LARUS Foundation explains this distinction in What Is IP Address Registration?.

Registration information describes the administrative relationship surrounding an Internet number resource.

It does not necessarily describe where every device using the address is physically located.

The RIPE NCC explicitly states that it is not a geolocation provider.

This distinction is particularly important for globally operated networks.

Registry Country vs Actual Network Location

Imagine a company is registered in the Netherlands.

It operates a public IPv4 block.

That same address space might be used by infrastructure located in:

• Germany;
• France;
• Singapore;
• Japan;
• or several countries simultaneously.

The organisation's registered location therefore does not automatically define the operational location of every address it controls.

Similarly, an address may be administered through one Regional Internet Registry while being routed or used elsewhere.

So these are different questions:

Which organisation is associated with this address?

and:

Where is this address currently being used?

A geolocation system that treats the first answer as the second can produce misleading results.

Why Can an IP Location Be Wrong?

There are many reasons.

Some relate to the network architecture.

Others result from the way geolocation databases collect and update information.

The most important causes include address reassignment, VPNs, mobile networks, CGNAT, corporate routing, cloud infrastructure and stale location records.

1. IPv4 Addresses Can Move Between Networks

IPv4 scarcity has created an increasingly active environment in which existing address space is reused.

An address block may originally have been used by:

Network A in Country A

and later be transferred or redeployed by:

Network B in Country B.

The registry information may be updated.

BGP routing may change.

RPKI may be updated.

The new network may begin using the addresses immediately.

But third-party geolocation databases may still associate the prefix with its previous location.

This can create a temporary mismatch:

Current network: Singapore
Registry information: Updated
BGP origin: Updated
Geolocation database: Germany

The address is not physically travelling from Germany to Singapore.

The network's operational use has changed while some external datasets have not yet caught up.

LARUS Foundation's 2026 IPv4 transfer analysis explains how address reuse increasingly forms part of the modern IPv4 lifecycle.

2. Reassignment Does Not Update Every Database at Once

There is no single button that instantly updates every commercial geolocation service worldwide.

A network operator can update:

• registry information;
• routing configuration;
• RPKI;
• IRR objects;
• reverse DNS;
• and operator-published data.

But independent geolocation providers operate their own databases and update schedules.

Some may recognise a change quickly.

Others may take longer.

This explains why one lookup service might correctly identify the new country while another still reports the previous one.

The problem is not necessarily inconsistency in the IP address.

It is inconsistency between independent information systems.

3. VPNs Can Change the Apparent Location

A Virtual Private Network can make a user's Internet traffic appear to originate from another network.

Suppose a user is physically in Kuala Lumpur.

They connect to a VPN server in Tokyo.

A website may see the public IP address of the Tokyo VPN server rather than the user's normal Malaysian Internet connection.

The geolocation result might therefore be:

Japan

even though the user's physical location remains:

Malaysia

In this case, the geolocation database may actually be correctly locating the network exit point.

What it is not doing is identifying the user's physical position.

This distinction matters.

4. Proxies Can Produce Similar Effects

Proxy services can also separate a user's physical location from the IP address seen by a destination service.

The user connects to a proxy.

The proxy then connects to the destination.

The destination sees the proxy's source address.

Its geolocation system therefore estimates the location associated with that network rather than necessarily identifying the original user's location.

VPNs, proxies and similar architectures are another reason an IP address should not automatically be treated as proof of physical presence.

5. Mobile Networks Can Be Difficult to Geolocate

Mobile networks can have complex architectures.

A smartphone may be physically located in one city while its Internet traffic exits through provider infrastructure somewhere else.

Mobile operators may use:

• central gateways;
• regional gateways;
• CGNAT;
• dynamic addressing;
• large shared address pools;
• and rapidly changing network assignments.

A user in one region may therefore appear to be located near a provider's network infrastructure rather than near the handset itself.

As users move, the relationship between network location and user location can become even more complicated.

6. Carrier-Grade NAT Can Hide Individual Users

Carrier-Grade NAT, commonly known as CGNAT, allows large numbers of customers to share a smaller pool of public IPv4 addresses.

Instead of every customer appearing on the public Internet with an individually unique IPv4 address, many users may share the same public address.

For example:

User A
User B
User C
User D

↓

CGNAT infrastructure

↓

198.51.100.20

A geolocation service sees the public address.

But that address may represent many users across a broad service area.

This limits how precisely the public IPv4 address can be associated with any one customer.

7. Dynamic IP Addresses Change Users

Many ISPs assign addresses dynamically.

An IPv4 address used by one household today could later be assigned to another subscriber.

The address may remain associated with the same general ISP network, but the exact user can change.

Therefore:

An IP address observed at one moment should not automatically be assumed to identify the same subscriber indefinitely.

This is important both for geolocation and for broader interpretations of IP address data.

8. Corporate Networks Can Centralise Internet Traffic

Enterprises often route traffic through central gateways.

Imagine a company has employees in:

• Bangkok;
• Jakarta;
• Kuala Lumpur;
• and Manila.

All corporate Internet traffic might exit through one security platform in Singapore.

External websites may therefore see employees from all four locations as:

Singapore

The geolocation may correctly identify the corporate network exit point.

It still does not identify the physical position of each employee.

9. Cloud Infrastructure Complicates Location

Cloud services make IP geolocation even more complex.

A company may operate workloads across several cloud regions while using:

• global load balancing;
• anycast;
• reverse proxies;
• content delivery networks;
• edge platforms;
• or bring-your-own-IP configurations.

The organisation associated with the address may be in one country.

The cloud platform may be headquartered in another.

The workload may be running in a third.

And the user may access it through an edge server in a fourth.

Which one is the "location" of the IP address?

That depends on what the geolocation provider is attempting to describe.

10. Anycast Can Make One IP Address Exist in Many Places Operationally

Anycast routing allows the same IP prefix to be announced from multiple locations.

Traffic is routed toward an appropriate instance according to BGP routing conditions.

Anycast is widely useful for infrastructure such as:

• DNS;
• CDNs;
• security services;
• DDoS protection;
• and distributed Internet services.

In an anycast architecture, asking for the single physical location of an IP address can be misleading.

There may be multiple legitimate network locations serving the same address.

The routing system determines which instance a particular user reaches.

This demonstrates again why:

network identity

and:

physical geography

are not always one-to-one relationships.

11. Different Databases Use Different Methods

There is no requirement that every commercial geolocation provider use the same algorithm.

One provider may rely heavily on:

• network observations;
• ISP submissions;
• and routing data.

Another may combine:

• commercial datasets;
• user observations;
• registry information;
• and historical patterns.

Another may update certain networks more frequently.

As a result:

Database A: Kuala Lumpur
Database B: Singapore
Database C: Johor Bahru

can all exist for the same address.

That disagreement does not mean three physical devices exist.

It reflects different inference methods.

What Is an IP Geofeed?

A geofeed is one mechanism that allows network operators to publish location information for their own IP prefixes.

RFC 8805 defines a CSV-based format through which an operator can map an IP prefix to coarse geographic information such as:

• country;
• region;
• and city.

For example, a conceptual entry can associate a prefix with:

MY, Johor, Johor Bahru

The purpose is to give geolocation consumers information directly from the network operator rather than requiring every database to infer deployment location independently.

RFC 8805 specifically notes that network operators may need to communicate location changes when prefixes move between locations, and consumers may incorporate geofeed data into broader geolocation processes.

How Are Geofeeds Discovered?

The IETF has also standardised mechanisms for finding geofeed information.

RFC 9632, published in 2024 and replacing RFC 9092, describes how geofeed references can be associated with Internet number-resource information and includes an optional mechanism using RPKI to authenticate geofeed data.

This creates an important distinction.

A network operator may publish a statement about where its prefixes are deployed.

A geolocation provider may consume that information.

But the provider can still combine it with other data.

Geofeed information is therefore a useful source, not necessarily a universal command to every geolocation database.

Can Geofeed Data Still Be Wrong?

Yes.

Operator-published data also needs to be maintained.

An enterprise could publish a prefix as being located in London and then move the deployment to Frankfurt without updating its feed.

The network operator is closer to the operational reality, but that does not eliminate the need for data maintenance.

RFC 8805 therefore discusses both authority verification and accuracy checking when consuming geofeed information.

Accurate geolocation remains a shared data-quality problem.

IP Geolocation vs WHOIS and RDAP

IP geolocation, WHOIS and RDAP should not be treated as interchangeable.

These systems can contain related information.

But each solves a different problem.

For example:

RDAP: Organisation A
BGP: AS64500
RPKI: AS64500 authorised
Geolocation: Singapore
Actual user: Malaysia

All of those statements could potentially coexist without contradiction.

They describe different layers.

This is why LARUS Foundation treats accurate registry data as important while also distinguishing registry information from routing and other operational data.

Does RDAP Tell You Where an IP Address Is Located?

Not reliably in the geographic sense most users expect.

RDAP is designed to provide structured registration information.

It can help answer questions such as:

• Which address range contains this IP?
• Which organisation is associated with the resource?
• Which registry provides the authoritative registration response?
• What contacts or entities are associated with it?

It is not designed as a GPS system.

A country or address appearing in registration data may refer to the organisation associated with the resource rather than the physical position of the device using it.

This is a major source of confusion in online IP lookup tools.

Can an IP Address Reveal an Exact Home Address?

Generally, an ordinary public IP lookup should not be expected to reveal someone's exact home address.

IP geolocation may estimate:

• country;
• region;
• city;
• or network area.

But several architectural factors prevent a simple one-to-one relationship between public IP and exact physical residence:

• NAT;
• CGNAT;
• dynamic address assignment;
• mobile networks;
• VPNs;
• corporate gateways;
• proxies;
• and imperfect geolocation databases.

Internet service providers may hold subscriber records that create a more specific relationship between an assigned address, a time period and an account.

That is different from public IP geolocation.

The two should not be confused.

Why Country-Level Geolocation Is Usually Easier Than City-Level Geolocation

In general, broader geographic estimates are easier than extremely precise ones.

Determining that a prefix is likely being used in:

Japan

is a less demanding problem than deciding whether it is located in:

Tokyo

versus:

Yokohama.

City-level inference requires more detailed data.

The smaller the geographic target, the easier it becomes for:

• network topology;
• provider architecture;
• mobile gateways;
• VPNs;
• shared prefixes;
• and outdated data

to produce incorrect conclusions.

This is why a geolocation service should ideally communicate its confidence and granularity rather than presenting every result as equally precise.

Why IPv4 Transfers Can Create Geolocation Problems

IPv4 transfers deserve special attention because IPv4 addresses can have long histories.

Consider a hypothetical /24.

Stage 1

The prefix is used by a hosting company in the United States.

Geolocation databases learn:

United States

Stage 2

The block is transferred to another organisation.

Registry information changes.

Stage 3

The new holder deploys it in Singapore.

BGP now announces the prefix through a different network.

Stage 4

Some geolocation databases detect the change.

Others continue reporting:

United States

The address block is operationally valid.

The registry may be accurate.

The routing may be correct.

But some third-party datasets remain stale.

This is one of the practical challenges of address reuse.

LARUS Foundation's IPv4 transfer data analysis highlights why transfer completion and operational deployment are related but distinct stages.

Why This Matters More as IPv4 Is Reused

The IPv4 ecosystem increasingly depends on redistribution.

Addresses move through:

previous deployment

→ transfer or reassignment

→ registry update

→ routing preparation

→ new deployment

The address number stays the same.

Its operational context changes.

Third-party data therefore has to follow the resource through that lifecycle.

Geolocation is one example.

Other information that may also need updating includes:

• reverse DNS;
• reputation data;
• routing authorisations;
• IRR information;
• security policies;
• customer allowlists;
• and abuse contacts.

Address reuse works best when the surrounding information can accurately follow the new operational reality.

How Wrong IP Geolocation Can Affect Users

An incorrect location can create visible problems.

Wrong Language or Website Version

A website may automatically show content intended for another country.

Streaming Restrictions

A streaming service may believe a customer is in the wrong licensing region.

Fraud Detection

A security system might flag a login because the IP appears to originate from an unexpected country.

Payment Services

Transaction-monitoring systems may compare account information with IP geolocation.

An incorrect location can contribute to additional verification.

Search Results

Search services may return information intended for the wrong city or country.

Advertising

Location-based advertising may target the wrong market.

Access Control

Some enterprises restrict services according to geographic rules.

Incorrect geolocation can cause legitimate users to be denied access.

Content Delivery

Incorrect geographic assumptions may influence which server or service location is selected.

This can affect performance.

Should IP Geolocation Be Used for Security Decisions?

It can be one signal, but relying on it as the only signal can create problems.

Suppose a security system says:

Block every login whose IP address is outside Malaysia.

That may sound simple.

But a legitimate user could be:

• travelling;
• connected through a corporate VPN;
• using a mobile provider with an overseas gateway;
• or using an address incorrectly geolocated by the database.

Likewise, an attacker can use infrastructure located inside an allowed region.

Therefore, IP location should usually be considered alongside other signals such as:

• authentication;
• device information;
• behavioural patterns;
• account history;
• risk scoring;
• and transaction context.

Geolocation can add context.

It should not be mistaken for proof of identity.

Geolocation Is Not Identity

This distinction is particularly important.

An IP address can contribute to a network identity.

It can be stable enough to appear in:

• allowlists;
• routing policies;
• customer systems;
• APIs;
• firewalls;
• and security platforms.

But that does not mean the address uniquely identifies a human being.

Likewise:

IP geolocation ≠ personal identity

and:

IP geolocation ≠ exact physical presence.

These concepts may overlap operationally, but they are not the same technical property.

What Can Network Operators Do When IP Geolocation Is Wrong?

Operators deploying address space in a new location can take several steps.

1. Keep Registry Information Current

Ensure the relevant organisation, contacts and resource information accurately reflect the current administrative relationship.

LARUS Foundation's guide to registry-data accuracy explains why this is important for wider Internet coordination.

2. Publish a Geofeed

Operators can consider publishing location information following RFC 8805.

This gives data consumers an operator-supplied indication of where prefixes are intended to be geolocated.

3. Publish a Discoverable Geofeed Reference

RFC 9632 describes the current standards-track mechanism for finding and optionally authenticating geofeed information.

4. Contact Major Geolocation Providers

Many commercial databases provide correction processes.

An operator should be prepared to provide information showing:

• the affected prefix;
• the correct deployment location;
• the operating organisation;
• and evidence that it is authorised to speak for the resource.

5. Check Multiple Databases

Do not assume one provider represents the entire ecosystem.

Testing several commonly used databases can reveal whether an error is isolated or widespread.

6. Monitor After an IPv4 Transfer

Geolocation should be included in post-transfer operational checks alongside:

• BGP;
• RPKI;
• IRR;
• reverse DNS;
• reputation;
• and registry information.

7. Plan Before Moving a Prefix

If a known prefix is moving between countries or regions, operators can prepare location information before the migration rather than waiting for customer complaints afterward.

RFC 8805 specifically describes geofeeds as a way for operators to communicate location changes instead of waiting for external geolocation algorithms to learn them over time.

A Practical IP Geolocation Checklist for Network Operators

When deploying or acquiring an address block, operators should check:

Registry

• Is the organisation information current?
• Are operational contacts correct?

Routing

• Is the expected ASN originating the prefix?
• Is the deployment visible through BGP?

RPKI

• Does the ROA match the intended routing configuration?

Geolocation

• Do major databases show the correct country?
• Is city-level data reasonable?
• Are old deployment locations still appearing?

Geofeed

• Is operator-supplied location data available?
• Is it current?

Reputation

• Are previous abuse or spam associations still present?

DNS

• Is reverse DNS configured appropriately?

Applications

• Are customers reporting geographic restrictions or unexpected localisation?

This wider review helps distinguish a routing issue from a data-quality problem.

Accurate Registry Data Does Not Guarantee Accurate Geolocation

This is one of the most important conclusions.

A network can have:

correct registry information

correct BGP announcements

correct RPKI

and:

incorrect third-party geolocation.

That does not reduce the importance of registry accuracy.

It simply shows that each data layer has a different responsibility.

Registry information should accurately describe the administrative relationship around the resource.

BGP should accurately reflect network reachability.

RPKI should accurately describe authorised route origins.

Geolocation systems should attempt to represent geographic deployment.

Keeping these layers aligned improves operational clarity.

Treating one layer as a replacement for all the others creates confusion.

Frequently Asked Questions

What is IP geolocation?

IP geolocation is the process of estimating the geographic location associated with an IPv4 or IPv6 address.

Does an IP address contain location information?

No. The numeric IP address itself does not inherently encode a person's physical location. Geographic information is associated with the address using external data and inference.

Why is my IP address showing the wrong location?

Possible reasons include outdated geolocation databases, IPv4 transfers, dynamic IP assignment, mobile-network architecture, VPNs, proxies, CGNAT, corporate gateways and cloud infrastructure.

Why does my IP show another city?

Your traffic may exit through ISP infrastructure located elsewhere, or the geolocation provider may only know the approximate location of the broader address block.

Why does my IP show another country?

A prefix may have been transferred or redeployed, your traffic may be passing through a VPN or proxy, or the geolocation database may contain outdated information.

Can an IP address show someone's exact home address?

Usually not through ordinary public geolocation. IP geolocation is generally an estimate of network geography and should not automatically be treated as an exact residential address.

Is WHOIS the same as IP geolocation?

No. WHOIS and RDAP provide registration information associated with Internet resources. Geolocation services attempt to estimate where an address is being used.

Does RDAP show the physical location of an IP?

Not necessarily. RDAP provides registration information. An organisation's registered address does not automatically represent the physical deployment location of every IP resource associated with it.

What is a geofeed?

A geofeed is operator-published information mapping IP prefixes to coarse geographic locations. RFC 8805 defines a common geofeed format.

Can an ISP correct IP geolocation?

Operators can publish accurate geofeed information, maintain registry data and submit corrections to geolocation providers, but independent database operators ultimately maintain their own datasets.

Why do different IP geolocation websites show different locations?

They can use different datasets, algorithms, observations and update schedules.

Does VPN use change IP geolocation?

A VPN commonly changes the public source IP address visible to a website. The website may therefore geolocate the VPN exit server instead of the user's actual physical location.

Does CGNAT affect geolocation?

Yes. CGNAT can cause many customers to share one public IPv4 address, making the address a poor indicator of an individual user's precise location.

Can IPv4 transfers cause incorrect geolocation?

Yes. A transferred prefix can be deployed in a different country while some geolocation databases continue associating it with its previous use.

Is IP geolocation accurate enough for security?

It can be useful as one risk signal, but it should generally not be treated as definitive evidence of identity or exact physical presence.

Conclusion

IP geolocation is useful because Internet services often need some understanding of network geography.

It can help with:

• content localisation;
• traffic optimisation;
• fraud analysis;
• advertising;
• regional services;
• and network operations.

But its usefulness depends on understanding what it actually represents.

An IP address does not inherently contain a physical location.

Instead, geolocation systems create an estimate by combining information about networks, routing, operators, observations and historical usage.

That estimate can become inaccurate when:

addresses move

networks change

users share addresses

traffic exits elsewhere

or:

databases become stale.

This is particularly important in the modern IPv4 environment.

As scarce address space is increasingly transferred, reassigned and redeployed, the numeric resource can remain unchanged while its operational geography changes completely.

The correct response is not to conclude that IP geolocation has no value.

It is to understand its limits.

For network operators, good practice means keeping multiple layers accurate:

registry records

→ routing

→ RPKI and related authorisations

→ operator-published geolocation data

→ third-party geolocation databases

These systems should support one another, but they should not be confused with one another.

The broader principle is simple:

An IP address identifies a point in network addressing and routing. Geography is contextual information associated with that address, not an intrinsic property of the number itself.

The more clearly Internet services understand that distinction, the more accurately they can use geolocation data without turning an estimate into a false statement of physical reality.