Proxy Pool Cooldowns: Track Failures and Probe Recovery

A proxy misses one deadline. The pool deletes it. An hour later, the proxy is healthy again, but your application has no way to discover that because it threw away the record.

Removal can be appropriate for a revoked account or an endpoint the operator retired. A transient failure deserves a different state.

Keep enough history to make the next decision

Eligible

Available for ordinary work under the current policy.

Cooling down

Temporarily withheld until a recorded deadline.

Probe permitted

One controlled attempt may assess recovery.

Disabled

An operator or durable condition removed it from service.

Store the reason and stage with the transition. A connection refusal, rejected credential, slow response body, and destination HTTP error should not all increment an undifferentiated “dead proxy” counter.

Use an elapsed-time clock for an in-process cooldown. A monotonic clock avoids making a short wait depend on a wall-clock adjustment. Do not persist a monotonic timestamp as though it were a portable date shared by other machines; a distributed scheduler needs a separately defined time and ownership model.

Recovery should not release a stampede

When the deadline expires, permit a small recovery attempt rather than sending the entire waiting queue at once. A successful attempt can restore eligibility; another failure can extend the pause according to a bounded policy.

Choose the probe for the job it is meant to predict. A successful TCP connection is not a complete HTTP or SOCKS transaction. An unrelated IP-check page does not establish that the required destination is reachable or permitted.

No universal cooldown duration follows from the word proxy. Set it from the operation's latency budget, the service's behavior, and the consequences of another failed attempt. Preserve the endpoint record so a temporary interruption does not silently become a permanent loss of capacity.