代理IP架构设计：采集Shopify / BigCommerce 公开数据时的代理策略

跨境选品采集的第一个误区：以为所有电商站的代理策略是通用的

跨境选品场景里，很多团队的做法是：搭一个采集脚本，挂上代理池，先跑 Shopify 站、再跑 BigCommerce 站、再跑独立站，代理策略统一——每个请求换一个 IP，并发 10，超时 15 秒。

结果往往是：Shopify 站跑得还行，BigCommerce 站成功率突然掉到 50% 以下，独立站更是各有各的表现。

原因是：不同平台的访问频率控制机制不一样，代理策略需要适配目标站的控制逻辑，不是反过来。

这篇以 Shopify 和 BigCommerce 为例，拆一下两种平台的访问频率控制特征，再讲怎么对应调整代理策略。方法本身是通用的——你可以用同样的思路分析任何目标站。

Shopify 的访问频率控制特征：Bucket 模型 + 请求头泄露

Shopify 的公开页面（产品列表、产品详情、集合页）有一套基于令牌桶（Token Bucket）的访问频率控制机制。这个机制有几个可以观察到的特征：

特征一：HTTP 响应头里会返回限流状态。 Shopify 的响应头通常会包含类似 X-Request-Id、Retry-After 这样的字段。当你触发了频率限制，会收到 429 状态码，Retry-After 告诉你等多少秒再重试。

特征二：限流粒度是 IP + 店铺。 同一个 IP 访问同一个 Shopify 店铺的频率被独立计算。你用同一个 IP 同时访问店铺 A 和店铺 B，两个店铺的限流计数器是独立的。

特征三：令牌恢复速度相对固定。 根据公开文档和社区实践，Shopify 公开页面的频率限制通常是每秒 2-4 个请求（具体值因店铺计划不同而异，且可能变化）。令牌用完后需要等恢复，不是硬性封禁。

这意味着什么？

对 Shopify 来说，代理策略的核心不是"换 IP 速度"，而是控制同一个 IP 对同一个店铺的请求速率。你有 100 个 IP，每个 IP 每秒发 2 个请求，总吞吐就是 200 QPS——比用 10 个 IP 每个拼命发 20 个请求然后被限流、重试、再被限流效果好得多。

BigCommerce 的访问频率控制特征：更激进的指纹关联

BigCommerce 的公开页面访问频率控制相对不那么透明，但有几个可以通过实际测试观察到的特征：

特征一：不一定返回 429。 BigCommerce 在触发限流时，有时直接返回 403 或显示验证页面，而不是标准的 429 + Retry-After。这意味着你不能简单地靠"收到 429 就等一下"来处理。

特征二：可能做更多的请求环境关联。 除了 IP 地址，BigCommerce 可能会关联请求头中的其他信息（如 User-Agent 一致性、Accept-Language、连接特征）来综合判断。单纯换 IP 但请求头不变，效果可能打折。

特征三：限制恢复时间更长。 一旦某个 IP 被限制，冷却时间可能不是几秒，而是几分钟甚至更长。

这意味着什么？

对 BigCommerce 来说，代理策略的核心是IP 和请求指纹的联动轮换——换 IP 的同时要换请求头的组合，而且被限制的 IP 需要更长的冷却时间。

代理调度策略：怎么根据这些差异做适配

基于上面的分析，代理调度层需要对不同平台采用不同的策略参数。具体做法：

按平台类型建策略配置。 给 Shopify 类目标站和 BigCommerce 类目标站分别设一组参数：

 PLATFORM_STRATEGY = {
     "shopify": {
         "rotation_mode": "time_based",
         "rotation_interval": 30,        # 30秒换一次IP
         "max_qps_per_ip": 2,            # 每个IP每秒最多2个请求
         "cooldown_on_429": 5,           # 收到429后冷却5秒
         "cooldown_on_403": 60,          # 收到403后冷却60秒
         "rotate_headers": False,        # Shopify对请求头不敏感
         "session_sticky": False,        # 不需要粘性会话
     },
     "bigcommerce": {
         "rotation_mode": "per_request",
         "rotation_interval": None,
         "max_qps_per_ip": 1,            # 保守一点
         "cooldown_on_429": 30,
         "cooldown_on_403": 300,         # 冷却时间更长
         "rotate_headers": True,         # 换IP时同时换请求头
         "session_sticky": False,
     },
     "default": {
         "rotation_mode": "per_request",
         "rotation_interval": None,
         "max_qps_per_ip": 3,
         "cooldown_on_429": 10,
         "cooldown_on_403": 120,
         "rotate_headers": False,
         "session_sticky": False,
     }
 }

速率控制器实现。 在代理调度层加一个令牌桶，限制同一个 IP 对同一个域名的请求速率：

 import time
 import threading
 ​
 class RateLimiter:
     def __init__(self, max_qps):
         self.max_qps = max_qps
         self.tokens = {}  # {ip:domain: [timestamps]}
         self.lock = threading.Lock()
 ​
     def allow(self, ip, domain):
         key = f"{ip}:{domain}"
         now = time.time()
         with self.lock:
             if key not in self.tokens:
                 self.tokens[key] = []
             # 清理1秒前的记录
             self.tokens[key] = [t for t in self.tokens[key] if now - t < 1.0]
             if len(self.tokens[key]) < self.max_qps:
                 self.tokens[key].append(now)
                 return True
             return False

在取 IP 时，不仅要从池子里借到一个可用 IP，还要通过 RateLimiter.allow() 检查这个 IP 对当前域名是否还有请求配额。没有就跳过，试下一个 IP。

请求头轮换。 对 BigCommerce 类目标站，换 IP 时同时换一组请求头。维护一个请求头模板池：

 HEADER_PROFILES = [
     {
         "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...",
         "Accept-Language": "en-US,en;q=0.9",
         "Accept-Encoding": "gzip, deflate, br",
     },
     {
         "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 ...",
         "Accept-Language": "en-GB,en;q=0.8",
         "Accept-Encoding": "gzip, deflate",
     },
     # ... 更多组合
 ]

注意：请求头模板要合理，不要混搭——比如不要在 Windows 的 User-Agent 上挂 macOS 的平台标识。浏览器的指纹组合是有内在一致性的，胡乱组合比不换更容易被识别。

采集架构：怎么在一套系统里同时处理多种平台

如果你的跨境选品采集需要同时覆盖 Shopify 站、BigCommerce 站和其他独立站，架构上建议这样组织：

目标站分类层。 先对目标站做分类：Shopify、BigCommerce、WooCommerce、其他。分类可以通过检测响应头或页面特征来自动判断——比如 Shopify 站的 HTML 里通常包含 cdn.shopify.com，BigCommerce 站的响应头可能包含 X-BC- 前缀的字段。

 def detect_platform(url, response_headers, html_snippet):
     if "cdn.shopify.com" in html_snippet:
         return "shopify"
     if any(h.startswith("X-BC-") for h in response_headers):
         return "bigcommerce"
     # WooCommerce 检测
     if "wp-content" in html_snippet and "woocommerce" in html_snippet.lower():
         return "woocommerce"
     return "default"

策略路由层。 根据平台类型从 PLATFORM_STRATEGY 里取对应的参数，传给代理调度模块。

代理调度层。 接收策略参数，执行相应的轮转模式、速率控制和请求头轮换。这层的代码不需要知道目标站是什么平台——它只根据参数行事。

这种分层的好处是：新增一种平台类型时，只需要加一组策略参数和一个检测规则，不用改调度层的核心逻辑。

冷却队列：被限制的 IP 不要立刻丢掉

Shopify 的 429 冷却几秒就能恢复，BigCommerce 的 403 可能要等几分钟。不管哪种，被限制的 IP 不应该直接从池子里删除——它只是暂时不能用于这个目标站，过了冷却期还能复活。

实现方式：在 Redis 里维护一个"冷却队列"：

 Key:    proxy:cooldown:{ip:port}:{domain}
 Value:  resume_timestamp
 TTL:    等于冷却时间

取 IP 时，除了检查评分和域名隔离，还要检查这个 IP 是否在冷却中。冷却中的跳过，TTL 到期后自动释放，IP 恢复可用。

这比直接淘汰 IP 的好处是：代理 IP 有成本，一个 IP 被某个目标站限制了 5 分钟，但它对其他目标站可能完全正常。直接删除等于浪费资源。

怎么知道你的策略参数设对了

策略参数（QPS 上限、冷却时间、轮转间隔）不是一成不变的。目标站会调整访问频率控制策略，你的参数也需要跟着调。

建议的验证方法：

小样本探测。 每次开始正式采集前，先用 5-10 个 IP 做一轮探测：逐步提高单 IP 请求速率，记录什么速率下开始收到 429/403。这个"触发阈值"就是你设 max_qps_per_ip 的依据。

成功率趋势监控。 正式采集过程中，按目标站分别统计成功率。如果某个平台的成功率突然从 90% 掉到 70%，大概率是对方调整了限流策略，你需要重新做探测并调参。

不同参数组的 A/B 测试。 把同一个目标站的采集任务分成两组，用不同的策略参数（比如 A 组 QPS=2、B 组 QPS=3），跑一天，看哪组的综合成功率和吞吐更高。

FAQ

Q：怎么判断一个 Shopify 站用的是基础版还是高级版？

从采集侧很难准确判断，因为 Shopify 不在公开页面暴露店铺计划类型。但好消息是：对于公开页面的访问频率控制，不同计划版本的差异不大——主要差异在 API 调用限额上，不在前端页面访问上。所以代理策略不需要区分店铺计划版本。

Q：BigCommerce 站的 API 和前端页面的限流是一样的吗？

不一样。BigCommerce 的 API（如果你有合规的 API Key）有独立的频率限制体系，和前端页面的访问频率控制是分开的。如果目标站提供了公开 API 且你有合规的访问权限，走 API 通常比采集前端页面更稳定，也更可控。

Q：请求头轮换的"模板"需要多少组？

10-20 组就够了。关键不是数量多，而是每组的内在一致性——User-Agent、Accept 系列、Sec-CH-UA（如果模拟 Chromium 系浏览器）这些字段要对得上。一组不自洽的请求头比不换更容易触发异常判断。