Scrapy + 隧道代理：企业级爬虫 5 步上手指南

692 阅读 0 评论 75 点赞

当爬虫从个人脚本走向生产环境，最先碰壁的往往不是解析逻辑，而是 IP 封禁。目标站点的反爬策略日趋成熟，仅靠单机裸 IP 发请求，几分钟就会被拉黑。隧道代理正是为解决这个问题而生——你只需对接一个固定入口，供应商在后端帮你完成 IP 轮换、地域调度和连接保活。

本文以国内主流代理服务商青果网络（qg.net）的隧道代理为例，结合 Scrapy 框架，用 5 步带你从零搭建一个可用于生产的企业级爬虫系统。隧道代理的核心优势在于"云端自动切换 IP"——开发者只需配置一个固定的代理入口地址，每次请求自动分配不同的出口 IP，无需手动维护 IP 池，极大简化了接入成本。

第 1 步：搭建项目骨架

一切从脚手架开始。Scrapy 的 CLI 工具可以一行命令生成规范的项目结构：

pip install scrapy pymongo
scrapy startproject enterprise_crawler
cd enterprise_crawler
scrapy genspider product_spider target-site.com

生成后的目录如下：

enterprise_crawler/
├── scrapy.cfg
└── enterprise_crawler/
    ├── settings.py          # 全局配置中枢
    ├── middlewares.py        # 下载中间件（代理、UA、重试）
    ├── pipelines.py          # 数据清洗与持久化
    ├── items.py              # 数据模型定义
    └── spiders/
        └── product_spider.py # 业务爬取逻辑

在动手写 Spider 之前，先在 items.py 中把数据结构定下来。清晰的 Item 定义是后续 Pipeline 做字段校验、去重和落库的基础：

import scrapy

class ProductItem(scrapy.Item):
    title      = scrapy.Field()
    price      = scrapy.Field()
    url        = scrapy.Field()
    crawled_at = scrapy.Field()

这一步看起来简单，却直接决定了整个项目的可维护性。企业级爬虫往往需要多人协作，统一的 Item 契约能避免下游数据消费者在"这个字段叫 name 还是 title"上反复扯皮。

第 2 步：接入隧道代理

隧道代理与传统代理池有本质区别：你不需要自己维护 IP 列表并做轮换调度，每次发出请求时，云端自动切换出口 IP，开发者只需一次性配置代理地址和密钥即可。

道代理支持两种验证方式：密钥验证（AuthKey + AuthPwd）和白名单验证（绑定服务器 IP 免密访问）。在 Scrapy 场景下，推荐使用密钥验证，灵活性更好。

登录控制台（qg.net），开通隧道代理后，你会拿到三个关键参数：代理地址（proxyAddr，形如 host:port）、密钥（AuthKey）和密码（AuthPwd）。

在 Scrapy 中，代理的注入点是 Downloader Middleware。我们在 middlewares.py 中创建一个专用的 QgTunnelProxyMiddleware：

class QgTunnelProxyMiddleware:
    """
    青果网络隧道代理中间件。
    使用密钥验证方式（AuthKey + AuthPwd），
    将代理认证信息编入代理 URL，Scrapy 自动处理转发。
    Spider 本身无需关心代理细节。
    """

    def __init__(self, proxy_addr, auth_key, auth_pwd):
        self.proxy_addr = proxy_addr
        self.auth_key   = auth_key
        self.auth_pwd   = auth_pwd
        # 青果隧道代理 URL 格式：http://AuthKey:AuthPwd@代理地址
        self.proxy_url  = "http://%(user)s:%(password)s@%(server)s" % {
            "user":     auth_key,
            "password": auth_pwd,
            "server":   proxy_addr,
        }

    @classmethod
    def from_crawler(cls, crawler):
        return cls(
            proxy_addr = crawler.settings.get("QG_PROXY_ADDR"),
            auth_key   = crawler.settings.get("QG_AUTH_KEY"),
            auth_pwd   = crawler.settings.get("QG_AUTH_PWD"),
        )

    def process_request(self, request, spider):
        request.meta["proxy"] = self.proxy_url
        request.meta["download_timeout"] = 20

接下来在 settings.py 中注册中间件，并填入连接信息：

import os

# ---- 青果隧道代理配置 ----
# 以下三个值从青果网络控制台获取，务必通过环境变量注入，不要硬编码
QG_PROXY_ADDR = os.environ.get("QG_PROXY_ADDR", "代理地址:端口号")
QG_AUTH_KEY   = os.environ.get("QG_AUTH_KEY",   "你的AuthKey")
QG_AUTH_PWD   = os.environ.get("QG_AUTH_PWD",   "你的AuthPwd")

DOWNLOADER_MIDDLEWARES = {
    # 关闭 Scrapy 内置的代理中间件，使用青果专用实现
    "scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware": None,
    "enterprise_crawler.middlewares.QgTunnelProxyMiddleware": 543,
}

这里有一个容易忽略的细节：密钥一定不要硬编码在代码里。通过 os.environ.get() 从环境变量读取，或者使用 .env 文件配合 python-dotenv，是生产环境的基本操作。特别是当代码托管在 Git 上时，一次不小心的 commit 就可能导致代理账号泄露，进而产生高额费用。

快速验证代理是否生效： 在 Spider 的 start_urls 中加入 https://api.ipify.org 或 https://test.ipw.cn，这些站点会返回请求的出口 IP。如果每次返回的 IP 不同，说明隧道代理已经正常工作。

第 3 步：反检测策略

代理解决了 IP 层面的问题，但现代反爬系统的检测维度远不止 IP。User-Agent 指纹、请求频率模式、Cookie 关联……任何一个维度的异常都可能触发风控。我们需要在中间件层再加两道防线。

第一道：User-Agent 随机轮换。 固定的 UA 字符串是最明显的机器特征，每个请求随机切换可以有效降低指纹一致性：

import random

class RandomUserAgentMiddleware:

    USER_AGENTS = [
        # Chrome on Windows
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 Chrome/126.0.0.0 Safari/537.36",
        # Safari on macOS
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5) "
        "AppleWebKit/605.1.15 Safari/605.1.15",
        # Firefox on Linux
        "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) "
        "Gecko/20100101 Firefox/128.0",
        # Edge on Windows
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 Edg/126.0.0.0",
    ]

    def process_request(self, request, spider):
        request.headers["User-Agent"] = random.choice(self.USER_AGENTS)

第二道：反爬状态码自动重试。 当目标站返回 403、429 或 503 时，通常意味着当前请求被拦截，但隧道代理会在下一次请求时自动切换 IP，重试一次往往就能通过：

class RetryOnBanMiddleware:

    BAN_CODES = {403, 429, 503}

    def process_response(self, request, response, spider):
        if response.status in self.BAN_CODES:
            spider.logger.warning(
                f"反爬拦截 [{response.status}] → 重新入队: {request.url}"
            )
            return request.replace(dont_filter=True)
        return response

第三道：请求节奏控制。 这一道不是中间件，而是在 settings.py 中通过参数调优来实现：

DOWNLOADER_MIDDLEWARES = {
    "scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware": None,
    "enterprise_crawler.middlewares.QgTunnelProxyMiddleware": 543,
    "enterprise_crawler.middlewares.RandomUserAgentMiddleware": 544,
    "enterprise_crawler.middlewares.RetryOnBanMiddleware": 545,
}

# ---- 请求节奏 ----
CONCURRENT_REQUESTS     = 5       # 青果隧道默认每秒 5 并发起，按套餐调整
DOWNLOAD_DELAY          = 1.5     # 基础请求间隔（秒）
RANDOMIZE_DOWNLOAD_DELAY = True   # 在 0.5×~1.5× 范围内随机抖动
COOKIES_ENABLED         = False   # 关闭 Cookie 减少会话关联
RETRY_TIMES             = 3       # 最大重试次数

RANDOMIZE_DOWNLOAD_DELAY 这个参数非常值得注意。人类浏览网页的时间间隔天然带有随机性，而程序的固定间隔恰恰是最大的"机器特征"。开启随机抖动后，Scrapy 会在 0.5 × DOWNLOAD_DELAY 到 1.5 × DOWNLOAD_DELAY 之间随机取值，模拟更自然的访问模式。

第 4 步：数据管道与持久化

爬下来的数据如果不做清洗和入库，就只是一堆散落的字典。Scrapy 的 Item Pipeline 机制允许你将数据处理逻辑串成链式流水线——清洗、去重、入库，每个环节各司其职。

以下是一个 MongoDB Pipeline 的完整实现。选择 MongoDB 是因为它的 schema-free 特性非常适合爬虫场景——不同站点的数据结构可能差异很大，不用预先建表：

from datetime import datetime, timezone
import pymongo

class MongoPipeline:

    def __init__(self, mongo_uri, mongo_db):
        self.mongo_uri = mongo_uri
        self.mongo_db  = mongo_db

    @classmethod
    def from_crawler(cls, crawler):
        return cls(
            mongo_uri = crawler.settings.get("MONGO_URI", "mongodb://localhost:27017"),
            mongo_db  = crawler.settings.get("MONGO_DATABASE", "crawler_db"),
        )

    def open_spider(self, spider):
        self.client = pymongo.MongoClient(self.mongo_uri)
        self.db = self.client[self.mongo_db]

    def close_spider(self, spider):
        self.client.close()

    def process_item(self, item, spider):
        item["crawled_at"] = datetime.now(timezone.utc).isoformat()
        self.db[spider.name].update_one(
            {"url": item["url"]},       # 以 URL 做唯一键去重
            {"$set": dict(item)},
            upsert=True,                # 存在则更新，不存在则插入
        )
        return item

在 settings.py 中激活这条管道：

ITEM_PIPELINES = {
    "enterprise_crawler.pipelines.MongoPipeline": 300,
}
MONGO_URI      = "mongodb://localhost:27017"
MONGO_DATABASE = "crawler_db"

如果你的技术栈更偏向关系型数据库，把 MongoDB 换成 MySQL 或 PostgreSQL 也是同样的模式——只需替换 process_item 中的存储逻辑即可，Pipeline 的接口契约不变。

第 5 步：编写 Spider 与生产部署

前 4 步搭好了整个基础设施——代理接入、反检测、数据落地——Spider 本身只需要专注业务逻辑：解析页面、提取数据、处理翻页。

import scrapy
from enterprise_crawler.items import ProductItem

class ProductSpider(scrapy.Spider):
    name = "product_spider"
    start_urls = ["https://target-site.com/products?page=1"]

    def parse(self, response):
        for card in response.css("div.product-card"):
            item = ProductItem()
            item["title"] = card.css("h2::text").get("").strip()
            item["price"] = card.css("span.price::text").get("").strip()
            item["url"]   = response.urljoin(card.css("a::attr(href)").get())
            yield item

        # 自动跟踪下一页
        next_page = response.css("a.next-page::attr(href)").get()
        if next_page:
            yield response.follow(next_page, callback=self.parse)

注意 Spider 中没有出现任何关于代理或 UA 的代码。这正是中间件架构的价值——关注点分离做到位之后，业务开发者完全不需要操心底层的反爬对抗。

容器化部署

生产环境推荐用 Docker 封装，配合调度系统实现定时任务：

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["scrapy", "crawl", "product_spider", "-L", "INFO"]

部署方式可以按团队的基础设施选择。如果已经有 Kubernetes 集群，用 CronJob 是最自然的选择。如果是单机环境，crontab 加 Docker 就足够了：

# 每天凌晨 2 点执行一次（.env 中包含 QG_PROXY_ADDR、QG_AUTH_KEY、QG_AUTH_PWD）
0 2 * * * docker run --rm --env-file /etc/crawler/.env enterprise_crawler

监控与告警

Scrapy 内置了 Stats Collector，每次爬取结束会输出一份统计报告，包括请求总数、成功率、重试次数、Item 产出量等关键指标。在此基础上，可以接入 Prometheus + Grafana 做可视化监控，或者简单地解析日志中的统计信息推送到钉钉/飞书告警。

架构全景

回头看一眼整个系统的数据流：

Spider（解析 + 翻页）
  ↓ yield Request
Downloader Middlewares
  ├── QgTunnelProxyMiddleware    → 挂载青果隧道代理地址和密钥认证
  ├── RandomUserAgentMiddleware  → 随机 UA
  └── RetryOnBanMiddleware      → 反爬状态码重试
  ↓ 经青果隧道代理云端自动换 IP 后发往目标站
目标站点响应
  ↓ yield Item
Item Pipeline
  └── MongoPipeline             → 清洗、去重、入库

每一层只做一件事，彼此通过 Scrapy 的钩子机制解耦。当你需要切换代理供应商时，只改 QgTunnelProxyMiddleware；需要换存储引擎时，只改 Pipeline；需要加指纹伪装时，加一个新的 Middleware 即可。这种插件式的架构才是 Scrapy 在企业级场景中最大的竞争力。

常见踩坑备忘

在实际落地过程中，有几个问题值得提前注意。

DOWNLOAD_DELAY 不要设得太低。如果请求频率过高，目标站可能会对整个代理出口网段进行封禁，连累其他用户。1 到 3 秒的间隔对大多数站点来说是比较安全的。

如果目标站点使用了前端 JavaScript 渲染，Scrapy 默认拿到的是未渲染的 HTML。这时需要引入 Splash、Playwright 或 Selenium 中间件来获取渲染后的页面内容。可以通过在 parse 方法中检查关键元素是否存在来快速判断是否需要 JS 渲染。

最后也是最重要的一点：务必遵守目标站点的 robots.txt 协议和当地法律法规。技术能力不是突破法律边界的理由，企业级爬虫尤其需要在合规性上做到位。

青果网络代理IP - CTA Banner

企业级代理IP服务商

10年专注网络服务
千万级纯净 IP 池，覆盖全国390+城市
累计服务客户超8.5万

立即免费试用

// 青果网络企业级API示例
const config = {
  auth: "QGE_Enterprise_Key",
  region: "CN_ALL"
};

async function getProxy() {
  const res = await qgClient.fetch(config);
  console.log("Stable Connection.");
  return res.ip;
}