IP Checker

About the IP Checker

This IP checker shows the public address your connection presents to the internet, both IPv4 and IPv6 when your network supports both, exactly as our server sees it on the incoming request. Alongside the address it lists a small set of HTTP request headers behind that request: user-agent, accept-language, x-real-ip, x-forwarded-proto and host, each shown only when your client actually sent it, plus the raw x-forwarded-for chain when a proxy or load balancer added one.

You reach for a tool like this after switching networks, VPNs or proxies and wanting to confirm the change actually took effect, when debugging a reverse proxy or load balancer that is supposed to forward the original client address, or when you simply need to see what user-agent and language your browser or script is advertising to a remote server. It is also the fastest way to check a server's own outbound address: curling this endpoint from a machine tells you the IP that machine presents to the outside world, which is not always the same as an address shown inside some internal tool or gateway that strips client-identifying headers before the request reaches it.

What sets this apart from a bare search-engine answer box is the header detail. Most "what is my ip" pages stop at the address; this one also surfaces the exact request headers a server receives from you, which is what you actually need when debugging proxy chains, CDN configuration or bot/UA detection, rather than just a number to copy.

The detection happens server-side by necessity, your browser cannot observe its own public address without asking something outside your network, so the request itself reaches our server. The response carries a no-store cache header, so results are never served from cache, and the endpoint sits behind the same shared per-IP rate limit as every other tool here rather than being logged or retained beyond serving that one reply.

How to use it

1. Open the page; the check runs automatically and needs no button or input.
2. Read the displayed address and family label (IPv4 or IPv6) directly.
3. If your network is dual-stack, compare both the IPv4 and IPv6 lines shown.
4. Scan the header table for user-agent, accept-language, host and x-forwarded-proto, each appears only if your client sent it.
5. Check x-forwarded-for for the chain of proxies or load balancers in front of you.
6. Reload after switching VPN, Wi-Fi or mobile data to confirm your public address actually changed.
7. Curl the underlying endpoint from a server or script to confirm that machine's real outbound IP.

Examples

• Confirm a VPN is active: the address and its geolocation should match the VPN exit node, not your home ISP.
• Debug a reverse proxy: x-forwarded-for reads 203.0.113.10, 10.0.0.1, the first entry is the real client, the rest are hops added by proxies behind it.
• On a dual-stack network you see both an IPv4 line like 203.0.113.10 and an IPv6 line like 2001:db8::a1.
• Confirm a server's real egress address by curling the endpoint directly from that machine, useful when an internal tool or gateway reports the address as unknown because its own transport strips the client IP before the request reaches it.
• A mobile connection behind carrier-grade NAT shows a shared public address that is not the same as the private WAN IP your router's own admin page displays.
• Check the user-agent header after changing a script's HTTP client library, to confirm the remote server sees the string you expect.

What the tool shows, and what it deliberately does not

The header list is intentionally short: only user-agent, accept-language, x-real-ip, x-forwarded-proto and host are surfaced, each only when present, plus x-forwarded-for shown separately as the raw comma-separated chain. This keeps the output readable and focused on the fields that actually matter for proxy and client debugging, instead of dumping every header your browser sends.

It also does not do a few things some other IP tools promise. There is no geolocation, ISP name or city lookup attached to the address, no ASN or registrant lookup (use the WHOIS/RDAP tool for that), and no way to see a private or LAN address, since the server can only ever observe the public address a request arrives from.

• Shown: public IPv4 and/or IPv6 address, address family label.
• Shown: user-agent, accept-language, x-real-ip, x-forwarded-proto, host (only if sent).
• Shown: raw x-forwarded-for chain (only if a proxy added one).
• Not shown: geolocation, ISP/ASN, or any registrant data.
• Not shown: your private/LAN IP, the server never sees it.

Reading x-forwarded-for safely

x-forwarded-for is a de facto standard header that proxies and load balancers append to, recording the client address at each hop. By convention the left-most entry is the original client and each proxy behind it adds its own address to the right, but the header is trivially spoofable by anyone who can reach your server directly, so it should only be trusted when a proxy you control strips or overwrites any client-supplied value before appending its own.

A newer standard header, Forwarded, encodes the same information in a structured for=/proto=/by= format and is less common in the wild; most infrastructure, including this tool's own display, still centers on x-forwarded-for because that is what real-world proxies actually send.

• Left-most entry in x-forwarded-for is conventionally the original client.
• Each proxy in the chain is expected to append, not rewrite, the existing value.
• The header is spoofable by any client that can reach your app directly.
• Only trust it behind a proxy configured to strip/overwrite untrusted input.
• x-real-ip is a simpler, single-address alternative some proxies set instead.

Why a same-machine check sometimes shows "unknown"

Some environments, embedded internal tools, certain API gateways, MCP-style transports and container platforms, strip or never populate client-identifying headers before a request reaches the final handler, so a check running inside that layer can report the caller's IP as unknown even though the machine has a perfectly normal public address. Querying a plain HTTP endpoint like this one over a regular connection avoids that layer entirely and reports the address the server's own network stack actually saw, which is the reliable way to confirm a server or script's real outbound IP.

Frequently asked questions