📍 What Is My IP
See your public IP address, reverse hostname, browser, OS, and proxy headers.
🔍 Details
| Client IP | 216.73.216.65 |
| REMOTE_ADDR | 172.19.0.5 |
| X-Forwarded-For | 216.73.216.65 |
| X-Real-IP | — not set |
| CF-Connecting-IP | — not set |
| Hostname (rDNS) | — not set |
| Browser | Unknown |
| OS | Unknown |
| User-Agent | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) |
| Accept-Language | — not set |
| Accept-Encoding | gzip, br, zstd, deflate |
| Protocol | HTTP/1.1 |
| TLS | No (HTTP) |
📚 About Proxy Headers
• REMOTE_ADDR: IP of the TCP connection (a proxy IP if behind a proxy)
• X-Forwarded-For: Original client IP added by proxies (comma-separated chain)
• CF-Connecting-IP: Real client IP set by Cloudflare
• X-Forwarded-For from untrusted sources can be spoofed — production code must validate against a trusted proxy list.
📖 What this check tells you
This page shows the source IP our server observed for your connection, together with any proxy-related headers the request carried. The IP shown is not necessarily your device address: on mobile and corporate networks, CGNAT and proxies make many users share one address, and through a VPN you see the exit node. Its main use is confirming how a service perceives the client it is talking to.
| Item | What it means | How to fix it |
|---|---|---|
| Trusting the leftmost X-Forwarded-For | X-Forwarded-For gains an entry at each hop, producing client, proxy1, proxy2. The client can put anything it likes at the front, so the leftmost value is entirely untrustworthy. An implementation that takes it lets an attacker bypass IP allowlists, rate limits and bans by adding one header line. |
Count the trusted proxies in your own topology and take the entry that many positions from the right. On nginx, list only your load balancer or CDN ranges in set_real_ip_from and set real_ip_recursive on; — the first value not on the trusted list is then taken as the real client. |
| Behind a CDN every visitor looks the same | With Cloudflare or similar in front, every connection the origin sees comes from an edge server address. Log analysis, geolocation and rate limiting all stop working at once, and there is a classic accident where the origin blocks itself by treating the edge as one very busy client. | Use the header your CDN sets for the real client — CF-Connecting-IP on Cloudflare, True-Client-IP generically. On nginx that is real_ip_header CF-Connecting-IP; plus the published CDN ranges in set_real_ip_from. Those ranges change, so automate refreshing them, and close off any path that reaches the origin directly without passing the CDN. |
| Treating IPv6 at IPv4 granularity | In IPv4 one address roughly means one subscriber, but in IPv6 a single subscriber is handed a /64 or larger — on the order of 18 quintillion addresses. Rate limiting or banning per address is defeated the moment the same user shifts to the next address along. |
Aggregate IPv6 per /64, or /56 if you want to be stricter. Also give any database column storing an address 45 characters — the maximum once IPv4-mapped forms such as ::ffff:192.168.0.1 are included — and check that your log-parsing regexes are not built around the IPv4 \d+\.\d+ shape. |
Do not use an IP address as a user identifier. On mobile networks CGNAT has hundreds or thousands of people sharing one address, while a single user can change address within minutes. Neither same IP means same person nor different IP means different person holds. Geolocation is broadly right at country level but far less reliable at city level. Note too that under the EU GDPR an IP address counts as personal data, so if you store one, define the retention period and the purpose.