تحوّل نقاش واسع على Hacker News في 16 أغسطس إلى درس مهم لفرق التشغيل حول إعداد صغير في Cloudflare. كان مالك موقع يتوقع صفحة بلا JavaScript، ثم أدخل النطاق في مسار Cloudflare، فوجد في HTML الذي وصل إلى المتصفح سكربتاً من static.cloudflareinsights.com/beacon.min.js مع الخاصية data-cf-beacon. عنوان النقاش ربط الأمر بتغيير nameservers، لكن الحد التقني أدق من ذلك: DNS وحده لا يعيد كتابة HTML. الحالة المهمة هي hostname يعمل بوضع proxied، حيث تمر الاستجابة عبر edge لدى Cloudflare.

مخطط يوضح مرور HTML من الخادم الأصلي عبر وكيل طرفي يضيف beacon RUM صغيراً قبل وصوله إلى المتصفح

ما الذي حدث

الإشارة العامة جاءت من نقاش “Tell HN: Cloudflare silently injects its analytics when you switch nameservers”، وكان عند التحقق يملك مئات الأصوات وأكثر من مئة تعليق. المنتدى يوضح حجم الاهتمام، لكنه ليس دليلاً كافياً على سلوك المنتج. الأساس الأدق هو وثائق Cloudflare. وثائق Web Analytics و Observatory RUM تصف beacon JavaScript يمكن حقنه تلقائياً في المواقع proxied. كما أعلن منشور Cloudflare في 17 سبتمبر 2025 أن Web Analytics سيُفعّل افتراضياً للنطاقات المجانية ابتداءً من 15 أكتوبر 2025، مع استثناء زيارات EU و UK. وتشرح الوثائق الحالية إمكان تعطيل الإعداد التلقائي أو استخدام تثبيت يدوي للـ snippet.

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

الفرق بين DNS-only و proxied

الدقة هنا تمنع نصائح خاطئة. سجل DNS-only يحل الاسم فقط ولا يضع Cloudflare داخل مسار HTTPS الذي يحمل HTML، ولذلك لا يستطيع إضافة كود إلى body. أما سجل proxied فيمرر الطلب عبر reverse proxy، حيث يمكن تطبيق WAF، cache، compression، observability، bot checks وتحويلات أخرى قبل إرسال الاستجابة إلى المتصفح.

في لوحة التحكم قد يبدو الفرق مجرد سحابة برتقالية أو رمادية. معمارياً، هو سؤال عن الجهة التي تتحكم في آخر جزء من مسار التطبيق. سواء كان الأمر R2 custom domains أو Pages أو origins عادية أو subdomains، يجب تحديد hostnames التي تعمل proxy والمنتجات المفعلة عليها. إذا كان المزود قادراً على إضافة headers أو عرض challenge أو حقن beacon أو تعديل HTML، فهو جزء من runtime للتطبيق وليس مجرد خدمة أسماء.

ما هي Web Analytics و RUM

تقدّم Cloudflare Web Analytics كتحليلات أداء تراعي الخصوصية. يجمع RUM beacon بيانات من Browser Performance APIs: navigation timing، resource timing، paint timing، Core Web Vitals مثل LCP و CLS و TTFB و INP، ومقاييس أخرى مرتبطة بتحميل الصفحة. وتذكر وثائق data origin أن https://static.cloudflareinsights.com/beacon.min.js هو مصدر السكربت، وأن /cdn-cgi/rum هو endpoint للمواقع proxied.

ينبغي أيضاً تجنب المبالغة. تقول وثائق Cloudflare إن beacon لا يصل إلى cookies أو localStorage أو sessionStorage أو IP address أو IndexedDB، وإن عنوان IP الذي يصل ضمن معالجة HTTP العادية يُطرح في أقرب مركز بيانات ولا يُخزن في قواعد التحليلات الأساسية. لذلك ليس دقيقاً وصف الحادثة بأنها تتبع cookies أو malware. المسألة المهنية هي أن default في البنية التحتية غيّر الصفحة المسلمة للمتصفح.

لماذا غضب المشغلون

المشكلة ليست حجم ملف JavaScript. بعض المواقع تعلن أنها بلا JavaScript. بعض المؤسسات الحكومية والصحية والمالية والتعليمية والإعلامية تحتفظ بجرد للسكربتات الخارجية. وفي مؤسسات كثيرة يجب مراجعة privacy notice وسجلات معالجة البيانات وconsent وCSP وSRI واختبارات الأمن وتقييم المورد قبل ظهور أي كود طرف ثالث في المتصفح على الإنتاج.

هناك أيضاً مسألة الثقة. أنشأ origin تسلسلاً من bytes، لكن المتصفح استلم تسلسلاً آخر. للفرق التي تعتمد على reproducible deployments أو CSP صارم أو نزاهة الموارد أو تدقيق supply chain، فإن edge mutation ليست تفصيلاً صغيراً. إذا اكتشفتها المؤسسة من شكوى مستخدم أو نقاش عام بدلاً من change ticket، فقد فشل مسار التحكم بالتغيير.

ليست حالة ذعر من malware

النقاش المفيد يجب أن يبقى دقيقاً. Cloudflare مزود بنية تحتية كبير، وWeb Analytics منتج رسمي، والحقن التلقائي موضح في الوثائق. هدف beacon هو قياس الأداء الحقيقي للمستخدم، لا سرقة كلمات المرور أو قراءة تخزين المتصفح. تسمية كل سكربت مضاف هجوماً تجعل التحليل أضعف.

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

قضية governance

لم تعد منصات edge أنابيب محايدة. CDN وWAF وbot management وserverless edge وanalytics وتحسين الصور وإخفاء البريد وsecurity challenges ومنتجات الأداء تقف بين origin والمستخدم. إعداداتها الافتراضية قد تغير bytes وheaders وتنفيذ JavaScript وcache والكمون والقياسات وسلوك الأخطاء. هذه مساحة من supply chain.

لذلك تحتاج المؤسسات إلى نموذج تغيير خاص بالـ edge. يجب أن يكون لإجراءات dashboard مالك واضح. وينبغي فحص defaults في الخطط المجانية مثل أي اعتماد إنتاجي آخر. يجب ربط إعلانات الموردين بمناطق zones وhostnames محددة. وأي تحويل تلقائي يغير response body يجب أن يدخل change management عندما يكون الموقع حساساً أو منظماً أو يعلن عدم استخدام JavaScript.

قائمة تدقيق عملية

ابدأ بمقارنة مباشرة. اجلب الصفحة نفسها من origin مباشرة ومن hostname العام، ثم قارن HTML وheaders وجرد السكربتات. ابحث عن static.cloudflareinsights.com وdata-cf-beacon و/cdn-cgi/rum وسكربتات bot management وemail decode وRocket Loader وZaraz وchallenge scripts وروابط الصور المحولة وreporting endpoints غير المتوقعة. لا تفحص الصفحة الرئيسية فقط؛ افحص subdomains أيضاً.

راجع Web Analytics وObservatory وSpeed وZaraz وRules وTransform Rules وPage Rules وWorkers routes وSnippets وBot Management وWAF managed challenges وcache settings. الهدف ليس تعطيل كل شيء، بل معرفة ما الذي يمكنه تغيير الاستجابة المرئية للمتصفح ومن وافق عليه.

استخدم CSP بوعي. يشرح دليل MDN أن Content Security Policy تحدد الموارد التي يمكن للصفحة تحميلها. يمكن أن يمنع script-src صارم beacon غير متوقع، ويمكن أن يكشف Content-Security-Policy-Report-Only الأثر قبل enforcement. لكن CSP لا يغني عن ضبط الإعدادات؛ حجب سكربت أدخله المزود قد ينتج ضجيج تقارير وفقدان قياسات إذا بقيت الميزة مفعلة.

اختبر Cache-Control: public, no-transform عندما يناسب الحالة. تقول FAQ لدى Cloudflare إن وجود هذا header يمنع proxy من تعديل payload الأصلي، وبالتالي لن يحقن beacon تلقائياً. لكنه ليس خياراً عاماً بلا تكلفة؛ قد يعطل تحسينات مفيدة ويحتاج اختباراً على صفحات ممثلة.

قائمة هجرة وخلاصة

قبل نقل نطاق، قرر لكل hostname هل ينبغي أن يكون DNS-only أم proxied. إذا كنت تحتاج CDN cache أو WAF فقد يكون proxy صحيحاً. إذا كان حفظ bytes origin بدقة أهم، فقد يكون DNS-only أو تصميم آخر أفضل. بعد تفعيل proxy، افحص delivered HTML وheaders وCSP reports وperformance beacons وsource maps وservice workers وسكربتات الطرف الثالث والطلبات إلى endpoints الخاصة بالمزود. في مسائل الخصوصية والقانون، قدّم الوقائع إلى compliance أو المستشار القانوني بدلاً من استنتاج حكم قانوني سريع.

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