الخلاصة

  • يملك حساب Workers Free سقفاً قدره مئة ألف طلب يومياً، ويبدأ العد من جديد عند منتصف الليل بتوقيت UTC. بعد تجاوز السقف، يتخطى fail open كود Worker ويعيد fail closed صفحة الخطأ 1027.
  • إذا كان Worker يفحص الوصول قبل خادم التطبيق، يترك الالتفاف القرار للقواعد الموجودة على الخادم الأصلي. وتوصي Cloudflare بوضع fail closed للوظائف الأمنية الحاسمة.

الحارس الذي يتوقف عند سقف السعر

يضع مشغّل الخدمة Worker أمام خادم التطبيق ليعدل الاستجابة أو يقرر من يدخل. في خطة Free يحصل الحساب على مئة ألف طلب كل يوم. عند استنفاد العدد لا تكتفي Cloudflare بإرسال إشعار مالي؛ ينفذ المسار وضع الفشل المختار. مع fail open يسير الطلب كما لو لم يُضبط Worker أصلاً. ومع fail closed ينتهي عند الخطأ 1027. النتيجتان تختلفان في ما يصل إلى المستخدم وما يصل إلى التطبيق.

تسمح Routes بوضع Worker أمام اسم مضيف مرتبط بخادم موجود أصلاً. إذا كان الكود يقوم بفحص الإذن وحده، فإن تجاوزه يترك الخادم الأصلي ليقرر. قد يرفض الخادم الطلب غير المصرح به إن كان لديه فحص مستقل. وما يحدث لأي عميل بعينه يتوقف على قواعد ذلك الخادم، وهي ليست مذكورة في دليل Cloudflare العام. لذلك يكون السؤال العملي محدداً: ما العمل الأمني الذي يختفي حين لا يعمل الكود؟

يمنع fail closed الطلب الزائد ويمنع معه المستخدم المصرح له. توصي به Cloudflare عندما يكون Worker جزءاً حاسماً من الأمن. يحافظ fail open على طريق الوصول إلى الخادم، لكنه يتخلى عن وظيفة Worker على تلك الطلبات. فريق المنتج يفكر في التوقف، وفريق الأمن في تجاوز الفحص، وفريق المالية في كلفة الخطة. وضع الفشل واحد؛ أصحاب الخسارة ثلاثة.

يتجدد الحد عند منتصف الليل UTC. تلك ساعة معروفة، لكنها لا تدير الفترة التي تسبقها. يظهر جدول Cloudflare أن خطة Paid لا تحمل هذا السقف اليومي المحدد للطلبات. شراء السعة يمكن أن يزيل نقطة التحول، أما الدفاع المستقل على الخادم فيحتاج عملاً آخر. افحص وضع كل مسار ورد الخادم من دون Worker قبل أن ينتهي اليوم المجاني.

المصادر