代理池隔离与恢复：避免异常出口过早回流

轮换代理或住宅代理池的整体指标可能看似正常，但少量出口会反复失败、短暂通过一次探测后又马上出错。若系统在看到一次成功后就恢复满量流量，出口会在“健康”和“异常”之间抖动，造成超时、会话漂移、重复重试和有效结果下降。

隔离是一种临时运维状态，目的不是惩罚出口，也不是绕过目标站的访问决定。它暂停给可疑路径分配正常业务，同时收集足够证据，判断问题来自客户端、网关、出口、目标站还是应用逻辑。

先分类故障，再决定隔离

单次失败不足以驱逐出口。超时可能发生在 DNS、客户端队列、代理网关、出口网络、目标站或业务期限。建议使用低基数原因类别：

目标站范围的证据应单独保存。某出口在一个获准目标上失败，不等于它对所有目标都异常；但任何情况下都不能用轮换规避访问控制或速率限制。

使用五态状态机

1. 健康： 可承担正常流量份额。
2. 可疑： 仅保留极小流量，在短确认窗口内收集证据。
3. 已隔离： 不承载生产流量，只允许受控探测。
4. 观察恢复： 探测通过后接收少量金丝雀流量。
5. 恢复健康： 只有观察窗口所有门槛通过后才恢复正常权重。

每次状态转换记录原因码、UTC 时间、单调时长、路由别名、地区、地址族、网关别名、出口指纹和目标类别。使用带密钥指纹，不公开完整住宅地址；日志不得包含代理密码、Cookie 或无必要个人数据。

明确定义隔离触发器

隔离应同时依赖多个信号，并设置最小样本量。例如：

可隔离 =
  请求数达到最小样本
  且分类失败率超过阈值
  且至少两个工作节点观察到失败
  且证据位于规定时间窗内

对受控目标上的 TLS 身份不匹配等严重事件，可采用较小计数；对噪声较大的目标响应，则应扩大样本并与全池基线比较。目标站整体故障不应导致所有出口被驱逐。

还要限制同时隔离的最大容量。触及上限时，应削减或排队非关键任务、发出告警并保护健康容量，不能静默切换为本机直连。可先用代理并发饱和测试确定自动隔离前需要保留的余量。

让冷却时间随复发增加

固定的短延迟容易造成抖动。保存隔离次数，复发时延长冷却：

冷却时间 = min(基础冷却 × 复发倍数, 最大冷却)

加入有限抖动，避免大量出口在同一时刻重新探测。一次成功不能立即清零历史，应在较长健康周期后逐步降低复发倍数。

具体数值取决于请求频率、池规模和业务期限，但必须具有下限、上限、复发记忆与随机化。配置值应随结果保存，确保后续审计可复现。

恢复探测必须接近真实业务

TCP 握手成功远远不够。低流量、获准的恢复探测至少应覆盖：

• 网关连接与代理认证；
• 预期的本地或远程 DNS 模式；
• 不关闭验证的 TLS 检查；
• 出口指纹与要求地区；
• 延迟是否处于规定范围；
• 自有或获准端点返回的有效业务标记；
• IPv4 与 IPv6 分开验证；
• 生产会使用的新连接和复用连接。

条件允许时使用两个独立工作节点。单一节点可能存在自身解析器、网络或时钟问题；跨节点一致成功比同一机器的连续请求更可信。

如果目标站已返回限速或拒绝访问，不应继续轮换探测寻找“能成功的出口”。恢复探测只验证服务健康，不规避策略。

连续证据通过后才进入观察恢复

出口必须在最小时间跨度内连续通过多次有效探测，才能进入观察恢复；同类故障再次出现时，应重置或延长门槛。

示例门槛包括：两个节点共三次有效探测；十分钟内没有传输或 TLS 失败；p95 延迟不超过全池基线加约定余量；每次地区与地址族正确；返回有效业务结果而不只是 HTTP 200；没有直连回退；重试量处于预算内。

这些只是示例，应依据自身基线设定并通过变更审核。

分阶段恢复业务流量

观察恢复先接收极少量幂等任务，再按 1%、5%、20% 和正常权重逐级放量，每级都设置观察窗口。门槛同时包含时间和请求数，避免低流量出口在没有足够证据时自动通过。

每阶段比较有效结果率、分类失败率、连接/TLS/首字节延迟分布、队列时间、活动并发、每个原始操作的重试数、会话与地区连续性，以及目标响应分布。

任何门槛失败都应返回隔离状态，并保留复发计数。不要在满量和零流量间来回切换。配合空闲超时与保活测试，避免陈旧复用连接造成虚假恢复或虚假失败。

区分出口、网关与目标范围

若同一网关后的多个出口同时失败，共因可能是网关、DNS 路径或客户端地区。至少维护三种范围：

• 出口范围： 同一指纹在多个节点异常；
• 网关范围： 多个出口只在某个网关后失败；
• 目标范围： 多条健康路径只对某类目标失败。

隔离大量出口无法修复坏网关；故障转移也不能抹掉出口证据。每条请求链都应保留路由标识。

用可决策指标而不是原始地址堆满看板

请求时长应记录为直方图，错误使用可预测、低基数分类。原始地址和不受控目标字符串会增加成本并泄露敏感信息。

至少记录健康、可疑、隔离和观察恢复出口数；按原因统计隔离与复发；稳定恢复用时；每个原始操作的请求次数；有效结果率。对状态快速切换、隔离比例上升、反复观察失败、健康容量耗尽，以及 HTTP 成功与业务成功之间的差距设置告警。

可结合HTTPS 代理 TLS 链路审计，补足信任边界验证。

上线步骤

1. 先以仅观察模式运行分类器，并与人工判断比较。
2. 只为一种高置信度故障类别启用隔离。
3. 设置严格的最大驱逐比例，强制代理场景必须关闭失败。
4. 初期由人工批准恢复，只有稳定证据支持的门槛才自动化。
5. 按地区和地址族逐步启用。
6. 演练网关级和目标级故障，确认不会误杀健康出口。
7. 每次策略变更后复盘误判、恢复时间和容量损失。

检查清单

• [ ] 已区分本地、代理、出口、目标与业务故障。
• [ ] 已定义最小样本量和确认节点数。
• [ ] 最大隔离容量不会摧毁池可用性。
• [ ] 冷却时间随复发增长并加入有限抖动。
• [ ] 探测覆盖认证、DNS、TLS、地区与有效结果。
• [ ] 不通过轮换绕过拒绝访问或限速。
• [ ] 观察恢复使用分阶段流量和明确门槛。
• [ ] 出口、网关和目标范围保持分离。
• [ ] 强制代理流量不会泄漏为直连。
• [ ] 日志不保存密码、Cookie 和原始个人数据。

常见问题

每个 403 或 429 都应隔离出口吗？

不应。这类响应通常反映目标认证、授权或速率策略。应尊重响应并检查获准集成，不能轮换出口绕过决定。

一次健康检查成功能恢复流量吗？

不能。一次探测可能恰好遇到短暂正常，也可能没有覆盖故障层。需要连续、代表性证据和有限的观察放量。

隔离会不会让容量不足？

会。必须限制驱逐比例、预留余量，并在容量不足时削减非关键任务，不能用无限重试掩盖问题。

是否应全局隔离某个出口？

只有证据证明出口全局异常时才这样做。目标级或网关级问题应保留其范围，避免移除仍然健康的路径。

合规说明

本流程仅用于获准运营或测试的代理资源、账号与目标。遵守合同、robots 与访问政策、速率限制、隐私义务和数据最小化要求。隔离与恢复用于提高可靠性，不得用于绕过封禁、冒充用户或掩盖被禁止的数据采集。