requests 直接换 proxies 会失败，因为动态住宅代理依赖认证网关动态分配出口 IP，需每次请求携带含唯一 session 标识的 Proxy-Authorization 头并禁用连接池复用，否则无法轮换 IP。

怎么在python爬虫中使用动态住宅代理轮换ip？

为什么 requests 直接换 `proxies` 会失败？

因为多数动态住宅代理服务（如 BrightData、Oxylabs、Smartproxy）返回的不是固定 IP，而是通过认证网关（auth gateway）统一入口 + 用户凭证动态分配真实出口 IP。直接填 http://user:pass@host:port 往往被拒绝，或复用同一出口 IP，失去轮换意义。

核心问题在于：这类代理要求每次请求都携带完整认证信息，且服务端根据 session、时间戳、甚至请求头特征决定是否分配新住宅 IP —— 不是“换 proxy 字符串”就能轮换。

常见错误现象：407 Proxy Authentication Required 或 403 Forbidden，即使账号密码正确
关键原因：代理网关需要在 HTTP Basic Auth 头中传入特定格式的 credential（比如 user-session-xxx:pass），而 session ID 必须随请求更新才能触发 IP 轮换
requests 默认复用连接池，proxies 字典一旦设置就缓存底层 socket，不会自动重发 auth 头

用 `requests.Session()` 配合自定义 `Auth` 类强制重认证

绕过连接池复用，确保每次请求都重建 auth 头并带新 session 标识（如时间戳、随机字符串），是触发住宅 IP 轮换最稳定的方式。

示例（以 BrightData 为例，其他服务商逻辑类似）：

Claw Code Suite (Python-Only Edition)

仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...

下载

from requests import Session
from requests.auth import HTTPProxyAuth
import time
import random
<p>class RotatingResidentialAuth:
def <strong>init</strong>(self, username: str, password: str):
self.username = username
self.password = password</p><pre class="brush:php;toolbar:false;">def __call__(self, r):
    # 每次请求生成新 session token，强制后端分配新住宅 IP
    session_id = f"{int(time.time())}-{random.randint(1000, 9999)}"
    r.headers['Proxy-Authorization'] = f'Basic {base64.b64encode(f"{self.username}-session-{session_id}:{self.password}".encode()).decode()}'
    return r

session = Session() session.auth = RotatingResidentialAuth("your-user", "your-pass") session.proxies = { "http": "https://www.php.cn/link/10d755ce8b2c70b635902a9ee5cadfa8", "https": "https://www.php.cn/link/10d755ce8b2c70b635902a9ee5cadfa8" }

每次调用都大概率拿到不同住宅 IP

resp = session.get("https://www.php.cn/link/dc17d9b4862d86f8054735577c04462a")

不依赖 HTTPProxyAuth 自动行为，手动构造 Proxy-Authorization 头更可控
session ID 中混入时间戳+随机数，避免服务端命中缓存
必须用 Session() 实例而非 requests.get()，否则无法维持代理配置和自定义 auth

遇到 `ConnectionResetError` 或超时怎么调？

动态住宅代理节点不稳定是常态，直接报错退出会中断爬取。重点不是“重试多少次”，而是识别哪些错误可恢复、哪些该换代理通道。

ConnectionResetError、TimeoutError、SSLError：大概率是当前出口 IP 被目标站封或节点故障，应立即丢弃本次 session，新建 Session() 实例（不要复用）
429 Too Many Requests：说明该住宅 IP 请求频次过高，需 sleep 30s+ 再用新 session 重试，不能简单重发
务必禁用 requests 的默认重试机制（urllib3.Retry），它会在同一 socket 上重发，仍走原出口 IP
建议在 session 层加 timeout： session.timeout = (3.05, 15)（connect 3.05s，read 15s），避免卡死

为什么不用 Selenium + 代理插件？

虽然能跑通，但实际生产中基本不可行。

住宅代理网关通常不支持 WebSocket 或长连接，Selenium 的 DevTools 协议握手容易失败，报 net::ERR_PROXY_CONNECTION_FAILED
浏览器指纹暴露严重，很多住宅代理服务明确禁止自动化浏览器访问（检测到 webdriver 或 headless 直接拦截）
性能差：启动浏览器开销大，IP 轮换延迟高（秒级），而 requests + 手动 auth 可控到毫秒级
除非目标站强制校验 JS 渲染或 Canvas 指纹，否则纯 requests 方案更稳、更快、更隐蔽

真正难的不是“怎么换 IP”，而是让每次请求都被代理网关当作独立会话处理 —— 这取决于你构造 auth 头的时机、内容和 session 生命周期管理。漏掉任意一环，IP 就卡住不动。