How I Test Free Proxies in Python — and When I Switch to Residential Proxies

Mehmet Bulat — Sat, 03 Oct 2026 13:36:14 +0000

If you work with web scraping, monitoring, QA, or automation, you eventually run into the same question:

Should I keep testing public proxies, or is it time to use a managed proxy network?

Public proxies are useful when I am prototyping a checker, testing networking code, or building a proof of concept. They are free and easy to experiment with.

The problem starts when the project needs to run consistently.

A list containing 10,000 proxies does not mean you have 10,000 usable proxies. Many will be offline, slow, incorrectly geolocated, blocked, or gone by the time your next job starts.

Already at the point where you need a managed pool?

Explore DataImpulse residential, datacenter, and mobile proxies →

Affiliate disclosure: this is an affiliate link. I may receive a commission from qualifying purchases or registrations at no additional cost to you.

In this post, I’ll show the basic way I test public HTTP proxies in Python, which metrics I care about, and the point where a managed residential or datacenter proxy network starts to make more sense.

What I Actually Want to Know About a Proxy

When I test a proxy, “does it connect?” is only the first question.

I usually care about:

Whether the connection succeeds
Response latency
Whether HTTPS works
Whether the exit IP is actually different
Country or location consistency
How often the proxy fails across repeated requests
Whether the proxy survives for more than a few minutes
Whether the workload needs rotation or a sticky session

A proxy can pass a one-time test and still be useless in production.

A Minimal Python Proxy Test

For a basic HTTP/HTTPS proxy check, Python’s requests library is enough.

import time
import requests

proxy = "http://127.0.0.1:8080"

proxies = {
    "http": proxy,
    "https": proxy,
}

started = time.perf_counter()

try:
    response = requests.get(
        "https://httpbin.org/ip",
        proxies=proxies,
        timeout=8,
    )
    response.raise_for_status()

    latency = time.perf_counter() - started

    print("Status:", response.status_code)
    print("Latency:", round(latency, 2), "seconds")
    print("Response:", response.json())

except requests.RequestException as exc:
    print("Proxy failed:", exc)

For a real checker, I would not stop at one successful request.

Test the Same Proxy More Than Once

A proxy that works once and fails four times is not a reliable proxy.

import requests
import time

def test_proxy(proxy, attempts=5):
    proxies = {"http": proxy, "https": proxy}
    successes = 0
    latencies = []

    for _ in range(attempts):
        started = time.perf_counter()

        try:
            response = requests.get(
                "https://httpbin.org/ip",
                proxies=proxies,
                timeout=8,
            )
            response.raise_for_status()
            latencies.append(time.perf_counter() - started)
            successes += 1
        except requests.RequestException:
            pass

    return {
        "proxy": proxy,
        "success_rate": (successes / attempts) * 100,
        "average_latency": (
            round(sum(latencies) / len(latencies), 2)
            if latencies else None
        ),
    }

Now I have something more useful than working = true.

Testing a Proxy List Concurrently

Public proxy lists can contain hundreds or thousands of entries, so sequential testing is slow.

from concurrent.futures import ThreadPoolExecutor, as_completed
import requests
import time

TEST_URL = "https://httpbin.org/ip"

def check_proxy(proxy):
    started = time.perf_counter()

    try:
        response = requests.get(
            TEST_URL,
            proxies={"http": proxy, "https": proxy},
            timeout=6,
        )
        response.raise_for_status()

        return {
            "proxy": proxy,
            "working": True,
            "latency": round(time.perf_counter() - started, 2),
        }
    except requests.RequestException:
        return {
            "proxy": proxy,
            "working": False,
            "latency": None,
        }

proxy_list = [
    "http://127.0.0.1:8080",
    "http://127.0.0.1:3128",
    "http://127.0.0.1:8888",
]

with ThreadPoolExecutor(max_workers=20) as executor:
    futures = [
        executor.submit(check_proxy, proxy)
        for proxy in proxy_list
    ]

    results = [
        future.result()
        for future in as_completed(futures)
    ]

working = [item for item in results if item["working"]]
print(f"Working proxies: {len(working)}/{len(results)}")

For large lists, I would also limit concurrency, cache recent results, store last_checked_at, and avoid hammering one test endpoint.

Why Free Proxy Lists Become Expensive

Public proxies are useful for learning, but they become expensive in developer time when you start dealing with:

Dead proxies
Connection timeouts
High latency
Wrong country data
HTTPS failures
Short lifetimes
Constant pool maintenance

Even when the proxy itself costs $0, you still pay in retries, compute time, monitoring, and maintenance.

That is why I care more about:

cost per successful operation

than simply the lowest advertised price.

Rotating vs Sticky Sessions

A rotating setup can look like:

Request 1 -> IP A
Request 2 -> IP B
Request 3 -> IP C
Request 4 -> IP D

A sticky session keeps the same exit IP for a period of time:

Request 1 -> IP A
Request 2 -> IP A
Request 3 -> IP A
Request 4 -> IP A

Neither is universally better. It depends on the workflow.

Residential, Datacenter, or Mobile?

When I move from public proxies to a managed provider, I still do not automatically choose residential proxies.

Datacenter proxies

A good first option when:

Cost matters
High speed matters
The target works fine with datacenter IPs
Residential characteristics are unnecessary

Residential proxies

More relevant when:

Geographic diversity matters
ISP-associated IPs are required
Localized search or pricing is being tested
A larger rotating residential pool is useful

Mobile proxies

More specialized for:

Mobile-network testing
Carrier-specific testing
Mobile localization
Workloads that specifically need mobile IP ranges

Using a more expensive proxy type when the workload does not need it is wasted budget.

When I Would Switch to a Managed Proxy Network

For me, the tipping point is simple:

When proxy maintenance becomes infrastructure work.

If a project requires continuous scraping, SEO monitoring, price tracking, international market research, ad verification, or reliable location targeting, I would rather use a managed pool.

One option is DataImpulse, which provides residential, datacenter, and mobile proxies under the same platform.

At the time of writing, its published entry pricing includes:

Residential proxies from $1/GB
Datacenter proxies from $0.50/GB
Mobile proxies from $2/GB

Its residential network is advertised as covering 90M+ residential IPs in 195+ countries.

Pricing and availability can change, so always check the current provider page before choosing a plan.

Check current DataImpulse proxy options and pricing →

My Public Proxy Tester Project

If you are still in the experimentation stage, I also maintain an independent open-source project:

Proxy Tester on GitHub →

This project is not connected to DataImpulse and does not use DataImpulse proxy pools. It is a separate public project intended for testing publicly available proxies.

A Practical Decision Flow

Only learning/testing?
        |
       Yes
        |
Public proxies + checker
        |
        v
Need continuous reliability?
        |
       Yes
        |
Can datacenter IPs handle it?
       / \
     Yes  No
      |    |
Datacenter  Need ISP-associated IPs?
             / \
           Yes  No
            |    |
      Residential  Re-check requirements

Mobile proxies belong in their own branch when a mobile carrier IP is specifically required.

Final Thoughts

Public proxies and managed proxy networks solve different problems.

I like public proxies for learning, prototyping, checker development, and small experiments.

I prefer managed proxies when I need reliability, geographic targeting, larger pools, rotation, sticky sessions, and predictable infrastructure.

If your project has already reached that second stage:

Explore DataImpulse proxies →

Disclosure

This post contains affiliate links to DataImpulse. I may receive a commission from qualifying registrations or purchases made through those links at no additional cost to you.

Use proxies, scraping tools, and automation only in ways that comply with applicable law, website terms, and the permissions you have for the systems you access.

DEV Community: Mehmet Bulat