Caddy مقابل Nginx على خادم VPS: مقارنة ملفات الإعداد

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost: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;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

تفترض أسطر TLS في كتلة Nginx أن Certbot قد شُغِّل بالفعل. بالنسبة لمنبع HTTP كالذي أعلاه، يمرّر Caddy الترويسة Host الواردة كما هي ويضبط X-Forwarded-For, X-Forwarded-Proto، و X-Forwarded-Host افتراضيًا. مع Nginx، تضيف عادة ترويسات الوكيل صراحة عندما يحتاج المنبع إلى المضيف الأصلي والمخطط وسلسلة عنوان العميل. تلك هي المقايضة مصغّرة: يأتي Caddy بإعدادات وكيل عملية افتراضية، بينما يجعل Nginx مزيدًا من ذلك السلوك صريحًا.

تقديم الملفات الثابتة:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

المصادقة الأساسية، تحمي كل شيء خلف اسم مستخدم وكلمة مرور:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost: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;
    }
}

تقوم كلتا الأداتين بتجزئة كلمة المرور خارج النطاق. يستخدم Caddy caddy hash-password؛ يستخدم Nginx htpasswd لبناء ملف .htpasswd. التوجيه هو basic_auth في Caddy الحالي، بالمناسبة. كان basicauth حتى أعاد v2.8.0 تسميته، كما هو مذكور في توثيق basic_auth في Caddy، ولا تزال الدروس القديمة توقع الناس فيه.

نصيحة احترافية: تلك التجزئة في الـ Caddyfile ليست كلمة المرور. إنها ناتج bcrypt من caddy hash-password. شغّل الأمر، والصق ما يطبعه. يرفض Caddy كلمات المرور النصية الصريحة في الإعداد، وهو الإعداد الافتراضي الصحيح ومفاجأة صغيرة في المرة الأولى.

الإعدادات تدافع عن نفسها. يطوي Caddy طبقة TLS وترويسات وكيل معقولة وإعادة توجيه في بضعة أسطر؛ أما Nginx فصريح ومُسهب ويسلّمك كل مقبض. إذا قضيت سنوات في Nginx، فالإسهاب ذاكرة عضلية والتحكم هو المقصود. إذا لم تفعل، فالـ Caddyfile إعداد يمكنك أن تحفظه في ذهنك. النقطة العملية بسيطة: إعداد Caddy أسهل للقراءة بنظرة سريعة، بينما يمنحك Nginx تحكمًا أكثر صراحة.

الأداء والذاكرة: قراءة نتائج القياس بعناية

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

In اختبار جهاز افتراضي رباعي النوى من طرف ثالث، بلغ Nginx نحو 48,000 طلب في الثانية، مقارنة بنحو 42,000 لـ Caddy. أبلغ الاختبار نفسه عن زمن استجابة HTTPS p99 قدره 2.1 ms لـ Nginx و2.4 ms لـ Caddy. تعامل مع هذه كنتائج من إعداد واحد لا كهامش أداء عام.

نطاقات الذاكرة في جدول المقارنة مأخوذة من اختبار VPS منفصل. أبلغ اختبار اصطناعي آخر عند 50,000 اتصال متزامن عن 145 MB لـ Nginx و520 MB لـ Caddy، لكن ذلك الاختبار استخدم عتادًا وظروف عبء عمل مختلفة بشكل جوهري. لا ينبغي مقارنة أرقامه المطلقة مباشرة بأرقام VPS أعلاه.

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

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

مأخذ شهادة wildcard (Caddy ليس دائمًا عديم الإعداد)

يستطيع Caddy أتمتة شهادات wildcard، لكن ليس بتحدّياته الافتراضية HTTP-01 أو TLS-ALPN-01. الشهادة لـ *.example.com تتطلب التحقق عبر DNS-01، وهو ما يفرضه Let's Encrypt لشهادات wildcard. يعني ذلك إضافة مزوّد DNS (مبنية في ثنائي Caddy لديك عبر xcaddy) إضافة إلى رمز API لمضيف DNS الخاص بك، مُعدّة في كتلة tls. إنها ليست قصة اكتب-سطرًا-واحدًا-وامضِ التي يروّج لها Caddy.

هذا يوقع مستخدمي المختبرات المنزلية الذين يضعون خدمات كثيرة تحت نطاق حقيقي يتحكمون به، مثل *.home.example.com، ويفترضون أن إصدار wildcard تلقائي مثل app.example.com. بالنسبة للأسماء الداخلية البحتة مثل *.homelab.internal، تعامل مع ذلك على أنه مجال PKI محلي/داخلي، لا wildcard عامًا من Let's Encrypt. لنكون دقيقين: Caddy يتعامل مع wildcard جيدًا، لكنه فقط لا يفعل ذلك بالتحدّيات الافتراضية، والإعداد خطوة أعلى من حالة النطاق الواحد. Nginx في الوضع نفسه هنا، لأن متطلب DNS-01 يأتي من Let's Encrypt، لا من الخادم.

إذا أردت واجهة GUI: Nginx Proxy Manager (استطراد قصير)

Nginx Proxy Manager كائن مختلف عن الأداتين أعلاه، ويستحق فقرة واحدة لأن الاسم يربك الناس. NPM هو غلاف GUI فوق Nginx: يدير قواعد الوكيل العكسي وشهادات Let's Encrypt عبر واجهة ويب على port 81. إنه ليس نواة Nginx، ولا يُعَدّ بالطريقة التي تُعَدّ بها نواة Nginx.

المقايضة هي المعتادة بين النقر والإعداد. NPM هو الزر السهل حتى تخرج عن المسار الميسّر. يُدار إعداده عبر قاعدة بيانات تطبيق بدلًا من ملف إعداد واحد مُحرَّر يدويًا. يستخدم إعداد Docker الافتراضي SQLite، بينما MySQL/MariaDB وPostgreSQL خيارات قواعد بيانات خارجية مدعومة. يؤثر ذلك الفرق أيضًا على قابلية النقل: يمكن غالبًا نقل إعداد Caddy بنسخ ملف Caddyfile واحد، بينما تتطلب عملية نشر Nginx Proxy Manager الحفاظ على بيانات التطبيق وقاعدة البيانات الخاصة به . NPM خيار جيد إذا كنت تفضّل فعلًا النقر على التحرير وبقي إعدادك بسيطًا. إنه الخيار الخاطئ لسير عمل البنية التحتية كشيفرة.

الترحيل من Nginx إلى Caddy (ما ينتقل وما لا ينتقل)

إذا كنت بالفعل على Nginx وتزن الانتقال، فابدأ بخفض توقعاتك بشأن الأتمتة: هناك محوّل إعداد NGINX لـ Caddy، لكنه غير مكتمل ولا ينبغي التعامل معه كمسار ترحيل موثوق بضربة واحدة. الترحيل من Nginx إلى Caddy هو في الأغلب إعادة كتابة يدوية، ومعظمه يصبح أقصر.

ما ينتقل ويصبح أبسط، وفقًا لـ دليل التحويل من مجتمع Caddy:

• بالنسبة لمنابع HTTP، reverse_proxy يمرّر الترويسة Host الواردة كما هي و يضبط ترويسات X-Forwarded-* القياسية افتراضيًا، لذا فإن معظم تلك proxy_set_header الأسطر تختفي.
• ينهار PHP من كتلة location مع try_files إضافة fastcgi_pass إضافة إلى كومة من المعاملات إلى توجيه php_fastcgi واحد.
• معالجة WebSocket تلقائية في Caddy v2. إذا أخبرك درس بإضافة توجيه منفصل websocket ، فهذا من مخلّفات Caddy v1. تجاهله.

ما لا ينتقل تلقائيًا: أي شيء مرتبط بوحدة Nginx محددة لا يمتلكها Caddy، ومنطق rewrite وlocation المعقّد الذي ستحتاج إلى إعادة التفكير فيه بدلًا من نقله، وإعدادات شهادات wildcard التي تعيدك إلى إعداد تحدّي DNS من القسم أعلاه. خصّص ميزانية للوحدات وعمليات إعادة الكتابة؛ والباقي عادة خفض صافٍ في عدد الأسطر.

أيهما ينبغي أن تثبّت؟ (القرار)

لقد رأيت الإعدادات والأرقام ومأخذ wildcard وتكلفة الترحيل، وإليك أين يستقرّ الأمر. ثبّت Caddy إذا كنت مطورًا منفردًا أو فريقًا صغيرًا، أو كان هذا نشرًا على خادم VPS جديد، أو أردت TLS تُعدّه وتنساه، أو كنت تشغّل Docker بتوجيه بسيط، أو أردت فقط إعدادًا يناسب الذاكرة العضلية. هذا ينطبق على معظم من يقرؤون هذا.

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

أيًّا استقرّ رأيك عليه، فالخطوة التالية هي وضعه على الجهاز. كلاهما Caddy و Nginx متاحان كعمليات نشر بنقرة واحدة في سوقنا، لذا يمكنك تخطّي عمل التثبيت والانتقال مباشرة إلى الـ Caddyfile أو كتلة الخادم. خادم VPS بسعة 1 GB نقطة بداية معقولة لنشر موقع واحد قليل الحركة، لكن حدّد حجم الخادم للتطبيق وحركة المرور خلف الوكيل لا للوكيل وحده. إذا كنت تستخدم Caddy كواجهة أمامية للخدمات المُستضافة ذاتيًا، فيمكنه أن يقف أمام مكدّس مراقبة Prometheus وGrafana أو عملية نشر Uptime Kuma دون الحاجة إلى أدوات TLS منفصلة.

خلاصة القسم: اختر Caddy ما لم يكن لديك سبب محدد يشير إلى Nginx.

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