如何使用轮换代理逐请求轮换与粘性会话，代码实战

轮换代理是一个主机和端口，随时间向你提供不同的出口 IP，因此发出一千次请求的爬虫不会从同一个地址发送，避免目标网站对该地址进行速率限制和封锁。你将 HTTP 客户端指向轮换端点而非目标网站，轮换在后台发生。这就是整个机制。其他所有内容（逐请求 vs 粘性、住宅 vs 数据中心、自建 vs 购买）都是叠加在此之上的选择。

本指南是实践版本。它涵盖真正改变代码的那一个决策（在每次请求上轮换新 IP，还是在一个会话期间保持同一 IP），为每种方式提供可运行的 Python 示例，然后直接说明何时使用托管轮换端点优于自行组建和维护代理池。如果你想了解代理的基础概念，什么是代理服务器 介绍了这一切所依托的间接层。

唯一重要的决策：逐请求 vs 粘性会话

几乎所有关于轮换代理的问题都归结为一个选择，而且不是选哪家提供商。而是：你想要每次请求都获得新 IP，还是在一系列请求中保持同一 IP？这两种模式解决的是相反的问题，选错模式是"使用了轮换代理"的爬虫仍然被封锁的最常见原因。

逻辑很简单。当每次请求彼此独立时（你一个接一个地拉取商品页面，不存在状态延续），每次请求使用新 IP 可以分散负载，使没有单一地址触发速率限制。但一旦请求之间相互依赖（设置了 cookie 的登录、你添加商品并结账的购物车），中途轮换就会让你失败。网站会看到你的会话在两次点击之间跳转到不同的国家，然后将你踢出。这时你需要粘性会话：整个序列使用同一出口 IP，再为下一个用户换一个。

Python 中的逐请求轮换

逐请求轮换最简洁的方式是让托管端点来处理：你将客户端指向一个主机，出口 IP 在后台更换。对你的代码来说，这只是一个代理，因此 requests 中除了代理 URL 之外什么都不需要改变。下面是一个简单的爬取示例，通过多次访问 IP 回显服务来验证 IP 正在变换。

# Per-request rotation: one endpoint, a new exit IP each call.
import requests

token = "_YOUR_TOKEN_"
endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012"
proxies = {"http": endpoint, "https": endpoint}

# Hit an echo service 3 times; each line should show a different IP.
for _ in range(3):
    resp = requests.get("https://httpbin.org/ip", proxies=proxies, verify=False)
    print(resp.json()["origin"])

将 httpbin.org/ip 替换为你的真实目标，同一代理配置会让每次请求都通过轮换出口发送。verify=False 标志会跳过 TLS 验证，因为流量通过代理的隧道中转；在生产环境中，你应该将 requests 指向提供商的 CA 证书包，而非禁用验证。从这里开始，解析工作照常使用 BeautifulSoup 或你已有的任何工具，代理对其是透明的。

Python 中的粘性会话

对于必须像一个用户一样的流程，你需要在属于同一会话的请求间保持出口 IP 固定。使用托管端点时，通常的机制是使用单个 requests.Session（以便 cookie 持久保留），并传入一个会话标识符，网关用它在一段时间内固定一个 IP。会话负责在请求间传递登录 cookie；固定 IP 则阻止网站看到你的"用户"在操作中途传送到别处。

# Sticky session: one IP + one cookie jar across a multi-step flow.
import requests

token = "_YOUR_TOKEN_"
endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012"

session = requests.Session()  # persists cookies across requests
session.proxies = {"http": endpoint, "https": endpoint}

# Step 1: log in (sets a cookie). Step 2: read a gated page.
# Same IP + same cookie jar make both look like one visitor.
session.post("https://example.com/login", data={"user": "u", "pass": "p"}, verify=False)
resp = session.get("https://example.com/account/orders", verify=False)
print(resp.status_code)

请求粘性窗口的具体方式（通过请求头、用户名中的会话 token 或专用端口）取决于提供商，请查阅其文档了解参数名称。模式是通用的：在共享状态的请求期间保持 IP，用户完成后释放。

自行实现轮换

你不一定需要托管端点来实现轮换。如果你有一个代理列表，可以自己为每次请求选择一个。了解这一点很有价值，因为它展示了托管端点为你做了什么，以及它在哪里会出问题。

# Manual rotation: cycle a list of proxies yourself.
import requests, itertools

pool = [
    "http://user:pass@ip1:port",
    "http://user:pass@ip2:port",
    "http://user:pass@ip3:port",
]
rotation = itertools.cycle(pool)  # round-robin instead of random

def fetch(url):
    proxy = next(rotation)
    return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=15)

使用 itertools.cycle 的轮询比随机选择更可预测，因为它均匀地分散负载，而不是重复使用随机数生成器偏好的那个。但请注意这段代码没有处理的内容：池中的无效 IP、返回带有 200 状态码的拦截页面的代理、在不同出口上重试失败请求、或移除已被标记的 IP。在实际运行中，这些情况才是大部分工作所在，而这正是托管轮换端点为你吸收的内容。如果你想了解循环地址的完整模式，如何轮换 IP 地址 深入介绍了其机制。

托管端点胜过自建的时机

上述手动版本对于针对容忍度高的网站的小型、稳定列表来说效果不错。一旦以下任一条件成立，它就不够用了：目标主动对抗机器人、你需要真实用户（住宅或移动）IP 而非数据中心 IP、你的代理池大到健康检查成为负担，或者你需要重试和逐请求 IP 选择却不想自己编写这些编排代码。

托管轮换端点将这一切压缩为一个主机和端口。你将客户端指向它，它负责选择出口 IP、按请求轮换或保持粘性会话、并在 IP 被封锁时在后台重试。你的爬取逻辑不会改变（仍然只是一个代理 URL），但代理池管理、健康检查和轮换策略不再是你的代码。诚实的权衡：你放弃对单个 IP 的精细控制，换取不用维护一个机群。对于大多数爬取来说，这是合算的，因为 IP 管道不是工作中创造价值的部分。

还有更高一级的方案。当目标还需要渲染浏览器、发出 CAPTCHA 挑战或需要可信指纹时，仅轮换 IP 只是解决了一部分问题，此时应该阅读 回连代理 vs 爬取 API。轮换端点给你一个干净的 IP 然后退出；爬取 API 端到端地管理轮换、渲染和重试，并将完成的页面交给你。

常见故障及其识别方法

轮换代理以少数几种可识别的方式失败。知道你面对的是哪种情况可以节省数小时的猜测。

你仍然被封锁。 通常是两种情况之一：你在需要粘性会话的流程上使用了逐请求轮换（导致网站看到你的会话跳转 IP），或者你的 IP 类型不匹配目标网站。无论轮换速度多快，防护严格的网站都会丢弃数据中心 IP；它需要真实用户的 IP。根据防御措施而非轮换速度匹配 IP 类型，类型权衡在 数据中心 vs 住宅代理 中有详细介绍。

200 实际上是封锁。 许多网站会以 200 状态码返回 CAPTCHA 或"你是人类吗"的页面，因此检查 status_code == 200 是不够的。在信任响应之前，检查响应体是否有已知的封锁标记（挑战字符串、意外重定向、异常短的响应）。将其视为失败并在新 IP 上重试。

身份验证错误。 407（或挂起的连接）几乎总是意味着代理 URL 中的凭据错误或格式有误。仔细检查 token 和 user:pass@host:port 格式。如果你在总体上调试代理状态码，如何解决代理状态错误码 将常见错误码映射到原因。

缓慢或超时。 住宅和移动出口通过消费者网络路由，速度慢于数据中心是其设计特性。设置合理的 timeout（示例中使用 15 秒）并配合重试，而非让单个慢出口卡住整个运行。如果托管端点普遍超时，这是提供商的信号，而非代码错误。

真正有效的最佳实践

大多数"最佳实践"列表都是在凑篇幅。以下几条确实能改变你的封锁率。控制请求速率而非突发（轮换会分散 IP，但在一秒内从任何池中发出一千次请求看起来仍然像是自动化）。随 IP 一起轮换你的 User-Agent，因为在数千个"不同" IP 上保持固定 UA 是一个明显的特征。根据目标网站而非反射性地购买最贵的套餐来匹配 IP 类型。对于生产环境，使用有明确日志记录策略的提供商，而非从网上搜刮的免费代理列表，那些列表速度慢、寿命短，而且是真正的安全风险，在 代理安全吗 中有介绍。如果你的最终目标不止于轮换，如何抓取网站而不被封锁 将这些内容置于更广泛的背景中。

常见问题

如何在 Python 中使用轮换代理？

将你的 HTTP 客户端指向轮换端点而非目标网站。使用 requests 时，构建一个 proxies 字典（{"http": url, "https": url}），其中 URL 是你提供商的主机、端口和凭据，并将其传入每次 requests.get 或 requests.post。出口 IP 在后台更换，因此你的解析代码完全不需要改变。通过多次请求 httpbin.org/ip 等回显服务并确认 IP 不同来测试。

逐请求轮换和粘性会话有什么区别？

逐请求轮换在每次请求上给你一个全新的出口 IP，分散负载，适合无状态的高吞吐量读取。粘性会话在一系列请求中保持同一 IP，适用于登录、购物车以及任何必须看起来像单一用户的多步骤流程。独立读取使用逐请求，请求间有依赖关系时使用粘性。

为什么我使用轮换代理仍然被封锁？

两种常见原因：在需要粘性会话的流程上使用了逐请求轮换（导致网站看到你的会话在操作中途跳转 IP），以及使用了错误的 IP 类型。无论轮换速度多快，防护严格的目标都会丢弃数据中心 IP。根据防御措施匹配 IP 类型，对有状态流程保持粘性会话，并检查"200"响应是否实际上是 CAPTCHA 页面。

我应该自己轮换代理还是使用托管端点？

对于针对容忍度高的网站的小型、稳定列表，自建有效。一旦你需要真实用户 IP、大型代理池、健康检查、重试或逐请求 IP 选择，托管端点就更胜一筹，因为它将这一切隐藏在一个主机和端口之后。性能和成本范围因目标和提供商而异，并非固定常数。权衡是用 IP 级别的控制换来不维护机群。

轮换代理可以用于登录后的爬取吗？

可以，但你必须使用粘性会话，而非逐请求轮换。在登录及其后的受保护页面上保持同一出口 IP 和同一 cookie jar，让网站看到一致的访客。如果你需要一个在多次单独运行中始终固定的 IP，那是静态住宅（ISP）代理，而非轮换代理。

通过轮换代理我可以发送多快的请求？

比单一 IP 快，因为轮换将请求分散到多个地址，但轮换不是突发请求的许可证。在一秒内从任何池中发出一千次请求看起来仍然像是自动化。控制请求速率，设置超时和重试，并随 IP 一起轮换你的 User-Agent。住宅和移动出口速度慢于数据中心是其设计特性，请在超时时间中留出余量。

HR

Hassan Rehan

软件工程师 · Crawlbase

Crawlbase 软件工程师，撰写关于轮换代理、抓取，以及把代理接入真实代码的实战细节的实操指南。