只要做过电商价格监控，多多少少都经历过这套循环：
- 刚上线：脚本飞快，价格几乎实时更新；
- 一周后：429、验证码开始多起来；
- 再过一阵：整段 IP 被限，连手动打开页面都开始卡。
然后大家第一反应就是：代理不行，换服务商、加 IP、升配置。
但现实是——只要策略不改，用哪家的住宅代理或机房代理，走着走着都容易进同一个坑。
这篇想解决的问题很直接：
问题：为什么价格监控总被限频？
解决：搭一套“频率控制 + 任务分片 + 失败重试”的通用方案，再用易路线路池去承载。
一、平台为什么要限你？先用对方视角看自己
在平台日志里，你不是“某个脚本”，而是一堆行为模式：
- 整体请求量冲得太猛
- 某个时间段，请求突然飙升，像在“扫站”。
- 单 IP 行为非常不自然
- 一条 IP 每秒刷一堆详情页、列表页，没有正常人的浏览节奏。
- 单商品 / 单店铺被重复围观
- 某个 SKU 几分钟被访问几十次，某店铺页面被成片抓取。
- 错误后的暴力重试
- 429 / 验证码 / 超时后立刻重试，再不行就换 IP 接着撞。
所以限频通常不是一句“IP 不干净”能解释的，而是：
总量太猛 + 单 IP 太凶 + 单资源太集中 + 重试太暴力 一起叠出来的。
二、方案一：先把频率控住——全局 / 单 IP / 单资源三道闸
1. 全局 QPS（站点级）
问题： 整体刷得太快，一眼就是“系统抓取”。
做法：
- 给每个站点设一个总 QPS，比如：20–30 QPS 起步；
- 先跑一周，看 429 / 验证码比例再慢慢往上调。
2. 单 IP QPS（代理级）
问题： 单条 IP 表现得太“机器人”。
做法：
- 给每条 IP 设上限：住宅 1–2 QPS，机房 2–3 QPS；
- 超限就让这条 IP 暂停几秒（熔断），再恢复。
3. 单资源频率（SKU / 店铺级）
问题： 某个商品或店铺短时间内被围着刷。
做法：
- 同一 SKU：比如每 10 分钟最多访问 1 次；
- 同一店铺首页：每分钟不超过 3–5 次；
- 超出的请求排队或延后执行。
一行话总结：
全局别像在“扫站”，单 IP 别像“脚本”，单资源别像“被盯上”。
三、方案二：任务分片——别把所有压力砸在同一块地方
就算你限速了，如果任务全挤在同一时间、同一批 IP、同一堆 SKU 上，风控看着还是不舒服。
任务分片的三个常用维度
- 按店铺 / 品牌分
- A 品牌用一组 IP，B 品牌用另一组；
- 某品牌被限，只改它那一组。
- 按类目 / 价格段分
- 类目拆成多队列：3C、服装、美妆……各跑各的节奏；
- 高毛利 / 高关注商品更新频率高一点，其它慢一点。
- 按时间窗口分
- 白天只刷重点商品；
- 凌晨跑全量补扫，错开平台高峰。
新手可直接落地的例子
你有 10 条易路机房 IP，要监控 5000 个 SKU，可以这样：
- 把 5000 个 SKU 拆成 5 个队列，每队 1000 个；
- 队列 1、2：每 10 分钟跑一轮，用 IP1–4；
- 队列 3、4：每 20 分钟跑一轮，用 IP5–8；
- 队列 5：只在凌晨 2–5 点跑，用 IP9–10。
这样一来：
- 不同 IP 干不同活；
- 不同队列节奏不一样；
- 平台看到的是“分散的、规律但不激进的刷新”。
四、方案三：失败重试——别把重试变成“自杀开关”
错误一定会有，问题在于你怎么处理。
按错误类型拆策略
- 网络错误（超时、连接失败）
- 重试 1 次；
- 换同组另一条 IP 再试 1 次；
- 再失败就丢进“补偿队列”，不要在当时死磕。
- 429 / 503 / 验证码页
- 这是明确在说“太频繁了”。
- 做法：
- 首次：延迟 5 秒，再试；
- 再遇：延迟 15 秒；
- 还遇：延迟 60 秒+，并下调本 IP 的频率上限或暂时停该队列。
- 404 / 410 等资源错误
- 标记 SKU 失效或下架，不要再打。
- 登录 / 权限相关错误
- 说明 Cookie / 登录流程出问题；
- 优先修登录逻辑，而不是换 IP 硬冲。
一句话：
能等就稍微等一下，能认输就别硬上。
五、方案落地：在易路代理里怎么搭线路池和标签？
策略有了，还需要一块好用的“地基”来承载。
1. 线路池怎么拆？
可以先拆三类：
PRICE_DC_POOL：机房 IP 池，负责绝大部分页面抓取；PRICE_RESI_POOL：小规模住宅池，用于登录态、购物车、订单等敏感接口；PRICE_SPECIAL_POOL（可选）：给风控极严的站点，用更干净、更少复用的线路。
2. 标签怎么用？
- 按站点 / 品牌打标签：
SHOP_A_DC、SHOP_B_DC、GLOBAL_DC； - 脚本写的是“用 SHOP_A_DC 标签”，而不是写死某个 IP；
- 换节点、扩容、摘掉不稳定 IP，全在易路面板里处理，代码不用改。
3. 新手接入小提示
如果你对 HTTP / SOCKS5 配置不熟，可以先照着
易路代理爬虫与 API 场景配置说明
跑通一条“通过代理访问目标站点”的基础链路，再慢慢把频控和任务分片逻辑往上叠。
六、为什么价格监控这类长跑，更适合用易路来做底座？
不拐弯，直接说几个实在的点：
- 住宅 + 机房搭配灵活：
机房线路顶住大量公开页面抓取，住宅线路专门处理登录和敏感操作，既稳又不会把钱全砸在住宅上。 - 多区域节点，方便“靠近目标站”：
美区、欧区、日韩、东南亚都有节点，可以根据电商站点的主要用户区来选更近的一圈，减少超时和抖动。 - 天然支持“分池 + 标签”的架构：
不同品牌、不同国家、不同优先级，都可以单独建线路池、打标签。你可以非常自然地把“任务分片”和“线路分工”绑定起来。 - 节点健康度可视化：
易路后台能看到每条线的延迟和成功率，哪条线最近在抖，一眼能看出来，配合你的频控逻辑做“自动降权 / 下线”非常方便。
总结一句：
你负责设计好节奏和规则，易路帮你把线路和出口整理得清清楚楚，这才是一套能长期复用的价格监控底盘。
FAQ
Q1：刚上来全局 QPS 开多少合适？
建议单站点 20–30 QPS 起步，单 IP 1–2 QPS。跑一周，看 429 / 验证码比例，再决定要不要往上加。
Q2：住宅和机房线路怎么配比较划算？
通常用机房线扛大部分抓取，住宅线只跑登录态和关键接口。预算紧的时候可以先 8:2 或 7:3，再根据风控情况微调比例。
Q3：任务分片优先按什么维度切？
优先考虑业务维度：品牌 / 类目 / 国家。谁最重要就单独一片，其他可以合并。关键是“别所有请求堆在一起”。
Q4：失败重试最大次数建议是多少？
网络错误 1–2 次足够，遇到 429 / 验证码与其反复重试，不如拉长间隔、降低该 IP 和队列的速率。
Q5：刚起步的小团队需要准备多少条易路线路？
可以用“小算式”：目标 QPS ÷ 单 IP 上限 = 基础 IP 数量，再多预留 20–30% 做冗余。比如 20 QPS / 2 QPS ≈ 10 条，再加 2–3 条备用。
电商价格监控想跑得久，靠的不是“更猛的轮换”和“更多的 IP”，而是节奏合理、压力分散、出错时肯松油门。
当你把频率控制、任务分片和失败重试都写成固定规则，再把这些规则落在一组分池清晰、节点可视的易路代理线路上，价格监控这件事就从“每天救火”，变成“能长期扩的基础能力”。