كيفية إعداد Caddy كوكيل عكسي في 2026 (HTTPS تلقائي، Docker، ومتى تختاره)

يضع الوكيل العكسي Caddy خادم ويب واحداً صغيراً وسريعاً أمام تطبيقاتك ويمنح كلاً منها شهادة HTTPS صالحة تلقائياً، دون الحاجة إلى certbot، ودون تجديدات عبر cron، وعادةً دون أكثر من ثلاثة أسطر من الإعدادات. وجّه نطاقاً إلى خادمك، واكتب example.com { reverse_proxy localhost:8080 }، وشغّل Caddy، وسيكون لديك بوابة HTTPS أمامية جاهزة للإنتاج. يرشدك هذا الدليل خطوة بخطوة عبر تثبيت Caddy، وكتابة ملف Caddyfile، وتشغيله في Docker، وتحديد متى يكون Caddy هو الوكيل العكسي المناسب مقارنةً بـ Nginx أو Traefik أو Cloudflare Tunnel.

ما هو الوكيل العكسي Caddy، ولماذا تستخدمه؟

يقع الوكيل العكسي بين الإنترنت العام وتطبيقاتك. فبدلاً من كشف كل تطبيق على منفذه الخاص (التشتّت الكلاسيكي بين server-ip:8080 وserver-ip:3000)، ينصت الوكيل على المنفذين 80 و443، وينهي اتصال TLS، ويوجّه كل طلب وارد إلى الواجهة الخلفية الصحيحة بناءً على اسم المضيف أو المسار. يمنحك ذلك عناوين URL نظيفة، ومكاناً واحداً لإدارة الشهادات، ونقطة تحكّم واحدة لترويسات الأمان وحدود المعدّل.

يتميّز Caddy لأن HTTPS التلقائي مُفعّل افتراضياً: فإذا كان يعرف اسم نطاقك، فإنه يوفّر لك شهادة من Let's Encrypt أو ZeroSSL ويجدّدها، ثم يستمر في تجديدها إلى الأبد. يستطيع Nginx وTraefik فعل ذلك أيضاً، لكن Caddy يحتاج إلى أقل قدر من الإعدادات للوصول إلى هناك. وكما عبّر عن ذلك موقع XDA، فإن Caddy هو "طريقة سهلة حقاً للحصول على شهادات SSL لتطبيقاتك المُستضافة ذاتياً"، وهذا بالضبط ما يريده معظم الناس من الوكيل العكسي.

تثبيت Caddy على Ubuntu أو Debian

على خادم VPS جديد يعمل بنظام Ubuntu أو Debian، ثبّت Caddy من مستودع apt الرسمي الخاص به. هذه هي الأوامر الحالية من وثائق Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

يؤدي التثبيت عبر apt إلى إعداد Caddy كخدمة systemd تبدأ عند الإقلاع وتقرأ إعداداتها من /etc/caddy/Caddyfile. تحقّق من الإصدار عبر caddy version؛ واعتباراً من منتصف 2026 يكون الإصدار المستقر الحالي هو Caddy 2.11.4 (يونيو 2026)، وقد عالجت إصدارات 2.11.x الأخيرة مشكلات أمنية، منها CVE-2026-27590 وCVE-2026-27589 (وقد جرى إصلاح كليهما في 2.11.1)، لذا شغّل نسخة مُحدّثة بدلاً من أي نسخة صدرت قبل عام. وإذا كنت تفضّل عدم لمس المضيف على الإطلاق، فانتقل إلى قسم Docker. وقبل أن تكشف أي شيء علناً، تأكّد أولاً من أن الجهاز نفسه محكم الإغلاق، وفقاً لدليلنا حول الساعة الأولى الآمنة على خادم VPS جديد.

ملف Caddyfile الأدنى: سطر واحد لـ HTTPS التلقائي

إن جوهر Caddy كله هو ضآلة ما تحتاج إلى كتابته. عدّل /etc/caddy/Caddyfile بحيث يحتوي على كتلة موقع بنطاقك الحقيقي والعنوان المحلي للتطبيق الذي تريد كشفه:

example.com {
    reverse_proxy localhost:8080
}

أعد التحميل عبر sudo systemctl reload caddy (أو caddy reload إذا كنت تشغّله يدوياً) وتكون قد انتهيت. عند البدء، ينصت Caddy على المنفذين 80 و443، ويطلب شهادة موثوقة لـ example.com، ويوجّه حركة المرور إلى تطبيقك على المنفذ 8080. يجب أن يتحقّق شرطان لإصدار الشهادة: أن يشير سجل DNS من نوع A/AAAA للنطاق إلى الخادم، وأن يكون المنفذان 80 و443 مفتوحَين للإنترنت العام حتى يكتمل تحدّي ACME. ولإجراء اختبار محلي سريع دون نطاق، استخدم localhost كعنوان للموقع، وسيثبّت Caddy شهادته الموقّعة ذاتياً. اعتد على تشغيل caddy validate --config /etc/caddy/Caddyfile قبل كل عملية إعادة تحميل؛ فهو يلتقط الأخطاء المطبعية قبل أن تُسقط الموقع.

توجيه عدة تطبيقات ونطاقات فرعية

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

app.example.com {
    reverse_proxy localhost:3000
}

grafana.example.com {
    reverse_proxy localhost:3001
}

api.example.com {
    reverse_proxy localhost:5000
}

يمكنك أيضاً التقسيم حسب المسار ضمن نطاق واحد باستخدام كتلة handle_path أو route، وهو أمر مفيد عندما ينبغي أن يقيم التطبيق على example.com/api بدلاً من نطاقه الفرعي الخاص. يتعامل Caddy مع ترقيات WebSocket تلقائياً، لذا تعمل التطبيقات الفورية دون توجيهات إضافية، ومنذ Caddy 2.11 صار يعيد كتابة ترويسة Host الخاصة بالمصدر الأعلى تلقائياً بالنسبة للمصادر العليا عبر HTTPS، ما يزيل مصدراً شائعاً لأخطاء "يعمل على المنفذ 8080 لكن ليس عبر الوكيل". يقترن نمط النطاق-الفرعي-لكل-تطبيق هذا بشكل طبيعي مع أسطول من الخدمات الصغيرة، من النوع الذي يغطّيه شرحنا التفصيلي حول استضافة تطبيقاتك ذاتياً على خادم VPS.

Caddy في Docker مع Docker Compose

يشغّل معظم المستضيفين ذاتياً Caddy داخل حاوية إلى جانب التطبيقات التي يقف أمامها. تجعل صورة caddy الرسمية هذا الأمر مسألة بضعة أسطر من Compose. والتفصيلة الوحيدة التي يغفلها الناس هي وحدة التخزين caddy_data: فهي تخزّن شهاداتك المُصدَرة، وبدونها يعيد كل إعادة تشغيل للحاوية طلب الشهادات ويمكن أن يصطدم بحدود معدّل Let's Encrypt.

services:
  caddy:
    image: caddy:2.11
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
  app:
    image: your-app-image
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

ولأن الحاويتين تتشاركان شبكة Compose، يمكن لملف Caddyfile الوصول إلى التطبيق باسم خدمته بدلاً من localhost:

app.example.com {
    reverse_proxy app:8080
}

هذا هو الإعداد بأكمله: docker compose up -d، ويقدّم Caddy الموقع app.example.com عبر HTTPS بشهادات تُجدَّد تلقائياً. وإذا كنت تفضّل أن تقود لوحة تحكّم كل هذا نيابةً عنك، فإن منصة مثل Coolify تغلّف الفكرة ذاتها؛ راجع دليلنا حول نشر أي تطبيق باستخدام Coolify.

Caddy مقابل Nginx مقابل Traefik: أي وكيل عكسي ينبغي أن تختار؟

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

الوكيل العكسي	أسلوب الإعداد	HTTPS تلقائي	ملاءمة Docker	الأنسب لـ
Caddy	Caddyfile (بضعة أسطر)	نعم، افتراضياً	إعداد بسيط وصريح	المستضيفون ذاتياً الذين يريدون HTTPS بلا إعداد تقريباً
Nginx	توجيهات nginx.conf	لا (يحتاج certbot)	يدوي، وناضج جداً	ضبط حركة المرور العالية ومحلات Nginx القائمة
Traefik	وسوم الحاويات / YAML	نعم، مع إعداد	يكتشف الحاويات تلقائياً	أساطيل Docker وKubernetes الديناميكية المبنية على الوسوم

إذا كنت تبدأ من الصفر وتريد فقط حفنة من الخدمات على HTTPS، فإن Caddy هو أسرع مسار. اختر Nginx إذا كنت تعرفه بالفعل أو تحتاج إلى منظومته الهائلة من الوحدات وضوابط الأداء الدقيقة. اختر Traefik إذا كانت حزمتك عالية الديناميكية وتريد أن يعيد الوكيل تهيئة نفسه مع ظهور الحاويات واختفائها، ولا تمانع في وجود أجزاء متحرّكة أكثر للوصول إلى ذلك.

أين يناسب Caddy مقابل Cloudflare Tunnel

يحلّ الوكيل العكسي والنفق مشكلات متداخلة بطريقتين متعاكستين، ومن الجدير معرفة أيهما تحتاج فعلاً. يتوقّع Caddy أن يكون المنفذان الواردان 80 و443 مفتوحَين حتى يستطيع قبول حركة المرور العامة وإصدار الشهادات مباشرةً. وهذا مثالي على خادم VPS بعنوان IP عام. أما Cloudflare Tunnel فيقوم بدلاً من ذلك بإنشاء اتصال صادر إلى Cloudflare ولا يحتاج إلى أي منافذ واردة مفتوحة على الإطلاق، وهو الأنسب خلف موجّه منزلي أو خلف NAT مقيّد حيث لا يمكنك إعادة توجيه المنافذ.

وهما ليسا متعارضين. يشغّل إعداد شائع Caddy كوكيل عكسي محلي يوجّه إلى تطبيقاتك وينهي اتصال TLS الداخلي، بينما يتولّى Cloudflare Tunnel الكشف العام والحماية على الحافة. إذا كان لخادمك عنوان IP عام وأردت أبسط حزمة ممكنة، فإن Caddy وحده كافٍ. وإذا كنت تستضيف من اتصال منزلي أو أردت حماية Cloudflare ضد هجمات DDoS في المقدّمة، فلجأ إلى النفق، أو ادمج الاثنين معاً.

الأسئلة الشائعة

هل استخدام Caddy مجاني؟ نعم. Caddy مفتوح المصدر بموجب رخصة Apache 2.0 ومجاني لأي استخدام، بما في ذلك التجاري. لا توجد فئة مدفوعة لميزات الوكيل العكسي، وHTTPS التلقائي عبر Let's Encrypt وZeroSSL لا يكلّف شيئاً.

هل يجدّد Caddy شهادات SSL تلقائياً؟ نعم. بمجرد أن يصدر Caddy شهادة لنطاق، فإنه يدير تجديدها من تلقاء نفسه، عادةً قبل انتهاء الصلاحية بمدة كافية، دون مهمة cron أو certbot. أبقِ دليل /data (أو وحدة التخزين caddy_data في Docker) دائماً حتى تبقى الشهادات بعد عمليات إعادة التشغيل.

Caddy مقابل Nginx: أيهما أفضل للوكيل العكسي؟ بالنسبة لمعظم الإعدادات المُستضافة ذاتياً، يكون Caddy أسهل لأن HTTPS تلقائي والإعداد بضعة أسطر. أما Nginx فهو أفضل إذا كنت تحتاج إلى منظومة وحداته الناضجة، أو كنت تضبط لحركة مرور عالية جداً، أو كنت تشغّله بالفعل. وكلاهما وكيلان عكسيان بمستوى الإنتاج.

هل يمكنني تشغيل Caddy كوكيل عكسي في Docker؟ نعم، وهي الطريقة الأكثر شيوعاً لتشغيله. استخدم صورة caddy الرسمية، وثبّت ملف Caddyfile، وأبقِ وحدة التخزين caddy_data دائمة حتى لا يُعاد طلب الشهادات عند كل إعادة تشغيل. وأشِر إلى التطبيقات باسم خدمتها في Compose بدلاً من localhost.

هل أحتاج إلى فتح أي منافذ؟ يحتاج Caddy إلى أن يكون المنفذان 80 و443 قابلَين للوصول من الإنترنت لإصدار الشهادات العامة وتقديم حركة المرور. وإذا لم تستطع فتح المنافذ الواردة، فاستخدم Cloudflare Tunnel بدلاً من ذلك، فهو يعمل عبر اتصال صادر.

Sources

• Caddy — بدء سريع للوكيل العكسي: ملف Caddyfile الأدنى الرسمي، وصيغة الأمر من سطر واحد، وكيف يستخدم HTTPS التلقائي المنفذين 80/443.
• Caddy — وثائق التثبيت: أوامر apt الحالية لـ Debian/Ubuntu وصورة Docker الرسمية.
• Caddy — إصدارات GitHub: الإصدار المستقر 2.11.4 (يونيو 2026)، وترويسة Host التلقائية للمصادر العليا عبر HTTPS منذ 2.11، وإصلاحات CVE-2026-27590 / 27589 (2.11.1).
• XDA — Caddy هو وكيلي العكسي المفضّل الجديد: رأي طرف ثالث حول سهولة حصول Caddy على SSL للتطبيقات المُستضافة ذاتياً.
• وثائق Traefik: وكيل عكسي مبني على الوسوم ويكتشف تلقائياً لأساطيل Docker/Kubernetes الديناميكية.