كيفية تثبيت خادم الويب Caddy مع HTTPS تلقائي

Caddy خادم ويب يحصل على شهادات TLS ويجدّدها افتراضيًا. لـ VPS صغير يستضيف نطاقًا أو اثنين يزيل ذلك فئة كاملة من مؤقتات Certbot وملفات مقتطفات Nginx. لغة الإعداد (Caddyfile) قصيرة. الوكيل العكسي وgzip وHTTP/2 ميزات عادية، لا عطلة نهاية أسبوع من وحدات إضافية.

Nginx ما زال الخيار الصحيح لبعض الفرق: لديكم إعدادات مجرَّبة في المعركة، أو تحتاجون وحدة محددة جدًا. هذا الدليل للحالة الشائعة الأخرى — تريد HTTPS يعمل على VPS جديد من Hiddence دون حفظ مقتطفات include. سنثبّت Caddy من مستودع apt الرسمي، ونشرح كيف يتحدث إلى Let's Encrypt، ونخدم موقعًا ثابتًا، ونوكّل تطبيقًا محليًا، ونستضيف عدة نطاقات، وننظر إلى السجلات، ونغطي معارك المنفذ 80 المعتادة مع Apache أو Nginx قديم.

متى يناسب Caddy

HTTPS التلقائي هو العنوان، لكن المكسب اليومي أجزاء متحركة أقل. يستمع Caddy على 80 و443، ويعيد توجيه HTTP إلى HTTPS، ويخزّن الشهادات في دليل بياناته. ما زلت تحتاج نطاقًا يشير إلى VPS. ما زلت تحتاج ألا تكسر ACME (جدار الحماية 80/tcp، لا عملية أخرى تسرق :80). شهادات البدل تحتاج وحدة مزوّد DNS — ذلك مسار أطول من شهادة مضيف واحد.

• HTTP→HTTPS تلقائي وتجديد الشهادات
• Caddyfile قابل للقراءة بدل كتل خادم طويلة
• وكيل عكسي قادر لـ Node وPython وPHP-FPM بإعداد إضافي أو خلفيات Docker
• HTTP/2 وافتراضيات TLS حديثة دون جدول شفرات
• وحدة systemd من الحزمة الرسمية

المتطلبات

يجب أن يُحل نطاق إلى هذا VPS قبل أن يستطيع Caddy إثبات ACME HTTP-01. إن كان DNS ما زال ينتشر سيفشل الإصدار ويعيد المحاولة؛ يبدو ذلك كـ «Caddy معطوب» بينما هو DNS فقط. أوقف Apache أو Nginx أولًا إن كانا يملكان 80/443.

• Ubuntu 22.04 أو 24.04
• سجل A للنطاق إلى عنوان IP لـ VPS (وAAAA إن استخدمت IPv6)
• المنفذان 80 و443 حرّان ومسموح بهما في جدار الحماية
• Root أو sudo

الخطوة 1: ثبّت Caddy من المستودع الرسمي

لا تثبّت Caddy قديمًا عشوائيًا من Ubuntu universe الافتراضي إن أردت سلوك TLS وACME الحالي. يوثّق مشروع Caddy مصدر apt. بعد التثبيت يوجد مستخدم caddy وتكون الخدمة مفعّلة.

ssh root@YOUR_VPS_IP
apt update && apt -y install debian-keyring debian-archive-keyring apt-transport-https curl gpg

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

apt update
apt -y install caddy

caddy version
systemctl status caddy --no-pager

الخطوة 2: أول Caddyfile — موقع ثابت

Caddyfile الافتراضي هو /etc/caddy/Caddyfile. استبدله بنطاقك. سيحاول Caddy الحصول على شهادة فور تحميل الإعداد إن لم يكن اسم المضيف localhost. ضع ملفات الموقع في دليل يقرؤه مستخدم caddy (غالبًا أذونات بأسلوب www-data، لكن الحزمة تستخدم المستخدم caddy).

mkdir -p /var/www/example
echo '<h1>It works</h1>' > /var/www/example/index.html
chown -R caddy:caddy /var/www/example

cat >/etc/caddy/Caddyfile <<'EOF'
example.com {
    root * /var/www/example
    file_server
    encode gzip
}
EOF

caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy

# Watch issuance:
journalctl -u caddy -f

الخطوة 3: وكّل تطبيقًا محليًا عكسيًا

إن استمع Gunicorn أو Node أو Docker على 127.0.0.1:8000 فيجب أن يكون Caddy العملية العامة الوحيدة. توجّه تعليمة reverse_proxy ترويسات Host وX-Forwarded-* بطريقة معقولة لمعظم التطبيقات. إن ولّد التطبيق عناوين HTTP مطلقة فاضبط أعلام الوكيل الموثوق / HTTPS في التطبيق (Django SECURE_PROXY_SSL_HEADER وExpress trust proxy وما شابه).

app.example.com {
    encode gzip
    reverse_proxy 127.0.0.1:8000
}

# Several hosts in one file are normal:
# blog.example.com {
#     root * /var/www/blog
#     file_server
# }

الخطوة 4: جدار الحماية وsystemd

اسمح بـ 80 و443. وحدة Caddy هي caddy.service؛ يكفي reload بعد تعديلات Caddyfile إن كانت العملية سليمة. إن غيّرت متغيرات بيئة لإضافة DNS فإعادة تشغيل كاملة أوضح. تعيش الشهادات تحت /var/lib/caddy/.local/share/caddy/ افتراضيًا — أدرج ذلك المسار في النسخ الاحتياطية إن كنت تهتم بحدود المعدل أثناء إعادة التثبيت.

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

systemctl enable --now caddy
systemctl reload caddy

# Backup cert storage (path may vary slightly by version):
ls -la /var/lib/caddy/

الخطوة 5: السجلات والضغط والترويسات

سجلات الوصول تساعد عندما يطرق روبوت مسارًا أو عند تصحيح 404. يمكنك التسجيل لكل موقع. أضف ترويسات أمان إن استضفت تطبيق متصفح؛ لا تنسخ حزمة ترويسات ضخمة دون فهم HSTS (بعد تعيين max-age طويل تتذكره المتصفحات).

example.com {
    root * /var/www/example
    file_server
    encode gzip
    log {
        output file /var/log/caddy/example.log
    }
    header {
        X-Content-Type-Options nosniff
        Referrer-Policy no-referrer-when-downgrade
        -Server
    }
}

mkdir -p /var/log/caddy
chown caddy:caddy /var/log/caddy
systemctl reload caddy

الخطوة 6: PHP وإضافات أخرى

يستطيع Caddy التحدث إلى PHP-FPM بتعليمة php_fastcgi. هذا كافٍ لكثير من استضافات WordPress أو Laravel، لكن ما زلت تحتاج php-fpm مثبتًا ومسار مقبس مطابق. إن كان لديك إعداد Nginx PHP مثالي فالهجرة في مساء واحد اختيارية — يتألق Caddy أكثر على وكيل عكسي + ثابت + TLS تلقائي.

example.com {
    root * /var/www/example
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

# Confirm FPM is running:
systemctl status php8.3-fpm

الهجرة من Nginx دون مفاجآت توقف

أوقف Nginx قبل تشغيل Caddy وإلا سيتقاتلان على 80/443. اخفض TTL لـ DNS في اليوم السابق إن كنت تنقل عناوين IP أيضًا. اختبر بـ curl --resolve حتى تصيب VPS الجديد قبل تبديل سجل A. أبقِ إعدادات Nginx في git لأسبوع إن احتجت التراجع.

• systemctl stop nginx && systemctl disable nginx
• ثبّت Caddy، تحقق من Caddyfile، شغّل Caddy
• curl -I --resolve example.com:443:NEW_IP https://example.com
• غيّر DNS حينها فقط إن كان عنوان IP جديدًا
• إعادة الإصدار تلقائية؛ لا تشغّل Certbot أيضًا ضد اسم المضيف نفسه

استكشاف الأخطاء

إخفاقات ACME شبه دائمًا DNS أو جدار حماية أو خدمة أخرى على المنفذ 80. تذكر أسطر سجل Caddy tls.obtain. إن عمل الموقع على HTTP لا HTTPS فلم يكتمل الإصدار أبدًا. إن رأيت شهادات أكثر من اللازم فقد ضربت حدود معدل Let's Encrypt — استخدم المرجع المصدّق التجريبي أثناء الاختبار لا الإنتاج.

• فشل validate: صياغة Caddyfile، قوس مفقود
• permission denied على الجذر: chown caddy لدليل الموقع
• bind: address already in use — ss -tulpn | grep -E ':80|:443'
• انتهاء مهلة الشهادة: dig +short للنطاق من VPS، ufw allow 80
• 502 reverse_proxy: الخلفية متوقفة، أو وكّلت إلى localhost من شبكة حاوية بشكل خاطئ

ملاحظات أمان

افتراضيات TLS في Caddy محافظة. مهمتك أمان التطبيق وSSH. لا تفعّل واجهة إدارة Caddy على واجهة عامة. نقطة الإدارة الافتراضية محلية؛ اتركها كذلك. إن استخدمت Caddyfile من الإنترنت فاقرأ كل مطابق — مقتطف يوكّل /* إلى عنوان IP داخلي قد يصبح وكيلًا مفتوحًا.

• لا تعرض واجهة الإدارة
• أبقِ الحزمة محدَّثة
• HSTS فقط بعد التأكد أن HTTPS يعمل لكل أسماء المضيف
• افصل أسماء مضيف الاختبار والإنتاج لحماية حدود معدل ACME

نصائح

• caddy fmt --overwrite /etc/caddy/Caddyfile يُبقي الملف قابلًا للقراءة
• استخدم مقتطفات import عندما يكون لديك مواقع متشابهة كثيرة
• لـ Docker صورة caddy:alpine مع Caddyfile مركَّب شائعة
• شهادات البدل تحتاج وحدة DNS ورمز API — احمِ ذلك الرمز
• اقرأ journalctl -u caddy قبل إعادة كتابة الملف كله

Caddy على VPS هو: حزمة رسمية، وCaddyfile قصير، ومنافذ 80/443 مفتوحة، وDNS يشير أصلًا إلى الخادم، وsystemd reload بعد التعديلات. استخدمه كخادم ملفات ثابتة أو وكيل عكسي أمام Gunicorn أو Node أو Docker. يعمل HTTPS التلقائي عندما يستطيع ACME الإجابة على المنفذ 80؛ إن فشل الإصدار فأصلح DNS وتعارضات المنافذ قبل أن تلوم Caddy. انسخ /var/lib/caddy احتياطيًا إن أعدت التثبيت كثيرًا.