2026 年粘性会话 vs 轮换会话 —— 谁在什么场景下更胜一筹，以及如何选对池策略

我们在客户侧见到最多的一类配置错误，既不是 IP 质量差，也不是国家选错，而是会话策略。很多人拿到一个住宅代理池，直接用默认的轮换模式接进自己的爬虫或 agent，然后纳闷为什么结账流程老是被标记。还有人给一个高强度的爬虫任务配了粘性会话，结果 30 秒内对着同一个 IP 打了 1,200 个请求，把目标站的限流规则全踩了一遍。

这篇文章基本就是我每周至少要跟新客户讲一次的那段对话。我们会讲清楚每种模式到底做了什么、各自更适合哪些场景、哪些翻车点最容易把人卡住，以及一张你接新池子时花两分钟就能跑一遍的流程图。这里绝大部分内容跟底层是哪家品牌无关 —— 粘性和轮换并不是供应商特有的概念，它们只是叠加在池子之上的路由策略。

粘性和轮换到底是什么意思

住宅代理池是一组上游 IP —— 根据供应商不同，通常从几万到几千万不等 —— 前面挂着网关入口。当你对网关完成鉴权并发出一个 HTTPS 请求时，网关会挑一个上游 IP 来转发。这两种模式描述的，就是同一个已鉴权会话在后续请求中"怎么挑 IP"。

轮换模式：每个请求都可能走不同的上游 IP。网关在每次转发时都现挑一个 —— 有时限定在某个国家或城市，有时完全放开。你的爬虫访问 A 页面，被路由到 IP 24.x.x.x；访问 B 页面，被路由到 67.x.x.x。从目标站的视角看，整条请求流就像是上千个不同的住宅用户，每人发了一个请求。

粘性模式：一旦你绑定了一个会话令牌（通常是用户名后缀或请求头），网关就会把一个上游 IP 钉死在这个会话上，持续一段时间。大多数池子我们默认 10 分钟，在后台最高可配到 30 分钟。在会话保持粘性期间，你客户端发往该会话的每个请求都走同一个上游 IP。从目标站的视角看，整条请求流就像是一个住宅用户在站内点来点去。

有些供应商把这套叫"高轮换"/“基于会话”，或者"endpoint-mode"/“session-mode”。行为完全一样，区别只在营销话术。Bright Data、Oxylabs、Smartproxy、Iproyal，以及我们聚合的 14 个住宅品牌，都通过网关参数暴露出大致相同的这两种模式。

粘性会话什么时候更胜一筹

粘性会话之所以存在，是因为某些场景一旦 IP 在流程中途变了就会直接崩。三种常见模式：

多步结账与账户流程。 一个用户从 IP X 把商品加入购物车，又从 IP Y 进入结账，再从 IP Z 提交付款 —— 在任何现代风控系统眼里，这都像是会话被劫持了。Stripe Radar、PayPal Risk、Shopify Capital Bot Score、Klarna、Affirm —— 它们全都把"同一会话内 IP 不连续"当作强烈的欺诈信号。结账用粘性，没得商量。

我们在 agent 购物机器人上反复见到这个翻车。客户把 browser-use 接上默认的轮换住宅代理，agent 成功打开商品页、加购、进结账 —— 然后被验证拦截或直接硬封。他们把锅甩给池子。换成粘性，同一个池子、同一个目标、同一份脚本：第一次就成了。

登录 + 已鉴权浏览。 大多数主流站点都会把会话 cookie 跟 IP 指纹绑定。从 IP X 登录，再从 IP Y 请求一个受保护页面，结果被登出或者吃个 401。Twitter、Instagram、LinkedIn、Reddit，以及基本上所有面临严重滥用压力的站点都这么干。任何需要鉴权的流程，粘性都是必选项。

反爬验证挑战的破解。 Cloudflare Turnstile、hCaptcha、DataDome 挑战、PerimeterX 插页 —— 它们的原理都是签发一个跟你 IP 绑定的令牌。从 IP X 破解了挑战，却从 IP Y 把令牌递上去，令牌会被拒。粘性时长要足够覆盖"破解耗时 + 令牌有效期"还留有余量。10 分钟能罩住大多数流程；30 分钟留给更慢的打码农场。

带 IP 状态的地理锁定内容。 有些目标站会记住"你昨天从马德里的 IP 看过西班牙语版本"，并用这个信号在你回访时跳过语言选择器。如果你在轮换，你每次都会撞到语言选择器，反而触发行为检测 —— 因为真实用户不会每次访问都看到它。

按 IP 限流的 API 鉴权流程。 OpenAI 的 API、AWS 签名请求、很多 SaaS API —— 它们都按 IP 限流。如果你在轮换，每个 IP 上的"消耗"都很小，但你却在每个 IP 上都去蹭那条限流线。粘性会把消耗集中起来，让 IP 攒出信誉，也避免了跨 IP 的限流互相干扰。

轮换会话什么时候更胜一筹

反过来说。当目标站对限流敏感、你需要把负载摊开，或者新鲜度比连续性更重要时，轮换更胜一筹。

页面之间相互独立的高量爬取。 要爬一百万个商品页？每个页面都是一笔独立交易。每个请求轮换一个 IP，能把负载分散到整个池子，也意味着没有哪个单一 IP 看起来像爬虫。代价是你没法维持会话状态，但对无状态爬取来说你本来也不需要。

搜索引擎爬取。 Google、Bing、百度都按 IP 激进限流。在这里用粘性等于自杀 —— 哪怕只设 10 分钟，你打个 50-100 个 SERP 就能把这个 IP 烧掉。用住宅池轮换、每次查询一个 IP（或每页结果一个 IP），才是标准打法。再配上足够的查询间隔和良好的 user-agent 变化。

广告验证。 当你要核实广告在各地是否正确投放时，每一次检查都应该看起来像一个独立用户。每次检查轮换一个 IP 正是你想要的 —— 而且你通常还需要次国家级的地理控制（城市或邮编），因为有些广告活动是按都会区定向的。

零售/航空/酒店的价格爬取。 这类目标站对"IP + 浏览器指纹"的关联很激进。同一个 IP 在五分钟内爬两次价格 = 机器人。同一个 IP 只查一次价格、再也不回来 = 噪音。轮换更胜一筹。我们见到客户在做旅游聚合搜索爬取时，用 F-Geofast 这类快速池跑"每个请求一个 IP"；那就是标准配置。

SEO / 品牌监控。 爬自己的站或竞品站，检查排名、内容、死链。用轮换住宅代理能避免你的爬虫在目标站的分析里露脸成"一个不停打遍每个页面的可疑 IP"。

球鞋、游戏、票务发售流程。 反直觉，但事实是：纯发售那一刻应该用轮换。站点此时没有任何状态需要维持（你之前没来过），而每个 IP 用一次就烧掉，能最大化你抢到那一个成功名额的概率。一旦商品进了购物车，就切到粘性去结账。这个模式我们在球鞋代理指南里有详细讲解。

那些专坑人的翻车点

有几种模式我们见得够多，值得明确点出来：

粘性时长太长。 给一个只需 4 分钟的结账流程配 30 分钟粘性，每个会话白白浪费 26 分钟的 IP。再乘上并发量，你会把池子可用的独立 IP 预算烧穿。把粘性时长调到大约"最长预期会话时长的 1.5 倍"。

粘性时长太短。 反过来。给一个 4 分钟的结账流程配 1 分钟粘性，意味着 IP 会在付款中途轮换，恰好触发你本想避开的那个欺诈信号。一定要在真实会话过程中，用 curl --proxy your_gateway:port https://ipinfo.io/ip 每 30 秒重复跑一次来测试，确认在结账完成前 IP 不会真的变掉。

轮换时地理多样性不够。 如果你的池子在目标国家只有 5,000 个独立 IP，而你每秒发 50 个请求，那池子在 100 秒内就会把全套 IP 跑完一轮。从目标站的视角看，100 秒之后你开始撞上的"新鲜" IP，其实是它们 100 秒前就见过的那些 IP —— 而现代反爬会盯着这一点。让池子规模跟你的请求速率匹配。

在一个脚本里不小心混用了模式。 你的库有个默认会话 ID 在不同线程间各不相同。两个线程共用一个会话，就会让多个并发请求复用同一个粘性 IP，看起来很怪（一个 IP 同时干 5 件事）。如果你用粘性，务必让每个并行 worker 都有自己的会话令牌，并通过在每个 worker 内部打印 IP 来验证。

轻信粘性时长文档。 有些上游供应商会缺斤少两 —— 它说 10 分钟，但 IP 4 分钟就变了，因为上游对端掉线了。永远要凭实测说话。我们在自家池子上监控这一点，当某个品牌撑不住文档承诺的粘性窗口时就重新调度流量；我们很多供应商对接都在住宅代理后台里有品牌专属的相关说明。

一棵快速决策树

配置新池子时，走一遍这个：

1. 你的工作流是否跨越多个、且必须看起来像同一个用户的请求？ 是 → 粘性。否 → 轮换。
2. 如果用粘性，你工作流里最长的单次会话预计多久？ 把粘性时长设成它的 1.5 倍，上限不超过品牌的最大值。
3. 如果用轮换，你会持续发送超过约 5 请求/秒吗？ 是 → 选一个"独立活跃 IP 数至少是你请求速率 5 倍"的池子。
4. 目标站会用 Cloudflare/DataDome/PerimeterX 发起挑战吗？ 如果会，且挑战破解耗时超过 1 分钟，那不管工作流是哪种类型都强制用粘性 —— 跨越了 IP 轮换的挑战注定失败。
5. 你在爬搜索引擎或广告投放型目标吗？ 强制轮换，至少做到每次查询一个 IP。
6. 你在做登录吗？ 粘性，没二话。

这不是纸上谈兵 —— 它是我们每周处理的工单的浓缩。大多数客户报上来的"这个池子不好用"，最后都查出来是模式选错了，而不是 IP 不行。

实现写法

切换模式的网关参数因供应商而异，但遵循几种常见形式。我们聚合的大多数品牌的惯例，是把会话 ID 嵌进用户名里：

# Rotating (no session ID)
curl -x http://USERNAME:PASS@gateway:port https://ipinfo.io/ip

# Sticky 10-minute session
curl -x http://USERNAME-session-abc123:PASS@gateway:port https://ipinfo.io/ip

有些品牌用请求头（X-Proxy-Session: abc123）代替用户名后缀。有些把轮换间隔放进用户名里（-rotate-30m）。后台在 My Proxies 下为每个品牌给出了正确的格式；如果你直接从那里复制生成好的 URL，模式默认就配对了。

对于 agent 类场景，我们建议为每个 agent 任务用一个全新的会话 ID，并在任务边界上轮换 —— 这样每个任务都像一段独立的人类会话，而前后相继的任务又不共享 IP 指纹。browser-use、Playwright、Selenium 都支持按 context 配置代理；在你新建浏览器 context 时配一个新的会话 ID 即可。

我们实际上会给客户默认推什么

当客户拿不准选哪个时：

• 爬取（最常见的需求）：轮换，住宅池。
• agent 浏览 / 结账 / 登录流程：粘性，住宅池，10 分钟会话。
• 一个任务里跨多站点的批量比价：轮换，住宅，快速品牌。
• 带地理精度的广告/SEO 验证：轮换，住宅 + 城市/邮编定向。
• 球鞋/票务发售：发售期间轮换，进购物车后切粘性。
• 我们自家正当业务的 API 限流绕过：粘性，ISP 静态 —— 此时 IP 信誉比轮换更重要。

如果你看到这里，发现自己一直在用错的模式做事，那么切换只是改一个参数。先在同一个池子上测一测，再去断定是池子本身的问题。十次里有八次，池子没毛病，是模式选错了。

—

Sara 从早期就开始在 Hell World 做反爬研究和池工程。如果你想就自己技术栈里某个棘手的会话策略问题聊一聊，Discord 服务器的 #engineering-help 频道是联系到她或团队成员最快的途径。