Guide
What's My IP: Check Your Address, Location and Leaks
Check what your IP reveals: address, geolocation, ISP, and proxy classification. Includes a curl-friendly endpoint for scripts and automated verification.

"What's my IP" sounds like a trivial question, and for a single number it is. The useful version is broader: what does my connection actually reveal to every site I visit, and does it match what I intended? When you are running through a proxy, those two things come apart more often than people expect — and the failure is silent.
flameproxies.com/whatsmyip answers the full version in a browser. For scripts and automation, ipcheck.flameproxies.com returns the same information in a form you can curl.
What Your IP Reveals
Every request you make carries your IP address, and from it a destination can derive:
Geolocation — country reliably, region reasonably, city with varying accuracy. This drives content localization, pricing, ad targeting, and access restrictions.
ISP and organization — which network you are on. A consumer broadband provider reads very differently from a cloud hosting company.
ASN — the autonomous system number identifying the network. Targets frequently aggregate reputation at this level rather than per address.
Connection type — residential, mobile, business, datacenter, or hosting. This is the classification that determines whether protected sites treat you as a person or as infrastructure.
Proxy or VPN indicators — whether the address appears in known proxy, VPN, or hosting ranges.
When you route through a proxy, all of this should reflect the proxy, not you. Confirming that is the point of checking.
The Browser Tool
Open the page and it shows your current exit address with the full breakdown: geolocation down to city, ISP and organization, ASN, and how the address classifies. If you are connected through a proxy, that is what you should see — and if you see your own ISP instead, your proxy configuration is not applying to the browser.
The most common reasons for that mismatch, worth checking in order: the proxy is set at the system level but the browser overrides it, an extension is handling proxying and has been disabled, a PAC file excludes the domain, or the connection dropped and fell back silently without a kill switch catching it.
The Curl Endpoint
For anything scripted, use ipcheck.flameproxies.com. It returns IP information directly, with no page to parse.
curl https://ipcheck.flameproxies.comThrough a proxy:
curl -x "http://user:pass@gateway.flameproxies.com:8080" \
https://ipcheck.flameproxies.comThis is the single most useful command when setting up proxy access. If the address that comes back is the proxy's, your configuration works. If it is yours, the proxy is not being applied — and you have learned that in one second rather than after a collection run produces unusable data.
Verifying targeting
Encode targeting parameters and confirm they resolve:
curl -x "http://user-country-DE-city-Berlin:pass@gateway.flameproxies.com:8080" \
https://ipcheck.flameproxies.comCheck that the returned country and city match what you asked for. Geographic drift — requesting Berlin and receiving Hamburg — produces wrong-market data with no error anywhere in your pipeline, so this check is worth running for every market you plan to use rather than just one.
Confirming rotation
Two requests with no session parameter should return different addresses:
for i in 1 2 3; do
curl -s -x "http://user:pass@gateway.flameproxies.com:8080" \
https://ipcheck.flameproxies.com
doneAnd two with the same session parameter should return the same one:
for i in 1 2; do
curl -s -x "http://user-session-test001:pass@gateway.flameproxies.com:8080" \
https://ipcheck.flameproxies.com
doneRunning both is a complete check of rotation and stickiness in about four seconds, and it is worth doing once whenever you change session configuration.
Using It as a Session Gate
The pattern worth building into production: verify geography at session start, before collecting anything.
import requests
def session_is_valid(proxies, want_country, want_city=None):
try:
r = requests.get("https://ipcheck.flameproxies.com",
proxies=proxies, timeout=15)
data = r.json()
except Exception:
return False
if data.get("country_code") != want_country:
return False
if want_city and want_city.lower() not in (data.get("city") or "").lower():
return False
return TrueA session that fails this check gets discarded and re-requested rather than used. The cost is one lightweight request per session; the benefit is that wrong-market records never enter your dataset in the first place.
This is also where throughput matters in a way people do not anticipate. Verification requests consume concurrency and bandwidth. On a provider that caps either, instrumentation competes directly with collection for the same allowance — which is why teams under-instrument and then cannot explain their data quality problems. FlameProxies applies no request-rate limit and no concurrency cap, so a verification gate on every session runs alongside production work rather than eating into it.
Checking for Leaks
An IP check catches the main leak, but a few others are worth knowing about.
DNS leaks. Your traffic may route through the proxy while DNS queries go to your own resolver, exposing which domains you are visiting to your ISP. Use a DNS leak test alongside the IP check.
WebRTC leaks. Browsers can expose local and public addresses through WebRTC regardless of proxy settings. Browser-based proxy setups are particularly exposed; disable WebRTC or use a browser configuration that blocks it.
Header leaks. Some proxies forward X-Forwarded-For or Via headers that reveal the arrangement or your origin address. The proxy tester checks for this across a list of proxies.
IPv6 fallback. A proxy configured for IPv4 only, on a dual-stack machine, may let IPv6 traffic bypass it entirely. If the IP check returns an IPv6 address you did not expect, that is what happened.
Silent reconnection. A dropped proxy connection without a kill switch means traffic resumes on your real address. This is the leak that most often goes unnoticed, because everything appears to keep working.
When to Check
- Immediately after configuring any new proxy setup, before relying on it
- At the start of every automated session, for location-sensitive work
- Whenever you change targeting parameters
- When collected data looks like it came from the wrong market
- After any network interruption, if you are not running a kill switch
- Periodically, as a drift check on pool accuracy in each market
Alongside the Other Tools
The three tools cover different questions. whatsmyip answers "what am I presenting right now" for a single current connection. The proxy tester answers "which of these many proxies are usable" in bulk. The Flame Proxy Connector is what routes desktop applications through proxies in the first place, and displays its exit IP in the client so you can cross-check it here. All three are listed at flameproxies.com/tools.