إن تفعيل HTTPS للوحة تحكم ZimaOS لا يمنح تلقائيًا Jellyfin أو Vaultwarden أو Nginx Proxy Manager أو أي تطبيق Docker آخر عنوانًا يعمل عبر HTTPS. وهذا الالتباس تحديدًا هو ما أدى إلى بدء هذا النقاش في فبراير 2026. كان المستخدم قد فعّل HTTPS في إعدادات ZimaOS، وحفظ الشهادة التي أُنشئت لواجهة ZimaOS، وحاول استيرادها إلى Nginx Proxy Manager، لكن Jellyfin وNPM لم يعملا كما هو متوقع.
انتهى النقاش في النهاية إلى إعداد عملي اقترحه المجتمع: استخدام Nginx Proxy Manager كنقطة إنهاء TLS للتطبيقات الفردية، ونقل بوابة ZimaOS بعيدًا عن المنفذين 80 و443 إذا كان الوكيل العكسي يحتاج إليهما، وتهيئة اسم مضيف عبر DuckDNS، وإصدار شهادة لهذا الاسم. ونشر المستخدم لاحقًا لقطة شاشة تُظهر أن المضيفات الوكيلة تعمل، ولخّص النتيجة بأنها ناجحة.
افهم طبقات HTTPS الثلاث المنفصلة
هناك ثلاثة أشياء مختلفة يسهل الخلط بينها:
- HTTPS للوحة تحكم ZimaOS يحمي واجهة إدارة ZimaOS نفسها.
- HTTP الخاص بالتطبيق هو المنفذ الداخلي المعتاد الذي يستخدمه تطبيق مثل Jellyfin.
- HTTPS الخاص بالوكيل العكسي هو اسم مضيف عام أو محلي ينهي TLS ويوجّه حركة المرور إلى منفذ HTTP الداخلي للتطبيق.
لذلك فالشهادة التي أُنشئت لواجهة إدارة ZimaOS ليست شهادة شاملة لكل تطبيق. يحتاج الوكيل العكسي إلى شهادة يطابق اسم مضيفها العنوان الذي يفتحه المستخدمون فعليًا في المتصفح.
استخدم Nginx Proxy Manager كبوابة HTTPS الأمامية
أهم جزء قابل لإعادة الاستخدام في حل المجتمع هو البنية، وليس أرقام المنافذ المحددة لعام 2026. يستقبل Nginx Proxy Manager طلبات HTTPS لأسماء مضيفين مثل jellyfin.example.net، ثم يوجّهها إلى خدمة Jellyfin المحلية عبر HTTP. ويمكن لـ Jellyfin مواصلة الاستماع على منفذه الداخلي المعتاد؛ إذ لا يحتاج إلى إدارة الشهادة العامة بنفسه.
يحافظ Nginx Proxy Manager حاليًا على هذا النموذج: أنشئ Proxy Host، وحدد المضيف والمنفذ الوجهة، ثم أرفق شهادة SSL وفعّل فرض SSL اختياريًا. عند إعداد نظام جديد، اتبع التدفق الحالي في Nginx Proxy Manager للمضيفات الوكيلة والشهادات بدل التعامل مع لقطة شاشة قديمة باعتبارها وصفًا ثابتًا للواجهة.
عالج تعارضَي المنفذين 80 و443 قبل إصدار الشهادات
اكتشف المستخدم أن بوابة ZimaOS تستخدم المنفذين 80 و443 مسبقًا. وهذا مهم لأن الوكيل العكسي يحتاج عادةً إلى الاستماع على هذين المنفذين القياسيين. وكان الحل البديل الذي استخدمه هو تغيير منافذ بوابة ZimaOS في /etc/casaos/gateway.ini، ونقل المنفذ 80 إلى 85 والمنفذ 443 إلى 444، ثم إعادة تشغيل خدمة البوابة.
جاءت هذه التعديلات المحددة من المستخدم، وليس من رد دعم رسمي من IceWhale في هذا النقاش. لذلك ينبغي اعتبارها حلًا مجتمعيًا تاريخيًا، لا سلسلة أوامر عامة تصلح للجميع. قبل تغيير منافذ لوحة التحكم، سجّل عنوان URL الحالي، وتأكد من أنك تعرف كيفية الوصول إلى ZimaOS بعد التغيير، وفضّل استخدام واجهة ZimaOS الحالية عندما توفر طريقة مدعومة لتغيير منفذ الإدارة.
لماذا ساعد DuckDNS المستخدم المذكور؟
تحتاج جهة إصدار الشهادة إلى اسم مضيف يمكنها التحقق منه. أعدّ المستخدم DuckDNS، ثم استخدم اسم المضيف لطلب شهادة من خلال Nginx Proxy Manager. وقد عالج ذلك مشكلة مختلفة عن سؤال «كيف أصل إلى التطبيق؟»: وفّر DNS الاسم، بينما وفّر NPM إنهاء HTTPS وإعادة التوجيه.
حتى HTTPS المحلي فقط يحتاج إلى DNS يحلّ الأسماء محليًا
كان السؤال الأصلي يتعلق تحديدًا باستخدام HTTPS داخل الشبكة المحلية، وليس بالوصول عن بُعد. ولا يؤدي اسم النطاق إلى إجبار حركة المرور على مغادرة المنزل. يمكنك جعل اسم مضيف يُحل إلى عنوان ZimaOS داخل الشبكة المحلية عبر DNS محلي أو DNS منقسم، ثم جعل Nginx Proxy Manager يقدّم شهادة موثوقة لهذا الاسم.
يكون هذا عادةً أنظف من التصفح إلى عنوان IP خاص خام ومحاولة جعل شهادة عامة تطابقه. تُتحقق الشهادة من اسم المضيف، بينما يقرر DNS المحلي أن اسم المضيف يجب أن يُحل إلى عنوان خاص.
الشهادة الموقعة ذاتيًا خيار آخر، لكن يجب إدارة الثقة
اقترح أحد أعضاء المجتمع إنشاء شهادة باستخدام OpenSSL واستيرادها إلى Nginx Proxy Manager. قد ينجح ذلك للاستخدام المحلي البحت، لكن المتصفحات والأجهزة لن تثق تلقائيًا بشهادة موقعة ذاتيًا. ويجب على كل عميل ينبغي أن يعرض اتصال HTTPS نظيفًا أن يثق بالشهادة المصدرة أو بسلطة الشهادات المحلية.
بالنسبة إلى منزل يضم العديد من الهواتف وأجهزة التلفاز والأجهزة اللوحية والتطبيقات، يكون استخدام شهادة موثوقة علنًا لاسم مضيف غالبًا أسهل من تثبيت سلطة شهادات محلية يدويًا على كل جهاز.
Cloudflare بنية بديلة، وليس شرطًا
قال مشارك آخر إنه يستخدم Cloudflare داخل الشبكة المنزلية وخارجها. قد يكون Cloudflare مفيدًا إذا كان الاسم نفسه يجب أن يعمل عن بُعد، لكن السؤال الأصلي لم يتطلب وصولًا عامًا. لا تضف نفقًا لمجرد أنك تريد HTTPS على الشبكة المحلية.
تحقق من كل طبقة على حدة
- تأكد من أن التطبيق يفتح عبر عنوان HTTP المحلي المباشر.
- تأكد من أن اسم المضيف يُحل إلى الوكيل العكسي المقصود.
- تأكد من أن Nginx Proxy Manager يستطيع الوصول إلى مضيف التطبيق ومنفذه الداخليين.
- أرفق الشهادة فقط بعد نجاح التوجيه العادي عبر الوكيل.
- بعد ذلك فعّل فرض HTTPS واختبر من أكثر من عميل محلي.
يمنع هذا الترتيب الخلط بين مشكلة في الشهادة ومشكلة في توجيه Docker أو تعارض في المنافذ.
الأسئلة الشائعة حول HTTPS المحلي في ZimaOS
هل يؤمّن مفتاح HTTPS في ZimaOS تطبيق Jellyfin تلقائيًا؟
لا. فهو يؤمّن واجهة إدارة ZimaOS، وليس كل تطبيقات Docker.
هل أحتاج إلى نطاق عام لاستخدام HTTPS داخل الشبكة المحلية فقط؟
تحتاج إلى اسم مضيف تطابقه شهادتك. ويمكن لهذا الاسم أن يُحل إلى عنوان خاص بالشبكة المحلية داخل شبكتك.
لماذا نقل المستخدم المذكور ZimaOS بعيدًا عن المنفذين 80 و443؟
كان Nginx Proxy Manager يحتاج إلى منفذي HTTP وHTTPS القياسيين. وكان هذا التغيير حلًا بديلًا من المجتمع لذلك التثبيت.
هل تأكد نجاح إعداد المستخدم المذكور؟
نعم. عرض صاحب المنشور الأصلي مضيفات NPM متصلة بالإنترنت مع الشهادات، وقال إن الإعداد نجح.
