在做大规模数据采集时，sticky vs rotating proxies 的选择往往决定了你的采集任务能不能稳定跑完。粘性会话（sticky proxy session）会把一个住宅出口 IP 固定一段时间，轮换会话（rotating proxy session explained）则在每次请求时换一个新 IP。两者并非二选一，而是按场景组合使用。本文从原理、会话控制、落地实现到运营调优，给出一份可执行的决策框架。
粘性会话与轮换会话的核心区别
理解差异最直接的方式是看出口 IP 的生命周期。一个 rotating proxy session 通常由网关在每次 HTTP 请求时随机分配一个新 IP，适合无状态、高并发的公开数据抓取。一个 sticky proxy session 则由网关为某个会话标识绑定一个 IP，并在固定 TTL（常见 1 到 30 分钟）内保持不变，适合登录、分页、购物车等多步流程。
| 维度 | 轮换会话 | 粘性会话 |
|---|---|---|
| 出口 IP | 每请求更换 | 固定一个 IP，TTL 内不变 |
| 典型 TTL | 无（per-request） | 1–30 分钟 |
| 会话标识 | 无需指定 | 用户名中带 -session-xxx |
| 适用场景 | 高并发公开数据抓取 | 登录、分页、购物车、CSRF |
| 封禁风险 | 分散到多 IP，单 IP 低 | 集中在单 IP，需回收策略 |
为什么 IP 绑定状态会让轮换失效
很多站点把会话状态与出口 IP 绑定。当你登录后，服务器会把 CSRF token、购物车、分页游标与“发起请求的 IP”关联。一旦下一次请求来自不同 IP（轮换默认行为），服务器会判定会话异常，返回 401、403 或重定向到登录页。这正是住宅粘性会话存在的根本原因：你需要一个看起来像真实用户的住宅 IP，并在整个多步流程中保持不变。
典型会触发 IP 绑定校验的场景包括：
- 需要登录态的电商后台、订单详情、价格历史；
- 带 CSRF token 的表单提交流程；
- 依赖游标或 offset token 的分页接口；
- 社交平台的“连续浏览”风控，对短时间内换 IP 极其敏感。
会话控制如何编码到代理用户名
ProxyHat 通过用户名中的 flag 控制会话行为。默认请求走轮换端点；若要粘性，则在用户名中加入 -session-abc123。结合 -country-US 可以把住宅出口固定到美国，甚至细化到城市：
# 轮换（默认，每次请求换 IP）
http://user:pass@gate.proxyhat.com:8080
# 粘性会话 + 美国 IP
http://user-session-abc123-country-US:pass@gate.proxyhat.com:8080
# 粘性会话 + 德国柏林
http://user-session-abc123-country-DE-city-berlin:pass@gate.proxyhat.com:8080
# SOCKS5 粘性会话
socks5://user-session-abc123:pass@gate.proxyhat.com:1080会话标识 abc123 可以是任意字符串。同一个标识会被网关映射到同一个出口 IP，直到 TTL 到期或主动更换标识。需要换 IP 时，只需改 session 标识即可立即获得新住宅出口，不必等 TTL 自然到期。
实战示例一：Python 按请求轮换
下面是一个最简单的轮换抓取示例，适合无状态的公开数据采集。每次请求由网关自动分配新 IP，无需在客户端维护会话池：
import requests
proxy = "http://user:pass@gate.proxyhat.com:8080"
proxies = {"http": proxy, "https": proxy}
urls = [
"https://example.com/page/1",
"https://example.com/page/2",
"https://example.com/page/3",
]
for url in urls:
r = requests.get(url, proxies=proxies, timeout=15)
print(r.status_code, r.headers.get("x-final-url", url))这种模式下，单 IP 的请求量被稀释到接近 0，适合 SERP、商品列表、新闻聚合等不需要登录的公开页。如果你在做 SERP 追踪，轮换通常是默认选择。
实战示例二：Node 持有粘性会话跨多步流程
对于需要登录后再抓取的流程，必须保持同一出口 IP。下面的 Node 示例使用 undici 的 ProxyAgent，并在用户名中固定 session 标识，确保登录、加购物车、结账三步都来自同一个住宅 IP：
import { ProxyAgent, request } from "undici";
const session = "order-flow-7f3a";
const proxyUrl = `http://user-session-${session}-country-US:pass@gate.proxyhat.com:8080`;
const agent = new ProxyAgent(proxyUrl);
async function step(path, opts = {}) {
const res = await request(`https://target-site.com${path}`, {
method: opts.method || "GET",
dispatcher: agent,
headers: opts.headers || {},
body: opts.body,
});
return res;
}
// 1. 登录（同一出口 IP）
await step("/login", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ user: "buyer1", pass: "secret" }),
});
// 2. 加购物车（IP 不变，购物车状态有效）
await step("/cart/add", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ sku: "ABC-123", qty: 1 }),
});
// 3. 查看结账页（IP 仍一致，CSRF token 通过）
const checkout = await step("/checkout");
console.log(checkout.statusCode);关键点：整个流程复用同一个 ProxyAgent，session 标识不变，因此网关会把所有请求路由到同一个住宅出口。如果中途换 session 标识，等于换 IP，购物车和登录态会立刻失效。
运营调优：TTL、回收与并发
粘性会话不是“设了就忘”。你需要根据目标站点的行为调 TTL、在封禁信号出现时主动回收、并控制并行会话数量。
TTL 调优
ProxyHat 粘性会话的 TTL 通常在 1–30 分钟区间。短流程（登录+一两次请求）用 5 分钟即可；长流程（多页爬取、结账）用 10–30 分钟。TTL 过长会让单 IP 累积过多请求，触发风控；过短则会在流程未结束时被迫换 IP，导致会话失效。
遇到 429/403 时回收
当某个 session 标识收到 429（限流）或 403（封禁），应立即丢弃该标识并生成新标识。不要在同一 IP 上重试——那只会加深风控权重。一个简单策略：
if status in (401, 403, 429):
session = f"retry-{uuid4().hex[:8]}"
# 用新 session 标识重建 proxy agent并行会话数
并行 session 数量取决于目标站点的承载能力和你的套餐并发上限。经验上，单个站点同时维持 50–100 个粘性会话是相对安全的起点；超过 200 个并发会话时，建议分站点分批，并监控整体成功率。ProxyHat 套餐提供不同并发档位，可在 定价页查看。
何时轮换优于粘性
如果你的目标是无状态公开数据（SERP、商品列表、公开新闻），轮换几乎总是更优。原因有三：
- 请求稀释：单 IP 请求量趋近 0，大幅降低触发频控的概率；
- 无需会话管理：客户端不需要维护 session 标识池，代码更简单；
- 横向扩展容易：并发上限取决于网关吞吐，而不是单 IP 的可承受请求量。
在 公开数据采集场景下，轮换 + 合理并发 + 随机延迟，通常能拿到 95% 以上的成功率，而不需要粘性会话的复杂度。
法律与合规边界
无论用粘性还是轮换，都要在法律边界内操作。在美国，CFAA（计算机欺诈与滥用法）对“未授权访问”有明确界定，绕过技术性访问控制可能构成违法。在欧盟，GDPR 对个人数据的处理有严格要求，即使数据是公开抓取的，只要涉及可识别自然人，就需合法依据。建议：
- 遵守目标站点 robots.txt 与服务条款；
- 不抓取需付费墙或登录后才能访问的受限内容；
- 对涉及个人数据的内容评估 GDPR/CCPA 合规性；
- 控制请求频率，避免对目标站点造成实质损害。
合规不是“加上代理就免责”，代理只是基础设施，法律责任的主体仍然是数据采集方。更多技术细节可参考 ProxyHat 官方文档。
关键要点
核心结论：轮换适合无状态公开数据，粘性适合有状态多步流程；通过用户名中的
-session-xxx控制会话标识；遇到 429/403 立即换 session；并行会话数根据站点承载和套餐上限调整；始终在法律边界内操作。
- 轮换端点：默认行为，每请求换 IP，适合高并发公开数据。
- 粘性会话：用户名加
-session-abc123，TTL 内固定住宅 IP。 - IP 绑定状态：登录态、CSRF、购物车、分页游标都会绑定出口 IP，必须用粘性。
- 回收策略：429/403 立即换 session 标识，不要在同 IP 重试。
- 并发上限：50–100 个粘性会话为安全起点，超过 200 分批处理。
- 法律：CFAA/GDPR 仍适用，代理不等于免责。
选型没有银弹。把sticky vs rotating proxies 当成两个工具，按流程是否有 IP 绑定状态来切换，才能在采集效率和稳定性之间找到平衡。需要查看支持的地理位置，可访问 ProxyHat 位置列表。
