هذا المقال يتطلب مستوى: مبتدئ.

Caddy: reverse proxy وHTTPS تلقائي في 3 أسطر

لو بتجدّد شهادة SSL بإيدك كل 3 شهور، وبتكتب عشرات أسطر إعداد عشان توجّه دومين على تطبيقك، Caddy بيعمل ده كله في 3 أسطر، ويجدّد الشهادة لوحده قبل ما تنتهي. اللي هتكسبه: إعداد أقصر، وقفل نهائي لثغرة "نسيت أجدّد الشهادة".

المشكلة باختصار

أي تطبيق ويب محتاج قدّامه حاجة تستقبل طلبات الإنترنت، توزّعها على الخدمات الصح، وتأمّنها بـ HTTPS. الأداة دي اسمها reverse proxy. الطريقة الشائعة: تركّب Nginx، تكتب إعداد طويل، وتركّب Certbot منفصل عشان الشهادات. الطريقة دي بتفشل في نقطة واحدة متكررة: تجديد الشهادة خطوة منفصلة، ولو اتنسيت أو وقع الـ cron، المتصفح بيرفض موقعك ويعرض تحذير أمان للزوّار.

يعني إيه reverse proxy؟ (بمثال بسيط الأول)

تخيّل كومباوند فيه 5 فيلات وبوّابة واحدة. الزائر اللي جاي مش بيدخل ويلفّ يدوّر على الفيلا بنفسه. هو بيكلّم حارس البوّابة بس، يقوله "عايز فيلا رقم 3"، والحارس هو اللي يوصّله. الحارس كمان بيتأكد إن اللي داخل آمن، وبيمنع الزحمة.

الـ reverse proxy هو حارس البوّابة ده بالظبط. علميًا: هو خادم وسيط بيستقبل طلب العميل (المتصفح)، يقرّر أي خدمة خلفية مسؤولة عنه (تطبيق Node على port 3000، أو API على port 8080)، يوجّه الطلب لها، ويرجّع الرد. وفي الطريق بيتعامل مع تشفير TLS، يعني فكّ وتركيب HTTPS بدل ما كل تطبيق يعمل ده بنفسه.

إزاي Caddy بيجيب الشهادة لوحده؟

Caddy بيستخدم بروتوكول اسمه ACME عشان يطلب شهادة مجانية من Let's Encrypt. باختصار: Caddy بيقول لـ Let's Encrypt إنه بيمتلك الدومين، وLet's Encrypt بيبعت تحدّي بسيط على port 80 للتأكد، وبعد ما يتأكد بيصدر الشهادة. وأهم نقطة: شهادات Let's Encrypt صالحة 90 يوم بس، وCaddy بيجدّدها أوتوماتيك وهي لسه فاضلها حوالي 30 يوم، من غير أي تدخل منك.

الإعداد الفعلي: ملف Caddyfile

ده ملف Caddyfile كامل يوجّه دومينين على تطبيقين، ويفعّل HTTPS تلقائيًا للاتنين:

example.com {
    reverse_proxy localhost:3000
}

api.example.com {
    reverse_proxy localhost:8080
}

مفيش سطر واحد عن الشهادات. بمجرد ما الدومين بيشاور على سيرفرك وport 80/443 مفتوحين، Caddy بيجيب الشهادة ويفعّلها لوحده. التثبيت على Ubuntu والتشغيل:

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
sudo apt update && sudo apt install caddy
sudo systemctl reload caddy

الأرقام وما الذي تكسبه فعلاً

الإعداد المكافئ في Nginx لنفس الحالة (دومينين + HTTPS + تجديد) بيوصل بسهولة لـ 40 إلى 60 سطر، زائد إعداد Certbot وcron job منفصل للتجديد. هنا 6 أسطر. عدد نقاط الفشل اللي بتختفي: واحدة كبيرة، وهي تجديد الشهادة اليدوي. الافتراض: عندك دومين عام حقيقي، وport 80 و443 مفتوحين عشان تحدّي ACME ينجح.

الـ trade-off مقابل Nginx

مفيش أداة مجانية. بتكسب: HTTPS تلقائي، إعداد أقصر بكتير، وتجديد بدون تدخل. بتخسر: Nginx مكتوب بلغة C وأداؤه الخام تحت الحمل العنيف جدًا (عشرات آلاف الطلبات/ثانية) أعلى من Caddy المكتوب بـ Go. لكن لو موقعك أقل من المستوى ده، الفرق مش هتحسّه أصلًا.

متى لا تستخدم هذه الطريقة

• لو الخدمة خلف شبكة داخلية بدون دومين عام: تحدّي ACME على port 80 مش هيشتغل. هتحتاج DNS challenge أو شهادة داخلية.
• لو عندك إعداد Nginx ضخم شغّال ومستقر وفريق متمرّس عليه: التحويل مش أولوية.
• لو محتاج وحدات متخصصة في Nginx (زي بثّ RTMP) مش موجودة في Caddy افتراضيًا.

التحقق من أنه يعمل

curl -I https://example.com

المفروض ترجع HTTP/2 200 من غير أي تحذير شهادة.

الخطوة التالية

خُد دومين تجريبي تملكه، وجّهه (A record) على سيرفرك، حط الـ Caddyfile اللي فوق بدومينك بدل example.com، وشغّل sudo systemctl reload caddy. افتح الدومين في المتصفح: المفروض تلاقي القفل الأخضر اشتغل من أول مرة. لو ظهر تحذير، الغالب إن port 80 مقفول؛ افتحه في الـ firewall وأعد المحاولة.

المصادر

• توثيق Caddy الرسمي — Automatic HTTPS: caddyserver.com/docs/automatic-https
• توثيق Caddy — Caddyfile reverse_proxy: caddyserver.com/docs/caddyfile/directives/reverse_proxy
• Let's Encrypt — How It Works: letsencrypt.org/how-it-works
• بروتوكول ACME — RFC 8555: datatracker.ietf.org/doc/html/rfc8555