你实际上需要多少个代理？

我们在 Geonode 上销售代理服务，因此本文旨在论证：您应该购买的代理数量应少于原计划。 **这确实是我们的立场：过大的代理池并不会让您更安全，而且在基于流量计费的模式下，它甚至不会让您多花一分钱——这意味着人们一直抱有错误的认知，却从未见过能纠正这种认知的账单。**真正重要的数字是针对单一目标的并发量，而这个数值只需一个下午就能测出。 如果你只能从本文中记住一点，请记住下一节中的测量结果，而不是我们可能给出的任何具体数字。

唯一行之有效的方法

三个步骤，全部基于实践经验。

第一步：确定单个地址的上限。 从单个地址运行实际工作负载，逐步提高请求速率，找出目标开始出现响应异常的点——例如返回 429 错误、验证请求、响应变慢或内容质量下降。 该阈值即为该目标的单地址容量，这也是整个计算过程中唯一一个非估算的数值。

第二步：明确所需吞吐量。 具体需要多少请求，以及持续多长时间。请如实填写“持续多长时间”这一部分，因为在该公式中，这一因素的影响远大于其他任何因素。

第三步：进行除法运算。 所需吞吐量除以单个地址的容量，即可得出所需的并发地址数。为此需预留重试和波动的余量——50% 已相当宽裕，若需要更多余量，则第一步的测算结果可能过于乐观。

这就是整个方法。之所以这不是标准建议，是因为它要求在购买前进行测试，而供应商没有动力去建议这样做。

关于第一步的说明：应测量每秒完成的有效响应数，而非尝试的请求数。一个返回内容被剥离的 200 状态码的请求池是无法正常工作的，而聚合成功率指标会将其报告为运行正常。请检查响应中是否包含已知的稳定标记，并仅统计包含该标记的响应。

正确执行测量

整个方法的关键在于第一步，因此有必要详细说明如何操作，以免误导自己。

请针对实际目标进行测试，而非测试端点。 针对一个会回显您 IP 地址的服务进行测试，只能说明您的代理正常工作，却无法反映您真正关心的网站会如何对待您。每个目标都有其自身的容错阈值，而您需要的数值是针对特定目标而定的。

循序渐进，并记录所有数据。 从远低于预期阈值的速率开始，逐步提高，并在每个速率下保持足够长的时间以观察规律——至少几分钟。记录每个步骤的速率、状态码、响应大小和实际耗时：

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

要像关注状态码一样密切关注响应大小。 最常见的拒绝响应并非 429 状态码，而是携带较小页面内容的 200 状态码。当特定速率下平均响应大小出现下降时，表明目标系统开始提供缩减版内容，而若仅统计状态码，这一现象将无法察觉。

在一天的不同时段运行测试。 网站高峰时段的容错率通常较低，凌晨 3 点测得的限制值在中午可能不再适用。请采用最保守的数值。

使用第二个地址重复测试。 如果一个地址在每秒 2 次请求时达到上限，而另一个地址在同一时间也达到相同上限，那么该限制并非针对单个地址——而是源于你的子网、请求模式，或是其他无法通过增加地址数量来解决的问题。这是一个重要的负面结果，而获得它只需多进行一次测试。

**因此，应在达到上限之前停止，而非在达到上限时停止。**以目标所能承受的最大速率运行意味着，任何普通的波动都会使你超过该上限。将规模设定为测量上限的 60%–70%，能确保任务可靠地完成，而非仅在条件良好时才能完成。

示例：每日价格监控

这是最常见的工作负载，也是其结果最令人意外的场景。

需求： 每天检查 50,000 个产品页面一次。

**实测上限：**该目标系统在实施速率限制前，允许单个IP地址每两秒发送一次请求——即每小时约1,800次请求。

按 24 小时平均分配： 50,000 ÷ 24 ≈ 每小时 2,100 次请求。

所需地址数： 2,100 ÷ 1,800 ≈ 1.2。向上取整并留出余量：两到四个地址。

两个地址。面对每天五万个页面，而可用的地址池却号称有数百万个。

现在改变一个假设。假设该任务必须在两小时内完成，而不是分散在全天进行：

要求： 2 小时内处理 50,000 页 = 每小时 25,000 页。 所需地址数： 25,000 ÷ 1,800 ≈ 14，加上余量：约 20 个。

相同处理量，相同目标，却需要十倍的地址——这源于调度决策，而非数据抓取需求。

这是本文中最有价值的洞见。**你给自己设定的时间窗口才是决定性因素。**在购买更多地址之前，请先问问自己：这项工作真的需要快速完成吗？这种速度能带来多少价值？通常情况下，这种速度根本毫无价值，因为数据第二天早上就会被消耗掉。

示例：地理查询

形状完全不同，计算方式也截然相反。

**需求：**每天四次，查询30个市场的区域定价和库存情况，每个市场查询50页。

请求量： 30 × 4 × 50 = 每天 6,000 次请求。微不足道。

满足吞吐量所需的IP地址： 基本上只需一个。6,000次请求分散在一天内，相当于每14秒一次请求。

满足覆盖率所需的IP地址： 在30个国家中，每个国家至少有一个在需要时可用的出口。

这里的限制因素根本不是流量，而是覆盖范围。你应该评估的是，服务商是否在你需要的时间段内，在你所需的特定市场中确实拥有可靠的覆盖——而不是地址池中包含多少个地址。 一个包含一千万个IP地址但仅在您三个目标市场覆盖薄弱的地址池，远不如一个包含一万个IP地址但覆盖全部三十个市场的地址池。

这就是为什么“我需要多少”对于地理覆盖工作来说是个错误的问题，而“您能可靠地覆盖哪些地区，以及我能否进行测试”才是正确的问题。

示例：基于会话的工作

并发与身份识别完全等同的情况。

需求： 并行运行 10 个经过身份验证的会话，每个会话执行多步操作序列。

所需地址： 10 个，且必须是粘性地址——每个会话期间仅使用一个地址。

在此场景中，请求量无关紧要。关键在于每个会话都具有一致的身份：全程使用同一地址，且区域设置和时区保持一致。如果一个会话的请求来自四个不同国家，那就不算是一个会话，而是一种模式。

需要避免的错误是为此使用按请求轮转的端点，这是大多数网关的默认设置。请求虽然成功，但会话状态会丢失，而且只要没人检查出口地址，这种现象看起来就像是应用程序的错误。

另请注意，十个并发会话并不意味着永远有十个地址——而是指“同时”存在十个。一个全天顺序运行 200 个会话的工作负载，仍然只需十个可重复使用的粘性地址。

为什么数量越多并不意味着更安全

大多数超量购买背后的假设，其实在三个具体方面都是错误的。

封锁是按子网进行的，而不是按地址进行的。 网站通常以 /24 为单位进行封锁。 当一个包含五十个地址的地址块被封禁时，这些地址的行为就等同于一个地址；因此，一个分布不佳的大型地址池，在实际应用中并不具备真正意义上的“大型”优势。分布比数量更重要，我们已在什么是子网ID中详细探讨了其运作机制。

关键在于行为特征，而非身份。 如果您的请求因时间间隔、请求头或 TLS 指纹而看起来像是自动生成的，将它们分散到更多地址上只会分散行为特征，而无法消除它。结果是，被标记的地址反而会更多，而不是更少。

**未使用的地址会过期。**在轮换地址池中，一个未被使用的地址与目标之间不存在任何关联，无论好坏。持有“备用容量”并非囤积任何资源。

持有超过吞吐量所需的地址数量有一个真正的原因：**地址更替。**如果目标随时间推移将地址标记为可疑，你就需要备用地址进行轮换。这是真实的需求，其规模应根据观察到的标记率而非直觉来确定——测量每天有多少地址被标记，并保留足够维持几天使用的数量。

您实际上购买的是什么

这一点值得明确说明，因为答案会因定价模式的不同而有所差异，甚至会改变这个问题本身的含义。

在按每千兆字节计费的模式下——这是面向家庭用户以及通常面向数据中心的流量销售方式——您根本不是在购买IP地址。 您购买的是数据流量，而代理数量是流量池的属性，而非您所选套餐的属性。在此背景下询问“我需要多少个代理”属于类别错误——真正的问题在于您将传输多少流量，以及该流量池是否覆盖您所需的区域。 我们的家庭用户流量起价为 0.79 美元/GB，数据中心流量起价为 0.14 美元/GB，此价格于 2026 年 9 月根据我们的 定价页面 核实。

关于按IP计费——这是ISP和许多数据中心产品的销售方式——计费数量即为实际支付金额，整个计算过程就是预算核算。我们的价格为1.25美元/IP。在此情况下，上述计算直接关系到资金支出，花二十分钟算准绝对值得。

哪种计费模式更适合您，取决于您工作负载的特性，而非表面上的费率，二者不可直接比较。需要大量IP地址但使用时间较短的工作负载更适合按流量计费；而需要少量IP地址但使用时间较长的工作负载则更适合按IP计费。我们在代理计费指南中对相关计算进行了详细说明。

经验法则及其局限性

如果您在进行测量前需要一个起点，这些法则是有一定依据的。请将其视为一个可被替换的初步估计，而非最终答案。

有两个数据值得牢记。几乎没有任何工作负载需要超过几十个并发地址，而真正需要如此多的，要么是地理分布型（多个地点，每个地点流量较低），要么是受自设截止时间限制的。而且，最常需要调整的并非地址数量，而是时间安排。

判断配额设置错误的迹象

配额过少的表现包括：429错误增多、出现各种问题、随着运行进程推进成功率下降、任务完成时间晚于计划。解决方法是增加并发数或延长处理窗口。

配额过多的表现是：没有任何迹象。这就是为什么这种错误会持续存在。 过大的地址池在按流量计费模式下不会产生任何症状，因此无人察觉。而在按IP地址计费模式下，它会产生账单，这至少能引发疑问。

两种看似“数量过少”实则并非如此的情况：

被封锁的地址池。 如果所有地址的成功率同时骤降，增加地址数量也无济于事——这说明目标端发生了变化，或者你的请求模式正通过非地址信号被识别出来。

**目标端响应缓慢。**如果响应虽然缓慢但成功，增加并发度会在一定程度内提升吞吐量，但随后效果会停滞。 请测量每秒完成的请求数，当该数值趋于平稳时停止增加并发数——这一平稳状态的出现往往比预期更早。

通用诊断方法：分阶段增加并发数，并观察每秒完成的有效响应数。该数值会先上升、趋于平稳，然后下降。最优值就是平稳时的数值，而这个数值通常比任何人预期的都要小。

大家还常问

进行网页爬取需要多少个代理？

不要凭空猜测，而要实际测算：找出在您的实际目标网站上，单个IP地址开始受到限制的请求速率，将所需的吞吐量除以该数值，并留出余量。 大多数工作负载所需的并发IP地址数量仅为个位数或低两位数，而非数千个。

使用更多代理是否能降低被封禁的风险？

只有当封禁是针对特定IP地址时才有效。 如果您的请求因时间间隔、请求头构成或 TLS 指纹被识别为自动化请求，增加 IP 地址数量只会将相同的信号分散到更多代理池中，而非真正规避封禁。请求速率和请求模式比代理数量更重要。

每天 100 万次请求需要多少个代理？

这完全取决于时间窗口。 若分散在 24 小时内，相当于每秒约 12 次请求；按每个地址每两秒一次请求计算，大约需要 25 个并发地址。若压缩至两小时内，则需求量是前者的 12 倍。关键变量是时间安排，而非请求总量。

每个账户是否需要一个代理？

对于任何基于会话的操作，应为每个并发会话分配一个粘性地址——而非按账户分配。若十个账户在一天内依次操作，只有当这十个账户同时处于活动状态时，才需要十个地址。请注意，许多平台明确禁止多账户操作，因此在设计绕过限制的方案前，请务必查阅相关条款。

拥有更多IP地址好，还是拥有更优质的IP地址好？

“更好”是指IP地址在子网中分布均匀且适合目标平台。封禁通常以/24为单位进行，因此同一IP块中的50个地址会被视为一个整体。一个规模较小但分布均匀的IP池，其性能优于一个规模较大但集中分布的IP池。

如何判断代理数量是否不足？

429 错误增多、出现验证页面，以及随着请求进程的推进成功率逐渐下降。如果所有地址的成功率同时骤降，那则是另一个问题——目标端发生了变化，或者您的请求正因非地址信号被识别，此时增加地址数量也无济于事。

代理数量会影响价格吗？

在按 IP 计费模式下，价格直接受代理数量影响——您购买的就是代理数量。而在按千兆字节计费模式下，价格完全不受代理数量影响，因为您支付的是数据流量费用，而地址数量只是代理池的属性之一。这就是为什么无法仅凭标价来比较这两种计费模式。

地理定位需要多少个代理？

每个目标位置只需一个可靠的出口节点，流量大小通常无关紧要。向服务商询问的关键不在于他们拥有多少个IP地址，而在于他们是否在您的特定市场拥有可靠的覆盖范围，以及您是否可以在签约前进行测试。

总结

您需要的数值来自一次测量和一次除法：找出在实际目标环境中单个地址开始受到速率限制的位置，然后将您的吞吐量要求除以该数值。其余的都是细节调整。

决定结果的关键变量并非数据量，而是你设定的时间窗口。每天处理五万个页面，只需将流量分散到二十四个地址上；若需处理二十万个页面，则分散到二十个地址即可。在购买带宽以提升速度之前，请先确认是否有任何事项真正依赖于任务尽早完成——通常并没有，而最经济的优化方案就是耐心。

至于涉及地理位置的工作，问题性质则完全不同。流量规模微不足道，覆盖范围才是关键，有意义的评估在于服务商能否可靠地覆盖您的特定市场，而非其资源池有多大。这一点可以通过试用进行验证，只需一个下午的时间，其提供的信息将远比任何供应商（包括我们）在落地页上展示的数字更为可靠。