代理采集失败后，最危险的做法是无限重试。穿云代理可以提供稳定出口，但重试策略必须按错误类型分层：网络超时可以短退避，地区漂移要停队列，字段缺失要回到哨兵页验证。这样才能降低流量浪费，也避免把短时异常放大成持续拥塞。
先把失败分成三类
重试策略不能只看“失败”两个字。不同失败背后的修复动作完全不同，把它们放进同一个重试队列，容易让系统越跑越乱。建议先按返回结果和页面内容分成三类。
| 失败类型 | 第一动作 | 不要做什么 |
|---|---|---|
| 连接超时 | 短退避后少量重试 | 不要立刻扩大并发 |
| 地区漂移 | 暂停市场队列，固定出口规则 | 不要把错误页面写入正式数据 |
| 字段缺失 | 回到哨兵页检查页面结构 | 不要只换 IP 后继续跑全量 |
设置重试上限和退避间隔
每个队列都应该有明确上限。对公开页面采集来说，短时间内连续失败通常说明约束已经变化，而不是“再试几次就好”。穿云代理的使用重点是让队列恢复稳定，而不是把所有失败都交给代理池吸收。
一个可执行的起点是：超时类错误最多重试两次，每次增加退避；地区类异常直接暂停该市场队列；字段类异常先用固定哨兵页复测。只要哨兵页仍异常，就不应继续扩大采集范围。
上线前做一次小流量演练
新的重试策略上线前，先用少量页面跑 30 分钟。观察成功率、字段完整率和重试分布是否稳定。如果重试集中在同一类错误，说明问题还没有被解决；如果错误分布下降且字段完整，才适合逐步增加任务量。
- 先跑固定哨兵页，不直接跑全量目标。
- 把每次重试的原因写入日志，避免只记录最终失败。
- 按市场队列观察，不把不同地区混成一个统计值。
FAQ
重试次数设置越多越稳吗？
不是。重试次数过多会增加流量成本，并可能把短时拥塞放大。更稳的做法是少量重试后暂停队列，先确认地区、节奏和字段是否正常。
什么时候应该换代理出口？
当同一地区、同一节奏下哨兵页持续异常，且不是目标页面结构变化时，再考虑调整出口资源。不要把换出口当成所有失败的第一动作。
字段缺失可以直接补抓吗？
可以补抓，但要先确认缺失来自临时波动还是页面变体。如果输入条件已经漂移，直接补抓只会得到更多不可比数据。