ما هو Reverse Proxy؟ ولماذا لا تكفي Cloudflare لحماية سيرفرك وحدها

كثير من أصحاب المواقع يفعّلون Cloudflare ويظنون أن السيرفر أصبح في مأمن. لكن الحماية الحقيقية لا تأتي من إخفاء عنوان السيرفر، بل من طريقة بناء طبقة Reverse Proxy أمامه وإغلاق كل باب جانبي يمكن أن يصل منه المهاجم مباشرة.

ما هو Reverse Proxy؟

ببساطة، Reverse Proxy هو سيرفر وسيط يقف أمام تطبيقك، يستقبل طلبات الزوار نيابة عنه، ثم يقرر ما الذي يصل إلى التطبيق وكيف يصل. الزائر يتعامل مع Reverse Proxy فقط، ولا يرى السيرفرات التي تعمل خلفه.

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

ما الفرق بين Reverse Proxy و Forward Proxy؟

الفرق في الجهة التي يخدمها الوسيط. Forward Proxy يعمل لصالح المستخدمين ويخفي هويتهم عن المواقع، بينما Reverse Proxy يعمل لصالح السيرفرات ويخفي تفاصيلها عن المستخدمين.

وجه المقارنة	Forward Proxy	Reverse Proxy
يعمل لصالح	المستخدمين داخل الشبكة	السيرفرات والتطبيقات
يخفي هوية	العميل عن الموقع	السيرفر عن العميل
مكانه	بين المستخدمين والإنترنت	بين الإنترنت والسيرفرات
أمثلة	بروكسي الشركات، Squid	Nginx, Traefik, Caddy and Cloudflare

لماذا نحتاج Reverse Proxy؟

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

1. إنهاء التشفير (TLS Termination): يتولى Reverse Proxy شهادات HTTPS وفك التشفير، فلا يحتاج كل تطبيق خلفه إلى إدارة شهاداته الخاصة.
2. توزيع الحمل (Load Balancing): يوزع الطلبات على عدة نسخ من التطبيق، فإذا تعطلت نسخة يحوّل حركة البيانات إلى النسخ السليمة. نشرح هنا السيناريو المبسط، أما في البنى الكبيرة فيكون Load Balancer غالباً جهازاً أو خدمة متقدمة مستقلة بذاتها، توزع الحمل على عدة سيرفرات منفصلة وتراقب صحة كل منها.
3. التخزين المؤقت (Caching): يحتفظ بنسخ من الصفحات والملفات الثابتة ويقدمها مباشرة، فيخفف الضغط عن التطبيق.
4. تشغيل عدة تطبيقات على سيرفر واحد: يوجّه api.example.com إلى تطبيق، و app.example.com إلى تطبيق آخر، وكلاهما على المنفذ 443 نفسه.
5. إخفاء بنية السيرفرات الداخلية: لا يعرف الزائر عدد السيرفرات أو منافذها أو التقنيات التي تعمل عليها.
6. تحديد معدل الطلبات (Rate Limiting): يحد من عدد الطلبات القادمة من مصدر واحد، فيصعّب هجمات التخمين وإغراق السيرفر.
7. التحديث دون توقف الخدمة: تشغّل النسخة الجديدة من التطبيق، ثم يحوّل Reverse Proxy الطلبات إليها دون أن يلاحظ الزائر أي انقطاع.

كيف يعمل Reverse Proxy عملياً؟

أفضل طريقة لفهمه أن نرى المهمة نفسها بأربع أدوات مختلفة. المهمة: توجيه النطاق app.example.com إلى تطبيق يعمل على المنفذ 3000 مع تفعيل HTTPS.

إعداد Nginx:

server {
    listen 443 ssl;
    http2 on;
    server_name app.example.com;

    ssl_certificate     /etc/ssl/app/fullchain.pem;
    ssl_certificate_key /etc/ssl/app/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

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

إعداد Caddy:

app.example.com {
    reverse_proxy 127.0.0.1:3000
}

ثلاثة أسطر فقط. يحصل Caddy على شهادة Let’s Encrypt تلقائياً، ويجددها قبل انتهائها، ويحوّل HTTP إلى HTTPS دون أي إعداد إضافي.

إعداد Traefik مع Docker:

services:
  app:
    image: myapp:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=letsencrypt"
      - "traefik.http.services.app.loadbalancer.server.port=3000"

لا يوجد ملف إعداد مركزي للتطبيق هنا. يقرأ Traefik هذه الوسوم (Labels) من الحاوية ويبني التوجيه تلقائياً بمجرد تشغيلها، ويحذفه عند إيقافها.

إعداد HAProxy:

frontend https_in
    bind :443 ssl crt /etc/haproxy/certs/app.pem
    http-request set-header X-Forwarded-Proto https
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /health
    server app1 127.0.0.1:3000 check

يتميز HAProxy بالفحص الصحي للسيرفرات (Health Checks) وخوارزميات توزيع الحمل المتقدمة، لذلك يظهر كثيراً في الأنظمة ذات الضغط العالي.

ما الفرق بين Nginx, Traefik, Caddy and HAProxy؟

الفرق الجوهري في فلسفة كل أداة: Nginx أداة شاملة ومرنة، و Caddy تركّز على البساطة والتشفير التلقائي، و Traefik مصممة للحاويات و Kubernetes، و HAProxy متخصصة في توزيع الحمل بأعلى أداء.

وجه المقارنة	Nginx	Caddy	Traefik	HAProxy
لغة البرمجة	C	Go	Go	C
أسلوب الإعداد	ملفات إعداد نصية	Caddyfile بسيط أو JSON	وسوم Docker وملفات YAML	ملف إعداد نصي
شهادات HTTPS تلقائية	لا، يحتاج Certbot	نعم، مدمج	نعم، عبر ACME	لا، يحتاج أداة خارجية
اكتشاف الحاويات تلقائياً	لا	محدود	نعم، نقطة قوته الأساسية	محدود
دعم Kubernetes	عبر وحدات تحكم منفصلة	محدود	قوي، مع Gateway API	عبر وحدة تحكم خاصة
منحنى التعلم	متوسط	سهل جداً	متوسط	متوسط إلى صعب
الأنسب لـ	معظم مشاريع الويب	السيرفر الواحد والمشاريع الصغيرة	Docker و Kubernetes	الأنظمة عالية الضغط

متى تختار كل أداة؟

Nginx: اختر Nginx عندما تحتاج أداة مجرّبة تجمع بين سيرفر الويب و Reverse Proxy ويتوفر لها أكبر قدر من الشروحات والحلول الجاهزة. وما زال Nginx من أكثر سيرفرات الويب انتشاراً، إذ يعمل على 43.92% من الأجهزة التي تستضيف مواقع حسب مسح Netcraft لشهر يوليو 2026.

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

Traefik: اختر Traefik عندما تعمل تطبيقاتك داخل حاويات Docker أو على Kubernetes وتتغير باستمرار. يكتشف Traefik الخدمات الجديدة تلقائياً، وهذا يوفر عليك تعديل الإعدادات مع كل نشر جديد.

وازدادت أهمية Traefik بعد أن توقف مشروع ingress-nginx التابع لمجتمع Kubernetes عن تلقي أي تحديثات أو ترقيعات أمنية منذ مارس 2026، حسب الإعلان الرسمي لمشروع Kubernetes. هذا التوقف يخص وحدة التحكم ingress-nginx فقط، أما Nginx نفسه فما زال مدعوماً. وتدعم Traefik واجهة Gateway API التي يوصي بها مجتمع Kubernetes بديلاً للطريقة القديمة.

HAProxy: اختر HAProxy عندما يكون توزيع الحمل هو المهمة الأساسية وتحتاج أعلى أداء ممكن وتحكماً دقيقاً في الطبقتين الرابعة والسابعة. كثير من الأنظمة الكبيرة تضع HAProxy في الواجهة وخلفه Nginx أو التطبيقات مباشرة.

ماذا عن Envoy و Pingora؟

تُعد Envoy أداة Reverse Proxy مصممة لبيئات الخدمات المصغرة (Microservices) وشبكات الخدمات (Service Mesh)، وتُستخدم غالباً داخل Kubernetes. أما Pingora فهو إطار عمل مكتوب بلغة Rust طورته Cloudflare ليحل محل Nginx في شبكتها، وذكرت الشركة في مدونتها الرسمية أنه استهلك موارد معالجة أقل بنسبة 70% وذاكرة أقل بنسبة 67% مع حجم حركة البيانات نفسه. Pingora مفتوح المصدر، لكنه مكتبة برمجية تبني بها Reverse Proxy خاصاً بك وليس أداة جاهزة بملف إعداد.

هل يحمي Cloudflare سيرفرك فعلاً؟

يحمي Cloudflare سيرفرك فقط إذا كان السيرفر لا يقبل أي اتصال إلا القادم من Cloudflare. فشبكة Cloudflare في جوهرها Reverse Proxy عملاق: عندما تفعّل البروكسي على سجل DNS (السحابة البرتقالية)، يحصل الزائر على عنوان IP تابع لـ Cloudflare، وتمر طلباته عبر جدار حماية تطبيقات الويب (WAF) وحماية DDoS قبل أن تصل إلى سيرفرك.

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

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

كيف يُكشف عنوان السيرفر الحقيقي (Origin IP)؟

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

سجلات DNS القديمة

مواقع أرشفة DNS تحتفظ بسجلات A القديمة لنطاقك من الفترة التي سبقت انتقاله إلى Cloudflare. إذا لم تغيّر عنوان السيرفر بعد الانتقال، فالسجل القديم ما زال يشير إلى سيرفرك الحالي.

النطاقات الفرعية غير المحمية

يفعّل كثيرون البروكسي على www فقط، ويتركون النطاق الرئيسي أو نطاقات مثل dev و staging و ftp بحالة DNS فقط (السحابة الرمادية). استعلام DNS واحد على هذه النطاقات يكشف العنوان مباشرة.

سجلات البريد MX وترويسات الرسائل

إذا كان سيرفر البريد هو نفسه سيرفر الويب، كما في كثير من استضافات cPanel، فإن سجل MX يكشف العنوان. كذلك الرسائل التي يرسلها موقعك، مثل رسائل إعادة تعيين كلمة المرور، قد تحمل عنوان السيرفر في ترويساتها.

شهادات SSL وأدوات الفحص على مستوى الإنترنت

محركات مثل Censys و Shodan تفحص الإنترنت كاملاً وتسجل الشهادة التي يعرضها كل عنوان IP على المنفذ 443. إذا كان سيرفرك يعرض شهادة تحمل اسم نطاقك لأي اتصال مباشر، فالبحث عن اسم النطاق في هذه المحركات قد يقود إلى عنوانه. وتضيف سجلات شفافية الشهادات (Certificate Transparency) مصدراً آخر لتتبع شهاداتك.

مصادر أخرى أقل شهرة

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

ماذا يحدث عند تجاوز Cloudflare؟

عند تجاوز Cloudflare يصل المهاجم إلى سيرفرك مباشرة، فتتوقف كل الحمايات التي دفعت ثمنها أو اعتمدت عليها. يتصل المهاجم بالعنوان الحقيقي مع إرسال اسم نطاقك في ترويسة Host، فيرد السيرفر كأن الطلب طبيعي.

النتائج العملية لذلك:

• سقوط جدار حماية التطبيقات (WAF): الطلبات التي كان سيمنعها Cloudflare، مثل محاولات XSS و SQL Injection، تصل الآن إلى التطبيق دون فحص.
• انكشاف السيرفر لهجمات DDoS: حماية Cloudflare من هجمات حجب الخدمة لا تعمل على حركة البيانات التي لا تمر عبرها، فيمكن إسقاط السيرفر بحجم هجوم صغير نسبياً.
• تعطل حدود الطلبات وقواعد الحظر: كل قواعد Rate Limiting وحظر الدول والبوتات المضبوطة في Cloudflare تصبح بلا قيمة.
• فحص المنافذ الأخرى: بعد معرفة العنوان قد يفحص المهاجم منافذ أخرى مفتوحة مثل SSH ولوحات الإدارة.

كيف تحمي سيرفرك بعد كشف عنوانه؟

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

الخطوة 1: السماح لعناوين Cloudflare فقط في جدار الحماية

أغلق المنفذين 80 و443 أمام الجميع، ثم اسمح فقط لنطاقات العناوين التي تنشرها Cloudflare في الصفحة الرسمية cloudflare.com/ips. مثال باستخدام UFW يسمح لنطاقات Cloudflare فقط، ثم يرفض بقية الاتصالات على منافذ الويب دون المساس بمنفذ SSH:

for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443 comment 'cloudflare'
done

sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

تحذير لمستخدمي Docker: إذا كان Reverse Proxy أو التطبيق يعمل داخل حاوية Docker بمنفذ منشور (Published Port)، فقواعد UFW السابقة قد لا تحميه أصلاً. توضح وثائق Docker الرسمية أن Docker و UFW يستخدمان قواعد جدار الحماية بطريقة غير متوافقة، وأن حركة البيانات المتجهة إلى الحاويات تُمرَّر قبل تطبيق قواعد UFW عليها. لذلك في هذه الحالة استخدم جدار الحماية الذي يقدمه مزود الاستضافة، أو اتبع الحلول في قسم Docker أدناه.

أما في Traefik فيمكن تطبيق القاعدة نفسها على مستوى التوجيه بوسيط ipAllowList. المثال التالي مختصر ويحتوي نطاقين فقط للتوضيح، فلا تنسخه كما هو، بل ضع فيه كل نطاقات IPv4 و IPv6 المنشورة في قائمة Cloudflare الرسمية، وإلا ستحجب جزءاً من حركة البيانات الشرعية القادمة من Cloudflare:

labels:
  - "traefik.http.middlewares.cf-only.ipallowlist.sourcerange=173.245.48.0/20,103.21.244.0/22"
  - "traefik.http.routers.app.middlewares=cf-only"

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

الخطوة 2: تفعيل المصادقة المتبادلة (Authenticated Origin Pulls)

تجعل ميزة Authenticated Origin Pulls شبكة Cloudflare تقدم شهادة عميل (Client Certificate) عند كل اتصال بسيرفرك عبر مصادقة TLS المتبادلة (mTLS)، ويرفض السيرفر أي اتصال لا يحمل هذه الشهادة. الميزة متاحة في كل الخطط بما فيها الخطة المجانية.

لقطة من لوحة تحكم Cloudflare، من المسار SSL/TLS ثم Origin Server ثم Authenticated Origin Pulls.

مثال إعداد Nginx بعد تنزيل شهادة Cloudflare العامة:

ssl_client_certificate /etc/nginx/certs/authenticated_origin_pull_ca.pem;
ssl_verify_client on;

ومثال Caddy بالصيغة الحالية trust_pool التي حلت محل الحقل القديم trusted_ca_cert_file حسب وثائق Caddy:

app.example.com {
    tls {
        client_auth {
            mode require_and_verify
            trust_pool file /etc/caddy/certs/authenticated_origin_pull_ca.pem
        }
    }
    reverse_proxy 127.0.0.1:3000
}

تنبيه مهم: الشهادة العامة (Global AOP) مشتركة بين كل حسابات Cloudflare، فهي تثبت أن الطلب قادم من شبكة Cloudflare، لا من حسابك تحديداً. للحماية الكاملة استخدم الإعداد على مستوى النطاق (Zone-level) أو على مستوى اسم النطاق (Per-hostname) مع شهادة خاصة بك ترفعها بنفسك.

الخطوة 3: ضبط وضع التشفير على Full (strict)

يُنصح باستخدام Full (strict) لأنه يشفّر الاتصال بين Cloudflare والسيرفر ويتحقق من صلاحية شهادة المصدر، لذلك ثبّت على السيرفر شهادة صالحة أو شهادة Cloudflare Origin Certificate. تعمل ميزة Authenticated Origin Pulls في وضعي Full و Full (strict)، لكنها لا تعمل في وضعي Off و Flexible، حسب وثائق Cloudflare.

انتبه أيضاً إلى أن Authenticated Origin Pulls تحمي اتصالات HTTPS فقط، ولا تشمل HTTP العادي. فإذا كان المنفذ 80 متاحاً مباشرة، فتأكد أنه لا يقدم محتوى التطبيق، بل يكتفي بالتحويل إلى HTTPS أو يكون مغلقاً في جدار الحماية.

الخطوة 4: استعادة عنوان الزائر الحقيقي بأمان

بعد تفعيل Cloudflare ستظهر في سجلات سيرفرك عناوين Cloudflare بدل عناوين الزوار، فتتعطل أدوات مثل Fail2ban وحدود الطلبات في التطبيق. Cloudflare ترسل عنوان الزائر الحقيقي في الترويسة CF-Connecting-IP، ويجب أن يثق بها السيرفر فقط عندما يأتي الاتصال من Cloudflare.

في Nginx:

set_real_ip_from 173.245.48.0/20;   # سطر لكل نطاق من نطاقات Cloudflare
set_real_ip_from 103.21.244.0/22;   # وهكذا لبقية النطاقات
real_ip_header CF-Connecting-IP;

هذا المثال مختصر ويحتوي نطاقين فقط، فأضف سطر set_real_ip_from لكل نطاق IPv4 و IPv6 في قائمة Cloudflare الرسمية.

في Caddy ضمن الإعدادات العامة:

{
    servers {
        trusted_proxies static 173.245.48.0/20 103.21.244.0/22
        client_ip_headers CF-Connecting-IP
    }
}

وهنا أيضاً المثال مختصر بنطاقين فقط، فضع بعد trusted_proxies static كل نطاقات القائمة الرسمية، وإلا لن تُستعاد عناوين الزوار الحقيقية للطلبات القادمة من بقية النطاقات.

الخطأ الخطير هنا: استخدام real_ip_header دون تحديد set_real_ip_from، أو الثقة بالترويسة من أي مصدر. حينها يستطيع أي شخص يتصل مباشرة بالسيرفر أن يرسل ترويسة مزيفة ويظهر في سجلاتك بعنوان IP يختاره هو.

الخطوة 5: استخدام Cloudflare Tunnel (الخيار الأقوى)

تلغي ميزة Cloudflare Tunnel المشكلة من أساسها: بدلاً من أن تفتح منافذ على سيرفرك وتنتظر اتصال Cloudflare، تثبّت برنامجاً صغيراً اسمه cloudflared ينشئ اتصالاً صادراً مشفراً من سيرفرك إلى Cloudflare. لا حاجة لمنافذ ويب واردة مفتوحة، ولا لعنوان IP عام، ولا لقائمة سماح تحتاج إلى تحديث.

مثال ملف الإعداد config.yml:

tunnel: <TUNNEL-ID>
credentials-file: /etc/cloudflared/<TUNNEL-ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - hostname: api.example.com
    service: http://localhost:8080
  - service: http_status:404

يمكن أن يعمل cloudflared أمام Nginx أو Traefik أو Caddy مباشرة، فتبقى إعدادات Reverse Proxy كما هي، ويصبح Cloudflare Tunnel هو الطريق الوحيد إليها. والقاعدة الأخيرة http_status:404 ترفض أي اسم نطاق غير معرّف.

انتبه إلى نقطتين عند استخدام Tunnel:

• تثبيت cloudflared لا يغلق المنافذ المفتوحة تلقائياً. إذا كان السيرفر يستقبل اتصالات على 80 و443 قبل Tunnel، فستبقى مفتوحة حتى تغلقها بنفسك في جدار الحماية وتزيل المنافذ المنشورة من حاويات Docker.
• ميزة Authenticated Origin Pulls لا تنطبق على النطاقات الموجهة عبر Tunnel. حسب وثائق Cloudflare، الاتصال في Tunnel صادر من السيرفر، والمصادقة تتم عبر بيانات اعتماد الموصل (Connector) نفسه.

الخطوة 6: تغيير عنوان السيرفر وفصل الخدمات

إذا كان عنوانك قد ظهر سابقاً في سجلات DNS العامة، فكل الخطوات السابقة تمنع الاستغلال لكنها لا تمحو التاريخ. بعد تطبيق الحماية:

• غيّر عنوان IP للسيرفر إن أمكن، ولا تنشر العنوان الجديد في أي سجل DNS غير محمي.
• افصل سيرفر البريد عن سيرفر الويب، أو أرسل البريد عبر خدمة إرسال خارجية.
• راجع كل سجلات DNS وتأكد أن السجلات التي تشير إلى سيرفر الويب كلها بالسحابة البرتقالية.
• لا تعرض موقعك على عنوان IP مباشرة، واجعل Reverse Proxy يرد بخطأ على أي طلب لا يحمل اسم نطاق معروف.

كيف تحمي Origin IP عند استخدام Docker و Traefik و Dokploy خلف Cloudflare؟

في هذه البيئات يجب أن تعتمد الحماية على مكان نشر المنافذ، لا على UFW وحده، لأن المنافذ المنشورة من Docker قد تتجاوز قواعده كما ذكرنا. هذه أهم الإجراءات:

1. لا تنشر منافذ التطبيقات. اجعل Traefik وحده ينشر المنفذين 80 و443، واربط بقية الحاويات به عبر شبكة Docker داخلية دون ports:. وإذا احتجت منفذاً لتطبيق ما، فاربطه بالعنوان المحلي فقط مثل 127.0.0.1:3000:3000 بدل 3000:3000.
2. استخدم جدار الحماية لدى مزود الاستضافة. جدران الحماية السحابية تفلتر حركة البيانات قبل وصولها إلى السيرفر، فلا يتجاوزها Docker. اسمح فيها بالمنفذين 80 و443 لنطاقات Cloudflare فقط، و SSH لعناوينك أنت.
3. طبّق ipAllowList على مستوى Traefik. أضف وسيط السماح بنطاقات Cloudflare الكاملة على كل الموجّهات (Routers) العامة، فيرفض Traefik أي طلب مباشر حتى لو وصل إلى المنفذ.
4. احمِ لوحات الإدارة. لا تترك لوحة Dokploy أو لوحة Traefik متاحة للعامة على منفذ منشور. اجعلها خلف نطاق محمي بـ Cloudflare Access أو قصرها على عناوينك فقط.
5. أو انتقل إلى Cloudflare Tunnel. شغّل حاوية cloudflared على شبكة Docker نفسها ووجّهها إلى Traefik، ثم أزل نشر المنفذين 80 و443 كلياً، فلا يبقى على السيرفر أي منفذ ويب مفتوح للإنترنت.

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

كيف تتأكد أن سيرفرك غير مكشوف؟

تتأكد بأن تجرب ما قد يفعله المهاجم، لكن على سيرفرك أنت فقط. استخدم الأمر التالي من جهاز خارج شبكة السيرفر، مع استبدال 203.0.113.10 بعنوان سيرفرك الحقيقي و example.com بنطاقك:

curl -skI --resolve example.com:443:203.0.113.10 https://example.com/

هذا الأمر يتجاوز DNS ويتصل بعنوان سيرفرك مباشرة. النتيجة المطلوبة هي فشل الاتصال المباشر بسبب جدار الحماية، أو رفض اتصال TLS عند غياب شهادة العميل المطلوبة في Authenticated Origin Pulls.

أما ظهور استجابة HTTP مثل 400 أو 403 فلا يكفي وحده لإثبات الحماية، فقد تكون الاستجابة صادرة من التطبيق نفسه بعد أن وصل إليه الطلب متجاوزاً Cloudflare. لذلك تأكد أن الرفض يحدث على مستوى جدار الحماية أو Reverse Proxy قبل وصول الطلب إلى التطبيق، بمراجعة الإعدادات وسجلات الطلبات. مثلاً، Nginx المضبوط على ssl_verify_client on يرد بخطأ 400 مع رسالة No required SSL certificate was sent، وهذا رفض صادر من Reverse Proxy نفسه قبل الوصول إلى التطبيق، فهو مقبول. وإذا وصلتك استجابة طبيعية لا تحتوي الترويسة server: cloudflare ولا cf-ray، فسيرفرك مكشوف بالتأكيد.

كرر الفحص نفسه على المنفذ 80 عبر HTTP العادي، لأن الحماية على 443 وحدها لا تكفي:

curl -sI --resolve example.com:80:203.0.113.10 http://example.com/

قائمة فحص سريعة:

• الاتصال المباشر بعنوان السيرفر على 80 و443 يُرفض.
• لا توجد حاويات Docker تنشر منافذ ويب للإنترنت دون حماية.
• كل سجلات DNS التي تشير إلى سيرفر الويب محمية بالسحابة البرتقالية.
• سجل MX لا يشير إلى سيرفر الويب نفسه.
• ميزة Authenticated Origin Pulls مفعلة بشهادة خاصة بحسابك، أو أن السيرفر يعمل عبر Cloudflare Tunnel.
• وضع التشفير Full (strict).
• سجلات السيرفر تعرض عناوين الزوار الحقيقية، ولا يمكن تزويرها بترويسة مرسلة مباشرة.
• عنوان السيرفر الحالي لا يظهر في أرشيف سجلات DNS القديمة.

أي Reverse Proxy تختار؟

اختر الأداة حسب بيئتك، لا حسب شهرتها:

• سيرفر واحد وتطبيقات قليلة: Caddy، لأنه يوفر HTTPS تلقائياً بأقل إعداد.
• مشاريع ويب عامة وموقع على VPS: Nginx، لأنه الأكثر توثيقاً ومرونة.
• بيئة Docker أو Kubernetes: Traefik، لأنه يكتشف الخدمات تلقائياً ويدعم Gateway API.
• ضغط عالٍ وتوزيع حمل متقدم: HAProxy في الواجهة، وخلفه Nginx أو التطبيقات.
• أي خيار من السابق مع Cloudflare: أضف دائماً Cloudflare Tunnel، أو جدار حماية مع Authenticated Origin Pulls، فاختيار الأداة لا يغني عن إغلاق الطريق المباشر إلى السيرفر.

في النهاية، Reverse Proxy أداة قوية لتنظيم البنية التحتية وحمايتها، و Cloudflare من أفضل طبقات الحماية المتاحة، لكن كليهما يفقد قيمته إذا بقي السيرفر يرد على أي شخص يعرف عنوانه. ابدأ اليوم بفحص سيرفرك بالأمر السابق، ثم طبّق الطبقات واحدة تلو الأخرى. ولمزيد من الأساسيات اقرأ أمن الشبكات وتصميم الشبكات الآمنة وتقسيمها إلى مناطق، وإذا كنت تبدأ من الصفر فابدأ بـ ما هو عنوان IP.