چطور در سال 2026 Cloudflare را دور بزنیم (بدون سوزاندن IP دیتاسنتر)

اکثر آموزش‌های «چطور Cloudflare را دور بزنیم» که در اینترنت پیدا می‌کنید، از اواخر سال 2024 دیگر کار نمی‌کنند. دلیلش این نیست که Cloudflare دفاع‌های تازه‌ای اضافه کرده، بلکه این است که دفاع‌های قدیمی، یعنی فینگرپرینت JA3 و بررسی‌های ساده‌ی هدر، جای خود را به نسل جدیدی داده‌اند که هر میان‌بُری را از کار می‌اندازد. این راهنما توضیح می‌دهد که Cloudflare در سال 2026 واقعاً چه چیزهایی را بررسی می‌کند، چرا cloudscraper و undetected-chromedriver و اکثر افزونه‌های «stealth» شکست می‌خورند، و آن دستورالعمل چهارلایه‌ای که هنوز در محیط واقعی جواب می‌دهد چیست.

خلاصه‌ی صادقانه همان ابتدا: هیچ ترفند واحدی وجود ندارد. دور زدن قابل‌اتکای Cloudflare به IP درست، فینگرپرینت TLS درست، ترتیب درست فریم‌های HTTP/2 و (برای سطح Bot Management) یک مرورگر واقعی نیاز دارد. اگر فقط یکی از این‌ها را اشتباه انجام دهید، پیش از آنکه درخواست شما حتی به سرور مبدأ برسد، در فیلتر لبه (edge) رد می‌شوید.

Cloudflare در سال 2026 واقعاً چه چیزهایی را بررسی می‌کند

سیستم تشخیص بات Cloudflare به‌صورت یک خط لوله (pipeline) از فیلترها در لبه‌ی شبکه اجرا می‌شود. هر درخواست به‌ترتیب از این فیلترها عبور می‌کند. اولین فیلتری که آن را رد کند برنده است؛ یعنی یک درخواست ممکن است صرفاً به‌خاطر اعتبار IP رد شود، پیش از آنکه هیچ فینگرپرینت یا هدری بررسی شده باشد.

1. اعتبار IP (ASN + سابقه‌ی سوءاستفاده)

این اولین و ارزان‌ترین بررسی است. Cloudflare یک پایگاه‌داده بر اساس ASN (شماره‌ی سیستم خودگردان) نگه می‌دارد. ASNهای متعلق به ارائه‌دهندگان ابری معروف (AWS AS16509، GCP AS15169، Azure AS8075، OVH AS16276، DigitalOcean AS14061، Hetzner AS24940، Vultr AS20473) بیشترین موشکافی را می‌بینند. حتی با یک فینگرپرینت در سطح مرورگر واقعی، درخواستی که از این ASNها سرچشمه بگیرد، تا زمانی که بی‌گناهی‌اش ثابت نشود، گناهکار فرض می‌شود.

ASNهای مسکونی (Comcast AS7922، Verizon AS701، China Telecom AS4134، BT AS2856) قانونی فرض می‌شوند. درخواستی از یک IP مسکونی با فینگرپرینت ناشیانه‌ی پایتون هنوز می‌تواند رد شود (عبور کند)، در حالی که درخواستی از یک IP دیتاسنتر با فینگرپرینت بی‌نقص Chrome به چالش کشیده یا مسدود می‌شود.

2. فینگرپرینت JA4 TLS

JA4 جانشین سال 2023 برای JA3 است که توسط FoxIO منتشر شد. این روش فیلدهای مشخصی از TLS ClientHello را هَش می‌کند: نسخه‌ی TLS، مجموعه‌ی رمزها (به‌ترتیب)، افزونه‌ها (به‌ترتیب)، پروتکل‌های ALPN، الگوریتم‌های امضا و گروه‌های پشتیبانی‌شده. خروجی یک فینگرپرینت قطعی مانند t13d1516h2_8daaf6152771_b1ff8ab2d16f است.

Chrome 124 واقعی یک JA4 مشخص تولید می‌کند. Firefox 124 واقعی یک JA4 متفاوت. کتابخانه‌ی requests پایتون (که از urllib3 و OpenSSL استفاده می‌کند) یک JA4 تولید می‌کند که هیچ مرورگر واقعی‌ای هرگز آن را منتشر نمی‌کند، چون ترتیب رمزها و فهرست افزونه‌ها نه با Chrome می‌خواند و نه با Firefox. Cloudflare این الگو را پیش از تجزیه‌ی هر هدر HTTP علامت‌گذاری می‌کند.

نتیجه: هر کتابخانه‌ای که از OpenSSL سیستم یا TLS پیش‌فرض پایتون استفاده کند قابل‌تشخیص است. این شامل requests، aiohttp، httpx (پیکربندی پیش‌فرض) و هر wrapper «دور زدن» که روی آن‌ها ساخته شده باشد می‌شود.

3. ترتیب فریم‌های HTTP/2 و توالی شبه‌هدرها

اتصالات HTTP/2 شامل فریم‌های settings، window update، priority و headers هستند. مرورگرها این‌ها را با ترتیب مشخص و مقادیر مشخص ارسال می‌کنند. Chrome 124 یک فریم SETTINGS اولیه با این مقادیر دقیق می‌فرستد، سپس یک WINDOW_UPDATE، و بعد HEADERS. کتابخانه‌ی httpx پایتون با HTTP/2 فعال، یک payload متفاوت برای settings می‌فرستد و فریم‌های priority را که Chrome شامل می‌کند، رد می‌کند.

ترتیب شبه‌هدرهای HTTP/2 هم هویت را لو می‌دهد. Chrome به این ترتیب :method، :authority، :scheme، :path را می‌فرستد. Firefox به ترتیب :method، :path، :authority، :scheme. اکثر کتابخانه‌های پایتون و Go آن‌ها را به‌صورت الفبایی مرتب می‌کنند. Cloudflare این ترتیب را با الگوی موردانتظار برای User-Agent اعلام‌شده تطبیق می‌دهد و ناهماهنگی‌ها را علامت‌گذاری می‌کند.

4. ترتیب و حروف‌نویسی هدرها

هدرهای HTTP/1.1 ترتیب درج را حفظ می‌کنند. Chrome واقعی هدرها را با ترتیب ثابتی می‌فرستد: Host، Connection، Cache-Control، sec-ch-ua، sec-ch-ua-mobile، sec-ch-ua-platform، Upgrade-Insecure-Requests، User-Agent، Accept، Sec-Fetch-Site، Sec-Fetch-Mode، Sec-Fetch-User، Sec-Fetch-Dest، Accept-Encoding، Accept-Language. کتابخانه‌ی requests پایتون آن‌ها را دوباره مرتب می‌کند و گاهی حروف بزرگ متفاوتی به‌کار می‌برد. حتی تنظیم دستی هدرها به ترتیب درست هم کمکی نمی‌کند، چون کتابخانه‌ی زیرین دوباره آن‌ها را مرتب می‌کند.

5. چالش جاوااسکریپت (Managed Challenge)

اگر فیلترهای قبلی عبور کنند ولی امتیاز همچنان مشکوک باشد، Cloudflare یک چالش جاوااسکریپت ارائه می‌کند. این اسکریپت یک توکن را از مقادیر محیط مرورگر محاسبه می‌کند (هَش canvas، رندرکننده‌ی WebGL، audio context، ویژگی‌های navigator، اندازه‌گیری‌های زمان‌بندی) و آن را از طریق XHR ارسال می‌کند. هیچ کلاینت HTTP‌ای نمی‌تواند این را حل کند. شما به یک مرورگر واقعی نیاز دارید، و آن مرورگر باید واقعی به‌نظر برسد (بدون navigator.webdriver = true، بدون ویژگی‌های جاافتاده).

6. سیگنال‌های رفتاری (فقط Bot Management Enterprise)

در سطح Bot Management، Cloudflare حرکت ماوس، سرعت اسکرول، زمان‌بندی کلیک و دینامیک ضربه‌زدن به کلیدها را از طریق یک اسکریپت همیشه‌در‌حال‌اجرا جمع می‌کند. یک مرورگر headless که صفحه را بارگذاری می‌کند و بلافاصله بدون هیچ حرکت ماوسی اسکرپ می‌کند، ظرف چند ثانیه شناسایی می‌شود. کاربران واقعی نامنظم حرکت می‌کنند، مکث می‌کنند و دوباره می‌خوانند. بات‌ها خطی اسکرول می‌کنند و دقیقاً پیکسل‌به‌پیکسل کلیک می‌کنند.

چرا اکثر ابزارهای دور زدن دوره‌ی 2024 مرده‌اند

ابزارهای میان‌بُری که اسکرپینگ سال‌های 2021 تا 2024 را پیش می‌بردند، همگی یک نقطه‌ضعف مشترک دارند: سطح قابل‌مشاهده را وصله می‌کنند ولی پشته‌ی TLS زیرین را نه.

الگو روشن است: ابزارهایی که یک مرورگر واقعی را می‌پوشانند و لو‌رفتن‌های شناخته‌شده را وصله می‌کنند، ظرف چند ماه مسابقه‌ی تسلیحاتی را می‌بازند. ابزارهایی که پشته‌ی TLS مرورگر را شبیه‌سازی می‌کنند (curl_cffi، tls-client) زنده مانده‌اند چون به سیم (wire) نزدیک‌ترند.

دستورالعمل چهارلایه‌ای که هنوز جواب می‌دهد

یک دور زدن که در 2026 کار کند به هر چهار لایه نیاز دارد. حذف هر کدام نرخ موفقیت را به یک رقم می‌رساند.

لایه 1: IP مسکونی یا موبایل

این برای هر سایتی که Cloudflare Pro یا بالاتر اجرا می‌کند غیرقابل‌مذاکره است. فیلتر اعتبار IP، ASNهای دیتاسنتر را پیش از کامل‌شدن دست‌دادن TLS رد می‌کند. از یک پروکسی مسکونی با sticky session برای حداقل 10 دقیقه استفاده کنید تا کوکی cf_clearance دوام بیاورد.

لایه 2: فینگرپرینت TLS مرورگر واقعی

از curl_cffi (پایتون) یا tls-client (Go/پایتون) استفاده کنید. هر دو به یک BoringSSL اصلاح‌شده لینک می‌شوند که با ترتیب دقیق رمزها، فهرست افزونه‌ها و مقادیر ALPN مربوط به Chrome عرضه می‌شود.

from curl_cffi import requests

response = requests.get(
    "https://target.com/api/products",
    impersonate="chrome124",
    proxies={"https": "http://user-session-abc123:[email protected]:10001"},
    timeout=30,
)
print(response.status_code, len(response.text))

پارامتر impersonate="chrome124" پشته‌ی TLS را عوض می‌کند تا ClientHello بایت‌به‌بایت با Chrome 124 بخواند. هَش JA4 با یک نصب واقعی Chrome 124 یکسان خواهد بود. آن را با یک پروکسی مسکونی جفت کنید و از دو فیلتر اول عبور می‌کنید.

لایه 3: تطبیق ترتیب هدرها با مرورگر جعل‌شده

وقتی از impersonate استفاده می‌کنید، curl_cffi به‌طور خودکار هدرها را به ترتیب Chrome تنظیم می‌کند. اگر هدر سفارشی اضافه می‌کنید، آن‌ها را به‌جای درج در میانه، در انتها بیفزایید. از تنظیم هدرهایی که Chrome واقعی نمی‌فرستد پرهیز کنید (مثلاً X-Requested-With روی یک ناوبری عادی).

برای Accept-Language، آن را با موقعیت جغرافیایی پروکسی تطبیق دهید. یک IP مسکونی آمریکایی که Accept-Language: zh-CN,zh;q=0.9 می‌فرستد، یک سیگنال کوچک ولی واقعی است. برای IPهای آمریکایی از en-US,en;q=0.9، برای IPهای آلمانی از de-DE,de;q=0.9 و به همین ترتیب استفاده کنید. این یکی از معدود سیگنال‌هایی است که می‌توانید رایگان درستش کنید.

لایه 4: مرورگر واقعی برای چالش‌های JS (در صورت نیاز)

اگر هدف یک Managed Challenge را فعال کند (یک صفحه‌ی چالش CF در بدنه‌ی پاسخ می‌بینید)، curl_cffi به‌تنهایی نمی‌تواند آن را حل کند. به Playwright با Chromium وصله‌شده سوئیچ کنید.

from playwright.sync_api import sync_playwright
from rebrowser_playwright.sync_api import sync_playwright as rebrowser_sync

with rebrowser_sync() as p:
    browser = p.chromium.launch(
        headless=True,
        proxy={
            "server": "http://gate.jibaoproxy.com:10001",
            "username": "user-session-abc123",
            "password": "pass",
        },
    )
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York",
    )
    page = context.new_page()
    page.goto("https://target.com/", wait_until="networkidle")
    # حالا cf_clearance در context.cookies() قرار دارد
    cookies = context.cookies()
    cf_clearance = next((c for c in cookies if c["name"] == "cf_clearance"), None)
    browser.close()

به‌جای playwright استاندارد از rebrowser-playwright استفاده کنید. این ابزار لو‌رفتن‌های زمان اجرای CDP (Runtime.enable، آشکارشدن دستورهای CDP به صفحه) را که Cloudflare برای تشخیص اتوماسیون headless می‌خواند، وصله می‌کند. پس از عبور از چالش، cf_clearance را از کوکی‌ها استخراج کنید و آن را به curl_cffi برای حلقه‌ی اصلی اسکرپینگ بازگردانید. مرورگر یک‌بار به‌ازای هر session لازم است، نه به‌ازای هر درخواست.

ریاضیات هزینه: چرا مسکونی روی اهداف محافظت‌شده برنده است

غریزه‌ی استفاده از ارزان‌ترین پروکسی، روی سایت‌های محافظت‌شده با Cloudflare تقریباً همیشه اشتباه است. با اعداد واقعی این ریاضیات را مرور کنیم.

فرض‌ها: میانگین صفحه‌ی HTML برابر 500KB، اسکرپ مجموعاً 100,000 صفحه، هدف از Cloudflare Pro با Bot Fight Mode فعال استفاده می‌کند.

دو یافته‌ی قابل‌توجه:

1. ترکیب مسکونی + curl_cffi با ضریب 3 تا 18 برابر نسبت به هر ترکیب دیگری، برنده‌ی هزینه‌به‌ازای‌موفقیت است. این تصور که مسکونی «گران» است در $/گیگابایت درست ولی در $/صفحه‌ی‌موفق غلط است.
2. Playwright به‌ازای هر درخواست گران‌تر است چون بسته‌ی کامل دارایی‌ها (CSS، JS، تصاویر) را دانلود می‌کند. آن را فقط برای همان یک درخواستی که چالش را حل می‌کند به‌کار ببرید، سپس cf_clearance را به curl_cffi بسپارید.

دستورالعمل عملی: یک اسکرپر در سطح محصول

این الگویی است که به مشتریانی که اهداف محافظت‌شده با Cloudflare را در مقیاس بزرگ اسکرپ می‌کنند توصیه می‌کنیم. این الگو استفاده از Playwright (که کند و گران است) را به حداقل و استفاده از curl_cffi (که سریع و ارزان است) را به حداکثر می‌رساند.

from curl_cffi import requests as cf_requests
from rebrowser_playwright.sync_api import sync_playwright

PROXY_USER_FMT = "user-session-{sid}"
PROXY_HOST = "http://gate.jibaoproxy.com:10001"
PROXY_PASS = "your_password"

def get_cf_clearance(target_url, session_id):
    """فراخوانی یک‌باره‌ی Playwright برای حل چالش و استخراج cf_clearance."""
    with sync_playwright() as p:
        browser = p.chromium.launch(
            headless=True,
            proxy={"server": PROXY_HOST,
                   "username": PROXY_USER_FMT.format(sid=session_id),
                   "password": PROXY_PASS},
        )
        ctx = browser.new_context(user_agent="Mozilla/5.0 ... Chrome/124.0.0.0 Safari/537.36")
        page = ctx.new_page()
        page.goto(target_url, wait_until="networkidle", timeout=45000)
        cookies = ctx.cookies()
        browser.close()
    return {c["name"]: c["value"] for c in cookies}

def scrape_with_clearance(urls, session_id, cookies):
    """همان session_id (IP چسبنده) را برای تمام درخواست‌ها دوباره استفاده کن."""
    proxy = f"http://{PROXY_USER_FMT.format(sid=session_id)}:{PROXY_PASS}@gate.jibaoproxy.com:10001"
    out = []
    for url in urls:
        r = cf_requests.get(
            url,
            impersonate="chrome124",
            proxies={"https": proxy},
            cookies=cookies,
            timeout=30,
        )
        if r.status_code == 200:
            out.append((url, r.text))
        elif r.status_code in (403, 503) and "challenge" in r.text.lower():
            # cf_clearance منقضی شد؛ دوباره حل کن
            cookies = get_cf_clearance(url, session_id)
            r = cf_requests.get(url, impersonate="chrome124",
                                proxies={"https": proxy}, cookies=cookies)
            out.append((url, r.text))
    return out, cookies

# نحوه‌ی استفاده
session_id = "scrape-job-2026-05-27"
cookies = get_cf_clearance("https://target.com/", session_id)
results, cookies = scrape_with_clearance(target_urls, session_id, cookies)

نکات کلیدی این دستورالعمل:

• یک فراخوانی Playwright به‌ازای هر session. مرورگر چالش را حل می‌کند، کوکی cf_clearance را به curl_cffi می‌سپارد، سپس بسته می‌شود. تمام درخواست‌های بعدی با سرعت کامل از طریق curl_cffi انجام می‌شوند.
• شناسه‌ی sticky session گره‌خورده به وظیفه‌ی اسکرپینگ. همان IP برای کل طول عمر cf_clearance (معمولاً 30 دقیقه). استفاده‌ی مجدد از کوکی روی یک IP متفاوت آن را باطل می‌کند.
• چالش‌گیری مجدد خودکار. وقتی cf_clearance منقضی می‌شود، پاسخ شامل یک صفحه‌ی چالش CF است. آن را بگیرید و با Playwright دوباره حل کنید، سپس ادامه دهید.
• impersonate="chrome124" باید با رشته‌ی User-Agent که در Playwright تنظیم می‌کنید بخواند. عدم‌تطابق UA + JA4 خودش یک سیگنال تشخیص است.

چه زمانی باید کوتاه آمد

برخی استقرارهای Cloudflare را نمی‌توان با هیچ هزینه‌ی معقولی دور زد. اگر این سیگنال‌ها را دیدید، به‌جای سوزاندن بودجه روی دور زدنی که هرگز پایدار نمی‌شود، استراتژی را عوض کنید (از یک API استفاده کنید، با صاحب سایت همکاری کنید، یا داده را بخرید).

• Cloudflare Bot Management Enterprise + Turnstile + ردیابی رفتار. بانک‌ها، پردازشگرهای پرداخت، سایت‌های فروش بلیت (Ticketmaster) و برخی پلتفرم‌های شرط‌بندی ورزشی. نرخ موفقیت حتی با مسکونی + rebrowser بی‌نقص زیر 5 درصد است. هزینه‌ی هر درخواست موفق به 1 دلار نزدیک می‌شود.
• قوانین WAF سفارشی لایه‌بندی‌شده روی CF. برخی سایت‌ها محدودیت نرخ به‌ازای هر IP مسکونی اضافه می‌کنند که پس از 3 تا 5 درخواست فعال می‌شود. هیچ پروکسی‌ای نمی‌تواند از محدودیت نرخی که در منطق برنامه تعبیه شده بهبود یابد.
• سایت‌هایی که به ورود + 2FA + گره‌خوردن به دستگاه نیاز دارند. Cloudflare تنها مانع نیست؛ حتی با یک cf_clearance معتبر، لایه‌ی برنامه یک دستگاه ثبت‌شده می‌خواهد.

مرجع سریع

JIBAO Proxy ارائه می‌دهد پروکسی مسکونی پویا با بیش از 90 میلیون IP در بیش از 240 کشور، sticky session تا 60 دقیقه و هدف‌گیری در سطح کشور با شروع از 6.8 دلار بر گیگابایت. برای IPهای موبایل، پروکسی موبایل پویا را ببینید. هر دو به‌صورت آماده با curl_cffi، tls-client، Playwright، Puppeteer، Selenium و هر کلاینت HTTP که از پروکسی HTTP/SOCKS5 پشتیبانی کند کار می‌کنند.

مطالعه‌ی مرتبط: Sticky در برابر Rotating در سشن‌های پروکسی پیکربندی سشن را به‌طور عمیق پوشش می‌دهد. پروکسی برای ایجنت‌های هوش مصنوعی کاربرد ایجنت AI را توضیح می‌دهد که همپوشانی زیادی با گردش‌کار دور زدن Cloudflare دارد.