تقييد المعدل لواجهات API العامة: حصص عملية وتدفقات حظر

ما المشكلة التي يحلها تقييد المعدل فعلاً

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

غالباً ما تبدو "الإساءة" طبيعية في البداية: جامع بيانات يمسح كل نقطة نهاية لنسخ المحتوى، محاولات تخمين كلمات المرور، حشو رموز الدخول ضد مسارات المصادقة، أو عميل خرج عن التحكم يعيد نفس الطلب في حلقة ضيقة بعد مهلة. أحياناً لا يكون أحد يهاجمك على الإطلاق — تحديث تطبيق جوال يُطرح بقواعد كاش خاطئة وفجأة كل جهاز يستعلم API كل ثانية.

المهمة بسيطة: حماية وقت التشغيل والتحكم بالتكاليف دون منع المستخدمين الحقيقيين من أداء عملهم. إذا كان الباكند لديك مُقاساً (حساب استهلاك الحوسبة، قاعدة البيانات، الرسائل، استدعاءات AI)، يمكن لممثل ضوضائي واحد أن يحول ذلك إلى فاتورة حقيقية بسرعة.

تقييد المعدل لوحده غير كافٍ. بدون مراقبة واستجابات خطأ واضحة، تحصل على فشل صامت، عملاء مرتبكون، وتذاكر دعم تبدو كأنها "واجهتكم API تعطل" بينما هي في الواقع تقوم بالتقليل.

حاجز الحماية الكامل عادة يتضمن عدة قطع منفصلة:

• حدود المعدل: سقوف نافذة قصيرة (بالثانية/الدقيقة) لإيقاف الارتفاعات المفاجئة.
• حصص: مخصصات نافذة أطول (يوم/شهر) للحفاظ على توقعية الاستخدام.
• حظر مؤقت (Lockouts): حظر مؤقت لأنماط إساءة واضحة.
• استثناءات: قوائم سماح للتكاملات الموثوقة، الأدوات الداخلية، أو العملاء المميزين.

إذا كنت تبني باكند API على منصة مثل AppMaster، تظل هذه القواعد مهمة. حتى مع شيفرة نظيفة مُولّدة، سترغب في إعدادات افتراضية واقية حتى لا يقوم عميل واحد سيئ بإسقاط خدمتك كلها.

المصطلحات الأساسية: حدود المعدل، الحصص، التقييد، والحظر

تُختلط هذه المصطلحات أحياناً، لكنها تحل مشاكل مختلفة وتبدو مختلفة للمستخدمين.

حدود المعدل، الحصة، والتزامن: ماذا يعني كل منها

حدود المعدل هي حد السرعة: كم عدد الطلبات التي يمكن للعميل إرسالها في نافذة قصيرة (بالثانية، بالدقيقة). الحصة هي ميزانية: إجمالي الاستخدام خلال فترة أطول (يوم/شهر). حد التزامن يحدد عدد الطلبات الجارية في نفس الوقت، وهو مفيد للنهايات المكلفة حتى عندما تبدو معدل الطلبات طبيعي.

أين تضع الحد مهم:

• حسب IP: بسيط، لكنه يعاقب الشبكات المشتركة (مكاتب، مدارس، مزوّدي الجوال).
• حسب المستخدم: ممتاز للتطبيقات المسجّلة، لكن يعتمد على هوية موثوقة.
• حسب مفتاح API: شائع للواجهات العامة، يحدد الملكية ويسهل التواصل.
• حسب نقطة النهاية: مفيد عندما يكون أحد المسارات أثقل بكثير من الآخرين.

التقييد مقابل الحظر، وأين تناسب الحظر المؤقت

التقييد الناعم يبطئ العميل (تأخيرات، سعة انفجار أقل) حتى يتعافى دون كسر سير العمل. الحظر الصارم يرفض الطلبات فوراً، عادة مع HTTP 429.

الحظر المؤقت (lockout) أقوى من 429 العادية. 429 تقول "أعد المحاولة قريباً." الحظر المؤقت يقول "توقف حتى تتحقق حالة ما"، مثل فترة تهدئة، مراجعة يدوية، أو إعادة تعيين المفتاح. احتفظ بالحظر المؤقت لإشارات الإساءة الواضحة (حشو بيانات الاعتماد، الزحف العدواني، المحاولات المتكررة غير الصحيحة للمصادقة)، وليس لارتفاعات المرور العادية.

إذا كنت تبني API بأداة مثل AppMaster، عامل هذه الضوابط كمجموعات منفصلة: حدود نافذة قصيرة للاندفاعات، حصص أطول للتكلفة، وحظر مؤقت فقط للسلوك السيئ المتكرر.

اختيار حدود عملية بدون تخمين جامح

الحدود الجيدة تبدأ بهدف واحد: حماية الباكند مع السماح للمستخدمين العاديين بإكمال عملهم. لا تحتاج إلى أرقام مثالية من اليوم الأول. تحتاج إلى قاعدة آمنة وطريقة لتعديلها.

نقطة بداية بسيطة هي حد لكل مفتاح API يتوافق مع نوع API الذي تُشغله:

• حركة منخفضة: 60-300 طلب في الدقيقة لكل مفتاح
• حركة متوسطة: 600-1,500 طلب في الدقيقة لكل مفتاح
• حركة عالية: 3,000-10,000 طلب في الدقيقة لكل مفتاح

ثم قسّم الحدود حسب نوع النقاط النهائية. عادة ما تكون عمليات القراءة أرخص ويمكن أن تتحمل حدود أعلى. تُغيّر الكتابات البيانات، غالباً تُطلق منطق إضافي، وتستحق حدوداً أشد. نمط شائع هو مثلا 1,000/دقيقة لنهايات GET لكن 100-300/دقيقة لطلبات POST/PUT/DELETE.

حدّد أيضاً النهايات المكلفة وتعامل معها بشكل منفصل. البحث، إنشاء تقارير، الصادرات، رفع الملفات، وأي شيء يصل لعدة جداول أو يُشغّل منطق أعمال كثيف يجب أن يكون له دلو أصغر حتى لو كان بقية API سخيّاً. إذا كان الباكند يستخدم تدفقات عمل مرئية (مثل Business Process flows)، كل خطوة إضافية تمثل عملاً حقيقياً يتضاعف تحت الحمل.

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

أخيراً، قرّر ما يحدث عند تجاوز العميل للحد. معظم الواجهات العامة تُرجع HTTP 429 مع وقت إعادة محاولة واضح. إذا كان العمل آمناً للتأجيل (مثل تصدير)، ففكّر في وضعه في قائمة انتظار بدلاً من حظره الصارم حتى يحصل المستخدمون الحقيقيون على النتائج.

تصميم حصص لكل مفتاح تبدو عادلة

حصص لكل مفتاح عادةً هي النهج الأكثر عدلاً لأنها تطابق كيفية استخدام العملاء لخدمتك: حساب واحد، مفتاح API واحد، مسؤولية واضحة. حدود حسب IP ما زالت مفيدة، لكنها غالباً ما تُعاقب الأبرياء.

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

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

سياسة لكل مفتاح وحيدة البنية:

• اسمح دفعات قصيرة (تحميل صفحات، استيراد دفعات)، ثم قم بفرض معدل ثابت.
• أضف حد يومي لكل مفتاح للحد من الزحف والحلقات الخارجة عن السيطرة.
• زد الحدود حسب الخطة، لكن احتفظ بنفس البنية حتى يبقى السلوك متناسقاً.
• استخدم حد أقل للمفاتيح التي تم إنشاؤها حديثاً حتى تبني سلوكاً جيداً.
• احتفظ بحد IP صغير لالتقاط الفيضانات الواضحة والعمليات السيئة التهيئة.

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

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

إذا بنيت API على منصة مثل AppMaster، يصبح من الأسهل الحفاظ على منطق لكل مفتاح متناسق لأن المصادقة، قواعد العمل، والتعامل مع الاستجابات يعيشون في مكان واحد.

استجابات ورؤوس صديقة للعميل (حتى يتعافى المستخدم)

تقييد المعدل يعمل فقط على المدى الطويل إذا أمكن للعملاء فهم ما حدث وماذا يفعلون بعد ذلك. اهدف لاستجابات مملة ومتوقعة: نفس رمز الحالة، نفس الحقول، نفس المعنى عبر النهايات.

عندما يصل العميل إلى حد، رجّع HTTP 429 (Too Many Requests) مع رسالة واضحة ووقت انتظار محدد. أسرع تحسين هو إضافة Retry-After، لأن حتى العملاء البسطاء يمكنهم التوقف بشكل صحيح.

مجموعة صغيرة من الرؤوس تجعل الحدود مفهومة بذاتها. اجعل الأسماء متسقة وضمّنها في الاستجابات الناجحة (حتى يتمكن العملاء من تنظيم الوتيرة) وفي استجابات 429 (حتى يتعافى العملاء):

• Retry-After: عدد الثواني للانتظار قبل إعادة المحاولة
• X-RateLimit-Limit: عدد الطلبات المسموح بها في النافذة الحالية
• X-RateLimit-Remaining: الطلبات المتبقية في النافذة الحالية
• X-RateLimit-Reset: موعد إعادة ضبط النافذة (بثواني إبوك أو وقت ISO)
• X-RateLimit-Policy: نص قصير مثل "60 requests per 60s"

اجعل جسم الخطأ مُهيكلاً مثل استجابات النجاح. نمط شائع هو كائن خطأ مع code ثابت، message موجه للبشر، ونصائح للتعافي.

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

أخبر العملاء كيف يتراجعون عند رؤية 429s. التراجع الأُسّي (exponential backoff) خيار جيد افتراضياً: انتظر 1 ثانية، ثم 2، ثم 4، وحد أقصى (مثلاً 30-60 ثانية). كن صريحاً أيضاً حول متى يتوقّف العميل عن إعادة المحاولة.

تجنّب المفاجآت قرب الحصص. عندما يقترب مفتاح من الحصة (مثل 80-90% مستخدم)، أدرج حقل تحذير أو رأس حتى يهدئ العملاء قبل أن يبدأوا بالفشل. هذا مهم أكثر عندما يمكن لسكريبت واحد أن يضرب عدة مسارات بسرعة ويحرق الميزانية أسرع من المتوقع.

خطوة بخطوة: خطة نشر بسيطة للحدود والحصص

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

ابدأ بجرد سريع. أدرج كل نقطة نهاية، ثم صنف كل واحدة بحسب التكلفة (CPU، عمل قاعدة البيانات، مكالمات الطرف الثالث) والمخاطر (تسجيل الدخول، استعادة كلمة المرور، البحث، رفع الملفات). هذا يمنعك من تطبيق حد واحد قاسٍ على الجميع.

ترتيب نشر عادة يتجنب المفاجآت:

• وسم النهايات حسب التكلفة والمخاطر، وقرّر أيها يحتاج قواعد أشد (تسجيل الدخول، التصدير الجماعي).
• اختر مفاتيح الهوية بالأولوية: مفتاح API أولاً، ثم معرف المستخدم، وIP كملاذ أخير.
• أضف حدود نافذة قصيرة (كل 10 ثوانٍ أو كل دقيقة) لوقف الاندفاعات والسكريبتات.
• أضف حصص نافذة أطول (ساعة أو يوم) لحد الاستخدام المستمر.
• أضف قوائم سماح للأنظمة الموثوقة والأدوات الداخلية حتى لا يتعرقل عمل التشغيل.

اجعل الإصدار الأول محافظاً. من الأسهل تخفيف القيود لاحقاً من رفع الحظر عن المستخدمين الغاضبين.

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

إذا بنيت API على AppMaster، خطط لهذه القواعد جنباً إلى جنب مع نهاياتك ومنطق الأعمال حتى تطابق الحدود التكلفة الحقيقية لكل سير عمل.

سير حظر يوقف الإساءة بدون دراما

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

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

سُلّم تصاعدي بسيط

استخدم مجموعة خطوات صغيرة سهلة الشرح والتنفيذ:

• تحذير: أخبر العميل أنه يقترب من الحدود، ومتى يعاد الضبط.
• تباطؤ: أضف تأخيرات قصيرة أو حدود بالثانية أصغر لذلك المفتاح.
• حظر مؤقت: حظر لدقائق (ليس لساعات) مع وقت فك قفل محدد.
• حظر أطول: فقط بعد اندفاعات متكررة عبر نوافذ متعددة.
• مراجعة يدوية: للأنماط التي تبدو متعمدة أو متكررة.

اختيار ما تُقفل مهم. حسب مفتاح API عادةً هو الأعدل لأنه يستهدف المستدعي، لا الجميع خلف شبكة مشتركة. حسب الحساب يساعد عندما يدير المستخدم تدوير المفاتيح. حسب IP يمكن أن يساعد مع الحركة المجهولة، لكنه يسبب إيجابيات كاذبة مع NATs والمكاتب ومزودي الجوال. عندما تكون الإساءة خطيرة، اجمع الإشارات (مثلاً قفل المفتاح وطلب فحص إضافي لذلك الـ IP)، لكن حافظ على نصف القصف صغير.

اجعل الحظر الزمني بسيط القواعد: "محظور حتى 14:05 UTC" و"يُعاد بعد 30 دقيقة من السلوك الجيد". تجنّب الحظر الدائم للأنظمة الآلية. عميل معطّل يمكن أن يدخل حلقة ويستهلك الحدود بسرعة، لذا صمم العقوبات لتتلاشى عبر الزمن. فترة منخفضة مستمرة تقلل مستوى العقوبة.

إذا كنت تبني API في AppMaster، فإن هذا السُلّم يتوافق جيداً مع عدّادات مخزنة بالإضافة إلى Business Process يقرر السماح، التباطؤ، أو الحظر ويكتب وقت فك القفل للمفتاح.

للمنتهكين المتكررِين، احتفظ بمسار مراجعة يدوية. لا تجادل مع المستخدمين. اطلب معرفات الطلب، الطوابع الزمنية، واسم مفتاح API، ثم قرّر بناءً على الأدلة.

الأخطاء الشائعة التي تسبّب إيجابيات كاذبة

الإيجابيات الكاذبة هي عندما تمنع دفاعاتك المستخدمين الطبيعيين. عادة تحدث عندما تكون القواعد بسيطة جداً مقارنة بكيفية استخدام الناس الحقيقية لواجهة API.

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

تقييد على أساس IP فقط فخ شائع آخر. كثير من المستخدمين الحقيقيين يشاركون IP عام واحد (مكاتب، مدارس، مزوّدي الجوال، NAT سحابي). مستخدم ثقيل واحد يمكن أن يعيق الجميع ويبدو كأنها انقطاعات عشوائية. فضّل حدود كل مفتاح API أولاً، ثم استخدم IP كإشارة ثانوية للإساءة الواضحة.

تعطل المكونات يمكنه أيضاً خلق إيجابيات كاذبة. إذا كان مخزن محدد الحدون (limiter store) معطلاً، "الفشل مغلق" قد يطيح بواجهتك كلها. "الفشل مفتوح" قد يدعو لقفزة تأخذ الباكند كله. اختر سلوكاً واضحاً احتياطيًا: احتفظ بسقف طوارئ صغير على الحافة، وتدهور بلطف على النهايات غير الحرجة.

تعامل العميل مهم أكثر مما يتوقع معظم الفرق. إذا أعدت 429 عامة بدون رسالة واضحة، يعيد المستخدمون المحاولة بشدة ويزيدون الحظر. دائماً أرسل Retry-After، واجعل نص الخطأ محدداً ("عدد الطلبات كبير لهذا المفتاح. حاول مرة أخرى بعد 30 ثانية.").

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

قائمة فحص سريعة لتفادي الإيجابيات الكاذبة:

• فصل الحدود للنهايات المكلفة مقابل الرخيصة
• تحديد القيد الأساسي حسب مفتاح API وليس فقط حسب IP
• سلوك معرف عند عدم توفر محدد الحدون
• استجابات 429 واضحة مع Retry-After
• حدود موثقة ومعلنة قبل التنفيذ

إذا بنيت API على AppMaster، غالباً ما يعني هذا تعيين حدود مختلفة لكل نقطة نهاية وإرجاع أحمال خطأ متسقة حتى يتراجع العملاء دون تخمين.

المراقبة والتنبيه التي تفيد بالفعل

تقييد المعدل يعمل فقط إذا رأيت ما يحدث في الوقت الحقيقي. الهدف ليس التقاط كل قفزة، بل ملاحظة الأنماط التي تتحول إلى انقطاعات أو عملاء غاضبين.

ابدأ بمجموعة صغيرة من الإشارات التي تشرح كل من الحجم والنوايا:

• الطلبات في الدقيقة (إجمالي وعلى مستوى كل مفتاح)
• معدل 429 (الطلبات المحدودة) ومعدل 5xx (مؤشرات ألم الباكند)
• اندفاعات 401/403 المتكررة (مفاتيح خاطئة، حشو بيانات الاعتماد، عملاء معدّلين)
• أعلى النهايات حسب الحجم وبحسب التكلفة (استعلامات بطيئة، صادرات ثقيلة)
• نقاط نهاية جديدة أو غير متوقعة تظهر في الـ Top 10

لفصل "الحركة السيئة" عن "أرسلنا شيئاً جديداً"، أضف سياقاً إلى لوحات القيادة: وقت النشر، تغييرات Feature Flag، حملات تسويقية. إذا قفزت الحركة بعد إصدار وبقي خليط 429/5xx صحياً، فغالباً إنه نمو لا إساءة. إذا كان القفز مركزاً في مفتاح واحد، نطاق IP واحد، أو نقطة نهاية مكلفة، اعتبره مريباً.

التنبيهات يجب أن تكون مملة. استخدم عتبات مع فترات تهدئة حتى لا تُوقظك كل دقيقة لنفس الحدث:

• معدل 429 فوق X% لمدة 10 دقائق، أرسل إشعار مرة في الساعة
• 5xx فوق Y% لمدة 5 دقائق، أطلق تنبيه فوراً
• مفتاح واحد يتجاوز الحصة بنسبة Z% لمدة 15 دقيقة، افتح تحقيق
• اندفاعات 401/403 فوق N/دقيقة، علّم على احتمال إساءة

عندما ينطلق تنبيه، احتفظ بملاحظة حادث قصيرة: ماذا تغيّر، ماذا رأيت (أعلى المفاتيح/النهايات)، وماذا عدّلت (حدود، كاش، حظر مؤقت). بمرور الوقت، تصبح تلك الملاحظات كتاب اللعب الخاص بك.

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

قائمة فحص سريعة: فحوصات منطقية قبل وبعد الإطلاق

إعداد جيد ممل عندما يعمل. هذه القائمة تلتقط المشاكل التي عادة تخلق إيجابيات كاذبة أو تترك فجوات واضحة.

قبل إصدار نقطة نهاية جديدة

نفذ هذه الفحوص في البيئة التجريبية ومرة أخرى فور الإطلاق:

• الهوية: تأكد أن المحدد يقيس الشيء الصحيح (مفتاح API أولاً، ثم المستخدم أو IP كملاذ)، وأن المفاتيح المدورة لا ترث عقوبات سابقة.
• الحدود: اضبط حصة افتراضية لكل مفتاح، ثم عدّل اعتماداً على تكلفة النهاية (قراءة رخيصة مقابل كتابة مكلفة) والاندفاعات المتوقعة.
• الاستجابات: رجّع حالة واضحة ومعلومة التعافي (زمن إعادة المحاولة، الميزانية المتبقية، رمز خطأ ثابت).
• السجلات: سجّل من تم تحديده (مفتاح/مستخدم/IP)، أي مسار، أي قاعدة فعلت، ومعرّف طلب للدعم.
• تجاوز: احتفظ بقائمة سماح طوارئ لمراقباتك والتكاملات الموثوقة.

إذا بنيت على AppMaster، عامل كل نقطة نهاية جديدة كقرار فئة تكلفة: استعلام بسيط يمكن أن يكون سخيّاً، بينما أي شيء يُطلق منطق أعمال ثقيل يجب أن يبدأ بقواعد أشد.

عند وقوع حادث (إساءة أو قفزة مفاجئة في الحركة)

حِمِّن الباكند مع السماح للمستخدمين الحقيقيين بالتعافي:

• ارفع السقوف مؤقتاً فقط للنهايات الأقل خطورة (غالباً القراءات) وراقب معدلات الخطأ.
• أضف قائمة سماح قصيرة للعملاء المعروفين الجيدين أثناء التحقيق.
• شدد النهايات الخطرة بدل تخفيض الحدود العامة.
• فعّل هوية أقوى (اطلب مفاتيح API، قلل الاعتماد على IP) لتجنب حظر الشبكات المشتركة.
• التقط عينات: أعلى المفاتيح، أعلى الـ IPs، وكيل المستخدم، ونماذج الحمولة.

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

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

سيناريو نموذجي: حماية API عامة حقيقية دون كسر المستخدمين

تخيّل أنك تدير API عامة يستخدمها تطبيقان: بوابة عملاء (حركة عالية، ثبات) وأداة إدارية داخلية (حركة منخفضة، لكن إجراءات قوية). كلاهما يستخدم مفاتيح API، والبوابة تحتوي أيضاً على نقطة تسجيل دخول للمستخدمين النهائيين.

بعد الظهر، شريك يطلق تكاملاً معطلاً. يبدأ بإعادة المحاولات في حلقة ضيقة، مرسلاً 200 طلب في الثانية من مفتاح API واحد. بدون دروع، ذلك المفتاح يطغى على الباقي.

حدود لكل مفتاح تحتوي نصف القصف. المفتاح المعطل يصل إلى سقفاته في الدقيقة، يتلقى استجابة 429، ويبقى بقية عملائك يعملون. قد يكون لديك أيضاً حد منفصل منخفض للنهايات المكلفة (مثل الصادرات) حتى لا يستطيع حتى "حركة مسموح بها" إثقال قاعدة البيانات.

في الوقت نفسه، تبدأ محاولة تخمين كلمات مرور تضرب نقطة المصادقة. بدلاً من حظر كامل نطاق IP (مما قد يؤثر على مستخدمين حقيقيين خلف NAT)، تبطئها ثم تقفلها استناداً إلى السلوك: محاولات فاشلة كثيرة لكل حساب بالإضافة إلى نشاط عبر IP في نافذة قصيرة. المهاجم يتلقّى فترات انتظار متصاعدة ثم قفل مؤقت.

العميل الحقيقي الذي أخطأ في كتابة كلمة المرور عدة مرات يمكنه التعافي لأن استجاباتك واضحة ومتوقعة:

• 429 مع Retry-After حتى يعرف العميل متى يعيد المحاولة
• قفل مؤقت قصير (مثلاً 10-15 دقيقة)، وليس حظر دائم
• رسائل خطأ متسقة لا تكشف ما إذا كان الحساب موجوداً

لتأكيد الحل، تراقب بعض المقاييس:

• معدل 429 حسب مفتاح ونقطة نهاية
• معدل فشل المصادقة وعدّ حالات القفل
• P95 زمن الاستجابة وCPU قاعدة البيانات أثناء الحادث
• عدد المفاتيح المتأثرة (يجب أن يكون صغيراً)

هذا شكل تقييد معدل واقٍ عندما يدرء باكندك دون معاقبة المستخدمين الطبيعيين.

الخطوات التالية: ضع سياسة صغيرة وكررها

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

الإصدار الأول المتين عادةً يتضمن ثلاثة أجزاء:

• خط أساس لكل مفتاح (طلبات في الدقيقة) يغطي معظم النهايات
• حدود أشد على النهايات المكلفة (بحث، تصديرات، رفع ملفات، تقارير معقّدة)
• استجابات 429 واضحة مع رسالة قصيرة تخبر العملاء ماذا يفعلون بعد ذلك

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

اكتب السياسة بلغة بسيطة حتى يتمكن الدعم من شرحها بدون مساعدة هندسية. أدرج ما الذي يُحدّ (حسب مفتاح API، حسب IP، حسب الحساب)، نافذة إعادة الضبط، وكيف يمكن للعميل التعافي.

إذا كنت تطبّق هذا أثناء بناء باكند جديد، AppMaster يمكن أن يكون مناسباً عملياً: تستطيع إنشاء APIs، تعريف تدفقات أعمال (بما في ذلك العدّادات وقرارات الحظر)، ثم نشرها إلى مزودي سحابة أو تصدير الشيفرة المولّدة عندما تحتاج إلى سيطرة كاملة.