NexIP官方博客
动态IP没有一个对所有任务都合适的更换时间。更可靠的做法是按“工作单元”换，再按风控信号补换，不按固定秒数换：
- 公开数据采集（SERP 监控、公开商品页、比价）：每个请求或每一小批请求换一次出口。
- 有登录态或多步操作的流程（登录、表单提交、购物车、结算）：整个流程用同一个出口，也就是粘性会话，流程结束后再换。
- 长期运营的店铺后台、社媒账号：这类任务谈不上多久换一次，它本来就不该用动态轮换，应该改用独占固定的静态IP。
在上面的基础上再加一条：收到 429、403 或验证码这类信号时，主动切换出口。
下面分别讲怎么判断自己属于哪一类，以及每一类具体怎么配。
第一步：判断任务有没有“状态”
判断方法很简单：后一个请求是否依赖前一个请求留下的东西，比如 Cookie、登录态、CSRF Token、购物车 ID，或上一页返回的翻页参数。
- 不依赖的，属于无状态任务。每个请求单独发出去都能拿到结果，换IP不影响结果。
- 依赖的，属于有状态任务。中途换IP，服务端可能认为会话被劫持或环境异常，于是让 Token 失效、要求重新验证，或者直接拦截。
很多采集任务是混合的。比如先抓列表页，再逐个抓详情页，这两步通常都是无状态的；但有些站点的翻页参数和会话绑定，连续翻页就成了一个小的有状态单元。按“请求之间有没有依赖”来切分，比按“任务类型”切分更准确。
无状态采集：按请求或小批次轮换
公开页面采集最常见的限制是针对单个IP的速率限制。同一个地址在短时间内请求过多，就会被限流或弹出验证码。把请求分散到不同出口，可以压低每个IP上的请求密度，所以这类任务通常用每次请求自动轮换，或者每一小批请求换一次。
选每次请求换还是小批次换，可以这样考虑：
- 请求之间完全独立，比如每个关键词查一次 SERP、每个商品抓一次详情页，用每次请求轮换最简单。
- 一组请求之间有轻度依赖，比如同一关键词需要连续翻几页，或者翻页参数和会话绑定，就把这一组请求当作一个单元，用同一个出口跑完再换。
抓亚马逊这类电商前台时，列表、详情、价格这几步分别怎么选轮换方式，可以参考抓取亚马逊竞品价格该用哪种代理IP。
换得越频繁不一定越安全。 如果 IP 一直在变，Cookie、请求头和 TLS 指纹却始终是同一套，或者出口在一批任务里跨国跨城地跳，这种组合本身就不像正常访问，反而容易被识别为机器人。几条实用的约束：
- 一个出口配一套独立会话。 换IP时同时丢弃旧的 Cookie，不要让带着上一个IP痕迹的会话在新IP上继续用。
- 地区保持一致。 同一批任务固定在目标市场所在的国家或地区，不要随机全球轮换。
- 请求特征要合理。 请求头和客户端特征与真实浏览器保持一致，单靠换IP解决不了请求特征的问题。
有状态流程：粘性会话一直保持到流程结束
登录、提交带 CSRF Token 的表单、加购和结算这类流程，中途不要换IP。应该配置粘性会话，让同一个出口从流程第一步服务到最后一步。
配置时注意三点：
- 会话时长要盖过最长的流程。 先估算你的流程最慢要跑多久，包括页面加载、等待和重试的时间，再确认粘性会话的保持时长是否足够。不同服务商的会话时长规则不同，以你所用产品面板里的说明为准。
- 流程结束就主动结束会话。 不论成功还是失败，都换一个新会话、配一套新的 Cookie 再开始下一轮，不要让一个粘性出口无限期地复用下去。
- 流程长到撑不住就换产品类型。 如果一个流程要持续几个小时，或者需要隔天回来继续，动态粘性会话就不合适了，可以考虑按小时或按天租用的静态短效IP。
粘性会话的作用是支撑临时、短时的交互步骤，它替代不了固定出口。
按信号换：遇到 429、403、验证码怎么处理
除了按工作单元轮换，还要在程序里加上按信号切换的逻辑。常见信号和处理方式如下：
| 信号 | 常见含义 | 建议动作 |
|---|---|---|
| 429 Too Many Requests | 请求频率超过站点限制 | 先退避等待，再换出口重试，同时调低该站点的并发 |
| 403 Forbidden | 出口被拒，或请求特征被识别 | 换出口重试一次；如果换了好几个出口仍然是 403，先排查请求头、指纹，以及页面是否需要渲染 |
| 验证码或挑战页 | 软拦截，状态码可能仍是 200 | 按页面内容识别，不要只看状态码；换出口后记录下来 |
| 超时、连接中断 | 出口不稳定或线路问题 | 换出口重试 |
有两点容易被忽略：
- 给重试设上限。 同一个请求连续失败几次后就放进待处理队列，不要无限重试。无限重试只会更快消耗流量，也会让站点看到更密集的异常请求。
- 出口不一定是原因。 如果所有出口都被拦，问题多半出在请求本身，而不是IP。
多快才算合适：用自己的数据测出来
各站点的拦截阈值不公开，而且会随风控策略调整，网上流传的“每分钟多少次”不能直接照搬。比较稳的做法是按目标域名分别测：
- 从低并发、较长的请求间隔开始，用小样本跑。
- 逐步提高单个出口承担的请求数和并发数，每次只改一个变量。
- 记录每档设置下的成功率、429 和 403 的比例、验证码出现率，以及每拿到一条有效数据消耗的流量。
- 拦截率明显上升时，退回上一档，把那一档作为这个站点的运行参数。
站点规则会变，这组参数也要定期复测。不同站点的结果差别很大，建议按域名分别保存，不要全局共用一套。
长期账号：直接用固定出口
跨境店铺后台、长期运营的社媒账号、TikTok 账号，需要的是一个长期稳定的登录环境。任何形式的动态轮换，包括粘性会话到期后的自然更换，都会让登录出口不断漂移。
这类任务应该用独占、固定的静态长效IP，一个账号或店铺对应一个出口，同时保持浏览器环境前后一致。浏览器环境这一层，可以交给 NexBrowser 这类工具管理。亚马逊后台的具体做法可以看亚马逊卖家后台用动态IP还是静态IP；如果拿不准采集任务该用动态还是静态，可以看静态住宅IP和动态住宅IP哪个适合采集。
判断完之后，怎么选和怎么验证
如果你的任务是公开采集或短流程，用动态住宅IP就够了。NexIP 的动态住宅流量套餐按流量计费，同一个套餐里可以选择轮换或粘性会话：无状态采集用轮换，登录和多步流程用粘性。接入方式支持 API、账密、端口转发和进程代理，协议支持 HTTP/HTTPS/SOCKS5，认证支持账密或白名单。抓取量很大、流量不好预估时，也可以看按带宽计费、不限流量的动态带宽套餐。
如果你的任务是长期运营店铺或账号，就选静态住宅长效IP。它独占固定，按月或按年租用，分家宽原生、家宽广播、数据中心三种。官网建议 TK 运营使用家宽原生IP。
拿到代理后，正式跑任务之前先做三项检查：
- 轮换是否生效。 在轮换模式下，连续请求一个返回出口IP的检测地址，确认每次或每批的出口确实在变。
- 粘性是否稳定。 在粘性模式下，在你估算的最长流程时间内反复请求，确认出口始终不变。
- 地区是否正确。 核对出口所在的国家和地区与设置一致。确认后，再用真实目标站点跑一小批请求，记下成功率，作为后续调整参数的基准。
评论(0)