Python爬虫反爬策略应对：User-Agent、Cookie与IP限制处理技巧

桃夭

发布时间：2026-10-29 | 5人浏览过

原创

针对Python爬虫面临的User-Agent校验、Cookie会话追踪与IP频次封禁三大基础反爬策略，系统讲解识别原理、排查方法、代码实现与工程化应对方案。

编写爬虫采集网络公开数据时，请求被目标站点拦截、返回空内容或直接抛出 403、429 等状态码，通常并非网络中断，而是触碰了站点的反爬虫风控规则。在绝大多数常规网站的防御体系中，风控过滤主要集中在客户端身份标识（User-Agent）、会话上下文凭证（Cookie）以及网络接入源（IP）三个核心维度。本文针对这三类最典型的反爬策略，系统梳理检测逻辑、代码应对方法与工程化实践技巧，帮助建立稳定健壮的数据采集逻辑。

Python爬虫反爬策略应对：User-Agent、Cookie与IP限制处理技巧 — 图 1：HTTP 请求反爬判定与分层拦截原理机制

一、User-Agent 伪装与请求标头协同机制

User-Agent（用户代理）是 HTTP 协议中用于标识发起请求的客户端软件环境的字符串。使用 Python 的标准网络库（如 urllib）或第三方库（如 requests）直接发起网络请求时，如果不显式指定请求头，客户端会在请求中携带默认的库标识，例如：

# Python 默认发出的 User-Agent 字符串示例
python-requests/2.31.0
Python-urllib/3.11

目标站点的 Web 服务器或反爬虫网关可以在接收到请求的瞬间，根据预设的正则表达式过滤规则直接拦截所有包含此类机器标识的请求，并返回 403 Forbidden 状态码。因此，伪装真实浏览器的 User-Agent 是爬虫能够获取数据的最基础前提。

1. 现代浏览器 User-Agent 的组成结构

合法的桌面端或移动端浏览器 UA 具备固定的格式规范，包含操作系统平台、排版引擎内核与具体版本号。例如，在 macOS 上运行的 Chrome 浏览器 UA 结构如下：

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

伪装 UA 时切忌随意拼接不存在的版本号。如果使用了过时多年的浏览器版本（如 Chrome 60）或者操作系统与浏览器内核冲突的组合，往往更容易被 WAF 判定为异常流量。

2. 请求标头（Headers）的协同与上下文对齐

只替换 User-Agent 字段在现代反爬体系中往往是不够的。浏览器在发起页面访问时，会同时附带一组协同工作的请求头。若请求头过于单薄，风控系统依然能够根据缺少 Accept、Accept-Language 或 Client Hints 标头识别出机器请求。

典型的必要协同请求头包括：

Accept: 声明客户端能够处理的内容类型，常规 HTML 请求通常包含 text/html,application/xhtml+xml,application/xml;q=0.9,...。
Accept-Language: 声明语言偏好，如 zh-CN,zh;q=0.9,en;q=0.8。
Accept-Encoding: 声明支持的压缩算法，如 gzip, deflate, br。
Referer: 标明请求来源页面。采集详情页时附带列表页的 Referer，能有效降低被风控直接拒绝的几率。

3. 代码实现：构建随机 User-Agent 与请求头管理

在实际生产环境中，建议维护一个常用主流真实 UA 列表进行轮询，或者使用 fake-useragent 库动态生成。同时，使用 requests.Session 统筹管理公共请求头：

import random
import requests

# 预设主流真实桌面端与移动端 User-Agent 池
USER_AGENTS = [
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36",
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Safari/605.1.15"
]

def create_configured_session():
    """初始化预装完整标准标头的 Session 实例"""
    session = requests.Session()
    
    # 随机选择一个 UA，并装配标准浏览器请求头
    selected_ua = random.choice(USER_AGENTS)
    headers = {
        "User-Agent": selected_ua,
        "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
        "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8",
        "Accept-Encoding": "gzip, deflate, br",
        "Connection": "keep-alive",
        "Upgrade-Insecure-Requests": "1"
    }
    
    session.headers.update(headers)
    return session

# 示例验证执行
if __name__ == "__main__":
    session = create_configured_session()
    # 示例输出：发送前打印校验生效的头部参数
    print("已生效的 User-Agent:", session.headers["User-Agent"])

二、Cookie 与用户状态追踪应对策略

仅有合法的 User-Agent 能够让请求进入 Web 容器，但很多网站要求访问者具备特定的身份状态。Cookie 是服务端写入客户端、并在后续每次请求中原样携带的一串键值对，目标网站常利用 Cookie 实现两类反爬机制：

会话鉴权与权限隔离：用户必须登录才能查看详情数据，服务器验证 Cookie 中携带的 SessionID 或 JWT Token。缺少此凭证时，请求会被服务端重定向（302）至登录页面。
动态防盗链与人机挑战：部分反爬系统（如 Cloudflare、各类安全防护 WAF）在检测到无 Cookie 请求时，先返回一段带有混淆 JavaScript 的 5秒盾或验证码页面。浏览器运行 JS 计算出动态 Token 并写入 Cookie 后重新发起请求才可放行。直接使用 requests.get() 无法执行 JS，因而拿不到合法 Cookie。

1. 使用 Session 自动管理 Cookie 生命周期

很多开发者习惯每次请求都调用独立的 requests.get()，这会导致前序请求中服务端返回的 Set-Cookie 响应头被直接丢弃。改用 requests.Session() 可以让底层自动维护 Cookie Jar，在多次请求间延续登录会话：

import requests

def fetch_data_with_session():
    # 创建带有连接池与 Cookie 自动维护功能的 Session
    session = requests.Session()
    session.headers.update({
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/122.0.0.0 Safari/537.36"
    })
    
    # 步骤 1: 访问登录接口或初始首页，获取初始会话 Cookie
    init_url = "https://example.com/login"
    login_payload = {"username": "crawler_user", "password": "your_secure_password"}
    
    # 模拟登录。服务端会返回 Set-Cookie 并自动存入 session.cookies
    response = session.post(init_url, data=login_payload, timeout=10)
    
    # 步骤 2: 验证 Cookie 是否正确获取
    if "session_token" not in session.cookies:
        print("未获取到核心会话凭据，需检查登录参数或是否有人机验证码")
        return
        
    # 步骤 3: 访问受权限保护的数据接口（此时会自动在请求头附带完整 Cookie）
    data_url = "https://example.com/api/v1/user/profile"
    data_response = session.get(data_url, timeout=10)
    return data_response.json()

2. Cookie 失效的主动拦截与刷新逻辑

Cookie 具有生命周期（Max-Age / Expires）。长时间运行的爬虫如果未处理过期事件，会持续收到重定向或报错。工程化应对方案是捕获特征响应并触发重登或切换：

def safe_request_with_retry(session, url, login_func):
    """带会话有效性校验的请求封装"""
    resp = session.get(url, allow_redirects=False)
    
    # 检测登录态失效：重定向到登录页或返回未授权状态码 401
    if resp.status_code in [302, 401] and "/login" in resp.headers.get("Location", ""):
        print("检测到 Cookie 会话已失效，正在触发重新获取...")
        login_func(session)
        # 重新发起原请求
        resp = session.get(url)
    
    return resp

三、IP 限制与频次控制工程技巧

当目标网站识别出某一个 IP 在短时间内发起了远超正常人类操作频率的请求量（例如 1 秒内请求数十次）时，就会触发网络层的限频规则。典型的表现有：

返回 HTTP 状态码 429 Too Many Requests。
服务端强行重置 TCP 连接（Connection Reset by Peer）。
返回 403 Forbidden，且浏览器正常访问也会提示“当前网络异常，已被临时封禁”。

1. 代理类型的关键区别：透明、匿名与高匿

使用代理 IP 时，必须明确代理的匿名级别：

代理类型	目标服务端能否检测到使用了代理	目标服务端能否获取爬虫真实 IP	爬虫场景适用度
透明代理 (Transparent)	能（存在 `Via` 标头）	能（`X-Forwarded-For` 记录真实 IP）	不可用，起不到防封效果
普通匿名 (Anonymous)	能（存在 `Via` 标头）	不能（隐藏了真实 IP）	低，已知是代理常被批量拦截
高匿名代理 (Elite / High)	不能（无任何代理标识标头）	不能（完全呈现为代理服务器自身）	必须采用此类型

排查提醒：免费代理网站公开提供的代理列表，绝大多数为透明代理或早已被各大云厂商拉入黑名单，连通率普遍不足 10%。在正式爬虫项目中，不要依赖公开免费代理作为生产环境的解决方案。

2. 请求节流与随机休眠抖动

固定间隔的轮询请求（例如每隔整整 1.0 秒执行一次请求）具有极其明显的机械周期性，易被统计分析模型直接捕获。在单机采集且并发要求适中的场景下，通过 time.sleep() 配合随机正态分布或区间抖动，能够显著降低被风控算法判为机器人的概率：

import time
import random

def polite_sleep(min_seconds=1.5, max_seconds=3.5):
    """产生随机抖动延迟，模拟自然人类浏览节奏"""
    sleep_time = random.uniform(min_seconds, max_seconds)
    time.sleep(sleep_time)

3. Python 中配置高匿代理与失败重试降级

在 requests 中，可以通过字典方式向 proxies 参数传递 HTTP 与 HTTPS 代理。在实际工程中，需要为代理设置严格的超时控制（timeout），并配置重试机制以防止由于单点代理节点失效导致任务整体挂起：

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def request_via_proxy(target_url, proxy_ip_port):
    """通过指定高匿代理发起网络请求，并配置自动化重试机制"""
    proxies = {
        "http": f"http://{proxy_ip_port}",
        "https": f"http://{proxy_ip_port}"
    }
    
    session = requests.Session()
    
    # 定义重试策略：针对 429、500、502、503 等瞬态状态码进行指数退避重试
    retries = Retry(
        total=3,
        backoff_factor=1.5,
        status_forcelist=[429, 500, 502, 503, 504],
        raise_on_status=False
    )
    
    adapter = HTTPAdapter(max_retries=retries)
    session.mount("http://", adapter)
    session.mount("https://", adapter)
    
    try:
        # 必须显式设置 timeout，代理节点经常出现网络黑洞或连接停滞
        response = session.get(target_url, proxies=proxies, timeout=(3.05, 7))
        
        if response.status_code == 200:
            return response.text
        elif response.status_code == 429:
            print("当前代理 IP 访问频率超限，应触发代理轮换")
            return None
    except requests.exceptions.ProxyError:
        print(f"代理节点 {proxy_ip_port} 连接失败，应从池中剔除")
    except requests.exceptions.Timeout:
        print(f"代理节点 {proxy_ip_port} 响应超时")
        
    return None

四、三大反爬应对策略全景总结

在实际爬虫系统的演进过程中，反爬手段往往并非孤立存在，而是多种机制组合生效。处理异常报错时，建议先确定拦截层次，再应用针对性的处理技术。

五、生产环境标准排查流程与防封建议

当现存爬虫程序突然产生大面积异常时，建议按照以下排查顺序定位瓶颈，避免盲目修改代码：

第一步（核验 IP 是否可用）：使用独立设备或切换手机移动热点，在终端通过 curl -I https://example.com 检查是否依然被阻止。如果更换网络后能够立即响应，说明当前网络出口 IP 已被封锁，应优先处理代理池与降频逻辑。
第二步（核验标头完整性）：使用浏览器开发者工具重新抓取当前正常访问的数据包，完整导出 Request Headers，并使用 Postman 或轻量 Python 脚本原样重放。如果原样重放成功而精简后的爬虫报错，说明站点校验了特定的自定义 Header、Referer 或 Client Hints 字段。
第三步（核验 Cookie 与会话状态）：检查报错页面是否伴随状态码 302。在响应中查看是否包含跳转至登录或验证码页面的指示。若存在，应检查对应账号是否被注销、Cookie 是否达到有效时限，并及时执行刷新。

遵循上述定位步骤与分层实现方案，可以在绝大多数常规数据采集场景下有效突破基础反爬限制，兼顾抓取效率与工程代码的稳健性。