不知道大家在日常开发中，有没有遇到过这种极其抓狂的场景：写了个 Scrapy 爬虫，跑十万级规模的项目稳如老狗，一旦把目标定到百万级页面，系统就开始疯狂“作妖”了。
跑着跑着突然报
MemoryError
，直接被系统的 OOM Killer 无情干掉；或者爬虫每隔几小时就自己停顿，看日志发现是引擎又在重新初始化了；好不容易挂上了代理，结果并发一上来，满屏的
407 Proxy Authentication Required
错误，成功率直线下滑。
今天，我们就从底层根因剖析，结合生产环境的最佳实践，特别是配合
爬虫代理
，给大家分享一套能让 Scrapy 稳定流转百万级页面的架构调优方案。
为什么你的 Scrapy 会在百万级页面“翻车”？
Scrapy 是一个极其优秀的框架，但它的默认参数和机制其实是针对中等规模任务设计的。在大规模长跑任务中，以下几个瓶颈会被无限放大：- 引擎频繁初始化带来极高损耗：如果爬虫因为封禁或内存问题需要频繁重启，Scrapy 每次执行都会完整重建 Scheduler、Downloader、Spider 等整套组件。如果你每 50 万页面重启一次，初始化时间叠加起来可能吃掉总运行时间的 10%~15%。
- 隐蔽的内存泄漏：当 Pipeline 处理（比如写数据库）的速度跟不上爬取速度时，Scrapy 引擎的 Slot 队列会大量堆积未释放的 Request/Response 对象。此外，如果你习惯在 Spider 的 parse() 方法里往 self.data 堆积数据却不清理，内存就会一直暴涨直到 OOM。
- 代理IP管理与 407 错误：Scrapy 默认不会重试 407 状态码。如果代理认证失败或 IP 被封返回了 407，这个请求就直接报废了，导致严重的数据漏爬。
核心优化方案与代码实战
为了解决上述问题，我们需要从引擎生命周期、内存控制以及代理调度三个维度进行大改。1. 开启 JOBDIR 断点续爬与内存清理
首先，百万级爬虫绝对不能每次崩溃都从头再来。我们需要开启 JOBDIR 持久化调度器队列。 其次，Pipeline 必须要改为批量异步写入，防止 IO 阻塞拖垮整个引擎。# settings.py
SCHEDULER = "scrapy.core.scheduler.Scheduler"
JOBDIR = "job_data/" # 开启调度器持久化，中断后重启可无缝恢复进度
REQUESTS_DEPTH_LIMIT = 50000 # 限制请求排队缓冲区大小
# 内存保护机制，达到物理内存预警值后自动暂停而非 OOM
MEMUSAGE_ENABLED = True
MEMUSAGE_LIMIT = 4096 # MB
2. 生产级代理集成：智能 IP 管理
大规模爬取离不开优质的动态代理。这里我们以爬虫代理为例。爬虫代理的核心特点是使用 Proxy-Authorization 头进行基础认证，并且支持通过 Proxy-Tunnel 头部的随机数来实现精准的 IP 切换与复用。 我们需要手写一个强壮的中间件，处理认证、强制切 IP 以及 407 错误的捕获重试。代码示例：智能代理中间件
# middlewares.py
import base64
import random
class YiniuProxyMiddleware:
# 16YUN代理配置
PROXY_HOST = "t.16yun.cn"
PROXY_PORT = "31111"
PROXY_USER = "your_username" # 替换为实际用户名
PROXY_PASS = "your_password" # 替换为实际密码
failure_count = {
}
def process_request(self, request, spider):
# 1. 构建基础认证头 Base64编码
auth = base64.urlsafe_b64encode(f"{self.PROXY_USER}:{self.PROXY_PASS}".encode('utf8')).decode('ascii')
request.meta['proxy'] = f"http://{self.PROXY_HOST}:{self.PROXY_PORT}"
request.headers['Proxy-Authorization'] = f'Basic {auth}'
# 2. 每次请求生成不同的 tunnel 随机数，强制切换 IP
tunnel = random.randint(1, 10000)
request.headers['Proxy-Tunnel'] = str(tunnel)
# 3. 建议访问 HTTPS 目标时使用 Keep-Alive
request.headers['Connection'] = 'Keep-Alive'
def process_response(self, request, response, spider):
# 拦截 407 错误 (代理认证失败或 IP 被封禁)
if response.status == 407:
return self.handle_407(request, spider)
# 拦截常见限制状态码，标记代理异常
if response.status in [403, 429]:
self.mark_failed(request)
return response
def handle_407(self, request, spider):
self.mark_failed(request)
# 清除旧的认证信息，重新生成 Tunnel，强制换新 IP 重试
if 'Proxy-Authorization' in request.headers:
del request.headers['Proxy-Authorization']
request.headers['Proxy-Tunnel'] = str(random.randint(1, 10000))
# 重新放回调度器
return request.copy()
def mark_failed(self, request):
proxy = request.meta.get('proxy')
if proxy:
# 记录失败次数，可在此处扩展踢掉连续失败代理的逻辑
self.failure_count[proxy] = self.failure_count.get(proxy, 0) + 1
3. 配置 407 重试与并发压测
中间件写好了，千万别忘了在 settings.py 中把 407 加入重试列表，否则 Scrapy 依然会直接丢弃这些请求：# settings.py
RETRY_ENABLED = True
RETRY_TIMES = 3
# 必须显式加入 407 错误，防止代理切换失败导致漏爬
RETRY_HTTP_CODES = [500, 502, 503, 504, 407, 408, 429, 403]
# 启用我们的自定义中间件，优先级需合理设置
DOWNLOADER_MIDDLEWARES = {
'myproject.middlewares.YiniuProxyMiddleware': 100,
'scrapy.downloadermiddlewares.retry.RetryMiddleware': 90,
}
# 并发数：百兆带宽下可设到 64~128
CONCURRENT_REQUESTS = 64
# 针对使用了代理的场景，每个 IP 视为一个独立域名，放开并发限制
CONCURRENT_REQUESTS_PER_IP = 16
优化效果总结
经过上面这套组合拳的改造，百万级页面的爬取任务将发生质的飞跃。根据实测数据对比：- 总耗时：从原先频繁重启导致的 ~120 小时，大幅缩减至 ~35 小时。
- 内存表现：告别持续上升到 OOM 的噩梦，内存峰值稳定在 3.5GB 左右。
- 请求成功率：得益于正确的 407 错误处理和爬虫代理的高效调度，成功率从 ~60% 飙升至 ~94%。
- 容灾能力：意外中断后能够达到秒级恢复进度，不再需要从头再来。
