代理按请求计费

你支付的是什么费用

你为服务商计入用量的请求数量付费。它可能销售固定套餐，也可能按使用量收费。价格通常按每千次或每百万次请求报价，这让资费更容易比较，却不能说明结账时必须花多少：最小套餐可能包含更多请求。

同一个“请求”一词，可以描述不同服务。普通代理将应用的请求转发给网站，再返回响应，由应用加载页面、提取数据。数据采集 API 的价格则可能还包含运行浏览器、处理访问限制和准备结果。因此，仅比较请求单价不够，还需要知道服务为该价格完成哪些工作。

这种定价适合按日程执行的工作。你可能已经知道要检查多少页面、多久检查一次。接下来，确定每次检查消耗多少请求，就能估算一个月所需套餐，以及增加页面后用量会增长多少。

响应大小不一定影响价格。如果资费对每个请求收取相同金额，一次响应获取更多数据，费用可能与获取小响应相同。不过，应检查资费包含什么：带宽、响应大小或执行时长可能设有上限。额外数据处理也可能另行收费。

请求套餐不会决定你获得多少 IP 地址。例如，轮换服务可以通过一个共享连接端点提供 IP 池访问。IP 变化和在会话内保留地址，取决于服务设置。单凭一次 IP 变化，无法判断会收取多少请求。

服务将什么算作一个请求

首先区分请求与连接。HTTP 请求要求网站执行某个操作，例如返回页面或提供数据，网站随后发回响应。数据双向传输，本身并不意味着应扣除两次请求；那需要另有计费规则。

连接是应用与服务器通信的通道。多个请求可以使用同一连接。HTTP/1.1 允许复用连接，HTTP/2 则允许多个通信过程同时通过一个连接进行。因此，请求数、已建立连接数，以及同一时刻活跃的连接数，是不同指标。

HTTPS 又增加一个细节。通过 HTTP 代理连接时，应用通常发送 CONNECT 命令，建立通往网站的隧道。后续请求以加密形式通过该隧道。代理转发数据，但在普通使用情况下无法读取单个 HTTP 请求。SOCKS 代理同样提供通往目标的连接；应用每次操作不一定需要新建连接。

因此，有些服务用“请求”指连接，或代理服务器能够计数的另一种事件。另一些则计数单独的 HTTP 请求或 API 调用。所以，浏览器开发者工具中的请求数，可能与服务商控制面板用量不同。仅支持 HTTP、HTTPS 或 SOCKS5，并不能确定计数规则。

购买大套餐前，先做小规模测试。记录应用完成多少任务，以及服务扣除多少请求。使用之后计划采用的相同应用、协议和设置。简单 HTTP 客户端测试，无法反映还会加载脚本及其他页面资源的浏览器的用量。

为什么一个页面可能使用多个请求

打开页面通常不仅需要主文档。浏览器还会单独加载样式、脚本、图片和数据。保持打开的页面可能持续联系服务器获取更新。根据应用设置，这些请求中的部分也会经过代理。如何收费取决于资费。

跟随重定向会增加请求。如果网站回应页面位于另一地址，配置为跟随重定向的应用就会向该地址再发送 HTTP 请求。因此，用简单客户端获取一份文档，与在浏览器打开完整页面，可能消耗不同请求数。列表里的 URL 数量，还不能说明处理它们需要多少请求。

API 则可能产生相反效果：一个请求可以获取许多记录。本例中，浏览器通过五个请求加载包含价格的耳机商品页面。应用通过同一代理调用该零售商的商品目录 API，一次请求就获取五个商品价格。这是提供商品数据的零售商 API。如果它分页返回目录，每一页都需要另一次请求。有时可增加每个响应的商品数量，前提是 API 支持该设置，并返回全部所需数据。

这种方式有助于从套餐获得更多有效工作。反复加载完整页面、获取已经保存的数据，以及过于频繁地查价，都可能迅速耗尽额度。一次调用获取多个商品、保存结果并选择适当检查频率，可以减少同一任务所需请求。同样工作负载下，额度可在套餐有效期内用得更久；也可以用它检查更多商品。

测量每项完成任务的用量很有帮助。任务可能是检查一个页面、获取完整列表，或检查脚本运行后才出现的元素。应测量获得该结果所需的完整过程，包括只统计起始 URL 时容易漏掉的额外页面加载。

这种计费模式适合哪些场景

定时监测

请求用量可以与定期检查联系起来。应用可能监测页面可用性、公开信息列表的变化，或所需地区的搜索结果。目标数量和检查频率预先已知。测试能显示每次检查使用多少请求，并帮助估算月度消耗。

不同页面无须以相同频率检查。如果信息每天变化一次，每分钟检查通常都会返回相同数据。更频繁的检查可留给需要迅速发现变化的页面，让套餐用于真正需要的观察。

通过 API 和目录采集数据

这里的用量取决于网站如何提供信息。如果列表已包含全部所需内容，就没有必要打开每个详情页。额外请求可留给数据缺失的条目，或自上次运行后已变化的记录。一次调用取得的所需数据越多，完成整个采集所需的请求就越少。

还要考虑服务具体做什么。搜索 API 可能返回已解析结果，普通代理则把下载和处理交给应用。这些服务完成的工作量不同。比较价格时，应检查响应包含什么，以及哪些工作仍需你自己完成。

网站审核和浏览器检查

技术审核往往有明确流程：打开地址、检查响应、必要时跟随重定向，再保存发现。如果大多数地址处理方式类似，测试就更容易估算用量。浏览器检查可能需要更多请求，因为它依赖脚本、图片和正常工作的页面元素。

根据目的选择检查方式。仅查看页面是否响应，简单客户端往往就够了。测试结账表单，则需要加载表单运行所需内容。禁用必要文件虽然减少请求，但测试就无法反映用户体验。

错误和重试如何影响用量

发出的请求，并不总返回所需数据。网站可能返回错误、访问验证，或另一个页面。即使 HTTP 200 也不能保证应用收到了想要的内容：状态码报告的是 HTTP 层面成功，响应内容仍需单独检查。

这些请求的计费规则各不相同。有些服务计算所有发出的请求，另一些只为满足其成功完成定义的响应收费。托管 API 可能在一个响应的价格中包含多次内部数据获取尝试。额外模式或功能有时也会改变计费规则。因此，“按请求付费”不会自动等于“只为取得的数据付费”。

应用发起的重试，与服务内部的重试不同。应用再次发送请求，会创建一个新请求。服务对你已提交的任务内部重试时，这些尝试可能已包含在价格中。应确认哪些尝试会从套餐扣除。

测试时记录三个数字：启动的任务数、计费请求数和完成的任务数。完成的定义取决于目的。采集数据时，响应必须包含所需字段，且信息足够新。监测可用性时，正确检测出网站不可用，同样算完成一次检查。

这些数字有助于反映真实成本。如果响应不断需要再试一次，或只能丢弃，便宜请求也可能不划算。更贵的服务可能替你完成部分工作。应比较获得所需结果的支出，同时考虑仍留给应用的工作。

如何计算所需套餐

先统计计划工作：多少目标需要处理、多久处理一次。然后加入正常获取之外需要的请求，例如测试中观察到的重试。如果不同页面组表现不同，应分别计算。为工作量增长保留的储备也应单独列出，避免将同一批额外请求重复加入。

以一个示例说明。应用检查 150 个 URL，每 30 分钟一次，持续 30 天。假设所选资费下，每次正常检查使用一个请求，额外尝试令用量增加 5%。本例所有数字和价格均为假设，并非服务商测试结果或 ProxyCompass 资费。

所选套餐留有 23,200 个请求的储备，可在套餐有效期内应对工作量增长。预计重试已包含在 10,800 次额外尝试中；不应再把储备计作这些相同重试的用量。

假设套餐价格为 $10。它包含 250 千次请求，所以每千次名义价格为 $0.04。你需要为整个套餐支付 $10。将预计用量 226,800 个请求乘以该费率，得到 $9.072。这是已用部分的价值，不是购买金额：固定套餐仍花费 $10。

现在假设，经过额外尝试后，应用完成了全部 216,000 次计划检查。每千次完成检查的成本约为 $0.0463：$10 ÷ 216,000 × 1,000。这个金额同时考虑额外请求和已购买的储备。如果完成检查数更少，就用支出除以实际完成数。

其他任务也按同样方式计算。按使用量计费时，将计费请求数乘以费率，并考虑该费率对应多少请求。采用套餐时，使用其完整购买价格。再将支出除以完成任务数。如果多个项目共享套餐，应决定如何在项目间分摊成本。

还应检查应用能否按时完成工作。本例每天需要 7,200 次检查，平均每分钟启动五次。可以每半小时同时启动全部 150 次检查，也可以将其分散在该时间段内。如果每次检查都使用假设中的尝试次数，套餐用量相同，但启动负载不同。连接数或请求速率限制，可能使第一种时间安排无法按计划运行。

如何减少不必要的请求

移除重复地址，并随着工作推进保存结果。失败后，应用应从停止处继续。如果每次都重新运行整个列表，已处理页面就会再次消耗套餐。记录哪些任务已经完成，哪些仍待处理。

采用获取所需数据的加载方式。如果服务器响应已包含所需文本，可能无须运行浏览器。如果数据仅在脚本执行后出现，简单下载可能不够。对于数据采集服务，浏览器模式和额外功能有时消耗更多点数，或适用另一费率。因此，一个点数不总等于一个请求。

缩小响应不一定节省请求。如果服务商按 HTTP 调用计数，短响应可能与长响应消耗相同请求数。要减少数量，可以降低未变化数据的检查频率、复用已保存结果，或在一次 API 调用中获取多条记录。信息仍须满足任务的时效要求。

限制重试，并考虑请求失败原因。如果网站暂时不可用，或要求降低速度，立即重试可能返回相同响应，再消耗一次请求。暂停或降低频率可能更有用。对创建或更改数据的操作尤其要谨慎：重新提交前先检查首次尝试结果。响应丢失不代表服务器什么都没做。

调整后，同时检查结果和用量。请求数降低，可能是因为应用停止执行部分工作。只有以更少请求，仍取得完整度和时效相同的所需数据，这种减少才有用。

选择资费时检查什么

首先确认服务适用于你的网站和应用。代理类型、可用国家、会话行为，以及能否通过提供的 IP 访问所需页面，都很重要。然后比较包含的工作：谁加载页面、运行浏览器、提取数据和重试失败尝试？这有助于解释两个服务的每请求价格为何不同。

检查套餐有效期、追加规则，以及未用请求如何处理。请求单价较低的大套餐，只有能在期限内用于所需工作才划算。如果部分已购请求没有使用，每项完成任务的成本可能比小套餐更高。

比较时，从项目中选择典型页面，包括通常较难处理的页面。记录耗时、请求用量、取得的结果和应用设置。测试将反映所需套餐规模、大致工作成本，以及能否按时完成。