شكرًا لك، لم أكن قد رأيت طلب الدمج (PR) هذا. الأمر مثير للاهتمام - إعدادي مختلف قليلاً في أنني أبقيت على خادم الويب Nginx الخاص بـ Discourse كما هو، وأقوم بتشغيل Caddy بشكل منفصل في Docker Compose أمامه، وذلك بشكل أساسي لتوفير HTTP/3 على الحافة.
هناك تغيير صغير على جانب Discourse: أضفت نقطة ربط دائمة في ملف app.yml بحيث يستخدم Nginx قيمة X-Forwarded-For الخاصة بـ Caddy لتحديد عنوان IP الحقيقي للعميل عند وصول الطلبات عبر المقبض Unix. كنت بحاجة في البداية إلى حل بديل باستخدام X-Real-IP في Caddy، ولكن بعد إضافة الإصلاح على جانب Nginx، تمكنت من إزالة ذلك والتحقق من أن Discourse لا يزال يسجل عنوان IP الصحيح للعميل.
كما قمت بتعطيل QUIC 0-RTT/البيانات المبكرة صراحةً في تكوين Caddy مع الإبقاء على تمكين HTTP/3، لتجنب حالة الحافة الإضافية المتعلقة بالبيانات المبكرة.
يتمكين نهجي أيضًا من تسجيل الوصول إلى HTTP في Caddy على مستوى الموقع، مما يمنحني التخفي الافتراضي للرؤوس الحساسة للمصادقة في Caddy. أقوم بتدوير سجلات json-file الناتجة في Docker عند حجم 25 ميجابايت × 3. لاحظت أن طلب الدمج (PR) الحالي يحتوي على كتلة تدوير السجلات في الخيارات العامة لـ Caddy، وهو ما تصفه وثائق Caddy بأنه تكوين للسجلات التشغيلية بدلاً من سجلات الوصول إلى HTTP.
لذا، فهو ليس تثبيتًا قياسيًا غير مستوعب تمامًا، ولكنه أيضًا نهج مختلف عن استبدال Nginx بـ Caddy بالكامل.
سألقي نظرة فاحصة على طلب الدمج (PR) هذا. في الوقت الحالي، أنا مهتم بشكل أساسي بمعرفة ما إذا كان هناك اهتمام كافٍ بهذا النهج لجعل دليل خطوة بخطوة يستحق الجهد، بدلاً من البدء في إنشاء واحد على الفور.