رفع خطای 1015 Cloudflare در اسکریپینگ

مقدمه

خطای Cloudflare 1015 یکی از رایج‌ترین مانع‌ها در وب اسکریپینگ است: سرور یا CDN شما را به‌خاطر ارسال درخواست‌های زیاد در بازهٔ زمانی کوتاه محدود می‌کند. این مقاله به‌صورت عملی و فنی برای توسعه‌دهندگان پایتون (و کسانی که با ابزارهای سرور-جانبی کار می‌کنند) نوشته شده؛ پس از خواندن این مطلب شما می‌توانید علت خطا را تشخیص دهید، راه‌حل‌های سریع برای کاربران عادی اجرا کنید، و برای اسکریپرهای تولیدی استراتژی‌های مطمئن و مقیاس‌پذیر پیاده‌سازی کنید.

خطای 1015 Cloudflare چیست؟

این خطا نشان می‌دهد که تعداد درخواست‌های ارسال‌شده از یک منبع (معمولاً یک آدرس IP) از حد مجاز تنظیم‌شده توسط مالک سایت یا پیکربندی Cloudflare فراتر رفته است. هدف اصلی محدودسازی درخواست‌ها جلوگیری از سوءاستفاده (مثل brute-force یا DDoS) و حفظ عملکرد سرور است.

نکات فنی کلیدی:

• Cloudflare یا لایهٔ مورد استفاده، درخواست‌ها را بر اساس IP، مسیر، هدرها یا الگوهای رفتاری شمارش می‌کند.
• تعداد و بازهٔ زمانی قابل تنظیم است و ممکن است از چند ثانیه تا ساعت یا حتی ممنوعیت دائمی متغیر باشد.

مدت زمان بلاک و محدودیت‌ها

مدت بلاک به تنظیمات مالک سایت بستگی دارد و می‌تواند از چند ثانیه تا چند ساعت باشد. برخی سرویس‌ها (یا تنظیمات مدیریتی) ممکن است برای مکرر نقض‌کنندگان، بلاک طولانی‌تر یا دائمی در نظر بگیرند. همچنین APIهای عمومی در بعضی سرویس‌ها سقف‌های جهانی (مثلاً 1200 درخواست در 5 دقیقه) دارند که عبور از آن باعث مسدود شدن موقتی همهٔ فراخوانی‌ها می‌شود.

راه‌حل‌های سریع برای کاربران عادی

• صبر و تلاش مجدد: ساده‌ترین راه صبر کردن تا اتمام پنجرهٔ نرخ (cooldown) است.
• تعویض شبکه / تغییر IP: قطع و وصل مودم، استفاده از VPN یا تعویض شبکه ممکن است مشکل را برطرف کند.
• بررسی افزونه‌ها و بدافزارها: افزونه‌هایی که رفرش خودکار یا درخواست‌های پس‌زمینه می‌فرستند را غیرفعال کنید و دستگاه را برای بدافزار بررسی کنید.
• پاک‌سازی کش و کوکی: گاهی داده‌های خراب در مرورگر باعث رفتار غیرمعمول می‌شود.

راهکارهای عملی و فنی برای اسکریپرها

برای اسکریپینگ در مقیاس باید پیش از هر چیز مفهومی به نام «نرخ‌دهی مسئولانه» و طراحی برای تحمل خطا را بپذیرید. در ادامه راهکارهای کلیدی را با توضیحات و مثال می‌بینید.

مدیریت مسئولانهٔ درخواست‌ها (Responsible Request Management)

ایدهٔ کلی: تعداد و توزیع درخواست‌ها را طوری تنظیم کنید که شبیه رفتار یک کاربر واقعی به نظر برسد و از ایجاد بار ناگهانی روی سرور جلوگیری شود.

• از تاخیر تصادفی بین درخواست‌ها استفاده کنید (مثلاً backoff تصاعدی یا jitter) تا الگوی غیرطبیعی نسازد.
• از کش محلی یا سیستمی استفاده کنید تا پاسخ‌های تکراری را دوباره از شبکه فراخوانی نکنید.
• در صورت امکان درخواست‌ها را گروه‌بندی (batch) یا از APIهای رسمی سایت استفاده کنید.

چرخش پراکسی‌ها (Proxy Rotation)

ایده: به‌جای ارسال همهٔ درخواست‌ها از یک آدرس IP، ترافیک را بین مجموعه‌ای از پراکسی‌ها توزیع کنید تا هر IP مقدار کمی درخواست داشته باشد.

مثال پایتون ساده برای استفادهٔ چرخشی از پراکسی‌ها با requests:

import random
import requests
from time import sleep

proxies = [
    'http://10.10.1.10:3128',
    'http://10.10.1.11:3128',
    'http://10.10.1.12:3128',
]
user_agents = [
    'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
    'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)',
]

session = requests.Session()
for url in ['https://example.com/page1', 'https://example.com/page2']:
    proxy = {'http': random.choice(proxies), 'https': random.choice(proxies)}
    headers = {'User-Agent': random.choice(user_agents)}
    try:
        resp = session.get(url, proxies=proxy, headers=headers, timeout=10)
        print(resp.status_code)
    except requests.RequestException as e:
        print('error', e)
    sleep(random.uniform(1, 3))

شرح مختصر کد:

• ورودی‌ها: لیست proxies و URLهایی که می‌خواهید بخوانید.
• خروجی: پاسخ HTTP و وضعیت آن یا استثناء در صورت خطا.
• هر حلقه یک پراکسی و User-Agent تصادفی انتخاب می‌کند و با تاخیر تصادفی بعدی ادامه می‌دهد.

نکات: مدیریت خطا و retry با backoff، بررسی محتوا (برای تشخیص صفحهٔ Captcha یا صفحهٔ challenge) و حذف پراکسی‌های معیوب ضروری است.

پراکسی‌های پریمیوم و residential

پراکسی‌های رایگان اغلب در دیتاسنترها میزبانی می‌شوند و شناخته‌شدن و مسدود شدن آن‌ها سریع‌تر است. پراکسی‌های residential یا موبایل اعتبار آی‌پی بالاتری دارند اما هزینهٔ بیشتری دارند و معمولاً برحسب ترافیک یا حجم شارژ می‌شوند. در تصمیم‌گیری تعادلی بین هزینه و پایداری مورد انتظار را در نظر بگیرید.

چرخاندن هدرها و User-Agent

هدرها (مخصوصاً User-Agent) نقش مهمی در تشخیص هویت «بین یک مرورگر واقعی» و «یک ربات» دارند. داشتن مجموعه‌ای از User-Agentهای به‌روز و تطابق هدرهای دیگر (Accept, Accept-Language, Connection) مهم است.

import random

def make_headers():
    pool = [
        'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
        'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)',
        'Mozilla/5.0 (X11; Linux x86_64)',
    ]
    return {
        'User-Agent': random.choice(pool),
        'Accept-Language': 'en-US,en;q=0.9',
    }

شرح: تابع make_headers یک هدر تصادفی می‌سازد؛ حتماً ترکیب هدرها را با هم منطبق کنید تا تناقض در اطلاعات نداشته باشید (برای مثال یک UA که متعلق به موبایل است نباید هدرهای دسکتاپی بفرستد).

استفاده از Web Scraping APIs و پراکسی‌اجرانگِیتورها

راه‌حل‌های سرویس‌محور (APIهای اسکریپینگ یا پراکسی‌اجرانگیتورها) مزایایی مثل مدیریت اتوماتیک چرخش پراکسی، دورزدن چالش‌ها و مانیتورینگ خطا دارند و هزینهٔ مهندسی و نگهداری را کاهش می‌دهند. معایب: هزینهٔ ماهیانه و تکیه بر سرویس ثالث.

مثال اجرای یک فراخوان curl برای پراکسی‌اجرانگیتور:

curl -k 'https://proxy.example.com/v1/?api_key=YOUR_API_KEY&url=http://httpbin.org/anything&premium=true'

شرح: پارامترهای کلیدی شامل api_key (اعتبار شما)، url (هدف) و پرچم‌هایی مثل premium=true یا residential=true هستند. خروجی این درخواست محتوای صفحۀ هدف است که از طریق پراکسی سرویس عبور داده شده.

استراتژی‌های عبور از Cloudflare (گزینه‌ها و مقایسه)

لیستی از راه‌های مرسوم، با مزایا و معایب کوتاه:

• ارسال مستقیم به سرور origin: ممکن است کار کند اما نیازمند کشف IP origin و گاهی غیرقانونی یا مغایر با قوانین میزبان است.
• استفاده از نسخه کش‌شده (مثلاً Google Cache): ساده و سریع اما برای محتوای متغیر مناسب نیست.
• Cloudflare solvers (مثل FlareSolverr): راهکارهای آماده که چالش‌های JS را حل می‌کنند اما با هر آپدیت Cloudflare ممکن است کارایی‌شان کم شود.
• اسکریپ کردن با headless browsers تقویت‌شده: شبیه‌سازی مرورگر واقعی؛ قابل اعتماد ولی هزینهٔ منابع و پهنای باند بالاتر دارد.
• پراکسی‌های هوشمند با bypass داخلی: سرویس‌های تجاری که مکانیزم‌های اختصاصی برای عبور از Cloudflare دارند؛ هزینه‌بر اما پایدارتر.
• مهندسی معکوس و توسعهٔ bypass اختصاصی: پیچیده و زمان‌بر اما در مقیاس بزرگ می‌تواند مقرون‌به‌صرفه و بهینه باشد.

اسکریپ کردن با headless browsers تقویت‌شده

Headless browsers مثل Puppeteer، Playwright یا Selenium در حالت پیش‌فرض نشانه‌هایی (fingerprints) تولید می‌کنند که شناسایی آن‌ها را آسان می‌کند؛ از جمله مقدار navigator.webdriver. افزونه‌ها یا پکیج‌های stealth این نشت‌ها را می‌پوشانند، اما هزینهٔ منابع را افزایش می‌دهند.

// Puppeteer Extra + stealth (نمونهٔ جاوااسکریپت)
const puppeteer = require('puppeteer-extra')
const stealth = require('puppeteer-extra-plugin-stealth')
puppeteer.use(stealth())
;(async () => {
  const browser = await puppeteer.launch({ headless: 'new', args: ['--no-sandbox'] })
  const page = await browser.newPage()
  await page.goto('https://quotes.toscrape.com/')
  await page.screenshot({ path: 'screenshot.png' })
  console.log('Saved screenshot')
  await browser.close()
})()

شرح بخش‌ها (خط‌به‌خط یا بخش‌به‌بخش):

• require: وارد کردن بسته‌ها؛ پلِی‌سِسِتِهای stealth رفتار مرورگر را اصلاح می‌کنند.
• puppeteer.launch: مرورگر را اجرا می‌کند؛ گزینه headless را بسته به نیاز سازگار کنید.
• page.goto: ناوبری به URL هدف؛ در این مرحله ممکن است Cloudflare یک چالش اجرا کند.
• screenshot: نمونه‌ای از عمل موردنظر؛ در پروژه واقعی داده‌ها را با page.content() یا استخراج DOM می‌گیرید.

نکتهٔ مهم: ترکیب headless بر پایهٔ stealth با پراکسی residential قابل اطمینان‌ترین ترکیب در مقابل تشخیص است، اما هزینه‌ها و مصرف پهنای‌باند را به‌شدت افزایش می‌دهد.

پراکسی هوشمند با bypass داخلی

پراکسی‌های هوشمند که bypassهای اختصاصی برای Cloudflare نگهداری می‌کنند، معمولاً قابل‌اعتمادتر از راه‌حل‌های متن‌باز هستند زیرا به‌طور مستمر نگهداری و آپدیت می‌شوند. اما توجه کنید که تکیهٔ کامل به یک سرویس خارجی ریسک vendor-lock و هزینه بلندمدت را افزایش می‌دهد.

مسائل حقوقی، امنیتی و اخلاقی

• خواندن فایل robots.txt: همیشه ابتدا robots.txt را بررسی کنید تا بخش‌های ممنوعه را نشکنید.
• حفظ حریم خصوصی: داده‌های شخصی را بدون رضایت جمع‌آوری یا ذخیره نکنید.
• پایبندی به قوانین و ToS: بعضی سایت‌ها صراحتاً اسکریپینگ را منع کرده‌اند؛ نقض قوانین می‌تواند تبعات حقوقی داشته باشد.

جمع‌بندی و توصیه‌های عملی

خلاصهٔ نکات اجرایی:

• ابتدا با راهکارهای ساده (کاهش نرخ، تغییر IP، بررسی افزونه‌ها) مشکل را برطرف کنید.
• برای مقیاس‌پذیری از ترکیب چرخش پراکسی، چرخش هدرها، و مدیریت درخواست با backoff استفاده کنید.
• در صورت نیاز به عبور از چالش‌های پیچیده، از headless browsers تقویت‌شده یا سرویس‌های پراکسی هوشمند بهره ببرید؛ اما هزینه و ریسک‌های حقوقی را بسنجید.
• همیشه مسئولانه اسکریپ کنید: robots.txt، حریم خصوصی و بار سرور را رعایت کنید.

اگر می‌خواهید، می‌توانم مثال‌های عملی بیشتری به‌خصوص برای پایتون (با aiohttp برای همزمانی ایمن، یا پیاده‌سازی Retry/Backoff) آماده کنم تا یک pipeline کامل و مقاوم در برابر Cloudflare برایتان طرح بزنم.