الغوص العميق في Patchright: أتمتة Playwright غير قابلة للكشف مع بروكسيات سكنية

ما هو الغوص العميق في Patchright ولماذا يهمك كمهندس كشط وباحث أمني

إذا سبق لك أن شغّلت Playwright ضد صفحة محمية بـ Cloudflare Turnstile أو DataDome، فغالبًا رأيت تحديًا لا نهاية له أو خطأ 403 خلال أقل من 200ms. السبب نادرًا ما يكون السكربت نفسه — بل بصمة المتصفح التي تكشف أنك تتحكم فيه برمجيًا. هنا يأتي دور Patchright، وهو تفرّع (fork) من Playwright يصحّح إشارات الكشف الأكثر شيوعًا على مستوى البروتوكول والـ runtime. في هذا الغوص العميق في Patchright نشرح بالتفصيل التقني ما الذي يرقّعه، وما الذي لا يرقّعه، ولماذا تبقى سمعة IP هي الفيصل النهائي حتى بعد إغلاق كل تسريبات CDP.

الموضوع موجّه لباحثي أمن وباحثي كشط كبيرين يبنون أتمتة مشروعة على بيانات عامة أو في نطاق اختبار اختراق مصرّح به. لسنا هنا نتحدث عن تجاوز ضوابط الدخول أو انتحال الهوية — بل عن جعل أتمتة Chrome الحقيقية تبدو كـ Chrome حقيقي.

إشارات الكشف التي يستهدفها Patchright

أنظمة مكافحة البوتات الحديثة لا تعتمد على إشارة واحدة. تجمع نقاط بيانات من طبقة المتصفح وطبقة الشبكة وطبقة السلوك، ثم تُسجّلها في نموذج تصنيف. Patchright يهاجم الطبقة الأولى — بصمة المتصفح — بإغلاق أكثر القنوات تسريبًا للمعلومات:

1. navigator.webdriver

وفقًا لـ مواصفات W3C WebDriver، يجب أن يضع المتصفح navigator.webdriver = true عند التحكم به عبر بروتوكول آلي. Playwright الأصلي لا يخفي هذا. Patchright يعيد تعريف الخاصية لتعود false أو undefined، وهو ما يفعله Chrome الحقيقي في جلسة يدوية. هذا وحده لا يكفي، لكن غيابه يكفي لرفضك فورًا في بعض البوابات.

2. تسريبات CDP و Runtime.enable

عندما يبدأ Playwright جلسة، يستدعي Runtime.enable و Page.enable عبر بروتوكول Chrome DevTools (CDP). هذا يترك آثارًا يمكن للجافاسكربت من جهة الخادم رصدها: وجود window.cdc_adoQpoasnfa76pfcZLmcfl_Array أو دوال CDP مكشوفة، وكائن Runtime في حالة غير متوقعة. Patchright يرقّع هذه الاستدعاءات بحيث لا تظهر آثار CDP في النافذة العامة، ويمنع تسريب أسماء دوال التصحيح.

3. إشارات أعلام سطر الأوامر

Playwright يمرّر أعلامًا مثل --enable-automation و --remote-debugging-port افتراضيًا. هذه الأعلام تظهر في navigator.appVersion ويمكن كشفها عبر chrome.runtime أو حتى عبر سلوك العملية. Patchright يحقن --disable-blink-features=AutomationControlled ويحذف الأعلام الكاشفة من سطر الإطلاق، مما يجعل العملية تبدو كأنها تشغيل Chrome عادي.

4. محاذاة قناة Chrome الحقيقية (channel='chrome')

هنا يكمن الفرق الجوهري: Playwright افتراضيًا يستخدم Chromium المجمّع معه، والذي يملك بصمة TLS/JA3 مختلفة عن Chrome المستقر. Patchright يدفعك لاستخدام channel='chrome'، أي تشغيل نسخة Chrome الحقيقية المثبتة على النظام. هذا يعني أن ClientHello في TLS يتطابق مع بصمة Chrome الحقيقية، وتسلسل التشفيرات (cipher orderings) مطابق لما تتوقعه أنظمة الكشف. هذا أمر حاسم لأن JA3/JA4 أصبح إشارة أساسية في تصنيف البوتات.

القاعدة: إذا كان بصمة TLS متصفحك لا تطابق بصمة المتصفح التي تدعي أنه أنت، فسترفعك أنظمة الكشف حتى لو كان كل شيء آخر مثاليًا.

ما الذي يرقّعه Patchright وما الذي لا يرقّعه

هذا هو الجزء الذي يسيء فهمه كثيرون. Patchright ليس عصا سحرية. إليك مقارنة صريحة:

الميزة	Patchright	playwright-stealth	Camoufox
navigator.webdriver	مرقّع برمجيًا	مرقّع عبر إضافة JS	مرقّع على مستوى C++
تسريبات CDP / Runtime.enable	مرقّع	غير مرقّع	غير قابل للتطبيق (ليس Chromium)
أعلام سطر الأوامر	منظّفة	غير منظّفة	غير قابل للتطبيق
بصمة Canvas / WebGL	غير مرقّع	تخفيض جزئي	تشويش أصلي
الخطوط المثبتة	غير مرقّع	غير مرقّع	عشوائية
الإشارات السلوكية (حركة الماوس، سرعة الكتابة)	غير مرقّع	غير مرقّع	غير مرقّع
محاذاة TLS/JA3 مع Chrome الحقيقي	نعم عبر channel='chrome'	لا (يستخدم Chromium)	نعم (Firefox مخصص)

الخلاصة: Patchright يغلق التسريبات البروتوكولية والـ runtime، لكنه لا يلمس بصمة Canvas أو WebGL أو الخطوط. هذا يعني أن موقعًا يجمع بصمة Canvas ويمررها لنموذج تصنيف قد يرى بصمة متسقة مع Chrome حقيقي، لكن إن كان جهازك يفتقر لخطوط شائعة أو ينتج بصمة Canvas غير معتادة، فقد يرتفع نتيجتك.

لمقارنة أعمق بين بدائل التخفي، راجع مستودع Patchright الرسمي و وثائق Playwright الرسمية حول المتصفحات.

لماذا تبقى سمعة IP هي الفيصل بعد إغلاق تسريبات CDP

هنا النقطة التي يفشل فيها كثيرون: حتى لو أغلق كل تسريب CDP، وجعلت navigator.webdriver = false، ومحَيتَ بصمة TLS مع Chrome حقيقي، فإن Cloudflare Turnstile و DataDome لا يزالان يصنّفانك بناءً على سمعة عنوان IP الخروج.

أنظمة مكافحة البوتات الحديثة تنظر إلى:

• نوع ASN: هل هو مزود استضافة (datacenter ASN) أم مزود إنترنت منزلي (residential ASN)؟
• سجل IP: هل ظهر هذا IP في هجمات سابقة أو في شبكات بوت معروفة؟
• الكثافة: كم طلبًا صدر من هذا IP في الساعة الماضية؟
• اتساق الجغرافيا: هل يتطابق موقع IP المعلن مع ترويسة Accept-Language وبصمة المتصفح؟

بروكسيات مركز البيانات (datacenter) تأتي من ASNs معروفة (مثل OVH، DigitalOcean، AWS). أنظمة الكشف تعرف هذه النطاقات وتمنحها درجة مخاطرة عالية افتراضيًا. لذا، حتى مع Patchright مثالي، ستحصل على تحدي CAPTCHA أو رفض مباشر.

البروكسيات السكنية (residential) تأتي من ASNs تابعة لمزودي إنترنت حقيقيين (Comcast، AT&T، Vodafone)، مما يجعل درجة المخاطرة منخفضة. هذا هو السبب الجوهري لضرورة دمج Patchright مع بروكسيات سكنية — أحدهما يغلق بصمة المتصفح، والآخر يغلق بصمة الشبكة.

تخيل الأمر كطبقات: Patchright يغلق الطبقة البرمجية، والبروكسي السكني يغلق طبقة الشبكة. إغلاق طبقة واحدة فقط لا يكفي ضد Cloudflare أو DataDome.

محاذاة بصمة TLS/HTTP2 مع IP السكني

هنا يتقدم الخبراء عن المبتدئين. بصمة JA3/JA4 هي تجزئة (hash) لرسالة ClientHello في TLS، وتشمل: إصدار TLS، وقائمة التشفيرات بالترتيب، والإضافات (extensions)، ومجموعات المنحنيات الإهليلجية. Chrome المستقر ينتج بصمة JA3 محددة وقابلة للتنبؤ.

عندما تستخدم channel='chrome' في Patchright، تحصل على نفس بصمة JA3. لكن المشكلة التالية: هل تتطابق هذه البصمة مع ما يتوقعه الخادم من عنوان IP السكني؟

معظم المواقع لا تتحقق من تطابق JA3 مع ASN بشكل صريح، لكن أنظمة متقدمة (مثل بعض تكوينات Cloudflare Bot Management) تتحقق من اتساق الإشارات: إذا كان IP من Comcast في الولايات المتحدة، لكن بصمة JA3 تشير إلى Chrome 119 على Windows، فيجب أن تكون ترويسات HTTP/2 (SETTINGS، WINDOW_UPDATE، PRIORITY) متسقة مع ذلك. Patchright يضمن هذا لأنه يستخدم Chrome حقيقيًا، بينما مكتبات مثل curl-impersonate تحتاج محاكاة يدوية.

النقطة العملية: استخدم بروكسي سكني من نفس البلد الذي تدّعي أن متصفحك منه. إذا كان Accept-Language يقول en-US و IP من ألمانيا، فهذا تناقض يرفع درجتك.

مثال عملي: Patchright مع ProxyHat وبجلسة سكنية لاصقة

الآن ننتقل إلى الكود. هذا مثال لأتمتة مشروعة — جمع بيانات عامة من صفحة محمية، أو اختبار اختراق مصرّح به على بنية تحتية تملكها. نستخدم سياقًا دائمًا (persistent context) في Patchright مع بروكسي سكني لاصق من ProxyHat بجلسة country-US-session-abc123.

from patchright.sync_api import sync_playwright

# بناء URL البروكسي مع استهداف جغرافي وجلسة لاصقة
proxy_url = "http://user-country-US-session-abc123:PASSWORD@gate.proxyhat.com:8080"

with sync_playwright() as p:
    # سياق دائم يحافظ على ملفات تعريف الارتباط والتخزين المحلي
    browser = p.chromium.launch_persistent_context(
        user_data_dir="./chrome_profile",
        channel="chrome",  # استخدام Chrome الحقيقي لمحاذاة JA3
        proxy={"server": proxy_url},
        headless=False,  # headless=True يكشف أحيانًا؛ استخدم وضع-headed
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-first-run",
            "--no-default-browser-check",
        ],
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York",
    )

    page = browser.new_page()

    # تعيين ترويسات متسقة مع IP الأمريكي
    page.set_extra_http_headers({
        "Accept-Language": "en-US,en;q=0.9",
    })

    # التنقل إلى الصفحة المحمية
    response = page.goto("https://example.com/protected-page", wait_until="domcontentloaded")

    print(f"Status: {response.status}")
    print(f"Title: {page.title()}")

    # انتظار أي تحدي CAPTCHA يحل نفسه في الخلفية
    page.wait_for_timeout(5000)

    # استخراج البيانات
    content = page.content()
    print(content[:500])

    browser.close()

النقاط الجوهرية في هذا المثال:

• channel='chrome': يضمن بصمة TLS/JA3 مطابقة لـ Chrome المستقر، وليس Chromium.
• session-abc123: جلسة لاصقة تحافظ على نفس IP السكني عبر الطلبات، مما يمنع اكتشاف تذبذب IP.
• country-US: استهداف جغرافي يتطابق مع Accept-Language و timezone_id.
• headless=False: بعض أنظمة الكشف تتعرف على وضع headless حتى مع Patchright؛ تشغيل headed أكثر أمانًا.
• سياق دائم: يحافظ على ملفات تعريف الارتباط، مما يجعل الجلسة تبدو كعودة مستخدم حقيقي.

للاختبار عبر SOCKS5 بدل HTTP، استخدم المنفذ 1080:

proxy_url = "socks5://user-country-US-session-abc123:PASSWORD@gate.proxyhat.com:1080"

يمكنك بناء URL البروكسي برمجيًا عبر SDK أو ببساطة تنسيق السلسلة. تأكد من استبدال PASSWORD بكلمة مرورك الفعلية من لوحة تحكم ProxyHat. للاطلاع على المواقع المتاحة، راجع صفحة المواقع.

مثال Node.js

const { chromium } = require('patchright');

const proxyUrl = 'http://user-country-US-session-abc123:PASSWORD@gate.proxyhat.com:8080';

(async () => {
  const browser = await chromium.launchPersistentContext('./chrome_profile', {
    channel: 'chrome',
    proxy: { server: proxyUrl },
    headless: false,
    args: ['--disable-blink-features=AutomationControlled'],
    locale: 'en-US',
    timezoneId: 'America/New_York',
  });

  const page = await browser.newPage();
  await page.setExtraHTTPHeaders({ 'Accept-Language': 'en-US,en;q=0.9' });
  const response = await page.goto('https://example.com/protected-page');
  console.log('Status:', response.status());
  await browser.close();
})();

أخطاء شائعة وحالات حدية

1. نسيان محاذاة Accept-Language مع IP

إذا كان IP من ألمانيا لكن Accept-Language يقول en-US فقط، فهذا تناقض. الحل: استهدف country-DE واضبط Accept-Language: de-DE,de;q=0.9,en;q=0.8 و locale='de-DE'.

2. استخدام headless=True مع صفحات عالية الحساسية

بعض أنظمة الكشف تختبر navigator.permissions و WebGL بشكل مختلف في وضع headless. حتى مع Patchright، قد تنجح في اختبارات أساسية وتفشل في اختبارات متقدمة. للحالات الحرجة، استخدم وضع headed مع شاشة افتراضية (Xvfb على لينكس).

3. تدوير IP لكل طلب على صفحة واحدة

إذا بدّلت IP بين كل طلب HTTP داخل نفس تحميل الصفحة، فإن الخادم يرى طلبات أصول (CSS، JS، صور) من IPs مختلفة لنفس الجلسة — إشارة قوية للبوت. استخدم جلسة لاصقة لكل تحميل صفحة كامل على الأقل.

4. تجاهل بصمة Canvas

Patchright لا يشوّش Canvas. إذا كان جهازك ينتج بصمة Canvas نادرة (مثل GPU غير شائع)، فقد ترتفع درجتك. الحل: استخدم جهازًا بعتاد شائع، أو فكّر في Camoufox للحالات التي يكون فيها تشويش Canvas ضروريًا.

5. الاعتماد على Patchright وحده دون بروكسي سكني

هذا الخطأ الأكثر شيوعًا. مهندسون يظنون أن Patchright كافٍ، ثم يستخدمون بروكسي مركز بيانات ويتساءلون لماذا يُرفضون. بصمة المتصفح مثالية لكن IP من DigitalOcean — النتيجة: رفض. القاعدة: Patchright + بروكسي سكني = زوج لا يتجزأ.

أين هذا مناسب وغير مناسب

التقنيات الموصوفة هنا مناسبة لـ:

• البحث الأمني المصرّح به: اختبار اختراق على بنية تحتية تملكها أو لديك إذن كتابي لاختبارها.
• أتمتة البيانات العامة الممتثلة: جمع صفحات عامة لا تتطلب تسجيل دخول، مع احترام robots.txt وشروط الخدمة.
• مراقبة الأسعار والـ SERP: راجع حالة استخدام تتبع نتائج البحث و حالة استخدام كشط الويب.

غير مناسب إطلاقًا لـ:

• الاحتيال أو انتحال هويات حقيقية.
• تجاوز ضوابط الدخول أو تسجيل الدخول إلى حسابات لا تملكها.
• أنشطة تنتهك شروط خدمة المنصة بشكل صريح أو قوانين الخصوصية مثل GDPR أو CCPA.

الامتثال ليس رفاهية — هو أساس الاستدامة. اقرأ وثائق ProxyHat على docs.proxyhat.com للاطلاع على سياسات الاستخدام المقبولة.

النقاط الرئيسية

• Patchright يغلق تسريبات CDP و navigator.webdriver وأعلام سطر الأوامر، لكنه لا يلمس Canvas أو WebGL أو الخطوط أو الإشارات السلوكية.
• استخدام channel='chrome' ضروري لمحاذاة بصمة JA3/JA4 مع Chrome الحقيقي.
• سمعة IP تبقى الفيصل النهائي؛ بروكسي سكني من ProxyHat عبر gate.proxyhat.com:8080 يغلق طبقة الشبكة.
• محاذاة الجغرافيا (IP + Accept-Language + timezone) ضرورية؛ التناقض يرفع درجة المخاطرة.
• الجلسة اللاصقة (session-abc123) تمنع اكتشاف تذبذب IP داخل تحميل صفحة واحد.
• هذه التقنيات للأتمتة المشروعة والبحث الأمني المصرّح به فقط — ليس للاحتيال أو تجاوز ضوابط الدخول.

ابدأ ببناء أتمتتك النظيفة اليوم — أنشئ حسابًا على ProxyHat، اختر باقة سكنية تناسب حجم حمللك، وادمجها مع Patchright للحصول على أفضل مزيج بين بصمة متصفح نظيفة وسمعة IP منخفضة المخاطرة.