Morocco · Proxy_Hosting · 27-10-2026
كثير من المواقع المغربية الصغيرة، سواء متاجر إلكترونية على منصات جاهزة أو مواقع شركات مستضافة على خادم VPS بثمن يتراوح بين 60 و150 درهماً شهرياً، تكتفي بوضع شهادة SSL على الخادم الأصلي وتظن أن الأمر انتهى. المشكلة أن الخادم الأصلي يبقى مكشوفاً، ورقم IP الخاص به يظهر في السجلات وفي سجلات البريد، فيصبح هدفاً سهلاً لهجمات الحجب والمسح الآلي. هنا يأتي دور البروكسي العكسي.
البروكسي العكسي طبقة تقف أمام الموقع: الزائر يخاطب عنوان البروكسي، والبروكسي هو الذي يخاطب الخادم الأصلي. النتيجة أن IP الخادم الحقيقي لا يظهر لأي زائر، ويبقى الموقع محمياً حتى لو تغيّر عنوانه. في السوق المغربي، يلجأ أصحاب المواقع إلى هذه التقنية عندما يستضيفون على مزود أجنبي ويريدون إخفاء مصدر الخدمة أو توزيع الحمل بين خادمين.
الخطأ الشائع هو ترك منفذ الإدارة SSH مفتوحاً على نفس IP الذي يفترض أن يكون مخفياً، أو نسيان تعطيل الوصول المباشر إلى المنفذ 80 و443 على الخادم الأصلي. البروكسي لا يفيد شيئاً إن كان بإمكان أي شخص تجاوزه والوصول إلى الخادم مباشرة.
على خادم Ubuntu أو Debian، وهي التوزيعات الأكثر استعمالاً عند المستضيفين المغاربة، تبدأ بتفعيل الوحدات اللازمة: a2enmod proxy proxy_http ssl headers. بعدها تنشئ ملف إعداد في /etc/apache2/sites-available وتعطي فيه اسم النطاق، ثم تشير إلى الخادم الأصلي داخل كتلة VirtualHost.
القاعدة الأساسية التي ينساها الكثيرون هي تمرير ترويسة X-Forwarded-For وX-Forwarded-Proto، وإلا سيظن تطبيقك أن كل الزوار يأتون من نفس العنوان، فتفشل أنظمة الحماية من التخمين وتظهر عناوين IP خاطئة في سجلات الدخول. كما يجب ضبط ProxyPreserveHost On حتى يصل اسم النطاق الصحيح إلى الخادم الخلفي.
من الأفضل إنهاء تشفير SSL عند البروكسي باستخدام Certbot، وتعطيل شهادة الخادم الخلفي إن كانا على شبكة داخلية موثوقة. هذا يبسّط التجديد ويقلل نقاط الفشل. تأكد من إعادة توجيه كل طلبات HTTP إلى HTTPS عبر Redirect permanent، لأن خلط البروتوكولين يسبب تحذيرات في المتصفح ويربك أدوات الزحف.
بعد الإعداد، اختبر من خارج الشبكة: هل يمكن الوصول إلى IP الأصلي مباشرة؟ إن كانت الإجابة نعم، أضف قاعدة جدار ناري تسمح فقط لعنوان البروكسي بالاتصال. هذه الخطوة وحدها تحمي من معظم محاولات التجاوز.
يخلط كثير من القراء بين ثلاثة أشياء مختلفة تماماً. البروكسي العكسي يحمي خادمك من الزوار. البروكسي المفتوح، وهو ما يسأل عنه الناس بعبارة «ما هو البروكسي المفتوح»، هو خدمة عامة يمر عبرها المستخدم للوصول إلى مواقع محجوبة، وغالباً تكون غير آمنة وتُستعمل لسرقة البيانات. أما الوكيل المخصص، أي dedicated proxy، فهو عنوان IP محجوز لمستخدم واحد، ويُستعمل في أغراض مثل جمع البيانات أو إدارة حسابات إعلانية.
من الناحية التقنية، البروكسي المفتوح لا يصلح لاستضافة موقع: لا يدعم شهادات SSL خاصة بك، ولا يضمن ثباتاً، وقد يُغلق في أي لحظة. الوكيل المخصص قد يفيد في حالة واحدة فقط: إذا كنت تدير اختبارات أداء من عدة مناطق قبل إطلاق موقعك، فتستخدم عناوين مخصصة لمحاكاة زوار من دول مختلفة دون أن يختلط ترافيكك بغيره.
لاحظ الفرق في المسؤولية القانونية. في المغرب، الموقع الذي يستضيف محتوى غير قانوني يبقى صاحبه مسؤولاً حتى لو كان خلف بروكسي عكسي، لأن الجهات المختصة تصل إلى الخادم عبر مزود الاستضافة. البروكسي يخفي البنية التقنية، لا يمحو المسؤولية. لذلك لا تنظر إليه كأداة إخفاء هوية، بل كأداة هندسة شبكات.
أول خطأ هو نسيان تحديث سجلات DNS بعد تركيب البروكسي. إذا كان النطاق مسجلاً لدى Registrar مغربي أو أجنبي، يجب تغيير سجل A ليشير إلى عنوان البروكسي، والانتظار حتى تنتهي مدة TTL التي قد تصل إلى 24 ساعة. خلال هذه الفترة، بعض الزوار يصلون إلى الخادم القديم وآخرون إلى الجديد، فتظهر أخطاء متقطعة يصعب تشخيصها.
الخطأ الثاني هو عدم تخصيص ذاكرة كافية للبروكسي. Apache2 مع وحدة proxy يحتاج إلى ضبط عدد العمليات وProxyTimeout بما يناسب حجم الزيارات. موقع بسيط يستقبل 500 زيارة يومياً يعمل بذاكرة 1 غيغابايت، أما موقع تجاري في موسم الذروة، مثلاً خلال رمضان حيث ترتفع الزيارات مساءً، فقد يحتاج إلى 2 أو 4 غيغابايت حتى لا يتوقف البروكسي نفسه.
الخطأ الثالث هو تجاهل سجلات الأخطاء. راقب error.log أسبوعياً بعد التركيب؛ رسائل مثل «AH01114: HTTP: failed to make connection to backend» تعني أن الخادم الأصلي لا يستجيب أو أن جدار الحماية يحجب الاتصال، وليس أن البروكسي معطل. التمييز بين الاثنين يوفر ساعات من البحث.
أخيراً، لا تضع البروكسي على نفس الخادم الذي يستضيف الموقع ثم تتوقع حماية من انقطاع الشبكة. الفائدة الحقيقية تظهر عندما يكون البروكسي في موقع شبكي مختلف عن الخادم الأصلي، ولو بمنطقة استضافة أخرى.