Logo
Tutorials

Pool Maintenance

Re-check old pools, prune weak entries, retag rows, and prepare source pools for rotators.

Pools are where one-off proxy work becomes reusable inventory. A pool should tell a story: where the entries came from, how far they have been tested, and what they are safe to feed next. If every task dumps into one giant pool, the pool becomes a junk drawer. If you keep staged pools, you can always tell the difference between raw intake and something ready for a rotator.

Think of pool maintenance as a loop, not a cleanup chore you do once. Proxy quality decays. Sources repeat bad endpoints. A proxy that passed last week can fail today. The app gives you the tools to refresh a pool without rebuilding your entire workflow from scratch.

The Maintenance Loop

Open the pool, send its entries to Check Proxies, and filter to alive rows. From there, send the survivors to Benchmark Proxies. If anonymity matters, send the stable winners to Test Proxy Leaks. Save the final set into a clean pool with tags that describe what happened: checked, benchmarked, leak-clean, rotation-source, or whatever naming scheme your team actually uses.

The important part is that the final pool should contain rows that passed the current workflow, not rows that merely existed in the old pool.

Merge Or Replace

Use Merge when you are adding new candidates into a pool and want to preserve existing entries. Merge is also useful when you want exact duplicates to collapse while source metadata and tags carry forward.

Use Replace when the pool is meant to represent the current truth. For example, if rotation source should contain only rows that passed today's check/benchmark/leak-test flow, replace it with the final reviewed set.

Use New pool when you are changing workflow stage. A pool named raw extracted should not quietly become leak clean. Create a new pool and make the stage obvious.

Pool stageWhat belongs there
raw extractedUnchecked candidates from extractor runs.
checked aliveRows that passed Proxy Checker recently.
benchmark winnersRows with acceptable pass rate and latency.
leak cleanRows that passed the leak-test criteria for the workflow.
rotation sourceFinal curated source for a Rotation Engine rotator.

You do not need every stage for every job. Small workflows can skip straight from checked rows to final export. Long-lived rotators should be more disciplined.

Preparing A Pool For Rotation

Rotation Engine will make weaknesses visible quickly. If the source pool is stale, you will see cooling, quarantine, failure counts, and frequent switches. Before a pool becomes a rotator source, re-check it, benchmark it, and remove rows that repeatedly fail. Keep protocol mix intentional: a rotator built from unknown mixed protocols is harder to troubleshoot than one built from rows you already understand.

If a rotator starts quarantining a lot of entries, resist the urge to only loosen policy. First ask whether the pool itself is bad. Usually the fix is to rebuild the pool from fresh checker and benchmark results, then tune policy after the source quality is sane.

Tagging That Actually Helps

Tags are most useful when they describe a decision you made. checked, alive, benchmark-winner, leak-clean, manual-review, rotation-source, chain-candidate, and country or provider hints are useful. Vague tags like good are less helpful because they do not say why the row is good.

Keep one curated pool for the thing a runtime actually uses, and keep raw intake in a different pool. That separation makes replacement safe and makes later debugging much less miserable.

On this page