Proxy Pool Health: How To Test And Retire Burned Proxies (2026)

I once bought a fresh batch of proxies on a Friday, pointed my scrapers at them, and for about a day it was beautiful. The jobs flew, the blocks were near zero, everything came back clean. By the middle of the next week, half of those addresses were quietly useless. Some were timing out, some were handing back CAPTCHA pages, and my overall block rate had crept up so slowly that I almost missed it.

Nothing had crashed. The pool had simply aged, and nobody was watching it age. That is the whole reason this piece exists: a proxy is a living thing you manage, not a static line in a config file.

A proxy pool is a fleet, not a receipt

The mistake I see most often is treating proxies as a one time purchase. You buy a list, paste it in, and assume it keeps working forever. It does not. Addresses get flagged, connections go stale, providers recycle their ranges, and the sites you visit keep learning.

The better mental model is a fleet. Think of the way a taxi company thinks about its cars: some are on the road earning right now, some are in the garage resting, and a few are broken and waiting to be retired. Your job is not to buy the fleet once. It is to always know which addresses are working, which are struggling, and which are done, and to keep the working set topped up as the others fall away.

What healthy means for one proxy

Health is not one thing. For a single proxy there are three separate questions, and they fail independently.

• Can you reach it? Does it connect, or does it refuse and time out?
• Is it fast enough? An address that answers but takes fifteen seconds is dragging your whole run down.
• Is it still trusted by your target? This is the one people forget. An address can be perfectly reachable and perfectly fast while being completely burned in the eyes of the site you care about, handing back a block page on every request.

Health is all three at once. A pool full of fast, reachable, flagged addresses is a pool full of dead weight that looks alive.

Passive and active health checks

There are two ways to learn the health of your pool, and you want both.

Passive checks watch what your real traffic is already telling you. Every request you send through a proxy is a free health check, because it came back with good data, or it came back slow, or it came back as a block. You are collecting that signal anyway, so record it against the proxy that carried it.

Active checks probe on a schedule. You send a cheap test request through each proxy every so often, to a target you control or a neutral endpoint, just to ask whether it is still alive before a real job leans on it. Passive tells you how the pool behaved; active tells you the pool is ready before you spend a run finding out the hard way.

The signals a proxy is going bad

The failure signals are not all the same, and the difference tells you what is actually wrong.

• Connection refused or repeated timeouts mean the proxy itself is down or unreachable. That is a plumbing problem.
• A slow crawl upward in latency means it is overloaded or dying.
• Rising CAPTCHA pages and soft blocks from a proxy that still connects mean that address specifically has been flagged by your target.

That last one is the dangerous signal, because the proxy looks fine at the network level. Only the body of the response gives it away, which is exactly why you inspect responses and do not trust a 200 alone.

Health is per target, not global

Here is the idea that changes how you build the whole thing. Health is not global, it is per target.

An address that is stone cold burned on one big site can be completely clean on another that has never seen it. So a proxy is not simply good or bad, it is good for this site and bad for that one. If you track health as a single yes or no per address, you will throw away perfectly useful proxies just because one aggressive target flagged them. Track the pairing instead, this proxy against that site, and you get far more life out of the pool you already paid for.

Quarantine, do not delete

When a proxy starts failing, the instinct is to delete it, and that is usually too harsh. Addresses recover. A site that flagged an IP an hour ago may forget about it in a day, especially on mobile and residential ranges where the same address gets handed to real people all the time.

So instead of deleting, quarantine. Pull the suspect address out of active rotation, let it rest for a while, then send a quiet probe later to see if it has come back to life. You cool it down rather than throwing it away, and a large share of the pool you would have binned comes back on its own.

Warm new proxies in

The opposite move matters just as much. Do not slam a fresh proxy with your full load on the first request. A brand new source suddenly firing a hundred requests a minute at a site is its own kind of red flag.

Bring new addresses in gently. Give them a smaller share of the traffic at first, watch how the target treats them, and only promote them to full duty once they have behaved. A slow warm up costs you a little speed on day one and saves you a burned address on day two.

Measure the pool, not just the proxy

Zoom out from the single address to the pool as a whole. You need a few numbers that tell you its overall health at a glance:

• How many addresses are usable right now, versus quarantined, versus dead.
• The pool wide success rate and block rate over the last hour.
• The latency spread, not just the average but the slow tail.

Watch those together and you stop reacting to individual proxies and start managing a fleet. You can see the pool getting tired days before it would have taken a job down with it.

Health decides what rotation is allowed to use

Health and rotation are two different jobs that people blur together. Rotation is how you spread requests across addresses so no single one carries a burst. Health is deciding which addresses are even allowed into that rotation in the first place.

The cleanest way to think about it: your health layer maintains a pool of currently trusted addresses, and your rotation layer only ever picks from that trusted set. A burned proxy should never be handed to the rotator. It should already have been pulled out.

Datacenter and mobile fail in different shapes

The kind of proxy you run changes how this plays out. Datacenter addresses tend to fail in blocks: a whole range gets recognized and flagged together, so when one goes, the neighbors often go with it.

Mobile and residential addresses behave very differently, because they are shared with real users and rotate naturally. An address that looks burned this minute can be genuinely clean an hour later through no effort of yours. That natural recovery is a big part of why I lean on mobile pools for the heavy, long running jobs: the pool heals itself between passes instead of just draining away.

Retire and replenish

No matter how well you tend it, a pool leaks. Some fraction of your addresses will burn out for good every week, and if you are not topping the pool up, you are slowly starving your own scrapers.

Build the churn into the plan. Budget for replacement addresses the way you would budget for any consumable, keep an eye on how many usable proxies you have left, and refill before you hit the floor, not after your jobs have already started failing. A pool is a stock you keep replenishing, not a tank you fill once and forget.

Automate the whole loop

A human cannot watch hundreds of addresses by hand, so the whole loop should run on its own:

• Every request feeds its outcome back into a health record for that proxy and target pairing.
• Addresses that cross a failure threshold get quarantined automatically.
• Quarantined ones get retested on a timer and either promoted back or retired for good.
• The pool reports its own headline numbers, so you only get pulled in when the whole fleet is trending down, not for every address that has one bad minute.

The honest limits

A healthy pool is about reliability, not permission. Keeping your addresses clean and rotating makes your collection steadier; it does not entitle you to take anything you could not take before. Public data stays the target, the robots file still gets respected, the site’s terms still mean what they say, and a gentle pace to each host still holds no matter how big or how healthy your pool is.

I run this infrastructure in production every day, and a well managed pool is the difference between a job that quietly holds together for months and one that rots in a week while every dashboard stays green. The full written picks I actually use, the exact health checks I log, the quarantine timers, and the mobile pool I run on, live at dataresearchtools.com.

Get new guides and videos first — join the Telegram channel.