إصلاح تحذيرات HTTPS على ZimaOS والتطبيقات المستضافة ذاتيًا

إذا حذّرك المتصفح من أن لوحة معلومات ZimaOS أو التطبيقات «غير آمنة»، فافصل أولًا بين لوحة معلومات ZimaOS الرئيسية والتطبيقات التي تعمل عبر منافذها الخاصة. خلص موضوع المصدر في النهاية إلى أن هاتين مشكلتان مختلفتان في HTTPS.

يمكن لـ ZimaOS إنشاء شهادة محلية للنطاق https://zimaos.local. وقد يؤدي منح الثقة لهذه الشهادة إلى إزالة تحذير المتصفح الخاص بلوحة معلومات ZimaOS. لكنه لا يمنح HTTPS تلقائيًا لـ Plex أو Jellyfin أو Emby أو AdGuard أو تطبيقات Docker الأخرى، لأن هذه خدمات HTTP منفصلة. لوضع العديد من التطبيقات خلف أسماء HTTPS موثوقة، استخدم وكيلًا عكسيًا مثل Nginx Proxy Manager أو Caddy مع الشهادات المناسبة.

تحذير المتصفح الأصلي

الخيار 1: تعطيل HTTPS للوحة معلومات ZimaOS المحلية

ذكر Zima-Giorgio أنه يمكن إيقاف تشغيل HTTPS من لوحة إعدادات ZimaOS. في شبكة LAN خاصة موثوقة، قد يزيل HTTP العادي إزعاج تحذيرات الشهادة، لكنه يزيل أيضًا تشفير النقل بين المتصفح ولوحة المعلومات.

بالنسبة إلى أجهزة الكمبيوتر المحمولة أو الأجهزة التي تنتقل بين الشبكات، يكون منح الثقة لشهادة ZimaOS أفضل عادةً من إضعاف أمان المتصفح على مستوى العالم.

الخيار 2: تنزيل شهادة ZimaOS المحلية ومنحها الثقة

أوصى الرد الرسمي بتنزيل ملف CRT المُنشأ ومنح الثقة له على العميل. بعد إعداد الثقة، استخدم:

https://zimaos.local

وثّق شهادة CRT الخاصة بـ ZimaOS على Windows

قدّم الرد الأصلي هذه العملية لنظام Windows:

1. اضغط Win + R.
2. شغّل certmgr.msc.
3. افتح مراجع التصديق الجذرية الموثوقة → الشهادات.
4. اختر كل المهام → استيراد.
5. حدّد ملف CRT الذي نزّلته من نظام ZimaOS الخاص بك.
6. ضعها في مراجع التصديق الجذرية الموثوقة.
7. أعد تشغيل المتصفح.

لا تثق إلا بشهادة حصلت عليها من نسخة ZimaOS المعروفة لديك. يعني تثبيت شهادة جذرية الوثوق بها للتحقق من الاتصالات على ذلك العميل.

لماذا لا تؤمّن شهادة ZimaOS تطبيقات Jellyfin أو Plex أو Emby

أكد الكاتب الأصلي لاحقًا أنه استورد الشهادة بنجاح على Pop!_OS، وأوضح أن: zimaos.local نجح الأمر، لكن Plex وEmby وJellyfin ظلّت تظهر على أنها غير آمنة.

أوضح ردّ في عام 2026 السبب: تستمع تلك التطبيقات إلى خدمات ومنافذ منفصلة. ومن أمثلتها:

Jellyfin: http://ZIMAOS_IP:8096
Plex:     http://ZIMAOS_IP:32400

فهي لا ترث تلقائيًا شهادة لوحة تحكم ZimaOS. وهذا السلوك متوقع، وليس دليلًا على فشل استيراد ملف CRT.

استخدم وكيلًا عكسيًا لـ HTTPS عبر تطبيقات متعددة

لمنح التطبيقات أسماءً مثل:

https://jellyfin.example.com
https://emby.example.com
https://adguard.example.com

ضع وكيلًا عكسيًا أمامها. يتولى الوكيل شهادات TLS ثم يعيد توجيه كل طلب إلى منفذ HTTP الداخلي للتطبيق.

يتوفر Nginx Proxy Manager حاليًا في متجر تطبيقات ZimaOS:

Nginx Proxy Manager لنظام ZimaOS

لماذا يُبلغ Nginx Proxy Manager عن أن المنفذين 80 أو 443 مستخدمان بالفعل؟

حاول كاتب المصدر تثبيت وكيل، فواجه فورًا تعارضًا في المنافذ. وتتوقع وثائق Nginx Proxy Manager الحالية هذه المنافذ القياسية:

80 ← HTTP العام
443 ← HTTPS العام
81 ← واجهة إدارة NPM

إذا كان ZimaOS يستخدم بالفعل منفذي المضيف 80 أو 443، فلا يمكن لـ NPM ربط منفذ المضيف نفسه في الوقت ذاته.

إعداد Nginx Proxy Manager الرسمي

المنفذ 81 ليس وجهة HTTPS العامة

قام مستخدم لاحق في سلسلة النقاش نفسها بإعادة توجيه منفذي الموجّه 80 و443 إلى المنفذ الداخلي 81. وصحّح المجتمع ذلك:

الموجّه 80 ← منفذ NPM ‏80
الموجّه 443 ← منفذ NPM ‏443

المنفذ 81 هي واجهة إدارة NPM. ولا ينبغي أن تستقبل حركة مرور عادية من مواقع الويب العامة.

تحدي HTTP مقابل تحدي DNS

كما فرّقت سلسلة النقاش بين طريقتين للتحقق في Let's Encrypt:

• تحدي HTTP: يتطلب عادةً أن تتمكن جهة إصدار الشهادة من الوصول إلى الوكيل عبر المنفذ 80.
• تحدي DNS: يتحقق من التحكم في النطاق عبر سجلات/واجهة برمجة تطبيقات مزود DNS، ويمكنه تجنّب التحقق الوارد عبر المنفذ 80.

اختر إحدى الطريقتين عن قصد. لا تدمج إعدادات النهجين من دون فهم مسار التحقق الذي يستخدمه NPM.

هل تحتاج إلى MySQL لتشغيل Nginx Proxy Manager فقط؟

لا. يدعم إعداد Nginx Proxy Manager الحالي SQLite لتثبيت بسيط في حاوية واحدة. أما قاعدة بيانات MySQL/MariaDB/PostgreSQL خارجية فهي اختيارية.

وهذا يصحّح مصدر قلق آخر أُثير في سلسلة النقاش الأصلية: لا يحتاج المبتدئ إلى نشر MySQL لمجرد البدء في استخدام وكيل عكسي لعدد قليل من الخدمات المنزلية.

تغيير منفذ الويب في ZimaOS له تبعات

لاحقًا في الموضوع، نقل أحد المستخدمين ZimaOS بعيدًا عن المنفذ 80 وتمكن بعد ذلك من تثبيت Nginx Proxy Manager. ومع ذلك، تشير تقارير مجتمعية منفصلة من عام 2026 إلى أن تغيير منفذ لوحة معلومات ZimaOS قد يتداخل مع سلوك عميلَي Zima لسطح المكتب والهاتف المحمول.

لذلك فإن «نقل ZimaOS بعيدًا عن المنفذ 80» ليس حلًا شاملًا خاليًا من المخاطر. قبل تغييره، حدّد ما هو الأهم في بيئتك:

• الملكية القياسية للمنفذين 80 و443 بواسطة وكيل عكسي؛
• أو الحفاظ على سلوك ZimaOS الافتراضي الخاص بالعميل والاكتشاف.

HTTPS محلي فقط في مقابل HTTPS العام

إذا كنت تستخدم التطبيقات داخل منزلك فقط:

• يمكنك إبقاء HTTP المباشر على شبكة LAN موثوقة؛
• استخدم شهادات موثوقة محليًا؛
• أو شغّل وكيلًا عكسيًا داخليًا وDNS داخليًا.

إذا كنت تريد استخدام HTTPS المتاح عبر الإنترنت، فاستخدم نطاقًا، ومصادقة قوية، وشهادات صادرة بشكل صحيح، وتصميمًا مدروسًا للوصول عن بُعد والأمان. لا تعرّض منافذ إدارة التطبيقات أو واجهة إدارة NPM لمجرد إظهار رمز القفل في المتصفح.

قائمة التحقق من HTTPS في ZimaOS

1. حدّد ما إذا كان التحذير يتعلق بـ zimaos.local أو تطبيقًا منفصلًا.
2. بالنسبة إلى لوحة معلومات ZimaOS، نزّل ملف CRT المُنشأ ووثّق به إذا كنت تريد استخدام HTTPS محليًا دون تحذيرات.
3. استخدم https://zimaos.local بعد الوثوق بالشهادة.
4. لا تتوقع أن تؤمّن شهادة CRT الخاصة بـ ZimaOS منافذ التطبيقات المنفصلة.
5. استخدم وكيلًا عكسيًا لأسماء مضيفي HTTPS عبر تطبيقات متعددة.
6. تأكد من الخدمة المالكة للمنفذين 80 و443 قبل تثبيت NPM.
7. أبقِ منفذ NPM رقم 81 للإدارة، وليس لإعادة توجيه مواقع الويب العامة.
8. اختر التحقق عبر HTTP أو عبر DNS وفقًا لشبكتك.
9. لا تعرّض خدمات الإدارة غير الضرورية للإنترنت العام.

الأسئلة الشائعة حول HTTPS في ZimaOS

لماذا يُعد zimaos.local آمنًا بينما لا تزال Jellyfin تستخدم HTTP؟

لأن شهادة ZimaOS تنطبق على اسم مضيف لوحة المعلومات. أما Jellyfin فهي خدمة منفصلة تستمع على منفذها الخاص.

هل يمكن لوكيل عكسي واحد تأمين جميع تطبيقات ZimaOS؟

يمكنه إنهاء اتصالات HTTPS لعدة خدمات HTTP، شريطة تهيئة كل مضيف وكيل بشكل صحيح وتمكن الوكيل من الوصول إلى التطبيق المستهدف.

لماذا يتعذر على Nginx Proxy Manager البدء على المنفذ 443؟

هناك خدمة أخرى مرتبطة بهذا المنفذ على المضيف بالفعل. واجه موضوع المصدر هذه المشكلة عندما تنافست ZimaOS وNPM على منافذ الويب القياسية.

هل المنفذ 81 هو المنفذ الذي أُعيد توجيه حركة مرور HTTPS العامة إليه؟

لا. المنفذ 81 مخصص لواجهة إدارة NPM. يجب أن تصل حركة المرور العامة العادية إلى المنفذين 80 و443.