Public IP identification
The address a website sees arriving is not necessarily the IP configured on your computer. Between your device and the server there is at least one router doing NAT, and sometimes an entire chain of proxies noting each hop along the way.
It never leaves the local router without going through NAT; no server on the internet can address that number directly.
Any client can send this header already carrying a forged IP up front; only the segment written by a proxy you control is safe to use for a decision.
2001:db8::/32 exists only for written examples; it looks like a real public IPv6, but no router forwards traffic there.
The nginx instance that receives your connection on jkit.tools knows your real IP and forwards it to the Next.js container via X-Real-IP. Our API reads that header and returns it. We do not use external APIs.
Because most ISPs assign the IP via DHCP with a temporary lease, not a fixed address; restarting the connection can hand back a different address from the available pool.
Yes. It is just an HTTP text header; any client can send it with any content. It only becomes trustworthy from the point where a proxy you control overwrites or appends the value.
IPv4 uses 32 bits, about 4.3 billion possible addresses, exhausted at the regional registries years ago. IPv6 uses 128 bits, a far larger space, and skips NAT because every device can have its own public address.
Yes, on a typical IPv4 network. The router NAT translates traffic from every LAN device to the single public IP the ISP assigned to the connection, so an outside website sees the same address coming from the phone and the computer.
Your IP and headers come straight from our own server (behind our nginx). To automatically check the secondary protocol (IPv4 or IPv6), the browser queries a public IP-echo service; no other data is sent. We do not call fingerprinting APIs or geolocation providers.