抓取成本到底怎么算？CAPTCHA、空页与重试如何推高每条有效数据成本

代理套餐每 GB 很便宜，请求日志里也有不少 HTTP 200，月底核算时却发现毛利仍然很薄。常见原因不是账单算错了，而是分母用错了：团队把“发出了多少次请求”当成“交付了多少条有效数据”，却没有扣掉 CAPTCHA、空页、静默失败、重复结果和重试消耗。

公开社区里就有一位小型采集团队成员描述过类似困境：他按城市收集本地商家域名，Google SERP 在批次后段会出现 CAPTCHA 或同意页，Maps 的结果限制又迫使任务增加额外查询。计划覆盖 3 个城市、每城 30 个目标，最后只得到约 70～75 个干净域名，住宅代理与平台成本却已经明显侵蚀利润。这个案例不能代表行业平均水平，但它准确揭示了成本核算中最容易漏掉的一层：每个可交付结果背后，可能已经发生多次失败请求和补充查询。

真正值得比较的，不是每 GB、每个 IP 或每千次请求的标价，而是每条通过业务验收的数据成本。要算清它，先把请求、页面、字段和最终记录放进同一条漏斗。

一、先定义什么才算一条有效数据

RFC 9110 中的 2xx 表示 HTTP 请求已经被成功接收、理解和接受，但这并不替你的业务判断页面是否正确。对于采集任务，真正的“成功”通常要连续通过五层检查：

1. 请求完成：DNS、代理认证、连接和读取均正常结束。
2. 页面身份正确：返回的是目标详情页，而不是登录页、同意页、验证页、错误模板或首页。
3. 关键字段完整：例如商品 ID、名称、价格、币种和库存状态达到当前任务的必填规则。
4. 数据符合任务口径：地区、语言、时间、实体和页面版本均与采集目标一致。
5. 下游能够接收：通过去重、时效性、异常值和业务规则检查，最终进入交付表或数据库。

因此，成本核算的分母不应该是 request_count，也不应该只统计 http_200_count，而应使用 accepted_record_count。如果团队还没有统一这套成功口径，可以先参考代理成功率的四层验收方法，再把验收结果接入本文的成本公式。

二、每条有效数据成本的计算公式

先把一个核算周期内与当前任务直接相关的费用合并，再除以最终验收通过的记录数：

在计算前必须统一“有效记录”的粒度、必填字段、去重键和时间窗口。例如，同一商品在不同地区是否算两条记录、同一商品每天更新一次是否产生新记录，都要提前定义。不同方案只有使用同一记录口径，单位成本才具有可比性。如果核算周期内有效记录数为 0，单位有效数据成本应标记为“无法计算”或趋近无穷，而不是记录为 0。

为了让不同规模的任务更容易比较，通常再换算为每千条有效数据成本：

总成本中的四部分应保持同一时间窗口、同一目标范围和同一币种：

• 代理服务费：按 GB、按 IP、按带宽或固定周期支付给代理服务商的费用。
• 第三方 API 与托管浏览器费：网页抓取 API、托管浏览器实例及其他按调用次数或运行时长计费的服务。
• 自建基础设施费：云主机、容器、队列、日志、对象存储、数据库，以及未包含在其他服务中的网络传输费用。
• 人工成本：合规复核、工程排障、解析器更新、人工抽检和任务重跑产生的工时成本。遇到 CAPTCHA 时应暂停、降速、改用授权接口或人工确认，而不是把绕过验证当成常规成本项。

各成本项必须互斥。若 API 套餐已经包含代理网络、浏览器运行和流量，不应再次把同一部分计入代理服务费或自建基础设施费。共享服务器、日志平台和人工工时则应按请求量、运行时长、资源占用或实际工时分摊，并在不同方案中保持相同分摊方法。

核算时还要先明确用途：完全成本用于利润分析和报价，应包含人工与固定资源分摊；增量成本用于判断是否追加一批任务，只计算这批任务新增的实际支出。两者都可以计算，但不能混在同一张对比表里。

如果只想先定位重试放大和网络浪费，需要把任务级与记录级指标分开：

每个目标任务平均请求数同时包含正常流程和重试。一个目标正常完成本来就可能需要详情页、库存接口、翻页或评论接口等多个 HTTP 请求，因此这个指标不能全部解释为重试放大。要单独衡量异常重试，应结合“重试目标占比”和“每个重试目标平均额外请求数”。每条有效记录平均分摊请求数衡量记录产出效率；列表页一次请求可能产出多条有效记录，因此这个数完全可能小于 1，并不代表没有发生请求。“总请求尝试数”必须包含原始请求和所有重试，“总传输字节”也应包含失败响应、验证页和重试产生的流量。

三、CAPTCHA、空页和静默失败怎样进入成本

不同站点的验证页识别方式不同，不能只维护一个通用关键词列表。例如，Cloudflare 官方文档说明其 Challenge Page 会带有 cf-mitigated: challenge 响应头；这可以作为使用 Cloudflare 的目标站上的一个明确信号，但不适用于所有 CDN 和站点。其他目标仍需结合页面标题、关键 DOM、内容哈希与必填字段判断。

静默失败不应默认立即重试。多个出口在同一时间都缺少相同字段时，更可能是页面改版、解析器失效或数据源变化。只有在确认属于暂时性、可恢复故障后，才应进入受控重试；在没有完成失败分类前继续换 IP，容易把解析问题变成代理账单。

四、用一组示例把账算完整

下面是一组用于说明计算方法的假设数据，不代表 IPWeb 产品价格、成功率或任何行业平均水平。为了便于说明，假设每个目标任务对应一个详情页，并且每个通过验收的详情页最终产生一条有效记录，因此各漏斗阶段可以按同一目标单元统计。对于一次页面产生多条记录的列表页任务，应分别建立请求漏斗和记录漏斗，不能直接混用数量。

假设同一周期内，代理服务费为 1,260 元，第三方 API 与托管浏览器费 540 元，自建基础设施费 240 元，人工成本 960 元，总成本为 3,000 元。

两个数字都没有计算错误，但回答的是不同问题。前者衡量发送请求的成本，后者衡量交付有效数据的成本。如果团队用“25 元 / 千次请求”代替“每千条有效数据成本”进行报价，按照这组假设，真实交付成本会被低估约 40%。

还可以继续拆分归因：如果代理服务费占比高，就检查页面体积、重试和无关资源；如果第三方 API 与托管浏览器费高，就检查哪些目标真的需要渲染；如果自建基础设施费高，就检查闲置容量、日志留存和任务排期；如果人工成本高，就优先修复静默失败检测、页面变更告警和重跑流程。总成本本身只告诉你贵不贵，分层成本才能告诉你该改哪里。

五、最少需要记录哪些数据

不需要先建设复杂的数据平台。一个请求级日志表加一个任务级汇总表，就能完成第一轮核算。请求级至少保留：

• job_id、request_id、目标域名和任务地区；
• attempt_no、是否重试、上一次失败原因；
• 代理或路由标识、计费产品、会话标识；
• 请求与响应字节数、开始时间、延迟和浏览器运行时长；
• HTTP 状态码、代理错误码、Challenge 标记；
• 页面身份校验、必填字段校验、地区校验结果；
• 最终状态：有效、重复、过期、静默失败或人工复核。

任务级汇总只需要把这些日志按目标、地区、计费产品和日期聚合，输出总请求数、有效记录数、重试目标占比、每个重试目标平均额外请求数、无效流量、各类费用以及每千条有效数据成本。不要在日志中保存不必要的个人敏感信息；采集范围仍应符合目标站条款、适用法律和内部授权。RFC 9309明确了服务方用于表达自动客户端访问规则的 Robots Exclusion Protocol，但 robots.txt 不是访问授权的替代品，团队仍要同时检查站点条款和数据使用边界。

六、降低真实成本应该先改哪里

1. 先停掉“所有错误立即重试”

重试只适合可能恢复、并且业务允许重复执行的请求。RFC 6585 对 429 的定义允许服务端通过 Retry-After 告知等待时间；收到该字段时应优先遵守，而不是立即换一个出口继续请求。

对于确实可重试的临时故障，应设置指数退避、随机抖动和最大重试次数。AWS Well-Architected 的重试建议同样强调先判断错误是否值得重试，再使用退避、抖动和上限，避免同步重试形成新的请求尖峰。如果需要把失败反馈给代理调度器，可继续查看健康评分、冷却与失败 IP 剔除方法。

2. 在解析前拦住错误页面

先做轻量的页面身份检查，再进入昂贵的浏览器动作、解析和存储。页面标题、规范链接、关键 DOM、JSON-LD 类型和内容哈希都可以组合使用。任何一个信号都不应单独决定成败，但组合检查能显著减少错误页进入后续链路。

3. 只加载任务真正需要的资源

如果业务只需要文本字段，并且目标页面在不加载图片、字体或视频时仍能正确生成这些字段，可以在经过测试后拦截无关资源。Playwright 官方网络文档提供了按资源类型中止请求的方式。不要直接照搬“屏蔽所有图片”的规则：有些站点会通过图片加载触发脚本、反爬检查或懒加载，错误拦截反而会增加空页率。

4. 把去重和检查点放到重跑之前

任务中断后从头开始，会重复消耗已经成功部分的全部成本。为每个实体保存稳定键、更新时间和检查点，恢复时只处理未完成或已过期的部分。写入端使用幂等逻辑，避免网络重试生成重复记录。

5. 用同一批目标做小规模 POC

不同代理和 API 必须在相同目标、地区、时间段、并发、字段规则和退出条件下比较。至少运行到能够覆盖正常时段和异常时段，再比较有效记录成本、P95 延迟、重试目标占比、每个重试目标平均额外请求数、静默失败率和人工维护时间。只测一个连通地址，无法代表真实工作负载。

七、按 GB、无限量和按请求 API 怎么选

产品选型不应该从“哪一种最便宜”开始，而应从任务的流量结构、失败结构和维护能力开始。IPWeb 站内已有的住宅 IP 计费与购买指南更侧重套餐和选型；下面只比较它们如何进入“每条有效数据成本”公式。

简单的盈亏平衡点不能只用“固定月费 ÷ 每 GB 单价”计算，因为不同方案的有效率、页面体积、浏览器使用方式和人工投入可能不同。正确做法是给每个候选方案都计算同一个指标：

如果按 GB 方案在低流量时单位成本更低，就不必为了“无限量”提前购买闲置资源；如果任务已经长期占满带宽，流量账单又随失败和重试波动，无限量方案可能更容易控制预算；如果浏览器、调度和页面变化维护占据了主要成本，按请求 API 即使标价较高，也可能降低最终单位成本。结论必须来自你的目标级 POC，而不是供应商首页上的单一数字。

八、常见问题

1. HTTP 200 可以直接计入成功抓取数吗？

不能。HTTP 200 只能说明 HTTP 层请求成功，仍需检查页面身份、关键字段、地区、时效性和下游验收结果。

2. CAPTCHA 页面在按 GB 代理里会产生费用吗？

只要产生了数据传输，通常就会占用流量；具体扣费口径仍以当前订单和服务条款为准。CAPTCHA 应被标记为失败并触发暂停、降速或合规替代流程，不应无限重试。

3. 使用无限量代理后，还需要计算每条有效数据成本吗？

需要。代理服务费从变量变为相对固定后，带宽利用率、有效吞吐、第三方 API 与托管浏览器费、自建基础设施费和人工成本仍然决定每条有效数据的成本。

4. 网页抓取 API 显示请求成功，是否等于业务数据有效？

不一定。供应商显示的“请求成功”属于服务层口径，是否计费以及怎样占用套餐额度仍以当前订单规则为准；你的任务还要检查实体、字段、地区、时间和重复数据。服务结果、计费结果与业务验收结果应分别记录。

5. 重试成本应该算在失败请求还是成功请求上？

所有重试都应进入总请求数和总成本，最终再除以有效记录数。只保留最后一次成功结果，会掩盖前面已经消耗的流量和计算。

6. 人工排障成本怎样摊销？

先统计核算周期内用于该任务的开发、排障、抽检和重跑工时，乘以内部统一工时成本，再除以同周期的有效记录数。口径保持一致比追求绝对精确更重要。

7. 比较两个供应商时，至少要保持哪些条件一致？

保持目标 URL 样本、地区、时间段、并发、页面加载方式、重试上限、字段规则和退出条件一致，并同时比较有效率、静默失败率、流量、延迟与人工时间。

九、结论：先改分母，再谈降价

抓取成本失控时，最先要修正的往往不是套餐，而是统计口径。把总请求数换成最终有效记录数，把 CAPTCHA、空页、静默失败、重复数据和重试全部留在成本分子里，团队才能看见真实的单位交付成本。

接下来用同一组目标做小规模 POC：分别记录按 GB 代理、固定资源方案和按请求 API 的总费用、有效记录数与人工维护时间。只要所有方案都用同一条验收漏斗计算，哪一种更适合当前业务会变得清楚得多。