What is my IP?
Shows the address, IP version, forwarded-header context, and request metadata observed for this connection.
NetworkPublic IP, NAT, and Dual Stack: Which Address Is Really Yours?
There is no single “internet address of this machine” once routers, carrier NAT, proxies, and two IP families enter the path. A service sees the source of one connection at one point in the network; treat that observation as evidence about the path, not as a permanent identity.
A public IP belongs to a path, not an application
Start with the only answer a remote service can prove: the source address on the packet that reached it. The What is my IP? page reports that address, its IP version, and the request context visible at this endpoint. It does not peer into your laptop, home router, VPN client, or mobile carrier. If the browser used 2001:db8::42, that is what an IPv6-capable service sees. If another request left through a translated IPv4 path as 198.51.100.27, that service reports the IPv4 address. Neither answer invalidates the other.
Local addresses answer a different question. An RFC 1918 address such as 192.168.1.34 or 10.20.4.8 identifies an interface inside a private routing domain; an IPv6 link-local address beginning fe80:: reaches only the local link. Even a globally scoped IPv6 address may be one of several temporary addresses selected for outbound privacy. Asking an application for its local interface list therefore does not predict what a server will observe. The route, address-selection policy, tunnel state, and intermediate translators decide that at connection time.
NAT rewrites the conversation, not the host
Ordinary home and office IPv4 uses network address translation because private addresses are not routed on the public internet. A gateway maps an internal source address and port to one public address and another port, remembers the mapping, and reverses it for returning packets. Thousands of simultaneous flows can share one public IPv4 because the transport tuple distinguishes them. The public address therefore identifies the translating edge more accurately than the device behind it. It is useful for diagnostics and coarse policy, but weak as a user or machine identifier.
NAT also explains why unsolicited inbound traffic fails while outbound browsing works. The gateway has no existing mapping that says which internal host should receive a new connection. Port forwarding creates such a rule deliberately; universal plug-and-play may create one less deliberately. None of this is a firewall guarantee: stateful filtering and translation are related operations, not synonyms. Conversely, IPv6 usually does not need address translation, but globally routed addresses still belong behind a firewall whose inbound policy is explicit. “No NAT” means end-to-end addressing is possible, not that every socket is exposed.
CGNAT moves the translator into the provider
Carrier-grade NAT adds another translation boundary outside your premises. Your router may receive an address from the shared 100.64.0.0/10 space, or sometimes another non-public range, while many subscribers leave through a smaller pool of public IPv4 addresses. A port-forward on your router stops at the carrier mapping and cannot make an inbound service reachable. Dynamic DNS faithfully publishing the observed public address does not repair that missing inbound mapping either. The practical options are a real public address from the provider, native IPv6 with suitable firewalling, or a reverse tunnel to an endpoint you control.
CGNAT also makes reputation controls noisy. If one subscriber triggers abuse defenses, a shared egress address can acquire a poor reputation for everyone behind it. Rate limits keyed only by source IP aggregate unrelated households or mobile users. Incident logs that retain only the public address cannot distinguish subscribers without the carrier's timestamped port-allocation records. When diagnosing, compare the WAN address on the router with the address an external service observes, then classify both with the CIDR/Subnet Calculator. A mismatch is expected behind CGNAT, a VPN, or another upstream translator; it is a clue, not automatically a fault.
Dual stack makes two correct answers routine
A dual-stack client has usable IPv4 and IPv6. DNS may return both A and AAAA records, after which the client chooses a working path, commonly trying IPv6 preferentially while avoiding long delays when it is broken. The result is per destination, not a global mode switch. An IPv6-capable site can see your IPv6 address while an IPv4-only API, an older monitoring probe, or a VPN with incomplete IPv6 support sees IPv4 seconds later. Browser tabs can therefore report different public addresses without cache corruption, spoofing, or a faulty detector.
Do not infer the chosen family from DNS alone. A published AAAA record does not prove that the route, firewall, or application listener works; an absent AAAA forces IPv4 even when the client itself has excellent IPv6. Test the exact hostname and protocol from the affected network. Also watch for split tunnels: a VPN may carry IPv4 through corporate egress but leave IPv6 on the local ISP, or the reverse. That is both a diagnostic surprise and a policy leak if the organization believed all traffic inherited one egress identity.
Forwarded headers are claims with a trust boundary
Behind a reverse proxy or CDN, the origin's TCP peer is the proxy. To preserve client context, intermediaries add fields such as Forwarded, X-Forwarded-For, or provider-specific connecting-IP headers. These are strings in an HTTP request, not cryptographic proof. A direct client can send its own X-Forwarded-For; every untrusted proxy can prepend or replace values. The origin may trust a header only when the immediate peer is a known proxy and that proxy is configured to discard client-supplied copies and write the authoritative value.
The ordering rule matters. An X-Forwarded-For chain may contain several addresses, and blindly taking the leftmost or rightmost element is unsafe without knowing which hops append and which ranges are trusted. Configure the framework with the exact proxy count or trusted CIDRs, preserve the socket peer separately, and inspect the actual response and request context rather than a diagram. The HTTP Header Analyzer can organize pasted or public response headers and flag conflicting or duplicate fields; it does not turn a forwarded client claim into verified identity.
Allowlists and geography need an operating policy
An IP allowlist is reliable only when the allowed egress is deliberate and stable. Corporate NAT gateways and managed VPN exits can satisfy that contract; residential addresses, mobile networks, privacy relays, temporary IPv6 addresses, and cloud autoscaling usually cannot. Dual stack doubles the policy surface: allowing the office IPv4 while forgetting its IPv6 prefix creates inconsistent access depending on which family wins. Prefer identity-aware authentication for people, and reserve address allowlists for controlled network boundaries. Where an allowlist remains necessary, document owner, prefix, family, source of truth, expiry, and an emergency access path.
Geo-IP is even softer evidence. Databases map allocation and routing observations to an approximate location; VPNs, carrier exits, anycast, corporate backhaul, and stale assignments move the observed address away from the person. Use geography to adjust defaults or score risk, not as sole proof of residence or authorization. Log both the trusted client address and the immediate peer, with timestamp and IP family, so a later investigation can reconstruct the path. The disciplined question is never simply “what is the user's IP?” It is “which address did this service observe, through which trusted intermediaries, for this connection, and what decision are we justified in making from it?”