«هل أضع CDN أمامه؟» هو أول سؤال يطرحه معظم الناس بعد شراء خادم خارجي (offshore)، ولا توجد له إجابة واحدة، لأنه في الحقيقة سؤالان يرتديان معطفًا واحدًا. امتصاص هجوم والبقاء غير قابل للعثور عليه مشكلتان مختلفتان بحلول مختلفة، والترتيب الذي يحل إحداهما قد يُبطل الأخرى بصمت.
هذا الالتباس مكلف في الاتجاهين. يضع البعض CDN أمريكيًا كبيرًا أمام محتوى اختاروا من أجله استضافة تتجاهل DMCA، فيعيدون إلى الصورة تحديدًا ذلك النوع من الوسيط الذي كانوا يتجنبونه بمكتب شكاوى خاص به. ويتجاهل آخرون الأمر برمّته، فيتعرضون لموجة على طبقة التطبيق لم تُصمَّم الفلترة على مستوى الشبكة أصلًا لرصدها، فيستنتجون أن الحماية من DDoS كانت وهمًا. يفصل هذا الدليل بين المشكلتين، ويوضح ما تفعله كل طبقة فعليًا، ويخصص معظم مساحته للجزء الذي يحسم النتيجة في الحالتين: الطرق الست التي يتسرب بها عنوان الخادم الأصلي حتى حين يكون كل شيء آخر مُعدًّا بشكل صحيح.
مشكلتان تبدوان كمشكلة واحدة
أي شيء تضعه أمام الخادم يؤدي إحدى مهمتين: إبعاد هجوم عنه، أو إبقاء عنوانه مجهولًا. تتداخل المهمتان بما يكفي لتُخلَطا، وتختلفان بما يكفي لأن حل المشكلة الخطأ يكون إهدارًا للمال.
| ما الذي يقلقك | ما الذي يحله فعليًا | ما الذي لا يحله |
|---|---|---|
| فيضان حجمي يملأ أنبوبك (الطبقتان 3 و4) | فلترة على حافة الشبكة عند المضيف، مشمولة في كل باقة هنا | لا شيء تثبّته على الخادم — فبحلول ذلك الوقت يكون الأنبوب قد امتلأ بالفعل |
| فيضان طلبات على طبقة التطبيق تبدو حقيقية (الطبقة 7) | CDN أو WAF، وتخزين مؤقت، وحدود لمعدل الطلبات، ونقاط نهاية أقل تكلفة | فلترة الحزم، التي ترى HTTP صالحًا وتمرره |
| يجب ألا يستطيع أحد الوصول إلى الجهاز مباشرة | واجهة أمامية (CDN أو عقدة خاصة بك) مع جدار حماية لا يقبل إلا منها | CDN وحده، إذا كان الخادم الأصلي ما زال يجيب على الإنترنت بأكمله |
| يجب ألا يعرف أحد من يديره | تسجيل بلا KYC، وخصوصية الدفع، وانضباط الحساب | أي قدر من البنية التحتية — فهذه مسألة هوية |
| يجب أن يصمد المحتوى أمام الشكاوى | الولاية القضائية، ومضيف لا يتصرف بناءً عليها | CDN، الذي يضيف قناة شكاوى بدلًا من إزالة واحدة |
اقرأ الصف الأخير مرتين، لأنه الصف الذي يُوقِع الناس في الخطأ. كل شيء آخر في هذه الصفحة هندسة. أما ذلك الصف فليس كذلك.

ما يفعله مضيفك بالفعل، وأين يتوقف
الفلترة على الطبقتين 3 و4 مشمولة في كل باقة نبيعها، دون أي تكلفة إضافية، وتعمل عند حافة الشبكة لا على خادمك — وهذا هو المكان الوحيد الذي يمكنها العمل فيه، لأن رابطًا صاعدًا مشبَعًا لا يمكن إصلاحه بأي شيء يعمل خلفه. النطاق الترددي غير مقيَّد بعدّاد، فلا يتحول الهجوم إلى فاتورة. بالنسبة لغالبية ما يسميه الناس «هجوم DDoS»، هذه هي القصة كاملة.
ما لا تراه هو النوع الآخر. خمسمئة طلب في الثانية إلى نقطة نهاية بحث من أربعين ألف عنوان سكني ليست حركة مرور مشوَّهة؛ إنها حركة مرور. اتصالات Slowloris التي تُرسل رأسًا كل بضع ثوانٍ مؤدَّبة، فرادى. نموذج تسجيل دخول يُقصف بأجسام POST حقيقية لا يمكن تمييزه على مستوى الحزمة عن يوم اثنين مزدحم. لا تفيد هنا أي فلترة حزم، لأنه لا خلل في الحزم نفسها.
يوجد اتجاه واحد لحركة المرور نتصرف بشأنه فعليًا، ويستحق ذِكره بوضوح: الهجمات والبريد المزعج الجماعي الصادر من شبكتنا قد يُوجَّه إلى اللاشيء (null-routed) للحفاظ على سلامة بقية البنية التحتية. هذا إجراء تشغيلي لا يتعلق بالمحتوى — وهو التمييز الذي يوضحه دليل الاستضافة المتجاهلة لـDMCA لدينا بتفصيل أكبر.
ما الذي يخفيه CDN، ومكتب الشكاوى الذي ترثه معه
الآلية بسيطة وفعّالة فعلًا. يُحلَّل نطاقك إلى عناوين المزوّد، ويتصل العملاء بها، ويجلب المزوّد المحتوى من خادمك الأصلي. لا يظهر العنوان الحقيقي أبدًا في اتصال العميل، فلا يمكن لمن يعرف النطاق فقط أن يهاجمه. الحيلة نفسها هي سبب نجاح واجهة CDN مع البروكسيات المقاومة للرقابة: يرى الرقيب حركة مرور متجهة إلى عنوان لا يستطيع تحمّل حجبه.
ثلاثة أشياء تأتي معه، ولا شيء منها مخفي في الهامش:
- الحافة تُنهي جلسة TLS الخاصة بك. تكون حركة المرور نصًا صريحًا داخل شبكة المزوّد بحكم التصميم — فهذه هي الطريقة التي يعمل بها التخزين المؤقت والفلترة. ما يكتبه مستخدموك يصل إلى طرف ثالث قبل أن يصل إليك.
- قناة شكاوى لم تكن موجودة من قبل. يمكن تقديم الشكاوى ضد CDN مباشرة، ويرد CDN عليها: بإحالتها إليك، أو بذكر اسم مزوّد الاستضافة لديك، أو بإنهاء حسابك. إذا كان سبب اختيارك استضافة خارجية أن الشكاوى لا تصل إلى نتيجة، فإن وضع وسيط أمريكي في المقدمة يعيد وصل السلسلة التي دفعت لتقطعها.
- حساب. عنوان بريد إلكتروني، ووسيلة دفع، وغالبًا رقم هاتف، مرتبطة بنطاقك ومحفوظة إلى أجل غير مسمى. المزيد عن هذا أدناه، لأنه عادة ما يكون الحلقة الأضعف في الترتيب كله.
لا شيء من هذا يجعل CDN خيارًا خاطئًا. بل يجعله قرارًا ذا وجهين: ممتاز لمتجر أو تطبيق له مستخدمون حقيقيون وضغط حقيقي على الطبقة 7، ومعاكس للهدف فعليًا للنشر الذي يجذب طلبات الإزالة. إجابتنا على هذا السؤال في صفحة الاستضافة المتجاهلة لـDMCA كانت دائمًا النسخة المختصرة من هذا: من أجل مقاومة الإزالة، استخدم الفلترة على مستوى الشبكة التي تملكها بالفعل وتجاوز CDN.
الطرق الست التي يتسرب بها عنوان الخادم الأصلي رغم كل شيء
هذا هو القسم المهم، لأن الإخفاء ليس منتجًا تشتريه — بل خاصية إما أن تحافظ عليها أو تفقدها، عادة خلال أيام، بسبب واحد من ستة أشياء. تُكتشف الخوادم الأصلية كل يوم خلف إعدادات CDN سليمة تمامًا.
- سجلات Certificate Transparency. كل شهادة موثوقة عمومًا صادرة لنطاقك تُنشر في سجلات عامة ودائمة وقابلة للبحث خلال دقائق. هذه السجلات لا تنشر عنوانك؛ بل تنشر أسماء مضيفيك —
staging، وmail، وvpn، والنطاق الفرعي الذي أنشأته مرة واحدة في 2024. كل واحد منها مرشّح للتحليل، وسجل واحد فقط لا يشير إلى الواجهة الأمامية ينهي المحاولة. - تاريخ DNS. تؤرشف خدمات DNS السلبي كل عنوان تحلّل إليه نطاقك على الإطلاق. الانتقال خلف CDN لاحقًا لا يلغي نشر ما سُجِّل بالفعل — يجب أن يبدأ الإخفاء قبل أن يتحلّل النطاق للمرة الأولى، وإلا فأنت بحاجة إلى عنوان جديد، لا واجهة أمامية جديدة.
- السجلات التي لا يمكن تمريرها عبر بروكسي، والسجلات التي نسيتها. يجب أن تشير خوادم تبادل البريد إلى شيء يمكن الوصول إليه. وكذلك سجل
AAAAالمتروك حين تكون قد مرّرت IPv4 فقط عبر البروكسي، أو اسم مضيف FTP أو لوحة تحكم قديم، أو نطاق شامل (wildcard)، أو مضيف تطوير «مؤقت» عمره الآن ثلاث سنوات. - أي شيء يرسله الخادم. يحمل البريد الصادر من الخادم الأصلي عنوانه في ترويسات
Received— ورسالة إعادة تعيين كلمة المرور إفصاح ذاتي. تصل Webhooks، وعمليات جلب الصور الصادرة، ومعاينات الروابط، وpingbacks، وفحوصات التحديث، ومُبلِّغات الأعطال جميعها من العنوان الحقيقي، وأي شخص يستطيع جعل تطبيقك يتحدث إلى مضيف يتحكم فيه يتعرّف عليه. - فحص الإنترنت بأكمله. يُفحص كل عنوان IPv4 ويُفهرَس باستمرار بواسطة خدمات عامة، ويمكن الاستعلام عن النتائج خلال ثوانٍ. إذا كان خادمك الأصلي يجيب على المنفذ 443 بشهادتك، أو يقدّم صفحتك الرئيسية لأي ترويسة Host، فإن مطابقته استعلام واحد مقابل بصمة جسم الرسالة، أو بصمة الشهادة، أو بصمة أيقونة الموقع (favicon). هذه هي الطريقة التي يُعثر بها على معظم الخوادم الأصلية، ولا تكلّف الباحث عنها شيئًا.
- التطبيق الذي يتحدث عن نفسه. عناوين URL المطلقة وإعادة التوجيه التي تحتوي العنوان الخام، ونقاط نهاية الحالة أو المقاييس المتروكة مفتوحة، وتتبعات مكدس مفصّلة تسمّي مضيفين داخليين، وترويسات تكشف الخلفية (backend)، والمضيف الظاهري الافتراضي الذي يقدّم موقعك بسرور لأي شخص يطلبه بالعنوان.
حجب الخادم الأصلي بحيث لا تصل إليه إلا الواجهة الأمامية
الإخفاء الذي يعتمد على ألا يخمّن أحد العنوان ليس إخفاءً. لا يصمد الترتيب إلا حين يرفض الخادم الأصلي التحدث إلى أي طرف غير الواجهة الأمامية، بحيث يصبح تسرّب العنوان إزعاجًا لا حدثًا.
- ارفض افتراضيًا، ثم اسمح للواجهة الأمامية. اقبل المنفذين 80 و443 فقط من نطاقات العناوين المنشورة لدى المزوّد، وحدّث تلك القائمة تلقائيًا — فالنطاقات تتغير، والقائمة القديمة تفشل بالفتح أو بالإغلاق في أسوأ لحظة. كل شيء آخر، بما في ذلك SSH، مكانه نفق أو عنوان إدارة، كما في قائمة تحصين الساعة الأولى لدينا.
- وثّق هوية الواجهة الأمامية. شهادات العميل بين CDN وخادمك الأصلي — تُعرف عادة بسحب الخادم الأصلي الموثَّق (authenticated origin pulls) — تعني أن عنوانًا صحيحًا مع ترويسة Host صحيحة لا يحصلان على شيء دون الشهادة.
- الأفضل: بلا منافذ واردة إطلاقًا. نفق صادر فقط من الخادم الأصلي إلى الحافة، سواء كان موصل CDN الخاص به أو WireGuard إلى عقدة تشغّلها أنت، يعني أن الخادم الأصلي لا يستمع أبدًا على واجهة عامة. لا يمكن للفحص أن يجد ما لا يجيب، وهذه هي أقوى نسخة من هذا الترتيب على الإطلاق.
- مضيف ظاهري واحد، وترويسة Host واحدة. يجب ألا يعيد الخادم الافتراضي أي شيء مفيد. إذا كان موقعك يُحمَّل بالعنوان، فسيُطابقه ماسح خلال أسبوع.
- انقل البريد بعيدًا عن خادم الويب الأصلي. يجب أن يكون البريد قابلًا للوصول وأن يعرّف عن نفسه؛ أبقه على جهاز خاص به، كما يفترض دليل خادم البريد.
- تحقق من الخارج. كل فحص في هذه القائمة عديم المعنى إذا شُغِّل من الخادم نفسه. اختبر من شبكة ليست شبكتك.
عقدة أمامية خاصة بك بدلًا من CDN
يُتجاهل الخيار الثالث لأنه بلا ميزانية تسويقية: VPS صغير كواجهة عامة، ونفق مشفّر يعود إلى الجهاز الذي يحمل البيانات، وnginx أو HAProxy يمرران حركة المرور بينهما. من الخارج يبدو الأمر كأي خادم ويب. أما الخادم الحقيقي فيقع في مكان آخر، بلا منافذ واردة إطلاقًا.
ما تحصل عليه هو إخفاء دون أي طرف آخر في الترتيب — لا حساب لدى طرف ثالث، ولا مكتب شكاوى خارجي، ولا غريب يُنهي جلسة TLS الخاصة بك. كما تحصل على تقسيم للولاية القضائية يصعب شراؤه بطريقة أخرى: الواجهة حيث المستخدمون، والبيانات حيث يناسبك القانون، تختارهما من بين مواقعنا السبعة. ولأنه لم تُربط أي هوية عند التسجيل، فإن الواجهة قابلة للتخلص منها — يُستبدل عنوان محروق خلال دقائق بدلًا من التفاوض عليه.
ما لا تحصل عليه هو سعة anycast. لعقدة واحدة سعة عقدة واحدة، وبينما تحمي فلترتنا على مستوى الشبكة هذه العقدة تمامًا كما تحمي أي خادم آخر، فإن هجومًا حجميًا كبيرًا فعلًا هو مبارزة نطاق ترددي تفوز بها شبكة عالمية. الموقف الصادق: العقدة الأمامية هي الإجابة الصحيحة لإخفاء خلفية ثقيلة أو مكلفة — مصفوفة تخزين، أو جهاز GPU، أو خادم بريد، أو قاعدة بيانات — ولتقسيم الولايات القضائية. إنها ليست بديلًا عن CDN تحت ضغط مستمر على الطبقة 7.
الاختيار في جدول واحد
| وضعك | الترتيب | السبب |
|---|---|---|
| نشر يجذب إشعارات إزالة | مباشر، بلا CDN، في ولاية قضائية مختارة عن قصد | يضيف CDN مكتب شكاوى تعمّد مضيفك ألا يملكه |
| متجر أو SaaS بمستخدمين حقيقيين وضغط على الطبقة 7 | CDN في المقدمة، والخادم الأصلي محجوب على نطاقاته فقط | الطبقة 7 هي المشكلة التي بُني CDN فعليًا لحلها |
| نقطة نهاية للتحايل في دولة خاضعة للرقابة | واجهة CDN | يرى الرقيب عنوانًا لا يستطيع تحمّل حجبه |
| حركة مرور كبيرة من محتوى ثابت أو وسائط | CDN لتفريغ التخزين المؤقت | النطاق الترددي وزمن الاستجابة هما الهدف؛ والإخفاء أثر جانبي |
| إخفاء الهوية هو المتطلب الأساسي | عقدة أمامية خاصة بك، أو لا شيء في المقدمة | حساب لدى طرف ثالث سجل هوية لم يكن موجودًا من قبل |
| خلفية ثقيلة تستحق الإخفاء | عقدة أمامية مع نفق صادر فقط | الجهاز المكلف لا يظهر أبدًا على الإنترنت العام |
الحساب عادة هو الحلقة الأضعف
تأمّل ما يحدث حين تكون البنية التحتية مثالية والأوراق ليست كذلك. دُفع ثمن الخادم بعملة Monero، دون وثائق هوية ودون عنوان بريد إلكتروني — الترتيب الموصوف في صفحات الاستضافة بلا KYC لدينا. ثم يُفتح حساب CDN ببطاقة، وعنوان شخصي، ورقم هاتف، مع إدراج النطاق الذي يحميه. ذلك الحساب سجل هوية أقوى وأكثر ديمومة من أي شيء على الخادم، تحتفظ به شركة تستجيب لأوامر الاستدعاء القضائي، ويُبطل خصوصية الدفع كليًا.
الإصلاح ليس معقدًا، لكن من السهل نسيانه: إذا كان إخفاء الهوية هو الهدف، فإما أن تملك الواجهة الأمامية بنفسك، أو يكون الحساب أمامها قابلًا للتخلص منه وغير قابل للعزو إليك، تمامًا كالخادم خلفه. يتناول أمن التشغيل للخادم هذا الانضباط بشكل صحيح، وإجابتنا الصادقة عن إخفاء الهوية في الاستضافة الخارجية صريحة بشأن أي حلقات السلسلة تنكسر عادة أولًا. وهي كادت ألا تكون أبدًا الحلقات التقنية.
تدقيق مدى انكشاف خادمك خلال عشر دقائق
كل عنصر أدناه هو شيء سيتحقق منه طرف مهتم خلال الدقائق الأولى. نفّذها بنفسك، من جهاز ليس الخادم، قبل أن تحتاج إلى الإجابات.
- اسرد كل اسم مضيف أصدرت له شهادة على الإطلاق. ابحث عن نطاقك الرئيسي في محرك بحث Certificate Transparency وحلّل كل نتيجة. أي نتيجة لا تشير إلى الواجهة الأمامية تسرّب، بما في ذلك مضيفين لم تعد تستخدمهم.
- اقرأ تاريخ DNS الخاص بك. يُظهر استعلام DNS سلبي العناوين التي تحلّل إليها نطاقك قبل CDN. إذا كان خادم الأمس الأصلي هو نفسه خادم اليوم الأصلي، فإن الإخفاء لم يكن حقيقيًا قط.
- اسأل الخادم الأصلي مباشرة.
curl -sI --resolve example.com:443:198.51.100.10 https://example.com/— إذا أجاب الموقع، فإن جدار حمايتك لا يقيّد الواجهة الأمامية، ويستطيع أي شخص لديه عنوان مرشّح تأكيد ذلك بطلب واحد. - اسأله بفظاظة. يجب ألا يُرجع
curl -skI https://198.51.100.10/أي شيء يمكن التعرف عليه. المضيف الظاهري الافتراضي الذي يقدّم صفحتك الرئيسية هو الخطأ الوحيد الأكثر شيوعًا في هذه الصفحة. - افحص كل نوع سجل، لا نوع A فقط.
dig +short AAAA example.com، وdig +short MX example.com، والأمر نفسه لكل نطاق فرعي كشفته سجلات الشفافية. IPv6 المتروك دون بروكسي كلاسيكي. - أرسل بريدًا لنفسك من التطبيق. فعّل إعادة تعيين كلمة مرور واقرأ سلسلة
Receivedكاملة. إذا كان عنوان الخادم الأصلي موجودًا فيها، فهو موجود في كل رسالة أرسلتها على الإطلاق. - تأكد من إغلاق المنافذ. من شبكة غير ذات صلة، يجب أن يُظهر
nmap -Pn -p80,443 198.51.100.10حالة filtered لا open. - ابحث في الماسحات. ابحث عن بصمة شهادتك وبصمة أيقونة صفحتك الرئيسية (favicon) في فهرس فحص إنترنت عام. إذا كان خادمك الأصلي مفهرَسًا، فهكذا سيُعثر عليه.
حين يكون العنوان محروقًا بالفعل
افترض أنه سيبقى محروقًا. العنوان الذي ظهر في DNS السلبي وفي فهارس الفحص أصبح في سجل عام دائم، ولا يوجد تغيير في الإعدادات يسحبه. الاستجابة آلية لا ذكية.
- أصلح التسرب أولًا. التبديل إلى عنوان جديد دون إغلاق الثغرة يعيد إنتاج الموقف خلال أيام، وتكون قد أنفقت عملية ترحيل دون أن تتعلم شيئًا.
- ثم بدّل العنوان. انشر بديلًا — في ولاية قضائية مختلفة إذا كان السبب قانونيًا لا تقنيًا — واستعد النسخة الاحتياطية، وحوّل الخدمة. ولأنه لم تُربط أي هوية بالخادم الأول، فهذه بداية جديدة لا مفاوضة، وهي العائد العملي غير البرّاق لشراء خوادم بلا تاريخ حساب.
- جهّز التحويل قبل الطارئ. مدة صلاحية DNS (TTL) قصيرة، وإعدادات يمكنك إعادة نشرها من مستودع، واستعادة مُختبَرة، تحوّل عصرًا سيئًا إلى عشرين دقيقة. لا أحد يرتّب هذا أثناء الهجوم.
- أوقف العنوان القديم بالشكل الصحيح. لا تُبقِ الخادم القديم يخدم المحتوى نفسه على العنوان القديم؛ فذلك تأكيد حي لأي شخص يراقب، ويُبقي السجل حديثًا.
النسخة المختصرة
الفلترة على مستوى الشبكة تتعامل مع الهجمات الحجمية، وتأتي مع الخادم، ولا تكلّف شيئًا إضافيًا. CDN يتعامل مع طبقة التطبيق ويخفي الخادم الأصلي، بثمن وسيط يُنهي جلسة TLS الخاصة بك، ويرد على الشكاوى، ويعرف من أنت. عقدتك الأمامية الخاصة تشتري لك الإخفاء دون وسيط، لكن دون سعة عالمية. الولاية القضائية تحسم المسألة القانونية، ولا شيء من الثلاثة يمسّها. وكل هذه الترتيبات يُبطلها سجل واحد غير محمي ببروكسي، أو بريد إلكتروني واحد من الخادم الأصلي، أو مضيف ظاهري افتراضي واحد.
قرّر بحسب الهدف لا العادة، ثم اقضِ العشر دقائق على التدقيق — فهو يكشف انكشافًا حقيقيًا أكثر من أي ترقية. إذا كنت تريد هذه البنية دون طرف ثالث، فإن VPS صغير كـواجهة أمامية والعمل الحقيقي على عتاد مخصص خلفه هو الترتيب الذي نراه غالبًا لدى من سبق أن اكتُشفوا مرة واحدة.