下午三点，刚泡好的咖啡还没抿一口，正准备摸鱼刷两句手机，电脑屏幕突然就炸了——爬虫日志疯狂滚屏，全是红彤彤的警告，什么HTTP 403、Request Denied、Access Blocked，看得人心里一紧。

我赶紧点开代理后台，心凉了半截：昨天还好好用着的3000个代理IP，今天清一色显示“不可用”，一个能打的都没有。

更坑的是，这个爬虫任务已经跑了俩小时，数据才爬了一半。重新从头跑？那俩小时直接白瞎，等于半天活全干废；不从头跑？那堆断点数据乱七八糟的，手动整理起来能把人逼疯。

真不是我夸张，做爬虫的兄弟，十有八九都遇过这种崩溃时刻，说多了都是泪。

第一步：别慌，先搞清楚代理是“怎么死的”

很多人一看到代理失效，第一反应就是急着找新代理，东搜西找忙得脚不沾地，其实大多是瞎忙活。

关键不是找新的，而是先弄明白：这代理，到底是怎么凉的？

我总结了三种最常见的“死法”，一看一个准：

第一种，被目标网站封了。这是最常发生的情况，比如对方网站升级了风控，直接把你用的整个代理IP段都拉黑了。特征很明显：不是所有IP都不能用，一部分能正常访问，另一部分一用就报错。

第二种，代理服务商自己崩了。就是服务商那边出问题了，接口要么返回空列表，要么所有IP都连不上。这种更坑，特征是：所有代理同时失效，不管你换哪个网站爬，都是同样的报错，跟目标网站没关系。

第三种，自己的代码出bug了。比如代理调用的API密钥过期了，自己忘了续期；或者请求库更新了，格式不兼容，导致代理调用失败。这种最冤，特征是本地测试的时候好好的，一部署到线上就直接崩掉。

怎么快速判断？教你们一个笨办法，特别好用——随便拿两个失效的代理，去访问两个完全不相关的网站（比如百度和淘宝）。如果两个网站都打不开，那问题肯定在代理服务商或者你自己的代码上；如果只有原来要爬的目标网站打不开，那就是被对方针对了，网站把你代理封了。

第二步：能救多少是多少，别盲目推翻重来

搞清楚问题根源后，别着急把之前的工作全推翻，能救一点是一点，省得白费功夫。

如果你的爬虫是“增量爬取”——就是每次只抓新更新的数据，不重复爬旧的，那恢复起来最简单：直接换一家代理服务商，接着往下跑就行。

其实绝大多数爬虫任务，根本不要求所有IP都来自同一家供应商。我建议大家平时写代码的时候，一定要预留一个“备用代理池”的接口，主服务商崩了，代码自动切换到备用的。这个配置平时写着觉得多余，真到关键时刻，能让你少熬一个通宵，亲测有效。

但如果是“全量爬取”，比如要抓几百万条商品信息、新闻数据，那情况就棘手多了。这时候，“断点续爬”这个功能就救大命了。

说白了，断点续爬就是在爬虫跑的时候，每次请求成功或者失败，都把当前爬取的位置记下来——比如最后爬完的页码、最后一个商品的ID，存到本地或者数据库里。等代理失效了，不用从头开始跑，直接从记录的那个断点继续往下爬就行，之前爬的数据也不会浪费。

真心建议大家，所有爬虫项目都加上这个功能，不夸张地说，它救过的项目，比任何一个高端代理池都多。我之前就因为没加这个，代理崩了，从头爬了三天三夜，现在想起来还心疼。

第三步：长期来看，别把所有鸡蛋放一个篮子里

经历过几次代理全崩的教训后，我算是摸透了一个规律：再大的代理服务商，也不敢保证100%不翻车，总有掉链子的时候。

所以长期做爬虫，稳妥的做法就一个：分散风险，别把宝全押在一家身上。具体怎么做，给大家分享三个实操建议，都是我踩坑踩出来的经验：

1. 同时接入两到三家代理服务商，用代码做动态调度，这家崩了自动切下一家，不用手动操作；

2. 自己在本地维护一个自建代理池，把验证通过、能用的IP缓存起来，就算服务商全崩了，也能靠自建池撑一会儿；

3. 优化代码逻辑，每次请求失败，别反复重试同一个代理，直接自动切换下一个，减少被封的概率，也能提高效率。

可能有人觉得这套机制很复杂，其实不用自己从零开发，市面上很多开源方案（比如ProxyPool）已经做得很成熟了，花半天时间部署好，后面能帮你省下几十个小时的救火时间，绝对划算。

总结

代理全部失效这件事，做爬虫的人早晚都会遇到，躲不掉的。区别只在于：有人提前做了预案，半小时就能恢复正常；有人手忙脚乱，东奔西跑，折腾到半夜还没搞定。

下次再看到满屏的红色报错，别慌，先深呼吸，按顺序排查：是被网站封了？还是服务商崩了？或者是自己的代码出问题了？

记住，别轻易从头开始跑，能续爬的地方尽量续爬，能省不少功夫。另外，今天有空的话，不妨检查一下你的爬虫项目，看看有没有加断点续爬和备用代理的配置。

要是还没有，真的该补上了——别等代理崩了，才追悔莫及。