代理IP任务失败之后该怎么处理，取决于失败的原因。同样是一次没拿到结果，可能出在网络这一段，也可能出在目标那一端，两者的应对方式完全不同。把失败分成几类，再决定是原样重试还是换一条线路，处理起来就不靠猜了。
先分清失败的类型
- 连不上
- 本机与代理服务之间没建立起来，多半是位置端口或网络问题
- 连上被拒
- 代理服务拒绝了这次请求，常见于凭据过期或来源未登记
- 中途断开
- 连接建立了但中途断掉，多与线路状况有关
- 拿到结果但不对
- 连接正常，返回的内容不符合预期，问题在目标那一端
这四类里，前两类与接入有关，第三类与线路有关，第四类与目标有关。分类的意义在于处理方向：接入问题重复多少次都一样，需要改配置；线路问题换一条线路往往就好了；目标那一端的问题，换线路也不解决，要调整请求本身。
两类处理方式
一类是原样重试，同一条件再发一次，适用于偶发的网络抖动。另一类是换一条线路再试，适用于某个来源已经被目标拒绝的场合。两种方式的取舍在于代价：原样重试便宜但可能一直失败，换线路有效但会打乱既有的安排。代理IP的线路池让换线路这件事随时可做，这也是它在这类场景里被采用的原因之一。
- 先原样重试一次 排除偶发抖动，多数临时问题这一步就过去了
- 仍然失败就换线路 同一条线路连续失败两次以上，换一条更划算
- 换线路之后仍然失败 方向转到请求本身，检查参数和内容
重试几次就该停
同一个请求连续失败到三次，继续重试的收益就很低了。这时候应该停下来看记录，继续硬跑只会把时间耗掉。设一个上限还有一个好处：任务不会被一个永远过不去的请求拖住，整体进度保得住。
接入问题改配置，线路问题换线路，目标问题调请求。
把失败分类，处理方式自然就有了。
失败处理做得好，任务的成功率会稳定在一个可预期的水平上。关键是别把所有失败当成同一件事，也别用一个固定动作去应付所有情况。代理IP在这里的作用是让换一条线路变成一个随时可用的选项，处理起来多一条退路。先分类再处理，重试才有意义。