What is my IP
This page shows your source IP server-side (a request is required). No manual input is needed, and the output helps troubleshoot routing differences.
Result
REMOTE_ADDR 216.73.216.141
X-Forwarded-For 216.73.216.141
X-Real-IP 216.73.216.141
Forwarded (none)
CF-Connecting-IP (none)
Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.
How to use
Review each IP-related header to infer the request path. For real-client IP decisions, verify trusted-proxy settings as well.
Notes (this tool)
- Headers like X-Forwarded-For can be spoofed. Only trust them when set by trusted proxies.
- Behind CDN, load balancer, or reverse proxy, REMOTE_ADDR may be an edge IP.
About this page
What does this tool do?
Shows the client IP as seen by the server (REMOTE_ADDR) plus proxy-related headers.
Useful when you want to know your apparent public IP.
IP display basics
- REMOTE_ADDR is the direct source seen by the server.
- X-Forwarded-For may be added by proxies.
- Header values can be spoofed and are informational only.
Public IP vs local/private IP
“My IP” usually means your public IP (visible from the internet). Separately, you also have local/private IPs inside your LAN or corporate network.
- This page shows the source IP as seen by the server.
- Visibility changes with VPN/Proxy/CDN/load balancers.
Why the IP may differ
It’s common that the IP is not what you expected. For troubleshooting, consider the network path (device → router → ISP → VPN/Proxy → CDN → server).
- VPN/Proxy is enabled
- Mobile networks/tethering change egress
- Behind CDN/load balancer, REMOTE_ADDR may be an intermediate IP
Typical use cases
- Confirm public IP when using VPN/Proxy
- Verify IP-based access controls
- Check IP visibility behind CDN/load balancer
Fields displayed
- REMOTE_ADDR (server-seen IP)
- X-Forwarded-For / X-Real-IP / Forwarded
- CDN headers (e.g., CF-Connecting-IP)
How to interpret the output
- Start with REMOTE_ADDR (what the server actually sees)
- If you are behind proxies, also check X-Forwarded-For and similar
- Without a trusted-proxy boundary, headers can be dangerous to trust
Common pitfalls
- Trusting X-Forwarded-For blindly
- REMOTE_ADDR becomes proxy IP behind proxies
- Mixing IPv6/IPv4 causes mismatches
Privacy & logging
IP addresses are used in access logs and audits. On shared/mobile networks, many users may share one IP, so attribution is limited.
- Use IP allowlists as a supplement, not the sole authentication
- Combine with timestamps/UA/auth logs in operations
What this tool does
- Check IP from server perspective
- Inspect proxy-related headers
- Initial checks for IP restrictions/audits
Debugging workflow (recommended)
- Paste actual headers or observed values
- Compare expected and observed values
- Trace proxy, CDN, and redirect paths
Operational notes
- Intermediaries may rewrite headers. Compare captures from equivalent points.
- Confirm final decisions with server logs and configuration such as trusted proxy and routing.
Referenced specs
- RFC 7239 (Forwarded header)
- RFC 9110 (HTTP Semantics)
FAQ
Can JS-only get my public IP?
In principle you need a server request to know the IP seen from outside.
Is X-Forwarded-For trustworthy?
Only if it is set by trusted proxies/load balancers.
How does it look on IPv6?
REMOTE_ADDR will show an IPv6 address. Whether you reach via IPv4 or IPv6 depends on your network.
References
Next to view (diagnostic order)
These links are generated from site_map rules in recommended diagnostic order.
- My User Agent — Show UA, language, and screen info for environment checks