小林是个程序员，接了个爬电商价格的需求。他花一百块买了个代理池，心想这下稳了。代码写完跑起来，一切看着都正常。
结果第二天一早到公司，人傻了：爬虫凌晨三点就彻底停了，日志里全是超时报错。
代理服务商半夜崩了两个小时，他的爬虫就在那儿傻傻重试两小时，最后直接躺平放弃。几百个商品价格，一条都没抓到。
小林盯着日志看了半天，突然想明白一件事：爬虫就跟开车一样，你不能默认路永远通畅。
代理会挂、IP会被封、网络会抽风。真正能稳定跑的爬虫，不是从来不出错，而是出错了知道自己该干嘛。
代理失效，其实就那么几种情况：
- 最常见：连接超时，代理堵死了，请求发出去没回音
- 其次：返回4xx/5xx，代理直接说“我处理不了”
- 最阴的：状态码200，但内容是假的——验证码页面、反爬假数据、价格全是0 这种不算网络错，但对你来说，这个代理已经废了。
遇到这些情况，爬虫不能只会死等或直接崩掉，必须给它装一套应急备胎系统。
先搞定重试：别瞎重试，要有策略
最简单的第一步是重试，但不是无脑狂点。
请求失败后，不能立刻再发，得等一等，而且等待时间要越来越长——也就是指数退避。
第一次失败等1秒，第二次2秒，第三次4秒。
既给代理一点恢复时间，又不会让你的请求像机枪扫射，反而被反爬盯上。
重试次数也要设上限，3～5次就够了。
超过这个次数还不行，说明代理不是抽风，是真挂了，再试也没用，必须换路。
重试解决临时波动，被封了就得换代理
如果只是网络抖动，重试能救回来。
但如果IP被网站封了，重试一万次也白搭，这时候必须切代理。
核心就一条：代理池绝对不能只有一个IP。
你得维护一个可用代理列表，爬虫从里面轮着用。
真正关键的是怎么切、什么时候切。
常用做法有两种：
- 给代理打健康分 成功加分，失败扣分，分数太低就标记不可用，暂时踢出池子，过一会儿再放回来试试——很多封禁是临时的，几小时就解。 这样坏代理自动淘汰，好代理留下来，越跑越稳。
- 失败达到上限立刻换下一个 别一失败就马上换代理，会疯狂浪费IP。 正确流程： 同一代理重试2～3次 → 确认真死 → 切换新代理 → 重新请求 既能扛住小波动，又不浪费时间在死代理上。
小林改完后的爬虫逻辑是这样的：请求外层包重试，失败等一会儿再试，同一个代理试3次不行，立刻从池子里拿新的，重新跑这条任务。
整个池子轮完还不行，就歇5分钟，再从头来一遍。
上线后效果立竿见影。有次他故意中途关掉一半代理，爬虫只是变慢了点，一条数据都没丢。
一个大坑：代理切换时，Session别乱带
很多人忽略一个问题：会话状态。如果网站要登录、靠Cookie维持状态，换代理后，旧Cookie还能用吗？
大概率不行。不少网站会把Cookie和IP绑定，换了IP还带旧Cookie，直接被判异常，账号一起凉。
稳妥做法：一个代理，配一个独立Session。代理挂了，整个Session一起扔掉，新代理建新Session，重新登录。虽然多几次请求，但稳定性直接拉满。
更阴的坑：代理没挂，但返回假数据
比代理失效更恶心的是：请求200成功，但数据是假的——价格0、标题乱码、隐藏商品、直接塞验证码。
不校验的话，脏数据全进库，后面全白干。解决办法很简单：加一层数据校验。
每次拿到页面，先快速检查几件事：
- 关键字段（价格、标题）有没有
- 数值是不是在合理范围
- 页面有没有出现“验证”“访问频繁”等关键词
只要异常，立刻判定代理被针对，踢掉换一个，重新请求。
小林加了校验后，又发现一个规律：被封的代理，基本都是请求太猛。他马上加了限流：每个代理每秒最多2个请求。调整完，代理寿命明显变长，切换次数少了一大半。
本质：用冗余换稳定，备胎才是安全感来源
代理切换这套东西，说到底就一个思路：用冗余换稳定。
一个代理不可靠，就多备几个；
一个请求会失败，就有策略重试；
一套链路会断，就自动换路。
小林后来把这段逻辑封装成一个小模块，取名叫“备胎系统”。
同事说名字太随意，他回了一句很实在的话：“备胎平时没人在意，但真用到的时候，能不能顶上，决定你是继续跑，还是原地趴窝。”
现在他的爬虫已经连续稳定跑了三个月。中间换过服务商、停过电、断过网，每次恢复都能自己续上，数据一条没漏。
对爬虫来说，没有永不失效的代理，只有永不躺平的备胎策略。