采集任务最常见的痛点不是完全访问不了。
而是跑着跑着开始不稳定，超时增多，重试变多，吞吐反而下降。
很多时候状态码看起来正常，但单位成功成本持续上升。
这篇文章只解决一个问题：Cloudflare 场景下采集站点不稳定时，如何识别超时来源，如何设计更克制的重试策略，以及如何通过连接复用降低链路抖动。
一、不稳定的本质 多数是分层漂移与链路成本上升
Cloudflare 的处置常见不是二选一。
更多是分层输出与软限制叠加。
你会看到这些典型现象。
延迟分位数抬高，偶发超时增多。
200 仍然很多，但内容更容易降级或缺字段。
失败集中在某些窗口或某些路径。
因此排查重点不该只盯成功率。
更应盯两条曲线。
内容完整度是否变差。
单位成功成本是否上升。
二、超时从哪里来 先把超时分成四类
超时不等于源站慢。
建议先按形态分四类，再决定治理方式。
1、边缘排队型超时
表现是 P95 P99 上升明显。
并发越高越慢，吞吐不升反降。
这常见于突刺被压平或软限速。
2、回源压力型超时
表现是某些时段普遍变慢。
尤其高价值端点更明显。
入口页可能正常，接口与详情更慢。
3、链路抖动型超时
表现是偶发超时与偶发中断交替出现。
不同出口差异很大。
同一任务换出口后表现大幅变化。
4、会话断裂型超时
表现是超时伴随验证频次上升或反复刷新。
失败后短窗口更容易继续失败。
本质是状态复用失败导致重新评估更频繁。
三、重试策略怎么做才不放大风险 先收敛失败潮
很多团队越跑越差，是因为重试策略在制造失败潮。
失败潮会把访问推入更保守通道。
结果是越重试越慢，越慢越重试。
1、退避 让重试间隔逐步拉开
避免毫秒级密集重放。
重试间隔应随连续失败逐步增长。
目标是降低短窗口密度，而不是立刻把请求堆满。
2、冷却 在失败窗口主动降压
当短时间失败比例升高时，主动进入冷却。
降低并发，暂停敏感路径。
让系统从保守层回到更稳定层。
3、上限 防止自激振荡
每个请求必须有重试上限。
每个任务必须有失败上限。
超过上限应转入队列与回收，而不是无限重放。
4、分路径策略 敏感端点更克制
入口页与静态资源可以更宽松。
搜索 分页 详情 数据接口更克制。
不要让全站共享同一重试规则。
四、连接复用优化 从网络成本里找回稳定性
在采集任务里，连接复用常被忽视。
但它对稳定性影响很大。
连接越频繁重建，越容易被链路抖动放大。
同时单位成功成本会上升。
1、保持连接池 复用 TCP 与 TLS
尽量复用连接，减少握手开销与抖动。
让请求更平滑，延迟尾部更可控。
避免每个请求都新建连接。
2、限制并发连接数 避免连接风暴
并发不只是请求数。
还包括同时建立的连接数。
连接风暴会放大突刺，触发排队与软限制。
3、对超时做分层配置
主文档 资源 接口分别配置超时阈值。
不要用一个超时参数覆盖所有请求。
接口更容易受排队影响，阈值与重试应更保守。
4、监控单位成功成本
把每次成功需要的请求次数与耗时统计出来。
如果成本曲线持续上升，即使成功率不降也属于不稳定。
优先做节奏整形与连接复用，而不是继续加压。
五、采集稳定性治理的访问层方法
采集站点不稳定，多数不是单一故障。
而是会话断裂，出口漂移，节奏突刺，失败潮叠加，导致分层漂移与软限制。
穿云API把这些问题收敛在访问层统一治理。
1、会话与出口稳定化
穿云API更容易把会话复用与出口策略统一管理。
减少同一任务前后像换人的概率。
让信任状态更容易持续复用。
2、节奏与失败窗口治理
通过访问层的节奏控制与异常回收。
更容易压平突刺，减少失败潮。
让限速与排队更难被触发或更晚发生。
3、用内容完整度与成本指标做闭环
只看状态码不够。
穿云API更适合用内容完整度与单位成功成本做观测与调整。
提前识别降级与分层漂移。
Cloudflare 场景下采集不稳定，常见来自边缘排队 回源压力 链路抖动 与会话断裂四类因素。
优化应先收敛失败潮，再做分路径重试策略，最后用连接复用降低网络成本与尾延迟。
用内容完整度与单位成功成本做主指标，才能把不稳定从玄学变成可度量问题。
