- Country
- …
- Reverse DNS
- …
- User agent
- …
Request headers your client sent
Headers appear here once the page has loaded.
Cookies, credentials and the delivery network's own routing headers are never shown or stored. Country comes from the network edge's IP geolocation; when it cannot resolve one, this page says so instead of guessing.
What this page can tell you
Every request you make on the web arrives from an IP address, and the server on the other end sees that address whether you think about it or not. This page simply reflects it back: the address itself, the country its geolocation record points to, the reverse-DNS name its owner published for it, and the HTTP headers your browser attached to the request.
Checking that a proxy is actually working
The most common use for a page like this is verification. Load it directly and note your IP; then route your traffic through a proxy and load it again. If the proxy is working, the address shown here is the proxy's exit IP, not yours, and the country should match the proxy's advertised location. From the command line, the same check is one request:
curl -x "http://user:pass@proxy-host:port" https://node4.io/api/tools/ip
Need the connection string for that command? The proxy connection string builder generates it for curl, Python and Node.js.
Why headers matter too
Your IP is only part of what a server learns about you. The headers your client sends — user agent, accepted languages, encodings, client hints — identify your browser and platform, and automation tools each have recognizable defaults. If you are debugging why a site treats your script differently from your browser, comparing this page's header table between the two is a fast way to see what differs. To decode the user-agent string itself, use the user-agent parser.