الإنذار الكاذب هو تنبيه بتوقّف موقع يعمل فعلاً. أسبابه الستة الشائعة: قراءة الموقع بترويسات بوت فيردّ جدار الحماية بتحدٍّ أمني، وعدم متابعة إعادة التوجيه مع الكوكيز، وإعلان العطل من فحص واحد دون إعادة محاولة، وتذبذب سجلات IPv6، ومهلة اتصال قصيرة جداً، وعدّ كود 4xx أو صفحة تحدٍّ توقّفاً كاملاً بدل «حالة متدهورة». العلاج أن تقرأ الأداة الموقع كما يقرؤه المتصفح تماماً.
لماذا الإنذار الكاذب أخطر من غياب المراقبة
حين يوقظك التنبيه ثلاث مرات في أسبوع بلا سبب حقيقي، يتعلّم عقلك تجاهله. وحين يأتي التنبيه الحقيقي في المرة الرابعة، تتجاهله أيضاً. هذه ظاهرة معروفة باسم إجهاد التنبيهات (Alert Fatigue)، وهي السبب الأول لفشل أنظمة المراقبة في المؤسسات: لا لأنها لم ترصد العطل، بل لأن أحداً لم يعد يصدّقها.
السبب 1: الأداة تقرأ الموقع كبوت لا كمتصفح
المواقع خلف Cloudflare أو جدار حماية تطبيقات (WAF) تتصرّف بحسب من يطرق الباب. الطلب الذي يصل بلا ترويسة User-Agent حقيقية، وبلا Accept-Language، وبلا Accept-Encoding، يبدو للجدار آلياً مشبوهاً، فيردّ بصفحة تحدٍّ أو بكود 403. الموقع يعمل تماماً لزوّارك، ويبدو متوقفاً لأداتك. العلاج: ترويسات متصفح كاملة في كل فحص.
السبب 2: عدم متابعة إعادة التوجيه مع الكوكيز
كثير من طبقات الحماية تعمل عبر دورة: تضع كوكي، ثم تعيد التوجيه، ثم تسمح بالمرور. أداة تتبع إعادة التوجيه دون الاحتفاظ بالكوكيز ستدور في حلقة لا تنتهي وتعلن فشلاً. المتصفح لا يفعل ذلك لأنه يحمل الكوكيز معه. أداة المراقبة يجب أن تحاكي هذا السلوك بالضبط، وأن تعامل الحلقة على أنها «متدهور» لا «متوقف».
السبب 3: إعلان العطل من فحص واحد
الشبكات ترتجف. حزمة تضيع، مسار يتغيّر، خادم DNS يتأخر لحظة. الفحص الواحد الفاشل ليس دليلاً كافياً على شيء. القاعدة الهندسية البسيطة: أعِد الفحص مرة ثانية بعد فاصل قصير قبل فتح أي حادثة. هذا وحده يزيل غالبية الإنذارات الكاذبة، وكلفته تأخير الاكتشاف الحقيقي ثوانيَ معدودة فقط.
السبب 4: تذبذب IPv6 — درس تعلّمناه بالطريقة الصعبة
كثير من النطاقات خلف CDN تنشر سجلات IPv4 وIPv6 معاً. لو ثبّتت الأداة عنوان IP واحداً عند أول استعلام، وكان عنوان IPv6 غير مستقر على تلك الشبكة، فسيفشل كل فحص لاحق رغم أن الموقع يعمل عبر IPv4 بلا مشكلة. رأينا هذا في نظامنا نفسه: تثبيت عنوان IP أُضيف كإجراء أمني تسبّب بإنذارات توقّف كاذبة لموقعين خلف Cloudflare. الحل الذي اعتمدناه: أزلنا تثبيت العنوان من مسار المراقبة نهائياً وأبقيناه على مسار الويب هوك وحده مع تفضيل IPv4 — لأن دقّة الإنذار في فحص «يعمل/متوقف» لموقع عام أثمن من حماية ضيقة لا يحتاجها ذلك المسار.
السبب 5: مهلة قصيرة جداً
مهلة اتصال مضبوطة على 3 ثوانٍ ستعلن عطلاً في كل مرة يتأخر فيها موقعك قليلاً تحت الضغط. الموقع البطيء ليس موقعاً متوقفاً، وهما يستحقان تنبيهين مختلفين: «بطء غير طبيعي» شيء، و«لا يستجيب» شيء آخر تماماً. اجعل مهلة إعلان التوقّف كريمة (10 إلى 30 ثانية)، وافصل تنبيه البطء عنها بحدّ مستقل.
السبب 6: تصنيف ثنائي بدل ثلاثي
أنظمة المراقبة التي تعرف حالتين فقط (يعمل / متوقف) مضطرة لتصنيف كل ما هو غامض على أنه توقّف. أضف حالة ثالثة: «متدهور». صفحة تحدٍّ أمني، كود 429، بطء يتجاوز الحدّ، شهادة تنتهي خلال أيام — كلها حالات تستحق ملاحظة لا إيقاظاً. هذا التمييز وحده يقلّص الضجيج إلى النصف تقريباً.
قائمة فحص سريعة لأداتك الحالية
اسأل أداتك ستة أسئلة: هل ترسل ترويسات متصفح كاملة؟ هل تتابع إعادة التوجيه محتفظة بالكوكيز؟ هل تعيد الفحص قبل فتح حادثة؟ هل تفضّل IPv4 عند وجود العنوانين؟ هل تفصل البطء عن التوقّف؟ هل عندها حالة «متدهور»؟ كل «لا» في هذه القائمة هي إنذار كاذب ينتظر موعده.
أسئلة شائعة
موقعي خلف Cloudflare وتصلني إنذارات متكررة، ما الحل؟
تأكد أولاً أن أداتك ترسل ترويسات متصفح كاملة وتتابع الكوكيز. إن استمر الأمر، أضف عناوين خوادم الفحص إلى قائمة السماح في Cloudflare، أو استثنِ مسار فحص مخصصاً من قواعد الحماية.
كم إعادة محاولة هي المناسبة قبل التنبيه؟
واحدة تكفي غالباً وتزيل معظم الضجيج. أكثر من اثنتين يبدأ في تأخير اكتشاف الأعطال الحقيقية بقدر يفوق الفائدة.
هل أوقف التنبيهات أثناء النشر؟
لا توقفها، بل استخدم وضع الصيانة. الفحوص تستمر وتُسجَّل فتحتفظ ببياناتك كاملة، لكن لا تُفتح حادثة ولا يصل تنبيه خلال النافذة.
فريق مراقب
الفريق الذي يبني ويشغّل منصة مراقب: مهندسو المراقبة الذين يديرون محرّك الفحص في الإنتاج، وكتّاب المحتوى التقني العربي. كل ما يُنشر هنا مبني على ما نراه فعلياً في بيانات المراقبة، لا على ترجمة مقالات أجنبية.
تعرّف عليناطبّق ما تعلّمته مع مراقب
راقب موقعك وبريدك تلقائياً وابدأ مجاناً خلال دقائق.
ابدأ مجاناً