代理池冷却：追踪失败并探测恢复

一个代理错过了一次期限。池就把它删掉。一小时后，该代理又恢复健康，但你的应用无从发现这一点，因为它已经把记录丢掉了。

对于被吊销的账户或运维人员已退役的端点，移除可能是合适的。而暂时性故障应当得到另一种状态。

保留足够的历史以做出下一次判断

可用

在当前策略下可用于常规工作。

冷却中

暂时扣留，直到某个已记录的期限。

允许探测

一次受控尝试可以评估恢复情况。

已停用

运维人员或某种持久条件已将其移出服务。

把原因和阶段与状态转换一起保存。连接被拒、凭证被拒、响应体缓慢以及目标端 HTTP 错误，不应全都去增加一个不加区分的“死代理”计数。

对于进程内冷却，使用经过时间的时钟。单调时钟可避免让短暂的等待依赖墙钟调整。不要把单调时间戳持久化为仿佛它是可移植的、能被其他机器共享的日期；分布式调度器需要单独定义的时间与归属模型。

恢复不应释放一场踩踏

期限到期时，允许一次小规模的恢复尝试，而不是把整条等待队列一次性放出。成功的尝试可以恢复可用性；再次失败则可以按有界策略延长暂停。

探测要按它应当预测的工作来选择。成功的 TCP 连接并不是完整的 HTTP 或 SOCKS 事务。一个无关的 IP 检查页面并不能证明所需目标可达或被允许。

“代理”一词推不出任何通用的冷却时长。要依据操作的延迟预算、服务的行为以及再次失败尝试的后果来设定。保留端点记录，好让一次临时中断不会悄无声息地变成永久的容量损失。