تصحيح أخطاء Cloudflare Browser Run قبل تشغيل المهمة مجددًا

Cloudflare غيّرت في 18 سبتمبر 2026 آلية تصحيح أخطاء Cloudflare Browser Run بعد فشل المهام. فبات تسجيل التشغيل المكتمل يعرض سجلات وحدة التحكم وطلبات الشبكة والبنية النهائية للصفحة، كي تشخّص الأدلة التي دفعت تكلفة إنشائها بالفعل قبل تشغيل متصفح آخر.

ما الذي تغيّر في تصحيح أخطاء Cloudflare Browser Run؟

كانت مهمة المتصفح، بعد انتهائها، لا تترك لك سوى مخرجاتها وآلية معالجة أخطائها وإعادة عرض لها إذا كنت قد فعّلت Session Recording. وحين لا يفسّر العطل نفسه، كان المسار المعتاد هو إضافة مزيد من السجلات التشخيصية ثم تشغيل المهمة مجددًا.

تضع لوحة Inspect الجديدة ثلاث طرق لعرض البيانات بجوار التسجيل المكتمل:

• تتيح Logs البحث في مخرجات وحدة التحكم الملتقطة وتصفيتها بحسب المستوى.
• تعرض Network طريقة كل طلب وحالته ورؤوسه وحمولته واستجابته وتوقيته. ويمكن تصدير هذا النشاط في ملف HAR، وهو تنسيق الأرشفة القياسي لمسار طلبات المتصفح.
• تعرض DOM بنية الصفحة عند نهاية التسجيل، وتتيح نسخ HTML المعاد بناؤه. والمقصود بـ DOM شجرة العناصر التي أنشأها المتصفح من الصفحة.

هذه أدلة تُفحص بعد التشغيل، وليست واجهة أخرى لتصحيح الأخطاء لحظة بلحظة. تعتمد ميزة Session Recording من Cloudflare على بيانات أحداث rrweb منظّمة، لا على فيديو. وهي تسجّل تغيّرات DOM وأحداث الماوس ولوحة المفاتيح والتنقّل. أما لوحة Inspect فتضيف إلى إعادة العرض قرائن قابلة للبحث بعد إغلاق الجلسة.

وهذا ما يميّز هذا الإصدار عن التغيير السابق في Browser Run من Cloudflare. إذ تتحكم ضوابط الجلسة وLive View المخصّصة للقراءة فقط في الوجهات التي يمكن للمهمة النشطة الوصول إليها وما يستطيع العميل فعله أثناء مشاهدتها، بينما تساعد Inspect فريقك على تفسير سبب فشل مهمة انتهت بالفعل.

ما الأعطال التي يمكن أن يكشفها التسجيل؟

تفيد اللوحة عندما يترك العطل وراءه دليلًا داخل المتصفح.

كيف يجد مؤسس SaaS منفردًا الطلب المرفوض؟

لنفترض أن مهمة استخراج دورية تصل إلى الصفحة لكنها لا تعيد أي بيانات. يمكن لعرض Network أن يكشف ما إذا كانت إحدى واجهات API قد أعادت 401، أو أعاد حد المعدّل 429، أو وجّهت عملية إعادة توجيه المتصفح إلى وجهة غير متوقعة، أو استغرقت إحدى التبعيات معظم وقت التشغيل.

يمكن فحص تفاصيل الطلب والاستجابة قبل إضافة سجلات مؤقتة. والنتيجة تشخيص أولي أضيق نطاقًا: أصلح بيانات الاعتماد أو آلية التراجع أو إعادة التوجيه أو التبعية البطيئة التي كشفها التشغيل الحالي بالفعل.

كيف يميّز مسؤول الوكالة تغيّر الصفحة من خطأ السكربت؟

قد يتعطّل سير عمل أحد العملاء لأن محدّدًا تغيّر، أو لأن صفحة تسجيل الدخول حلّت محل الشاشة المتوقعة، أو لأن طلب أحد الأصول أعاد خطأ. يعرض DOM النهائي وHTML المنسوخ الصفحة التي وصل إليها المتصفح فعلًا، فيما يوضح مسار الطلبات كيف وصل إليها.

وبذلك يحصل فريق التنفيذ على تسليم واضح. فبدلًا من عبارة «تعطّلت الأتمتة»، يتسلّم شجرة العناصر النهائية وملف HAR يضم ما هو متاح من الرؤوس والحمولات والحالات والتوقيتات.

كيف يتابع مهندس المنصة علامة التبويب الصحيحة؟

يفهرس التسجيل مصفوفات أحداثه وفق أهداف Chrome DevTools Protocol، مثل target-1، ويمثل كل هدف عادةً علامة تبويب واحدة في المتصفح. ويعرض التسجيل متعدد علامات التبويب هذه الأهداف كلًا على حدة، كما تتبع لوحة Inspect في لوحة المعلومات علامة التبويب التي تختارها.

وهذا مهم في عمليات تسليم المصادقة وفي تدفقات عمل الوكلاء. فقد تنجح علامة تبويب تسجيل الدخول بينما تفشل علامة تبويب العمل. وتحول الأدلة الخاصة بكل هدف دون خلط القصتين.

سجّل مهمة واحدة واستخرج مسار شبكتها

التسجيل اختياري، ويجب تفعيله عند إنشاء جلسة المتصفح أول مرة؛ فلا يمكن تشغيله لاحقًا عند إعادة الاتصال بجلسة قائمة.

أصغر إعداد مفيد هو جلسة Browser Session دورية واحدة تؤدي أعطالها حاليًا إلى إعادة إنتاج المشكلة يدويًا.

1. 1

   فعّل التسجيل عند البدء

   يمرّر مثال Puppeteer من Cloudflare الخيار recording: true في استدعاء البدء الأول. احتفظ بمعرّف الجلسة قبل إغلاق المتصفح:

   import puppeteer from "@cloudflare/puppeteer";
   
   interface Env {
   	MYBROWSER: Fetcher;
   }
   
   export default {
   	async fetch(request: Request, env: Env): Promise<Response> {
   		const browser = await puppeteer.launch(env.MYBROWSER, { recording: true });
   		const page = await browser.newPage();
   
   		await page.goto("https://example.com");
   		// ... your automation steps ...
   
   		const sessionId = browser.sessionId();
   		await browser.close();
   
   		return new Response(`Session recorded: ${sessionId}`);
   	},
   };

   يستخدم Playwright خيار البدء نفسه، بينما يضع اتصال CDP القيمة recording=true في عنوان WebSocket الخاص به.

2. 2

   اطلب التسجيل المكتمل

   بعد إغلاق الجلسة، اطلب التسجيل باستخدام معرّفها:

   curl https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID> \
     -H "Authorization: Bearer <API_TOKEN>"

   تضع الاستجابة مصفوفات الأحداث تحت result.events. وتمثل مفاتيحها، مثل target-1، معرّفات الأهداف التي تحتاج إليها في طلب الشبكة. قد يعيد التسجيل الجديد 404 لفترة وجيزة بينما تنهي Cloudflare معالجته؛ لذا أعد محاولة هذا الاستعلام بدل اعتبار أول 404 دليلًا على غياب التشغيل.

3. 3

   استخرج الطلبات الخام للهدف

   اختر هدفًا أعادته استجابة التسجيل. المعامل target مطلوب:

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>' \
     -H "Authorization: Bearer <API_TOKEN>"

   تعيد الاستجابة الطلبات الملتقطة بصيغة JSON، بما فيها تفاصيل الطلب والاستجابة المتاحة.

4. 4

   صدّر ملف HAR

   أضف format=har عندما يحتاج المطوّر إلى المسار في عارض شبكة المتصفح أو في أداة تحليل أخرى:

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>&format=har' \
     -H "Authorization: Bearer <API_TOKEN>"

   تعامل مع هذا الملف بوصفه أثرًا لتصحيح الأخطاء، وقيّد الوصول إليه. فالاستجابة الموثّقة قد تتضمن الرؤوس والحمولات المتاحة، ولذلك تستحق الحماية نفسها المطبّقة على بيانات المهمة التي تصفها.

من السهل الوقوع في خطأ عدم تفعيل التسجيل إلا بعد أول عطل. لا يمكن إنشاء أدلة بأثر رجعي؛ لذلك ابدأ بمهمة دورية يهمّك عطلها التالي.

تكلفة المتصفح ليست العبء الأكبر

لا تعرض صفحة تسعير Browser Run الحالية من Cloudflare رسومًا منفصلة للتسجيل أو لتخزينه. وتظل جلسة Browser Session المسجّلة خاضعة لفاتورة ساعات المتصفح والتزامن المعتادة. وما زالت Session Recording في المرحلة التجريبية، لذا تعامل مع ذلك بوصفه السعر المنشور اليوم لا وعدًا دائمًا.

تتضمن Workers Free مدة 10 دقائق من وقت المتصفح يوميًا وثلاثة متصفحات متزامنة. أما Workers Paid فلها حد أدنى قدره $5 للحساب شهريًا، وتشمل 10 ساعات من وقت المتصفح و10 متصفحات متزامنة، ثم تفرض $0.09 على كل ساعة متصفح إضافية و$2 على كل متصفح متزامن إضافي، استنادًا إلى المتوسط الشهري لذروة كل يوم.

السعر المباشر لتشغيل تشخيصي واحد ضئيل؛ أما تكلفة العمل البشري المصاحب له فليست كذلك. النموذج الآتي للتخطيط وليس معيار أداء صادرًا عن Cloudflare:

• تجاوز الحساب بالفعل ساعات المتصفح الـ10 المشمولة.
• تستغرق مهمة دورية واحدة 10 دقائق وتفشل 12 مرة خلال شهر.
• تستغرق إعادة إنتاج كل عطل وتشخيصه 20 دقيقة من وقت المشغّل.
• يستغرق فحص التسجيل الحالي 5 دقائق من وقت المشغّل.
• يُفترض أن تكلفة وقت المشغّل المحمّلة تبلغ $75 في الساعة.
• يلغي الفحص تشغيلًا تشخيصيًا واحدًا، لكن قد تظل هناك حاجة إلى تشغيل لاحق للتحقق من الإصلاح.

لا تتجاوز حصة وقت المتصفح الخام من هذا الفرق 18 سنتًا، أما الـ$225 الأخرى فهي تكلفة وقت المشغّل. كذلك تقرّب Cloudflare استخدام المتصفح على مستوى الحساب بعد جمع دورة الفوترة كاملة؛ لذلك لا تتعامل مع 1.5 سنت مقابل تشغيل مدته 10 دقائق كبند سيظهر في الفاتورة.

هذه هي النتيجة التجارية. لا تحوّل لوحة Inspect حوسبة المتصفح إلى مصدر توفير كبير، لكنها قد تختصر من الحادثة دورة كاملة من إضافة أداة القياس وإعادة الإنتاج والانتظار.

ما الذي يعجز التسجيل عن إظهاره؟

يلتقط التسجيل حالة المستند وأحداثه، لا كل بكسل معروض.

تحدد هذه القيود الأعطال التي ما زالت تحتاج إلى أسلوب تشخيص آخر. فقد تكمن المشكلة في رسم بياني مرسوم على Canvas، أو نموذج دفع داخل iframe تابع لطرف ثالث، أو حالة تشغيل فيديو، أو مشهد WebGL، أو قيمة أُدخلت في حقل محجوب، مع أن ما يحيط بها في التسجيل يبدو طبيعيًا.

كذلك لا يعرض DOM سوى البنية عند نهاية التسجيل. وقد يفسّر الصفحة التي انتهت عندها المهمة، لكنه ليس لقطة شاشة مطابقة على مستوى البكسل لكل حالة سابقة.

وهناك حدود تشغيلية أيضًا. تظل التسجيلات متاحة لمدة 30 يومًا، وتستغرق 1 ثانية على الأقل و2 ساعة على الأكثر، وتعمل مع Browser Sessions عبر launch() أو CDP. ولا تستطيع Quick Actions إنشاءها. وقد تولّد الصفحة شديدة النشاط تدفقًا ضخمًا للأحداث لأن كل تغيّر متكرر في DOM يتحول إلى بيانات تسجيل.

من ينبغي له تغيير سير العمل الآن؟

تحرّك هذا الأسبوع إذا كنت تشغّل مهام دورية عبر Puppeteer أو Playwright أو CDP، وكان التعامل مع العطل يبدأ عادةً بإعادة إنتاجه. أضف التسجيل إلى مهمة واحدة لا إلى كل المهام، ثم قِس ما إذا كان التسجيل يجيب عن سؤال التشخيص الأول.

انتظر إذا كانت الحالة المهمة موجودة أساسًا في Canvas أو WebGL أو الوسائط أو iframe من مصدر مختلف أو حقول نموذج محجوبة. أبقِ لقطات الشاشة وسجلات التطبيق وأدوات القياس المحددة ضمن هذا المسار، لأن التسجيل لا يستطيع أن يحل محلها.

لن تتأثر إذا ظل عملك مقتصرًا على Quick Actions. فالانتقال إلى Browser Sessions من أجل التسجيل وحده يغيّر التنفيذ ويضيف التزامن إلى نموذج التسعير، ولذلك يجب أن تبرر فائدة تصحيح الأخطاء هذا الانتقال.

خطوة يوم الاثنين

اختر جلسة Browser Session دورية واحدة سبق أن فشلت أكثر من مرة. أضف recording: true عند بدء تشغيلها الأول، وخزّن معرّف الجلسة إلى جانب معرّف المهمة لديك، ثم دع التشغيل المجدول التالي يُغلق بصورة طبيعية.

بعد ذلك، استخرج التسجيل وخذ أول معرّف هدف ذي صلة، ثم اطلب مسار الشبكة الخام أو ملف HAR. احسب الوقت اللازم لتحديد الطلب الفاشل أو الحالة النهائية للصفحة. إذا ألغت هذه الأدلة تشغيلًا تشخيصيًا واحدًا، فأبقِ التسجيل مفعّلًا في تلك المهمة واجعل المسار جزءًا من سجل الحادثة. وإن لم تفعل، فأوقفه مجددًا وأضف الإشارة الناقصة حيث توجد النقطة العمياء فعلًا.

إذا كنت تريد مزيدًا من الشروحات العملية لتغيّرات المنصات، فانضم إلى النشرة البريدية.