Blocking 是一种光谱，而不是错误码

Source: Dev.to

对阻塞的感知

大多数团队把阻塞想象成：

• 403 响应
• CAPTCHA 页面
• 明确的“访问被拒绝”屏幕

现代网站往往更倾向于更微妙的方式。它们：

• 让请求通过
• 返回有效的 HTML
• 保持响应码干净
• 静默地改变你能看到的内容

生产环境中的逐步限制

爬虫被逐步限制的典型迹象：

• 列表出现的条目更少
• 分页提前结束
• 搜索结果显得“稀薄”

没有错误，只有数据变少。

区域差异

你可能会期待在以下方面出现差异：

• 价格
• 排名
• 可用性

相反，所有内容开始显得异常统一。这通常发生在流量不再被视为来自真实终端用户位置时。

• 请求成功，但更新滞后
• “最新”内容其实并非最新
• 时效性数据失去准确性

站点并没有阻塞你——它在降低优先级。

消失的高级功能

• 排序选项
• 过滤器
• 丰富的元数据

基本内容仍在，除非你细心观察，否则很难发现限制。

硬阻塞 vs. 渐进阻塞

硬阻塞

• 噪声大，易于检测
• 易于绕过
• 易于升级

渐进阻塞

• 不太明显
• 更难诊断
• 推动机器人自行限制行为

从站点的角度来看，渐进阻塞更为优雅。

部分阻塞的后果

最大的失败模式不是宕机，而是在未意识到的情况下基于不完整或有偏差的数据做决策。这会影响：

• SEO 监控
• 市场调研
• 机器学习数据集
• 定价分析

如果爬虫不知道自己正被部分阻塞，流水线看似健康，却悄然偏离真实情况。

常见（适得其反）的修复方式

团队常尝试通过以下方式缓解降级：

• 增加重试次数
• 提高并发度
• 加快执行速度

这些通常会让情况更糟。

有效的缓解策略

真正有效的做法是让流量看起来并表现得像真实用户：

• 稳定的会话
• 真实的请求模式
• 合理的地理分布

这正是住宅代理基础设施（例如 Rapidproxy）的用武之地——不是作为绕过手段，而是用来降低爬虫流量与人类流量之间的差异。

转变诊断问题

不要问：

“我被阻塞了吗？”

而应问：

• “我的数据完整性是否随时间在变化？”
• “结果是否像用户看到的那样因地区而异？”
• “生产数据是否仍然与真实浏览器的抽查相匹配？”

监控部分阻塞

阻塞很少是一堵墙，更多时候是一条斜坡。如果你等到硬阻塞才发现问题，那已经等得太久——当网站说“不”时，它们往往已经在说“少”好几周了。

在大规模爬取中，成功的团队不仅监控可用性，还监控数据忠实度。在爬虫领域，部分真实往往比完全没有数据更糟。