FIELD NOTE 03 / WHAT THE SERVER SEES
WHAT YOUR PUBLIC IP
ACTUALLY SAYS.
A website sees the address that delivered your request to it. That can be useful. It is not a dossier on your network, your device, or the people using your connection.
01 / THE SHORT VERSION
A server receives an address, not your whole network.
When your browser asks for a page, the server needs a source address so it can send the response back. On a typical home connection, that is your router's public IPv4 address or your device's public IPv6 address. The server can log that address if it chooses. It does not receive a map of your home network with the request.
02 / NAT CHANGES THE VIEW
Several devices can look like one public address.
Most home IPv4 networks use network address translation, usually called NAT. Your laptop may be `192.168.1.42`, while your phone is `192.168.1.57`; neither address is routed on the public Internet. Your router translates their connections to its public address. A website on the other end commonly sees the router's public address for both devices.
That is why an IP address is a poor way to identify a person. A household, office, hotel, school, or mobile carrier can put many people behind one address. The address can also change when an ISP renews a connection.
03 / A VPN MOVES THE EXIT
The website sees the VPN provider's egress address.
With a VPN, your browser normally sends traffic through the VPN provider before it reaches the website. The website then sees the provider's exit IP address, not the public address assigned by your ISP. That changes what the destination sees. It does not make the request invisible to every party involved: the VPN provider and your ISP each still have their own part of the connection to observe.
04 / PROXIES ADD ANOTHER HOP
Reverse proxies can hide the visitor address from the application.
Many sites sit behind a reverse proxy or CDN. Cloudflare is a common example. The visitor connects to Cloudflare first, then Cloudflare forwards the request to the site's origin. Unless the proxy passes a trusted visitor-IP header, the application sees the proxy address instead of the visitor's address.
This is one reason an application must not blindly trust `X-Forwarded-For`. A public client can send that header too. The application should only trust forwarded-address headers when it is reachable solely through a proxy it controls.
05 / YOUR LAN ADDRESS IS NOT IN A NORMAL WEB REQUEST
A web page cannot simply ask for `192.168.x.x`.
Your private LAN address is useful inside your local network, but a normal HTTP request does not include it for the website. The same is true for link-local addresses such as `169.254.x.x` and `fe80::/10`. Browsers do not provide a standard JavaScript API that hands a website your private network address.
That boundary matters. A site can show the address that reached its server, as IPTHUNDER does. It cannot honestly claim that a normal page has discovered the private address assigned to your laptop or phone.
06 / WHAT AN IP CAN AND CANNOT SUPPORT
Use it as a connection clue.
An IP address can help an operator diagnose a route, spot an address-family mismatch, apply a rate limit, or check whether a reverse proxy is passing the expected headers. It cannot prove who is at a keyboard, identify every device on a LAN, or reveal a street address with certainty. Treat it as a connection fact with a limited scope.