إذا كان نص Playwright يعمل الأسبوع الماضي وأصبح الآن يصطدم بصفحة تحدي Cloudflare، أويعيد HTTP 403 مع error 1020، فالمشكلة نادرًا ما تكون في الكود. المشكلة أن متصفحك يعرّف نفسه بوصفه أتمتة عبر مجموعة إشارات قد لا تعرف أنه يصدرها.
يشرح هذا الدليل لماذا تحظر Cloudflare نصوص Playwright، وما الذي تقرؤه تحديدًا، والفئات الأربع من الحلول مرتبة حسب موثوقيتها الفعلية في الإنتاج. والخلاصة: تمنحك patches على مستوى الصفحة أسابيع قليلة، أما الهوية المتسقة على مستوى ملف المتصفح الثنائي فهي الإصلاح الدائم الوحيد.
لماذا يستدعي Playwright اكتشاف bot في Cloudflare؟
تحظر Cloudflare جلسات Playwright لأن متصفح Chromium الافتراضي الذي يتحكم فيه Playwright يصدر مجموعة متسقة من الإشارات التي دُرب Cloudflare Bot Management على تصنيفها كأتمتة. الحظر ليس عشوائيًا ولا يعتمد على rate limiting وحده؛ بل على تصنيف الهوية الذي يحدث قبل أول تفاعل ينفذه النص مع الصفحة.
تتضمن أول 200 ms من تحميل صفحة محمية بـ Cloudflare مجموعة فحوص للبصمة والسلوك تعمل قبل أن يتمكن كودك من التصرف. وبحلول اكتمال page.goto()، تكون الجلسة غالبًا قد صُنفت بالفعل.
لماذا تسوء المشكلة مع الوقت؟
تحدّث Cloudflare نماذج الاكتشاف باستمرار. ووفق Documentation الخاصة بـ Cloudflare Bot Management، تستخدم المنظومة machine learning مدربًا على أنماط الحركة عبر ملايين المواقع. وهذا يعني أن التوقيع الذي يصدره إعداد stealth اليوم قد يكون مقبولًا، ثم يوضع عليه علامة الشهر التالي بعد تحديث النموذج. ولهذا تكون عبارة «توقف عن العمل» النمط الأكثر شيوعًا في نقاشات تصحيح Playwright مع Cloudflare.
الإشارات الست التي تقرؤها Cloudflare من Playwright
لإصلاح مشكلة Playwright مع Cloudflare، يجب أن تعرف ما الذي تفحصه Cloudflare فعلًا. هناك ست إشارات عالية التأثير.
1. العلامة navigator.webdriver الأساسية
أبسط إشارة. تضبط نسخة Chromium عادية يتحكم فيها Playwright navigator.webdriver = true. تقرأ أنظمة الاكتشاف ذلك عند أول تنفيذ للنص. تتعامل معظم stealth plugins معه، لكن بعض patches قابلة للاكتشاف بذاتها.
2. بصمة TLS (JA3 / JA4)
ينتج Chromium الأساسي في Playwright TLS Client Hello بترتيب محدد لـ ciphers وقائمة extensions ومجموعة elliptic curves. ويشكل ذلك JA3 أوJA4 hash تستطيع Cloudflare مقارنته بتوقيعات automation clients المعروفة. وكما توضح مواصفات JA3 المفتوحة من Salesforce، فإن TLS handshake قابلة للبصم بمعزل عن user agent.
3. ترتيب إطارات HTTP/2
يكون ترتيب إرسال المتصفح لإطارات HTTP/2 من أنواع SETTINGS وWINDOW_UPDATE وHEADERS ثابتًا داخل إصدار Chrome، لكنه يختلف عن مكتبات الأتمتة التي تبني HTTP/2 بطريقة أخرى. وتقرأ Cloudflare هذه الطبقة.
4. بصمات Canvas وWebGL والصوت
عندما تشغّل الصفحة JavaScript الخاص بتحدي Cloudflare، ترسم محتوى اختباريًا في سياقات Canvas وWebGL ثم تقرأ pixel data. تنتج نسخة Chromium عادية في Playwright قراءات حتمية ومتكررة. وظهور القراءة نفسها عبر آلاف الجلسات إشارة bot بحد ذاته.
5. اتساق المنطقة الزمنية وlocale وجغرافيا IP
إذا عرض متصفحك en-US وAmerica/New_York بينما يمر IP عبر datacenter في فرانكفورت، يكون التعارض إشارة bot شبه مؤكدة. تقارن Cloudflare القيم الثلاث معًا.
6. الإشارات السلوكية بعد تحميل الصفحة
إذا اجتاز التحدي مرحلة البصمة، تبدأ فحوص السلوك: entropy حركة الفأرة، وأنماط التمرير، وإيقاع ضغط المفاتيح. ويمكن هنا اكتشاف التفاعلات البرمجية البحتة، مثل النقر الفوري عند إحداثيات دقيقة.
الفئات الأربع للإصلاح، مرتبة
هناك أربع فئات فعلية من الحلول لحظر Playwright في Cloudflare، وتختلف كثيرًا في مدة بقائها فعالة.
المستوى 4، الأقل موثوقية: تعديل User-Agent والعلامات الأساسية
هذا أول ما يجربه معظم المطورين: تعيين user agent مخصص، وإزالة العلامة --enable-automation، واستبدال navigator.webdriver عبر addInitScript. ولا يعالج ذلك إلا إشارة واحدة من الست.
العمر في الإنتاج: أيام إلى أسابيع. تجاوز اكتشاف Cloudflare الأساسي هذه الطبقة منذ زمن.
متى يناسب: المواقع التي لا تملك اكتشاف bot حقيقيًا وتحتاج فيها فقط إلى إخفاء العلامة الأوضح.
المستوى 3، موثوقية محدودة: Stealth plugins
عائلة plugins من نوع puppeteer-extra-stealth، المنقولة إلى Playwright عبر مكتبات مثل playwright-stealth. تعدل أكثر من عشر خصائص navigator، وتضيف noise إلى قراءات Canvas، وتعالج عدة إشارات عبر حقن JavaScript على مستوى الصفحة.
العمر في الإنتاج: أسابيع إلى بضعة أشهر. لـ patches نفسها توقيعات تستطيع الأنظمة اكتشافها، كما أنها تعمل في طبقة مختلفة عن rendering pipeline الأساسية في Chromium، ولذلك تظل قراءات Canvas وWebGL تكشف المتصفح في الحالات الطرفية.
متى يناسب: جمع بيانات خفيف من مواقع متوسطة الحماية، والنماذج الأولية، والبيئات التي تقبل أعطالًا عرضية.
لماذا يفشل في النهاية: patching على مستوى الصفحة نمط معروف. ووفق بحث عن اكتشاف المتصفحات headless، يمكن التعرف إلى المتصفحات المؤتمتة من توقيت patches وسلوكها حتى عندما تنجح في spoofing لقيم الخصائص.
المستوى 2، موثوقية متوسطة: Stealth plugins مع residential proxy وسلوك مدروس
يضيف هذا النهج residential proxy وتوقيتًا واقعيًا إلى مجموعة stealth plugins، مثل التأخيرات المتغيرة ومنحنيات حركة الفأرة وأنماط التمرير. ويعالج إشارة جغرافيا IP وإشارة السلوك.
العمر في الإنتاج: أشهر. وهنا تستقر معظم فرق الأتمتة مع المواقع المحمية بدرجة معقولة.
نمط الفشل المتبقي: تعارض locale والمنطقة الزمنية وIP. تشتري residential proxy في ألمانيا وتنسى ضبط منطقة المتصفح على Europe/Berlin، بينما تظل ترويسات اللغة ترسل en-US. لا يعطي التعارض خطأ في النص، لكنه يرفع معدل تحديات Cloudflare تدريجيًا خلال أسابيع.
المستوى 1، الأكثر موثوقية: اتساق الهوية على مستوى المحرك
يعني ذلك نسخة Chromium تُطبّق فيها patches على أسطح البصمة داخل ملف المتصفح الثنائي، لا عبر حقن JavaScript. ويعني ملفًا تُنشأ فيه Canvas وWebGL والصوت وخصائص navigator والشاشة والخطوط والمنطقة الزمنية وlocale كي تتطابق معًا ومع جغرافيا proxy IP. كما يعني ربط proxy بالملف لتحدث المحاذاة تلقائيًا بدل الاعتماد على ذاكرة المشغل.
هذا ما يقدمه Clawbrowser. يعني patching على مستوى المحرك أن أنظمة الاكتشاف لا تستطيع مطابقة نمط stealth نفسها، إذ لا يوجد كود stealth يعمل في الصفحة؛ القيم هي ببساطة ما يبلغ عنه المتصفح أصلًا. كما تلغي proxies المرتبطة بالملفات فئة تعارض locale والمنطقة الزمنية وIP.
إذا كنت تختار بين نقل Playwright إلى runtime محلية من فئة anti-detect أوإلى خدمة متصفح مستضافة، فراجع مقارنة Clawbrowser وBrowserbase لفهم مفاضلات النشر والخصوصية والتكلفة.
العمر في الإنتاج: غير محدد، مع إعادة توليد ملفات التعريف دوريًا. يتدهور النهج تدريجيًا لأن كل ملف فريد بدل حمل توقيع stealth معروف.
متى يناسب: أي مسار إنتاج تهم فيه الموثوقية أكثر من راحة البقاء على Chromium العادي، وخصوصًا أحمال وكلاء الذكاء الاصطناعي، لأن طبقة orchestration تواصل العمل من دون تغيير عند استبدال runtime تحتها.
التنفيذ خطوة بخطوة: إصلاح المستوى 1
يتطلب الانتقال من Playwright العادي مع stealth plugin إلى runtime على مستوى المحرك أربع خطوات وتغيير سطر واحد من الكود.
الخطوة 1: حدد شكل stack الحالية
قبل تغيير أي شيء، شغّل إعدادك الحالي أمام أداة عامة لفحص البصمة، مثل browserleaks.com أوcreepjs. سجل الأسطح التي وُضع عليها علامة؛ تفشل معظم إعدادات stealth plugins في Canvas وWebGL وTLS على الأقل.
الخطوة 2: ثبّت runtime
بالنسبة إلى Clawbrowser، ابدأ من archive مستقل لـ clawctl ضمن الإصدار العام
clawbrowser/clawctl:
# Download the matching clawctl-* archive for your OS/arch.
open https://github.com/clawbrowser/clawctl/releases/latestبعد استخراج archive، ثبّت تكامل الوكيل المناسب واضبط API key:
clawctl install --agent claude-code --json
clawctl config set --api-key "clawbrowser_xxxxx"الخطوة 3: ابدأ جلسة مُدارة بملف بصمة
clawbrowser start --session work -- --fingerprint=fp_us --country=US --connection-type=residential
clawbrowser endpoint --session work
# prints: http://127.0.0.1:9222تحدد العلامات --fingerprint و--country و--connection-type ملفًا تتوافق فيه Canvas وWebGL وnavigator والشاشة والخطوط والمنطقة الزمنية وlocale، وكذلك residential proxy IP المرتبط، مع هوية أمريكية.
الخطوة 4: غيّر سطرًا واحدًا في نص Playwright
قبل:
browser = await p.chromium.launch(headless=False)بعد:
endpoint = "http://127.0.0.1:9222"
browser = await p.chromium.connect_over_cdp(endpoint)
page = browser.contexts[0].pages[0]يعمل كل ما بعد ذلك، من locators والتنقل إلى assertions، من دون تغيير. ولا يتغير منطق الوكيل أوالأتمتة؛ يتغير نمط الاتصال وحده.
الخطوة 5: تحقق قبل تشغيل حركة الإنتاج
شغّل صفحة التحقق المرفقة بـ runtime للتأكد من أن الهوية الظاهرة خارجيًا هي المطلوبة:
clawbrowser start --session work --verify -- https://example.comهذه الخطوة التي تتجاوزها معظم الفرق ثم تندم عليها. يكتشف التحقق مرة بعد توليد الملف فئة أخطاء تعارض locale الصامتة.
لأنماط دمج CDP الكاملة، ومنها نشر جلسات متعددة، راجع Documentation الخاصة بـ Clawbrowser.
النتائج والفوائد المتوقعة
بعد الانتقال من stealth المبنية على plugins إلى اتساق الهوية على مستوى المحرك، تتغير المقاييس التالية في الإنتاج:
- معدل CAPTCHA ينخفض من نحو 30–60% على المواقع المحمية بـ Cloudflare، وهو المعتاد مع stealth plugins، إلى نسب أحادية الرقم، وتكون التحديات المتبقية ناتجة فعلًا عن أنماط السلوك لا تصنيف الهوية.
- عمر الجلسة يمتد من ساعات إلى أيام أوأسابيع، لأن الجلسة لا تتلقى علامات متزايدة بعد أول عشرات الإجراءات.
- عبء الصيانة ينخفض لأن patches لا تحتاج إلى تحديث مع كل تطور في نموذج اكتشاف Cloudflare.
- مسارات الحسابات المتعددة تصبح موثوقة لأن لكل جلسة هوية مميزة ومتسقة بدل توقيع stealth patch نفسه المشترك بين الجلسات.
والتحفظ الصريح: لا يتجاوز أي متصفح CAPTCHA دائمًا. ستظل المواقع التي تفرض Interactive Challenge على كل جلسة جديدة تفعل ذلك، وأي CAPTCHA تظهر ستحتاج إلى معالجة، إما بتعديل المسار أوخدمة solver أوتدخل بشري لبعض العمليات.
أخطاء شائعة ينبغي تجنبها
إضافة CDP overrides فوق patches على مستوى المحرك
إذا كانت runtime تدير البصمة في الملف الثنائي، فلا تستخدم أيضًا أوامر CDP في Playwright لاستبدال خصائص navigator أوسلوك Canvas. قد تختلف الطبقتان وتنتجان تناقضات قابلة للاكتشاف صُمم نهج المحرك أصلًا لإزالتها.
تدوير proxy في منتصف الجلسة
تغيير proxies أثناء جلسة نشطة، أي تبديل IP في منتصف مسار العمل، إشارة bot قوية لأن البشر لا يغيرون IP كل 30 ثانية. استخدم proxy واحدة لكل جلسة، وابدأ جلسة جديدة بملف مُعاد التوليد لهوية جديدة.
تجاهل محاذاة المنطقة الزمنية وlocale
إذا ضبطت proxies يدويًا، فعليك محاذاة المنطقة الزمنية وlocale واللغات المقبولة مع جغرافيا proxy يدويًا أيضًا. نسيان أي منها أشهر نمط فشل صامت. وتزيل أنظمة proxy المرتبطة بالملف هذه الفئة من الأخطاء.
إعادة استخدام البصمة نفسها لهويات «مختلفة»
تُعد جلستان لهما Canvas fingerprint وسلسلة WebGL renderer نفسيهما هوية واحدة لدى Cloudflare، بصرف النظر عن user agent المعروض في كل منهما. تحتاج الهويات المختلفة إلى ملفات بصمة مختلفة، لا cookies مختلفة فقط.
اعتبار headless مطابقًا لـ headful
يحمل Headless Chrome دلائل بصمة إضافية، مثل نتائج صوت مختلفة وقائمة plugins افتراضية ومسارات عرض مختلفة في بعض الحالات. فإذا كان تصحيحك المحلي في headful ونشر الإنتاج في headless، فتحقق من هوية الإنتاج منفصلة.
الأسئلة الشائعة
لماذا يعمل نص Playwright محليًا لكنه يُحظر في الإنتاج؟
السبب الأشهر اختلاف البيئة: يستخدم التطوير المحلي residential IP والمنطقة الزمنية الحقيقية وبصمة جهاز المطور، بينما يعمل الإنتاج في Linux container خلف datacenter IP أوproxy، مع منطقة زمنية وlocale وأسـطح بصمة قد تختلف. كود orchestration واحد، لكن طبقة الهوية مختلفة بالكامل. والإصلاح runtime تنتج هوية متسقة في البيئتين.
هل تكفي residential proxy لحل مشكلة Cloudflare؟
لا. تصلح residential proxy إشارة جغرافيا IP، لكنها تترك Canvas وWebGL وTLS وnavigator والمنطقة الزمنية كما هي. وإذا استمرت هذه الأسطح في إصدار أنماط أتمتة، تكتشف Cloudflare الجلسة. يجب أن يعالج الإصلاح الإشارات كلها معًا لا IP فقط.
هل تكفي playwright-stealth للمواقع المحمية بـ Cloudflare؟
غالبًا نعم للمواقع خفيفة الحماية. أما المواقع التي تستخدم Cloudflare Bot Management نشطًا أوحلول bot حديثة للمؤسسات، فغالبًا لا، وتتراجع الموثوقية بمرور الأشهر مع تحديث نماذج Cloudflare. ولأحمال الإنتاج التي تهم فيها الموثوقية، لـ stealth على مستوى plugins سقف معروف.
ماذا عن برنامج «Verified Bot» من Cloudflare؛ هل أسجل bot فقط؟
إذا كانت حالتك مؤهلة، مثل crawlers لمحركات البحث أوخدمات المراقبة أوأدوات accessibility، فإن برنامج Verified Bots من Cloudflare هو المسار المشروع والإجابة الصحيحة. لكن معظم الأتمتة ووكلاء الذكاء الاصطناعي لا تتأهل، ويجب على الأتمتة غير الموثقة التعامل مع الاكتشاف وفق إشاراتها.
هل يعمل النهج ضد موردي anti-bot الآخرين، مثل DataDome وAkamai وPerimeterX؟
تنطبق المبادئ نفسها: كلما زاد اتساق الهوية على مستوى الملف الثنائي، صعب تصنيف الجلسة كأتمتة. يزن كل مورد الإشارات بصورة مختلفة؛ يركز DataDome على السلوك، وAkamai على TLS، وPerimeterX على مزيج، لكن اتساق الهوية على مستوى المحرك هو الإجابة البنيوية في جميعها.
الخلاصة
النمط ثابت: يصدر Playwright مع Chromium العادي إشارات قابلة للاكتشاف، وتعالج patches على مستوى الصفحة بعض الإشارات بينما تصبح هي نفسها قابلة للاكتشاف، والإجابة الدائمة الوحيدة هي اتساق الهوية داخل ملف المتصفح الثنائي مع خروج proxy مطابق.
إذا استمر حظر نصك من Cloudflare، فأعلى تغيير أثرًا هو الانتقال من «إضافة stealth فوق Chromium» إلى «استخدام نسخة Chromium تكون فيها stealth افتراضية وتُربط proxy بملف متسق». هذا هو الإصلاح البنيوي، والفرق بين نصوص تعمل أسبوعين وأخرى تعمل عامين.
بُني Clawbrowser لهذه الطبقة تحديدًا. يدعم CDP القياسي، ولذلك يتغير سطر واحد في نص Playwright الحالي، بينما يدير المتصفح الأساسي البصمة وربط proxy واتساق الهوية الذي لا يضاهيه نهج قائم على plugins.
تابع القراءة
مقالات ذات صلة
لماذا تستدعي الأتمتة اختبارات CAPTCHA: دليل تشخيصي من 7 إشارات
إذا كان نصك يعمل بالأمس ويصطدم بـ CAPTCHA اليوم، فيمكن تحديد السبب. افحص الإشارات السبع بالترتيب من الأكثر احتمالًا.
قراءة المقال →
puppeteer-extra-stealth أصبح قديمًا: ما تستخدمه الأتمتة الحديثة بدلاً منه
لم يتم تحديث puppeteer-extra-plugin-stealth منذ 2023. تعرف على سبب فشله أمام أنظمة مكافحة البوت الحديثة وما البديل.
قراءة المقال →