At first, the architecture usually looks like this:

request
   |
pick proxy
   |
send request
   |
done

Then production happens.

DataImpulse provides usage-based proxy options here →

Some proxies time out. Some become extremely slow. Some work for five minutes and disappear. Others technically respond but fail repeatedly against the workload you actually care about.

At that point, random proxy selection is no longer enough.

A useful proxy layer needs to answer several questions:

• Which proxies are healthy?

• Which ones are currently failing?

• How long should a failed proxy stay out of rotation?

• Should every request use a different IP?

• When should a session keep the same IP?

• How should latency affect proxy selection?

• When does maintaining the pool cost more than using managed infrastructure?

This article builds a small proxy rotation model around those questions.

If the project already needs a managed residential, datacenter, or mobile proxy pool instead of maintaining public IPs manually, DataImpulse provides usage-based proxy options here →

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

Now let’s build the logic behind the decision instead of blindly rotating IPs.

Random Rotation Is Not Enough

The simplest implementation selects a random proxy:

import random

proxies = [
    "http://proxy-a:8080",
    "http://proxy-b:8080",
    "http://proxy-c:8080",
]

proxy = random.choice(proxies)

That works for a demo.

But suppose:

proxy-a -> 95% success rate
proxy-b -> 20% success rate
proxy-c -> 80% success rate

Pure random selection still sends roughly one third of the traffic through proxy-b.

The pool contains quality information, but the algorithm ignores it.

A better solution is to track proxy health.

Representing Proxy Health

Start with a small state model:

from dataclasses import dataclass, field
from time import time


@dataclass
class ProxyState:
    url: str

    requests: int = 0
    successes: int = 0
    failures: int = 0

    average_latency: float | None = None

    consecutive_failures: int = 0

    disabled_until: float = 0.0

    last_success: float | None = None
    last_failure: float | None = None

Each proxy now carries historical information rather than simply being a string.

We can calculate success rate:

def success_rate(proxy: ProxyState) -> float:
    if proxy.requests == 0:
        return 1.0

    return proxy.successes / proxy.requests

For example:

Proxy A
requests: 100
successes: 94

success_rate = 0.94

Already much more useful than:

working = true

Latency Matters Too

A proxy that succeeds consistently but takes 12 seconds per request may still be a poor choice.

We can maintain a rolling latency average.

def update_latency(proxy: ProxyState, latency: float):
    if proxy.average_latency is None:
        proxy.average_latency = latency
        return

    alpha = 0.25

    proxy.average_latency = (
        alpha * latency
        + (1 - alpha) * proxy.average_latency
    )

This uses an exponential moving average.

Recent latency has more influence, while older observations still contribute.

That is useful because network conditions change.

Creating a Health Score

Now combine success rate and latency.

There is no universal scoring function, but a simple one is enough to demonstrate the idea:

def proxy_score(proxy: ProxyState) -> float:
    reliability = success_rate(proxy)

    latency = proxy.average_latency or 1.0

    latency_penalty = min(
        latency / 10,
        0.5
    )

    failure_penalty = min(
        proxy.consecutive_failures * 0.1,
        0.5
    )

    return max(
        0,
        reliability
        - latency_penalty
        - failure_penalty
    )

Now proxies can be ranked.

ranked = sorted(
    proxies,
    key=proxy_score,
    reverse=True,
)

A healthy proxy naturally receives more traffic.

An unstable one gradually falls out of favor.

Do Not Retry a Dead Proxy Forever

Another common mistake is retrying failed proxies immediately.

Imagine a proxy is completely offline.

Without cooldown logic:

Request 1 -> Proxy A -> failure
Request 2 -> Proxy A -> failure
Request 3 -> Proxy A -> failure
Request 4 -> Proxy A -> failure

That wastes time.

Instead, apply temporary quarantine.

from time import time


def mark_failure(proxy: ProxyState):
    proxy.requests += 1
    proxy.failures += 1
    proxy.consecutive_failures += 1
    proxy.last_failure = time()

    if proxy.consecutive_failures >= 3:
        proxy.disabled_until = time() + 60

Then filter unavailable proxies:

def available(proxy: ProxyState) -> bool:
    return time() >= proxy.disabled_until

Now three consecutive failures remove the proxy from rotation for one minute.

Exponential Backoff Is Better

A fixed cooldown works, but repeated failures should probably lead to longer cooldown periods.

def calculate_backoff(failures: int) -> int:
    return min(
        2 ** failures,
        300
    )

Example:

Failure 1 -> 2 seconds
Failure 2 -> 4 seconds
Failure 3 -> 8 seconds
Failure 4 -> 16 seconds
Failure 5 -> 32 seconds
...
Maximum -> 300 seconds

Then:

proxy.disabled_until = (
    time()
    + calculate_backoff(
        proxy.consecutive_failures
    )
)

This prevents unstable proxies from continuously consuming resources.

Successful Requests Should Recover the Proxy

A proxy should also be able to recover.

def mark_success(
    proxy: ProxyState,
    latency: float,
):
    proxy.requests += 1
    proxy.successes += 1

    proxy.consecutive_failures = 0
    proxy.last_success = time()

    update_latency(proxy, latency)

This is important because temporary network failures happen.

One bad request should not permanently remove a proxy.

Weighted Proxy Selection

Instead of selecting the highest-scoring proxy every time, use weighted randomness.

Why?

Because always selecting the best proxy creates another problem:

best proxy
best proxy
best proxy
best proxy
best proxy

Eventually the “best” proxy receives almost all the load.

Weighted selection distributes traffic while still favoring healthier proxies.

import random


def choose_proxy(proxies):
    candidates = [
        proxy
        for proxy in proxies
        if available(proxy)
    ]

    if not candidates:
        raise RuntimeError(
            "No healthy proxies available"
        )

    weights = [
        max(proxy_score(p), 0.01)
        for p in candidates
    ]

    return random.choices(
        candidates,
        weights=weights,
        k=1,
    )[0]

Now a healthy proxy gets a higher probability rather than exclusive ownership of the workload.

Putting It Together

A request function could look like this:

import time
import requests


def request_with_proxy(
    url,
    proxies,
    timeout=8,
):
    proxy = choose_proxy(proxies)

    started = time.perf_counter()

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

        response.raise_for_status()

        latency = (
            time.perf_counter()
            - started
        )

        mark_success(
            proxy,
            latency,
        )

        return response

    except requests.RequestException:
        mark_failure(proxy)
        raise

The proxy pool is now adaptive.

Poor proxies slowly receive less traffic.

Repeated failures temporarily remove them.

Successful requests allow them to recover.

Rotation and Sessions Are Different Problems

Many people use “proxy rotation” as if changing the IP on every request is always desirable.

It is not.

Consider this workflow:

GET /login
POST /login
GET /dashboard
GET /account

If every request comes from a different IP and possibly a different country, the application may behave differently.

Sometimes the desired behavior is:

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

Then a new session can use:

Session 2 -> IP B

This is the idea behind a sticky session.

Rotation and stickiness are not opposites in the sense that one is better.

They solve different requirements.

A Simple Sticky Assignment

For an internal pool, a mapping can associate an application session with a proxy:

session_proxy = {}


def proxy_for_session(
    session_id,
    proxies,
):
    current = session_proxy.get(
        session_id
    )

    if (
        current
        and available(current)
    ):
        return current

    selected = choose_proxy(proxies)

    session_proxy[session_id] = (
        selected
    )

    return selected

Now the session remains consistent unless the proxy becomes unhealthy.

Public Proxy Pools Have a Maintenance Cost

This architecture is useful, but it also exposes an important fact.

The bigger a public proxy pool becomes, the more infrastructure you need around it.

You start adding:

• Validation workers

• Health scoring

• Persistent storage

• Geo-IP verification

• Retry queues

• Cooldowns

• Monitoring

• Metrics

• Alerting

• Re-testing jobs

• Proxy replacement

At some point, the question changes.

It stops being:

How can I build a better proxy checker?

and becomes:

Why am I operating proxy infrastructure at all?

When I Would Use Datacenter Proxies

Datacenter proxies are usually the first managed option I would test.

They often provide:

• High throughput

• Low latency

• Lower pricing

• Predictable infrastructure

If the target workload works with datacenter IPs, there may be little reason to immediately move to residential traffic.

This is also why comparing providers purely by residential proxy pricing can be misleading.

The cheapest proxy is often the cheapest appropriate proxy type.

When Residential Proxies Become Useful

Residential proxies become more relevant when the project requires things such as:

• ISP-associated IP addresses

• Geographic diversity

• Country-specific testing

• Local search monitoring

• International pricing research

• Large rotating IP pools

A managed network also removes much of the health-checking infrastructure described above.

Instead of maintaining thousands of individual IPs, the application connects to a gateway and lets the provider handle the pool.

An Example Managed Option

One provider that exposes residential, datacenter, and mobile proxy products under one platform is DataImpulse.

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

• Residential: from $1/GB

• Datacenter: from $0.50/GB

• Mobile: from $2/GB

Its residential network is advertised as including more than 90M residential IPs across 195+ countries.

That makes the architecture different.

Instead of:

Application
    |
local proxy database
    |
health checker
    |
rotation service
    |
thousands of public proxies

you can potentially move toward:

Application
    |
managed proxy gateway
    |
provider-managed IP pool

For workloads where maintaining the pool has become its own subsystem, that trade-off can be worth evaluating.

Explore current DataImpulse residential, datacenter and mobile proxy options →

Testing Public Proxies Is Still Useful

None of this means public proxies are useless.

They are great for:

• Learning

• Experiments

• Networking projects

• Proxy checker development

• Proof-of-concept systems

I also maintain an independent open-source proxy testing project:

Proxy Tester on GitHub →

This project is completely separate from DataImpulse.

The public proxies tested with it are not DataImpulse IPs, and the project does not use DataImpulse's residential, datacenter, or mobile proxy pools.

A Better Architecture

For a production-oriented proxy layer, I would separate responsibilities:

                   +------------------+
                   |  Application     |
                   +--------+---------+
                            |
                            v
                   +------------------+
                   | Proxy Selector   |
                   +--------+---------+
                            |
             +--------------+--------------+
             |                             |
             v                             v
     +---------------+             +---------------+
     | Health Store  |             | Session Store |
     +---------------+             +---------------+
             |
             v
     +---------------+
     | Proxy Pool    |
     +---------------+

The selector should not know everything.

It should ask other components for:

• Current health

• Session assignment

• Availability

• Proxy capabilities

This makes it much easier to replace the underlying proxy source later.

Public list today.

Datacenter provider tomorrow.

Residential pool later.

The application itself does not have to care.

The Real Metric: Successful Work

The more proxy infrastructure I build, the less interested I become in nominal proxy price.

Suppose one provider costs:

$0.50 / GB

but generates a high retry rate.

Another costs:

$1.00 / GB

but successfully completes almost every operation.

The first is cheaper only if the application actually gets useful work from that traffic.

The metric I care about is closer to:

total infrastructure cost
-------------------------
successful operations

And infrastructure cost includes more than bandwidth:

proxy traffic
+ retries
+ compute
+ engineering time
+ monitoring
+ maintenance

That calculation often changes which solution is actually “cheap.”

Final Thoughts

A reliable proxy system is not simply:

random.choice(proxy_list)

A production-oriented pool benefits from:

• Health tracking

• Latency measurements

• Weighted selection

• Failure cooldowns

• Exponential backoff

• Recovery logic

• Sticky session support

• Metrics

Building those systems is useful engineering work.

It is also exactly what reveals when operating a public proxy pool is no longer worth the effort.

For experiments, public proxies can be excellent.

For sustained workloads, managed datacenter or residential proxy infrastructure may reduce the operational burden significantly.

The important part is to optimize for successful work, not simply the lowest advertised proxy price.

Disclosure

This article contains affiliate links to DataImpulse. If a qualifying registration or purchase is made through those links, I may receive a commission at no additional cost to the reader.

The GitHub Proxy Tester linked above is my independent open-source project and is not affiliated with or supplied by DataImpulse.

Use proxy infrastructure and automated data collection only where you have the necessary authorization and in accordance with applicable law and service terms.