大多数抓取系统最终收敛到的架构是：云服务商中的容器，按队列深度扩缩容，无状态且可随时丢弃。这对计算而言是正确的设计。但对出口流量而言，这是最糟糕的设计，因为这些容器获得的地址正是受保护站点首先检查的东西。
云服务商的地址段是公开的。任何人都可以枚举它们，大多数反爬供应商也确实这么做。来自这些地址的流量并非因为其行为而被拦截，而是在第一个请求完成之前，就已经因来源而被打分。解决方法不是增加更多的工作节点或改进请求头，而是把代码运行的地方和流量出口的地方分离开来。
出口层是一个独立的关切点
一个有用的思维模型是：你的工作节点是计算，你的地址是身份，两者应当独立扩缩容。
短生命周期的工作节点是好事：启动五十个，处理完队列，然后停止。短生命周期的身份通常是坏事：每个从新的云地址接入的新工作节点，都是一股陌生的流量。你真正想要的，是一组在工作节点更迭之间保持稳定的出口地址，这样你的目标站点看到的身份，不会因为自动扩缩容器的每次反应而不断变动。
ISP 代理恰好适合这个角色，因为它们是固定的。每个地址在整个套餐周期内专属于你的账户,注册在真实的 ISP 名下而非云服务商的地址段,且不会轮换。你的工作节点来来去去,地址却不变。
两种认证模式，选择关乎架构
套餐中的每个地址都使用相同的端口（1337），有两种认证方式。在云端部署中，这不是偏好问题,而是由你的网络架构决定的。
授权源 IP。 你在控制面板中将基础设施的公网地址加入白名单,然后无需凭证即可连接：
185.199.108.153:1337这种方式适用于你的出口地址是可预测的情况,实际上也就是在工作节点前面有一个具有稳定地址的 NAT 网关或等效设备。如果适用,这是更简洁的选项,因为你的容器中完全不含任何凭证。
用户名和密码。 可从任何地方使用,无需白名单：
185.199.108.153:1337:USERNAME:PASSWORD当工作节点确实是跨越不断变化的地址的短生命周期节点,或分布在多个区域,或运行在你无法控制出站地址的环境中时,这正是你需要的方式。无服务器函数和多区域部署都属于这种情况。
常见的陷阱是,在源地址实际上并不固定的环境中选择了源 IP 认证。它在测试时从某个子网连接可以正常工作,但到了生产环境中,由于平台将其分配到别处,就会间歇性失败。如果你无法确信地说出你的出口地址,就使用凭证认证。
在工作节点间分配地址
你有 N 个地址和数量可变的工作节点,所以必须有某种机制把二者对应起来。
行之有效的做法是,把地址列表当作一种共享资源,通过显式租约来管理,而不是让每个工作节点自行挑选。一个工作节点从协调层取得一个地址,在其任务期间持有它,然后归还。有两点很关键：不能让两个工作节点同时使用同一个地址,从而使其表观请求速率翻倍；工作节点崩溃也不应永久地将某个地址从流通中移除。
那种朴素的替代做法，即把工作节点标识哈希映射到索引，一旦你的工作节点数量发生变化就会失效，而对于自动扩缩容的部署来说，这种变化是持续不断的。你会在扩容时遇到冲突，在缩容时出现闲置地址。
单个地址的请求速率才是这里真正的预算所在。ISP 套餐的带宽是不限量的，所以约束条件不是流量的 GB 数，而是一个固定地址能够合理产生多少流量。这个数字决定了你的部署需要多少个地址，这也是为什么按吞吐量而非数据量来定规模才是正确做法的原因。
健康检查应内置于地址池中
地址不会以统一的方式失效。某一个地址可能开始在某个特定目标上频繁触发验证挑战，而其他一切都正常，此时接收到该地址的工作节点会持续产生垃圾数据，直到有人注意到为止。
按地址而非按整体来追踪结果。如果你从多个目标采集数据，那么按目标区分的、滚动窗口内的单地址成功率，能让你隔离单个地址，而不必拉下整个地址池。聚合指标只会显示百分之五的下降，却掩盖了其实是某一个地址完全失效的事实。
隔离应当是临时且自动的，并配合一个探测机制，在地址恢复后将其放回。关于最初如何确立”正常”基准的方法，参见测试代理速度、成功率和位置准确性。
在购买前先规划好地理分布
有一个细节容易让云端团队栽跟头：在 ISP 套餐中，你需要在地址被配置之前一次性选定国家分布，之后无法更改。目前可选七个国家。
这与云端部署中几乎所有其他事情都不同，你在那里习惯了低成本地改变主意。请根据你实际采集的目标来决定分布比例，如果你在两个市场之间拿不准，就先购买你确定的那个套餐,再追加,而不是去猜测。
ISP 不适用的场景
固定地址并不能全面取代轮换,而云基础设施容易让人误以为可以,因为这样操作模型要简单得多。
如果你的工作负载是针对众多目标的高流量采集，单地址请求速率会远早于成本之前变得不现实，其症状表现为数据质量下降而非报错。这类工作应当交给轮换式的住宅代理，因为在设计上每个请求都可以来自不同的地址。相关权衡在ISP 代理与数据中心及住宅代理的比较中有详细说明。
真正适合固定出口层的工作负载包括：长期会话、任何需要认证的场景、将你的地址加入白名单的目标、期望固定来源的合作伙伴 API，以及一致性比数据量更重要的稳定采集。混合架构很常见也很合理，用 ISP 地址处理持久性工作，用轮换网关处理批量工作。
运维要点
将地址列表保存在配置中，而非镜像里。 为了改变地址池而重建容器是可以避免的。在启动时从你的密钥存储或配置服务中读取它。
不要记录带凭证的 URL。 这是代理凭证泄露到日志聚合系统中最常见的方式，因为最自然的调试日志行往往就是整个连接字符串。
按地址限制并发，而不仅仅是全局限制。 一个在小地址池中分布不均的全局限制，会把负载集中到你的分配逻辑偏爱的那些地址上。相关机制详见速率限制与请求节流。
在部署内部进行测试。 从笔记本电脑发起的连通性检查只能证明你的凭证有效。它无法证明你的任务定义是否正确地传递了环境变量，而这才是大多数时候真正的故障原因。
常见问题
我可以在无服务器函数中使用 ISP 代理吗？
可以，使用凭证认证。源 IP 白名单在那种环境下不切实际，因为出站地址不由你固定。
自动扩缩容的部署需要多少个地址？
按峰值并发任务数和保守的单地址请求速率来定规模，而不是按工作节点数量。工作节点可以闲置，但地址不应成为峰值时用尽的那个瓶颈。
代理层会成为瓶颈吗？
ISP 地址运行在千兆速度的数据中心基础设施上，所以单地址吞吐量很少成为限制因素。并发策略通常才是首先起约束作用的因素。
每个服务都应该拥有自己的地址吗？
如果它们的流量模式差异很大，那么是的。把一个稳定的低速率服务和一个突发性服务混用同一个地址，意味着突发性服务会决定两者受到的对待方式。
总结
云端抓取基础设施被封锁的原因，与代码质量毫无关系：这些地址被公开标记为云地址。在短生命周期的工作节点前面部署一层固定的 ISP 出口，能够把身份与计算分离开来，而这正是这种架构本来就需要的分离方式。
显式地租用地址，按地址追踪健康状况，按请求速率而非带宽来定规模，并在购买前就决定好地理分布，因为这个选择是不可更改的。相关套餐请见 ISP 代理定价页面。