请求失败率不是一个数，是一叠数。把失败按响应类型拆开，才能判断该动哪一层。
在典型的APP大数据分析类采集里，失败一般分五类：连接超时、TCP握手失败、HTTPS证书错误、目标站点返回4xx（含验证码页）、目标站点返回5xx。前三类偏网络层，后两类偏业务层。
一份公开的爬虫工程调研显示，中大规模采集任务的失败率结构大致是这样：
| 失败类型 | 常见占比 | 主责层 |
|---|---|---|
| 连接超时（含Connect Timeout） | 25%-40% | IP层/网络层 |
| TCP握手失败 | 5%-10% | IP层 |
| HTTPS证书错误 | 1%-3% | 代理配置层 |
| 4xx（403/429含验证码） | 30%-50% | 目标站点访问频率控制 |
| 5xx | 5%-15% | 目标站点自身+IP声誉 |
四五成的失败落在4xx，这也是很多团队直接怀疑目标站点访问频率控制机制的原因。但这一类里，能通过换IP策略解决的比例，通常比调重试更高——因为4xx里的429和触发验证码那类，本质是目标站点对当前IP+当前请求频率的组合做了限制。
结论倒过来说，只调重试和延时，能压的是「连接超时」的重复触发和「429立即缓解」，压不动的是「同一批IP在同一批目标URL上被反复标记」。IP策略要动的正是后者。
IP池的池型、复用、切换，三个维度怎么组合？
IP策略的三个基本维度：池型决定资源规模，复用决定单IP承载的请求量，切换决定何时换IP。三者组合直接决定失败率上限。
池型。IP池分数据中心IP、住宅IP、移动IP三类。舆情监测这类以门户站、新闻站为主的目标，数据中心IP足够；APP大数据分析里如果目标站点访问频率控制较严（比如电商类），住宅IP的通过率明显高于数据中心IP。行业普遍观察，同等采集节奏下，住宅IP在中高访问频率控制类站点的成功率能比数据中心IP高10-25个百分点。
复用。单个IP在同一目标URL上最多复用几次，是访问频率控制风险的第一控制点。一份常见的经验区间：
- 严访问频率控制站点（电商详情页、验证码敏感页），单IP在同一域名下建议不超过5-10次请求
- 中访问频率控制站点（新闻资讯、行业门户），单IP可复用20-50次
- 弱访问频率控制站点（公开API、静态资源），单IP可复用100次以上
切换。切换有两种触发方式：按时间切（每N分钟换一批）、按事件切（触发失败/验证码立即换）。企业级采集通常两者结合——按时间做基础换池，按事件做即时熔断。
三个维度的组合示例，可以直接抄：
| 场景 | 池型 | 单IP复用 | 切换策略 |
|---|---|---|---|
| APP大数据分析（电商类） | 住宅IP为主，数据中心IP补量 | 5-10次/域名 | 按事件熔断 + 每10分钟基础换池 |
| 舆情监测（新闻门户） | 数据中心IP为主 | 30-50次/域名 | 按事件熔断 + 每30分钟基础换池 |
| 舆情监测（社交平台数据） | 住宅IP | 3-5次/域名 | 每次请求换IP |
组合选定之后，失败率的可控上限就基本确定了。剩下的调优空间才是重试和延时。
短效、长效、隧道，三种模式的适配场景差在哪？
IP的提取模式决定了工程实现的复杂度。三种主流模式各有适配区间。
短效代理：每个IP有明确的存活周期，通常1-10分钟。适合需要高频换IP的场景。工程实现上，通常靠API批量拉取一批IP，业务侧维护本地IP池，用完丢弃。舆情监测的社交类采集、APP大数据分析里的高频访问频率控制页面，都适合短效代理。
长效代理：单个IP存活周期长，从几十分钟到几小时甚至更长。适合需要保持会话状态的场景，比如需要登录态、需要维持Cookie的采集任务。
隧道代理：业务侧只连一个固定入口（隧道端点），换IP由代理服务端自动完成。工程实现最简单，业务侧不需要维护IP池。适合并发不高、但对代码简洁性要求高的场景，或者由多语言技术栈共同调用的采集架构。
三种模式的失败率差异，通常不来自模式本身，而来自模式与业务的错配。常见错配：
- 用长效代理跑严访问频率控制的电商采集——IP来不及换，失败率在30分钟后飙升
- 用短效代理跑需要登录态的采集——IP刚换掉，Cookie就作废
- 用隧道代理跑并发100+的高吞吐任务——隧道后端调度延迟被放大
选择的顺序建议是：先看业务是否需要会话粘性，再看目标站点访问频率控制强度，最后看工程复杂度承受能力。
高失败率场景下，还有哪些非IP因素要一起动？
IP策略调完，失败率依然降不下来的情况并不少见。这时非IP因素得一起动。
请求头一致性。同一IP连续用不同的User-Agent，或者用带明显爬虫特征的UA，会立即触发目标站点访问频率控制。行业普遍做法是维护一个真实浏览器UA池，按域名做UA-IP绑定。
指纹层。TLS指纹、HTTP/2帧顺序、Header顺序，这些底层特征越来越多被目标站点用来做识别。这一层跟IP策略无关，属于HTTP客户端选型层面的问题。常见的做法是使用能自定义指纹的HTTP库，或者使用带完整浏览器指纹的无头浏览器。
并发节奏。同一时刻同一IP发起的连接数，和同一时刻同一域名的总连接数，是两个独立参数。前者过高触发IP层限制，后者过高触发目标站点的整体访问频率控制。企业级采集通常会为每个域名设置独立的并发上限。
重试策略本身。失败重试并不总能提升成功率——有时候重试反而加速IP被标记。合理的重试策略需要区分：连接超时可以重试（换IP+延时）；4xx里的403/429不能立即重试（要冷却+换IP）；5xx里的502/503可以重试（因为多半是目标站点自身瞬时问题）。
非IP因素动完，失败率还在10%以上，就要回头看目标站点自身是否有访问频率控制升级——比如新增了行为验证、新增了指纹校验。这属于工程调优的下一个循环。
一份可以直接抄的失败率排查清单长什么样？
按顺序过一遍，通常能定位80%以上的失败率异常。
| 序号 | 排查项 | 判断标准 |
|---|---|---|
| 1 | 失败按类型分层了吗？ | 至少要能拆出连接超时/TCP握手/HTTPS/4xx/5xx 五类 |
| 2 | 4xx里的403/429比例超过10%了吗？ | 超过 → 优先动IP策略 |
| 3 | 连接超时比例超过20%了吗？ | 超过 → 优先动池型和切换阈值 |
| 4 | 单IP在单域名上的复用次数控制了吗？ | 未控制 → 加复用上限 |
| 5 | 池型选对了吗？ | 严访问频率控制站点用数据中心IP → 换住宅IP |
| 6 | 切换是纯按时间还是按事件？ | 纯按时间 → 加事件熔断 |
| 7 | 请求头有没有做UA-IP绑定？ | 未绑定 → 立即绑定 |
| 8 | HTTP客户端是不是暴露了明显的爬虫指纹？ | 是 → 换指纹可配置的客户端 |
| 9 | 并发上限是不是按域名分别设置的？ | 未分别设置 → 分别设置 |
| 10 | 重试策略区分类型了吗？ | 未区分 → 按4xx/5xx/超时分别定策略 |
前六项是IP策略层的，占失败率下降幅度的大头。后四项是配套层，用来把IP策略的效果放到最大。
采集类工程里，失败率优化不是一次性完成的。目标站点访问频率控制机制会变，IP池的健康度也会波动。合理的做法是把失败率按类型做长期监控，每次曲线异常时按上面清单过一遍，而不是等失败率飙到20%再动手。
FAQ
Q：把重试次数从3次加到10次，能不能压失败率？
短期能压，长期不能。重试次数只压得住「瞬时抖动」类失败——比如网络层的TCP握手失败、目标站点的5xx瞬时错误。压不住的是「IP已被目标站点标记」这类失败，因为无论重试多少次，同一个IP就是不能通过。把重试次数从3提到10，前三次没成功的请求，后七次成功的概率通常不到20%，反而拉长了整批任务的完成时间。合理策略是重试1-3次配合换IP。
Q：住宅IP一定比数据中心IP成功率高吗？
不是。住宅IP在严访问频率控制的电商类、社交类目标站点上成功率明显更高，但在弱访问频率控制的新闻门户、公开API、静态资源上，两者差别不大——多花的钱换不来对应的成功率提升。选型要按目标站点访问频率控制强度分级来定。
Q：验证码页算成功还是算失败？
要算失败。验证码页返回的是200状态码，但内容不是目标数据。工程实现上要在业务层加内容识别——比如判断页面里有没有验证码关键字、有没有目标数据字段——把这类响应重新计入失败。不加内容层的判断，失败率数据会假性偏低，导致IP策略调优判断错。
Q：短效代理的IP存活周期越短是不是越好？
不是。存活周期越短，业务侧本地IP池的补给频率就越高，工程复杂度也越高——尤其是并发场景下。存活周期的选择应该按业务需要匹配：需要每次请求换IP的采集，选1-5分钟；需要维持短会话的，选5-30分钟。盲目追求短存活，反而会因为IP切换太频繁触发目标站点的另一种识别。
