Your IP, reverse DNS, and X-Forwarded-For: what servers see

Open a page that claims to know where you are and it feels like a parlor trick. It isn't — it's mostly your IP address, a header or two, and a database, and every step carries more uncertainty than the confident little map suggests. Here is what a server actually learns when you connect, and what it only guesses.

Your machine doesn't know its own public IP

This surprises people. The address on your laptop's interface is almost always a private one — something in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16, the ranges reserved for private networks by RFC 1918. Those addresses are not routable on the public internet. Your router performs NAT (network address translation), rewriting the source address of outbound packets to its own public IP. So the only thing that can tell you how you look from outside is a server with a public address that you've connected to.

It can get further removed. Many ISPs run carrier-grade NAT (CGNAT), where your router's WAN side is itself a private-ish address from 100.64.0.0/10 — the shared address space reserved by RFC 6598. You then share one public IP with many other subscribers. That's the simplest reason to ask a server: behind a NAT, your egress address is genuinely unknowable from inside. You can check yours at our connection inspector, or from a script:

curl https://exl.ink/api/ip

Reverse DNS: what the PTR record reveals

Forward DNS maps a name to an address. Reverse DNS goes the other way, mapping an IP back to a name via a PTR record, looked up under the special in-addr.arpa domain for IPv4 (and ip6.arpa for IPv6). The reverse DNS lookup overview covers the mechanics.

For most home connections the PTR is set by the ISP and leaks only coarse hints — the provider, sometimes a region, sometimes nothing. Something like 203-0-113-45.dyn.example-isp.net tells you the carrier and that it's a dynamic pool, not who you are. Two things are worth knowing: a PTR is controlled by whoever owns the IP block, not by you, and forward and reverse records don't have to agree. Anyone can publish a PTR claiming to be google.com; it means nothing unless the forward record for that name resolves back to the same IP. That round-trip check is forward-confirmed reverse DNS, and it's the only version worth trusting.

X-Forwarded-For is a hint, not a fact

When you sit behind a reverse proxy or CDN, the origin server's TCP connection comes from the proxy, not from you. To preserve the client address, proxies add the X-Forwarded-For header — a comma-separated list, leftmost being the claimed original client, each later entry a proxy in the chain. The standardized equivalent is the Forwarded header, with structured for, by, and proto parameters, though X-Forwarded-For remains far more common in the wild.

The critical part: a header is just bytes the client sends. Any client can put X-Forwarded-For: 1.2.3.4 on its own request. The MDN guidance is blunt: any security-related use must rely only on addresses added by a proxy you control, and if your server can be reached directly from the internet, no part of the list is trustworthy. Leftmost values are only safe where a spoofed answer does no harm.

The leftmost address is the easiest to read and the easiest to forge. Don't rate-limit, allow-list, or audit on a value an attacker can type.

In practice that means counting back a known number of trusted hops from the right, or skipping a known set of proxy IPs — never taking the leftmost entry at face value. For analytics, where a wrong answer just skews a chart, the leftmost non-private IP is fine. For anything that gates access, it is not.

Geolocation is a probability, not a pin

An IP doesn't carry coordinates. Geolocation is a lookup against a commercial database that maps address blocks to places, built from registry data, ISP hints, and inference. Country-level accuracy is high — MaxMind reports above 99% — but city-level accuracy commonly lands in the 20–75% range, better in dense metros and worse in rural areas. A suburban visitor often resolves to the nearest large city or the ISP's regional hub.

CGNAT, VPNs, mobile carriers that route traffic through a few gateways, and corporate egress all smear the result further. When a map drops a precise marker on your house, that precision is theater — the honest output is a city or region with a confidence radius, and even that can be flatly wrong.

IPv6 changes the shape of the problem

IPv4 scarcity is why NAT exists at all. IPv6 has enough addresses that every device can hold a globally routable one, so there's often no NAT in the path — the address the server sees can map to a single machine rather than a shared household exit. That's better for reachability and worse for privacy: a stable IPv6 address is a cleaner identifier. Privacy extensions — temporary addresses that rotate — exist to blunt this and are on by default in most modern systems.

Either way, your IP is sent automatically with every request and is available to any server and any third party loaded on a page. As the EFF's Behind the One-Way Mirror puts it, every request you make over the internet contains your IP — a foundational tracking signal precisely because it's baked into the protocol rather than something a browser setting can switch off. A VPN or Tor replaces it; clearing cookies does not.

What this means in practice

Want your real egress IP? Ask a public server — your own machine can't tell you behind any NAT.
Treat reverse DNS as a weak hint, and only trust it forward-confirmed.
Never make a security decision on X-Forwarded-For unless your own proxy set the value.
Read geolocation as country-confident, city-maybe — never as an exact location.

The connection inspector shows exactly these fields and nothing more — the IP, the PTR, the forwarded header, the country guess — so you can see the gap between what's measured and what's inferred. It's rate-limited and best-effort, and we don't log it. Refresh the page and it's gone.