How to Test If Your Residential Proxy Is Working (Step-by-Step Guide)

You've just set up a residential proxy. You paste in the credentials, configure your tool, and send a request. But how do you actually know it's working? Is it really routing through a residential IP? Is it the right location? Is it even doing anything at all?

Here's the direct answer: to verify a residential proxy is working, send a request through it to an IP-checking service like https://ipinfo.io/json and confirm the returned IP is different from your real IP, belongs to an ISP (not a data center), and matches the expected geo-location. That's the core test. Everything else in this guide builds on that to cover edge cases, automation, and common failure modes.

What "Working" Actually Means for a Residential Proxy

A proxy being "active" and a proxy "working correctly" are two different things. Your connection to the proxy server might be perfectly fine, but the proxy could still be routing your traffic through a data center IP — which most anti-bot systems detect and block instantly.

A residential proxy is specifically supposed to route your traffic through IP addresses assigned by real Internet Service Providers (ISPs) to real home users. According to IPinfo's documentation, the key identifier is that the IP's org field returns an ISP name (like "Comcast" or "Telekom") rather than a hosting provider (like "Amazon AWS" or "DigitalOcean"). That distinction is everything.

So when we say "test if it's working," we mean four things:

Step 1: Find Your Real IP First

Before you test anything through the proxy, you need a baseline. Open a terminal — without the proxy configured — and run:

curl https://ipinfo.io/json

You'll get something like:

{
  "ip": "203.0.113.45",
  "city": "Jakarta",
  "region": "Jakarta",
  "country": "ID",
  "org": "AS17974 Telkom Indonesia"
}

Save that IP. That's your real address. Everything you test through the proxy needs to return a different IP. If the proxy returns the same IP, it's either misconfigured or not routing traffic at all.

Step 2: Send a Request Through the Proxy and Check the IP

Now let's run the actual test. Here's how to do it with Python's requests library — the cleanest way to verify programmatically:

import requests

proxy_host = "your.proxy.host"
proxy_port = "10000"
proxy_user = "your_username"
proxy_pass = "your_password"

proxies = {
    "http":  f"http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}",
    "https": f"http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}",
}

try:
    response = requests.get(
        "https://ipinfo.io/json",
        proxies=proxies,
        timeout=15
    )
    data = response.json()

    print(f"IP seen by server : {data.get('ip')}")
    print(f"City              : {data.get('city')}")
    print(f"Country           : {data.get('country')}")
    print(f"ISP / Org         : {data.get('org')}")

except requests.exceptions.ProxyError as e:
    print(f"Proxy connection failed: {e}")
except requests.exceptions.Timeout:
    print("Request timed out — proxy may be slow or unreachable")

A successful test returns an IP that is different from your real one, with an org field that names a consumer ISP. That's your green light. If the org field shows "Amazon" or "Google Cloud" or any hosting provider, the proxy is routing through a data center — it's not behaving as a residential proxy.

Quick curl version: If you'd rather not write Python, test directly in the terminal:

curl --proxy "http://user:pass@host:port" https://ipinfo.io/json

Step 3: Verify the Geo-Location Matches Your Target

Most residential proxy services let you target specific countries, states, or even cities. After running the test above, compare the country and city fields against what you configured. Here's a quick automated check to add to your script:

EXPECTED_COUNTRY = "US"  # What you configured in your proxy settings

if data.get("country") == EXPECTED_COUNTRY:
    print("Geo-location check PASSED")
else:
    print(f"Geo-location MISMATCH: got {data.get('country')}, expected {EXPECTED_COUNTRY}")

Geo mismatches are more common than you'd think — especially with rotating proxies that cycle through a pool. If your target site serves different content by region (pricing, inventory, search results), a wrong geo means wrong data even if the proxy itself is technically connected.

Step 4: Check for IP and DNS Leaks

Here's a failure mode that catches a lot of people off guard. Your HTTP traffic routes through the proxy fine, but DNS queries slip out through your real connection — revealing your actual location and identity to privacy-aware sites. This is called a DNS leak.

The fastest way to check: while your proxy is active in your browser or tool, visit dnsleaktest.com and run the Extended Test. All DNS servers listed should belong to your proxy provider's network or the target region — not your home ISP.

For programmatic scraping, you can also run a quick DNS resolution check through the proxy to confirm it's resolving via the correct nameservers rather than falling back to your local resolver.

Step 5: Test Against a Real Target (The Stress Test)

IP checkers are friendly — they'll happily respond to any proxy. Real target sites are not. The ultimate verification is to actually attempt a request against one of the sites you're planning to scrape and check whether you get a valid response or a block page.

A good real-world test target is httpbin.org/ip — it simply echoes back the IP it received, no bot detection involved. Then step it up to a more protected target:

import requests

proxies = {
    "http":  "http://user:pass@host:port",
    "https": "http://user:pass@host:port",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

response = requests.get(
    "https://www.amazon.com",
    proxies=proxies,
    headers=headers,
    timeout=20
)

print(f"Status code : {response.status_code}")
print(f"Blocked?    : {'Yes' if 'Robot Check' in response.text else 'No'}")

A 200 status and real page content means your proxy is behaving like a genuine residential user. A 403, a redirect to a CAPTCHA page, or a "Robot Check" response means the proxy's IP has likely been flagged — time to rotate or switch to a different pool.

But there's a small problem with this approach at scale. Even legitimate residential IPs get flagged eventually if they're hammered too hard or lack proper browser fingerprinting. This is where the gap between "proxy working" and "proxy effective for scraping" becomes real. Tools like MrScraper's Residential Proxy pair proxy rotation with a full scraping browser that mimics real browser behavior — headers, TLS fingerprints, and all — making the overall request far harder to fingerprint and block, beyond what a naked proxy test can verify.

Common Failure Modes and What They Mean

Same IP returned as your real IP

The proxy isn't routing traffic at all. Double-check your host, port, username, and password. Also confirm you're setting both http and https keys in the proxies dict — a common omission that causes HTTPS requests to bypass the proxy silently.

Connection refused or timeout

The proxy server is unreachable. Could be a wrong port, firewall rule blocking outbound connections to that port, or the proxy pool being temporarily exhausted. Try a different port or endpoint if your provider offers multiple.

org field shows a data center

Your provider is passing off data center IPs as residential — a bait-and-switch that's unfortunately not rare with cheap proxy services. Cross-check the returned IP against ipinfo.io manually and look at the hosting flag in the response. If it's true, that IP is from a data center, not a home user.

Geo-location is wrong

Your proxy's geo-targeting either isn't working or the pool for that specific region is thin. Try re-authenticating with the geo-targeting parameter explicitly set in the username string (most providers use a format like user-country-us) and run the test again.

Automating the Health Check

If you're running a scraping operation that depends on proxies continuously, you don't want to test manually every session. Here's a simple health-check function you can run before any scraping job starts:

import requests

def proxy_health_check(proxy_url, expected_country=None):
    try:
        response = requests.get(
            "https://ipinfo.io/json",
            proxies={"http": proxy_url, "https": proxy_url},
            timeout=15
        )
        data = response.json()
        ip      = data.get("ip", "unknown")
        org     = data.get("org", "")
        country = data.get("country", "")

        is_residential = not any(
            dc in org.lower()
            for dc in ["amazon", "google", "digitalocean", "linode", "vultr", "azure"]
        )

        geo_ok = (expected_country is None) or (country == expected_country)

        return {
            "ip":             ip,
            "org":            org,
            "country":        country,
            "is_residential": is_residential,
            "geo_match":      geo_ok,
            "healthy":        is_residential and geo_ok
        }

    except Exception as e:
        return {"healthy": False, "error": str(e)}

result = proxy_health_check("http://user:pass@host:port", expected_country="US")
print(result)

Run this before your main scraper loop. If healthy comes back False, skip that proxy and pull the next one from your rotation. Simple, effective, and something you can log for monitoring over time.

Conclusion

Testing a residential proxy isn't complicated, but it requires checking more than just "did I get a response." You need to confirm the IP changed, confirm it belongs to an ISP rather than a data center, verify the geo-location matches your target, and check for leaks. The Python snippet with ipinfo.io covers all of that in under 20 lines.

Build the health check into your scraping workflow as a pre-flight step, and you'll catch misconfigured or degraded proxies before they waste your time — or worse, get your target accounts flagged.

What We Learned

• A working residential proxy should return a different IP, from a consumer ISP — not a data center or hosting provider.
• Use https://ipinfo.io/json as your test endpoint: it returns IP, location, and org in one clean JSON response.
• Always establish your real IP baseline first, before running any proxy test.
• DNS leaks can expose your real identity even when the proxy connection itself is active — always test separately with dnsleaktest.com.
• The org field in ipinfo.io is the fastest way to distinguish a residential IP from a data center IP.
• Automate the health check as a pre-flight step so misconfigured proxies never reach your main scraping logic.

FAQ

• What's the easiest way to test a residential proxy without writing code? Configure the proxy in your browser settings, then visit ipinfo.io in a tab. The page shows your apparent IP, ISP, and location. If it reflects the proxy's details rather than your own, the proxy is routing traffic correctly.
• How do I know if a proxy IP is truly residential vs. data center? Check the org field returned by ipinfo.io. A residential IP shows a consumer ISP name like "Comcast" or "Vodafone." A data center IP shows a cloud provider like "Amazon AWS" or "DigitalOcean." You can also cross-check with ipinfo.io's hosting flag — if it's true, the IP is from a data center.
• Why does my proxy return the right IP in testing but still get blocked on real sites? A valid residential IP is just one layer of detection. Sites also check browser fingerprints, TLS handshake patterns, header ordering, and behavioral signals. A bare proxy without browser-level spoofing can still be identified as automated even with a clean residential IP.
• How often should I run proxy health checks? At minimum, run one before each scraping session. For long-running jobs, add a periodic check every N requests or every few minutes, since rotating proxy pools can cycle onto flagged or data-center IPs mid-session.
• My proxy connection times out — what should I check first? Start with the port. Many firewalls block non-standard ports. Check if your proxy provider offers alternative ports (commonly 80 or 443 as fallbacks). Also verify that your username and password don't contain special characters that need URL-encoding in the proxy string.