Tools
Proxy checker
Verify what a target sees from your egress: the exit address, the network it belongs to, whether WebRTC exposes a second address, and whether the request carries headers that name a proxy. The check describes what a website receives; it cannot see what sits behind the exit address.
- QA a proxy configuration before it reaches a production pipeline.
- Check egress for a compliance review: which address and network a target actually sees.
- Verify what a vendor's endpoint presents, by ASN and operator, rather than by its description.
Check this connection
Connection check
Runs from this browser, through whatever proxy the browser or system is set to use. Nothing is sent until you start it.
What it reports, and its limits
What each line of the result means, where it comes from, and what it cannot tell you.
- 01Exit address
- The address your request reached our API from, and whether it is IPv4 or IPv6. The country is Cloudflare's placement of that address.
- 02Network
- Your browser asks ipapi.is about the exit address: the autonomous system (ASN) announcing it and its operator. The lookup does not say whether that is a hosting network or an ISP, so the page guesses from a short list of well-known cloud networks and from the operator's name, marks the guess as one, and says when it can't tell.
- 03WebRTC
- Your browser asks Google's public STUN server which address it sees. That request is UDP, which an HTTP proxy does not carry, so it can expose an address other than the exit address. An address of the other IP version is usually the same connection's second address, normal on a dual-stack line, though it still reveals you if the proxy only carries one version. Local addresses the browser masks behind a .local name are ignored.
- 04Headers
- Headers such as Via, Forwarded and X-Forwarded-For that name a proxy or an earlier address. This check runs over HTTPS, and a proxy cannot add headers inside an HTTPS tunnel, so any it finds were sent by the client itself or added by a proxy that decrypts the traffic (TLS interception). A clean result here says nothing about what the same proxy adds to plain-HTTP requests.
Check a proxy from a terminal
Point curl at the proxy you want to test. It tunnels the HTTPS request through it and prints the same JSON this page reads.
Shell
curl -sx http://USER:PASS@IP:PORT https://api.proxyforge.io/tools/echoReplace USER, PASS, IP and PORT with the proxy’s credentials and address. The response carries the exit address, its IP version, any proxy-revealing headers that reached us, and the client’s User-Agent. The network lookup and the WebRTC check need a browser, so they are not part of it, and the HTTPS note above applies to its headers too.
For proxy schemes, SOCKS5, authentication and debugging flags, see the curl proxy cheat sheet.
What a check contacts
- Our API, at api.proxyforge.io, returns your address, a short list of proxy-revealing headers and your user agent. We don’t store the result. The request itself is handled like any other request to our API, so it can appear in the server and security logs described in our privacy notice.
- ipapi.is, which your browser asks directly about the exit address. We send it nothing ourselves, and its own privacy policy applies.
- Google’s public STUN server, which your browser contacts for the WebRTC check.
Nothing is contacted until you start a check. For how we source the addresses on our own network, see sourcing and compliance and how to verify a provider’s IP sourcing.
Start with the evidence
Ask us to trace an address, send you the sourcing attestation, or price your current volume at our published rates. A named engineer will help with your technical and procurement review.
One business day, from a named engineer.