Skip to content
Crafzo
Menu

IP lookup essentials

Why Does a Website Show the Wrong IP Address?

Troubleshoot why websites may show a different IP than expected, including VPNs, proxies, NAT, mobile networks, and IPv6.

Updated
Reading time
7 min read

Wrong address, or wrong location?

This guide is about the address itself: a website, a log file or a lookup tool shows an IP address that is not the one you expected, for example not the one your router or network settings display, not the one you saw yesterday, or one that belongs to a company you have never heard of. If the address is recognisably yours but the city or country shown for it is wrong, that is a different problem with different causes, covered in why an IP lookup shows the wrong location.

Almost every case comes down to one fact: there is more than one address between your device and the website, and different tools show you different ones. The sections below take those addresses in the order they appear on the way out.

The address on your device is not the one websites see

The address your device shows in its own settings, ipconfig on Windows or ip address show on Linux, is almost always a private address: something in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 (RFC 1918) for IPv4, or an fd00::/8 unique local address (RFC 4193) for IPv6. Those ranges are never routed on the public internet. Your router translates them to its single public address as traffic leaves, and that public address is what every website, lookup tool and server log records.

A lookup that shows an address different from your device's own is therefore working correctly; the public versus private IP guide explains the translation step, and the router's WAN or internet status page shows the public address it is using, which should match an IP lookup run from any device on the same network.

IPv4 and IPv6: two public addresses at once

Most connections today carry both IPv4 and IPv6, which means your network has two public identities. When a site is reachable over both, clients using the Happy Eyeballs algorithm (RFC 8305) start connections over both families in parallel and keep whichever answers first, which in practice usually means IPv6. An IPv6-enabled lookup tool therefore shows a long hexadecimal address while an IPv4-only site, or a server log that only records IPv4, shows the familiar dotted form. Both are yours; neither is wrong.

The IPv6 address also changes on its own. Devices generate temporary addresses with randomised interface identifiers and rotate them over time (RFC 8981), so a lookup today and one next week can show different IPv6 addresses inside the same prefix while the IPv4 address stays put. To see the two sides separately, run the IPv6 lookup alongside a normal lookup; the IPv4 versus IPv6 guide explains why the prefix, not the full address, is what identifies your network.

VPNs, proxies and privacy relays

A VPN replaces your public address with its exit server's address for everything that goes through the tunnel, so every website and lookup sees the exit, often in another city or country; a proxy configured in a browser or operating system does the same for the traffic that uses it, which is why one browser can show a different address from another on the same machine; and corporate laptops frequently route all traffic through a company gateway, so the address a website sees belongs to the employer.

Apple's iCloud Private Relay is the case people least expect. When it is on, Safari traffic is sent through two relays; the second relay generates a temporary address and connects to the site, so the website sees an address from the relay service's ranges rather than your network's. Apple states that the relay address maps to the user's region and, by default, to the nearest city, and that it may be shared by more than one user in the same area. A lookup from Safari on an iPhone can therefore show an address belonging to a relay provider while a lookup from another browser on the same Wi-Fi shows your own, and both are correct. The VPN verification guide covers how to confirm which address a tunnel or relay is presenting.

Mobile data, carrier NAT and shared addresses

A phone on cellular data does not use the home router at all. Its traffic leaves through the carrier's gateway, so the public address belongs to the carrier and changes as you move between regions, reconnect or switch between cellular and Wi-Fi. Carriers also share each public address among many subscribers behind carrier-grade NAT, typically using the 100.64.0.0/10 shared address space (RFC 6598) internally, so the address a website sees may also be in use by thousands of other customers at the same moment.

The address shown on cellular is therefore expected to differ from the one shown on Wi-Fi, and both differ from the address the phone displays in its own settings; a lookup of the cellular address describes the carrier gateway, not the handset, which the mobile carrier guide and the CGNAT guide explain.

When only one website shows a strange result

If every lookup tool agrees but one website shows a different address, the website is the likely cause. Sites behind a reverse proxy or CDN see the proxy's address on the connection and must read the real client address from a forwarded header; a site that reads the wrong field, or logs the connection address, will show its own proxy's address instead of yours. The X-Forwarded-For guide and the Cloudflare proxy guide describe both halves of that problem.

Caching produces the opposite error: a page that prints the visitor's address and is then cached by a CDN or a browser shows the address of whoever triggered the cached copy. Split-tunnel VPN configurations and browser extensions that proxy only some traffic explain most remaining cases where two applications on one device disagree.

Fast troubleshooting steps

Work from the inside out. Compare the address in your device settings with the one on the router's status page to separate private from public; run a lookup over IPv4 and IPv6 separately; turn off any VPN, proxy, Private Relay or privacy extension and compare again; then test from a second browser and a second device on the same network, and from mobile data to confirm the carrier address is simply different. If a single website still disagrees with everything else, the explanation is on their side, in the forwarded-header and caching causes above. A lookup that shows the address with its ISP and network type, such as the free IP checker, is the quickest way to tell whose address you are looking at: your provider's, your employer's, a VPN exit's or a relay service's.

Sources

  1. RFC 1918: Address Allocation for Private Internets
  2. RFC 4193: Unique Local IPv6 Unicast Addresses
  3. RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency
  4. RFC 8981: Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
  5. RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space
  6. Apple Support: About iCloud Private Relay
  7. Apple Developer: Prepare your network or web server for iCloud Private Relay
  8. Microsoft Learn: ipconfig
  9. ip-address(8) Linux manual page

Frequently asked questions

Keep reading