你到底需要多少个代理 IP？

买代理之前最常问的那个问题，也是问错了的那个。要紧的不是你有多少个 IP，而是你的请求如何在它们之间铺开。

这是几乎每一次代理采购之前都会冒出来的问题：我需要多少个 IP？它听起来像是那种应该以一个数字作答的事情，也感觉像是决定这份工作能否跑通的那个数字。而在实践中，它通常是问错了的问题，而以它开场的团队，往往买错了东西。真正决定你的抓取能否干净地跑起来的，不是你拥有多少个地址，而是你的请求如何在你所使用的那些地址之间分布，以及是否有任何单个目标，曾从某一个地址上看到多到值得它在意的流量。

下面就讲如何把这件事想清楚，也包括那个”清点 IP 数量”确实是正确做法的唯一情形。

为什么这个问题被问错了

清点 IP 的本能，是一个更老的计价模型留下的残余。当代理是按端口、或按静态地址来卖的时候，你买下一个具体数量的 IP，而那个数字就是你的容量，于是清点是说得通的。现代住宅网络并不这样运作。你是从一个大型共享池里取用，你被计费的是你搬动的带宽、而非你触及的地址，而你最终用到多少个不同的 IP，是你如何配置轮换所产生的结果，不是你预先买下的一个数量。这次转变——在为什么按端口的时代结束了那篇里有更深入的讨论——正是”多少个 IP”不再对应任何你真正买下之物的原因。

这个提法之所以误导人，还有第二个理由。一个目标站点看不见你的池子。它看见的是抵达它自家门口的那些请求，并根据这些请求的行为，逐个地址地形成一份判断。一万个 IP 救不了一份把全部流量都从其中一小撮上送出去的工作，而数量不多、却铺得很开的地址，会从容地跑起一份幼稚的搭建根本跑不动的工作。分布才是那个变量，而不是库存。

真正决定你需求的是什么

有四件事决定一份工作需要什么。按顺序把它们过一遍，答案自己就掉出来了。

第一是你对单个目标的请求速率。不是你跨所有目标的请求总量，而是你在一个给定的时间窗里向某一个站点发出多少请求，因为速率限制是按 IP、按目标来强制执行的。第二是并发，也就是你同时有多少请求在途，它决定了有多少地址在被同时使用。第三是会话要求：你的工作是否需要为一段多步流程守住一个 IP——这正是那个会变成一个真实计数的唯一情形。第四是地理铺开程度，因为一份覆盖许多市场的工作，需要把它的流量铺到那些市场的每一个上，而不是一个集中在别处的大池子，而在牵涉到城市级定位之处，相关的问题是那座城市里的可得性，而不是整张网络的规模。

轮换型工作的粗略算法

对寻常的轮换式采集而言，有用的计算不是”存在多少个 IP”，而是”为了在每个目标那里都保持有礼，我的流量需要铺在多少个不同的地址上”。

取你对单个站点的请求速率，然后除以你愿意从任一个地址发出的速率。如果一份工作每小时向一个目标发出 60,000 次请求，而你希望没有哪个地址向那个目标发出超过大约每 20 秒一次请求——也就是每小时 180 次——那么在任何给定时刻，这份流量就需要铺在约 330 个不同地址的量级上。改动任一个输入，答案就跟着移动：把流量减半，你就只需要一半；把每个地址放慢，你就需要更多。这里的数字是示意性的，因为每个目标所容忍的速率都不同、而你应当按某个具体站点实际接受的程度去调，但这个计算的形状才是要点。你求解的是分布，而池子只需要足够大、并在你的目标市场里铺得足够开，来把它供上。

这正是负载均衡为你做的事，也正是为什么无限并发连接比一个标题上的 IP 数字更要紧：真正咬人的约束，是一个地址向一个站点发出多少请求，而不是总共存在多少个地址。如果你打的是许多不同目标，这个算法就按目标各算一遍，而铺在五十个站点上的流量，远比同样的流量全都瞄准一个要来得轻松。

你确实该清点的那个情形：粘性会话

有一种情形，一个数字确实就是正确答案，而这一点值得说精确。当你的工作需要一个被守住的身份时——一次多步搜索、一段登录流程、一串结账式的序列，或任何一个站点会跨请求追踪状态的过程——这些并发流程里的每一个，都需要它自己的一个粘性会话、待在它自己的 IP 上，直到那段流程结束。在这里计数是直接的：五十个同时进行的会话，就意味着那一刻有五十个被守住的地址，五百个就是五百个。

所以这个问题诚实的版本，不是”我需要多少个 IP”，而是”我需要多少个并发的粘性会话”——那是一个关于你工作负载形状的问题，而不是一个关于网络的问题。任何不要求被守住身份的部分，都应当轮换，因为轮换会自动分摊负载，而这也正是轮换模型被设计出来所要被使用的方式。

为什么池子的原始规模是一个薄弱的比较指标

各家提供方都在宣传池子规模，而那些数字大到难以做出有意义的比较。有三件事比标题上的数字更要紧。

在你所在市场里的分布排第一。一个非常大、却在你真正需要的那个国家或城市里很薄的池子，对你的工作而言，比一个在那里很密的较小网络更糟，所以唯一要紧的池子规模，是你正在采集之处所可得的那一份。质量排第二，因为被标记或被过度使用的地址会招来质询与失真的响应，无论它们有多少个，这就是为什么 IP 信誉对你的成功率的影响，比数量更直接，也是为什么去理解一个住宅 IP 究竟是什么会有帮助。并发可得性排第三：在你送出流量的那一刻可用的是什么才要紧，而不是这张网络曾经见过的每一个地址的累计计数。

其实际后果是，你不该按池子规模去挑一家提供方。拿一笔小额采购去跑你自己的工作负载并做测量——那正是测试速度、成功率与位置准确度那篇指南的用途。

该拿来做估算的是什么：带宽

既然你被计费的是搬动的数据、而非用到的地址，那值得去预测的数字就是带宽。估一估你那些目标的页面或响应大小，乘以你打算采集的量，你就得到一个与你实际将付之数相对应的数字——那正是估算每月带宽里所摆出的做法。这也让最大的那根成本杠杆变得显而易见，而它并不是 IP 的数量：只取你需要的、而不是整张渲染好的页面，才是省钱之处，正如削减代理带宽成本里所讲的。

如何配置

两种模式都来自同一个 gateway，差别就是用户名里的一个字段。省掉会话标识，每个请求就轮换——而这正是大多数采集应当做的：

import requests

# Rotating: every request exits through a different address
ROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
r = requests.get("https://example.com/page",
                 proxies={"http": ROTATING, "https": ROTATING}, timeout=15)

# Sticky: one held IP per concurrent flow, counted per session
def sticky(session_id):
    url = (f"http://customer-USERNAME-country-us-sid-{session_id}:"
           f"PASSWORD@p.shifter.io:443")
    return {"http": url, "https": url}

# 50 concurrent flows means 50 distinct session identifiers
for i in range(50):
    proxies = sticky(f"flow{i}")
    # run one multi-step sequence on this held address

默认就轮换，只在某段流程确实需要时才守住一个会话，并让池子去处理分布，而不是自己去试着管理一份固定的地址清单。

验证那个答案

无论你得出什么数字，那都是一个起始假设，而唯一可靠的确认是测量。盯住按目标、按地区的成功率，因为一次下滑，会在它变成一个数据缺口之前很久，就成为”你那按地址的速率对那个站点过于激进”的信号——那正是监控流水线所给你的。当一条路由劣化时，故障转移会在你调整的同时让工作继续跑。而如果你正看到封锁，那修法更常是节奏与请求卫生，而不是更多地址——那正是避免被封的实质。

一份简短的清单

对你最繁忙的那个单一目标，每小时多少请求？那个数，除以那个目标所容忍的按地址速率，大致就是你需要多少分布。
有多少并发流程需要一个被守住的身份？那就是你的粘性会话数，也是唯一值得说出口的那个数字。
你需要哪些国家与城市，而池子在那些地方是密的、而不只是整体上大？
你会搬动多少数据？那才是决定成本的数字。
你是在自己的工作负载上测过成功率，还是在信一个标题上的数字？

底线

“我需要多少个 IP”，是一个从一个已不再适用的计价模型里继承来的问题。在一张现代的、按带宽计价的住宅网络上，你买的不是一个地址计数，你买的是对一个池子的访问、并为你经由它搬动的数据付费，所以你该为之设计的东西是分布：铺得足够开，好让任何单个目标，都不会从任何一个地址上看到超过寻常的流量。为量而轮换，只清点你并发的粘性会话，以一张网络在你真正采集之市场里的密度、以及它在你自己工作负载上所交付的成功率去评判它，并把你的预算以带宽、而非地址来估。把分布做对，IP 的数量就不再是一件你必须去想的事。

那正是住宅代理被造出来所要提供的东西——一个由真实的、家庭级 IP 组成的大池子，带国家与城市定位、默认轮换，并为那些需要它的流程提供粘性会话。按 GB 计价才是值得围绕它去规划的那个数字，因为你为自己真正拉取的数据付费，而不是为一个你但愿够用的地址数量付费。