تتمثل النتيجة النهائية البسيطة لهذا المصدر في أن تغيير واجهة ZimaOS WebUI بعيدًا عن المنفذين 80/443 أدى إلى تعطيل الاتصال بتطبيق Zima App 2.3.0 على جهاز ZimaBoard 2 الخاص بالمستخدم، ولكن بعد تحديث ZimaOS إلى الإصدار 1.5 عاد المستخدم وأفاد بأن المشكلة قد حُلّت.
وهذا يعني أنه لا ينبغي للصفحة تعليم المستخدمين الحاليين ضبط منفذ مخفي باسم «منفذ ZimaClient» يدويًا استنادًا إلى مشكلة عام 2025. فقد كانت مشكلة توافق تاريخية بين العميل ومنفذ WebUI مخصص، ويحدد المصدر نفسه الإصدار 1.5 كنقطة استعادة الاتصال.
غيّر المستخدم المنافذ لصالح Nginx Proxy Manager
يحتاج Nginx Proxy Manager عادةً إلى منفذي المضيف 80 و443 لحركة مرور الدخول عبر HTTP/HTTPS. لذلك نقل المستخدم ZimaOS إلى:
[gateway]
port = 8080
[ssl]
enabled = true
port = 30443ثم أعاد تشغيل خدمة بوابة CasaOS/ZimaOS.
بعد ذلك، تعذّر على تطبيق Zima App لنظام Windows الاتصال
كانت بيئة المصدر كما يلي:
- ZimaBoard 2 1664؛
- نواة ZimaOS 6.12.25؛
- Zima App 2.3.0 على Windows 11.
بعد تغيير منفذ WebUI، فشلت إعادة تشغيل تطبيق Windows ومحاولة الاتصال مجددًا.
طلب IceWhale تفاصيل قابلة لإعادة الإنتاج بدلًا من التخمين بشأن إعداد المنفذ
طلب Zima-Giorgio من المستخدم تقديم وصف دقيق للمشكلة، وخطوات إعادة إنتاجها، والتغييرات السابقة، والإصلاحات التي تمت تجربتها، ومعلومات الأجهزة، وإصدار نظام التشغيل، وإصدار العميل. ويُعد ذلك تعاملًا جيدًا مع الأدلة، لأن فشل الاتصال الظاهر نفسه قد ينتج عن مشكلات في الاكتشاف أو الوصول عن بُعد أو TLS أو المنافذ أو إصدار العميل.
أدى التحديث إلى ZimaOS 1.5 إلى إصلاح حالة المصدر
بعد ثلاثة أيام، نشر ThomasSpi ما يلي: «بعد التحديث إلى Zima OS 1.5 أصبح يعمل. تم إصلاح المشكلة.»
وهذا هو الاستنتاج الأقوى في المصدر، وينبغي أن يحل محل التكهنات بشأن تعليم Zima App منفذًا مخصصًا يدويًا.
استمر ZimaClient الحالي في التطور
تصف وثائق IceWhale الحالية ZimaClient بأنه يعثر تلقائيًا على أسرع اتصال قابل للاستخدام بواجهة WebUI عبر الشبكة المحلية، والشبكة الخارجية، ونقطة الاتصال، وغيرها من المسارات المدعومة.
استخدم نموذج تثبيت ZimaClient الحالي والاتصال به قبل إعادة تطبيق إصلاح يعود إلى حقبة الإصدار 2.3.0.
حسّن ZimaOS 1.7.1 كذلك عنوان ويب Docker ومعالجة الشبكات الديناميكية
يتضمن سجل تغييرات الإصدار 1.7.1 إعدادًا أكثر مرونة لمنفذ عنوان ويب Docker، وتحسينًا للتعامل مع عناوين URL في بيئات الشبكات الديناميكية. وترتبط هذه التغييرات بعناوين URL للتطبيقات، ولا تثبت شيئًا محددًا بشأن خطأ ZimaClient القديم، لكنها تُظهر أن معالجة المنافذ وعناوين URL في المنصة واصلت التطور.
الوكيل العكسي وZimaClient مسارا وصول منفصلان
يمكن لـ Nginx Proxy Manager توفير نطاقات HTTPS سهلة للتطبيقات أو حتى للوحة تحكم ZimaOS. ويستخدم ZimaClient منطق الاكتشاف والوصول عن بُعد الخاص به. ولا ينبغي افتراض أن تغيير الوكيل العكسي سيعيد تهيئة ZimaClient تلقائيًا في كل إصدار.
إذا مرّرت لوحة تحكم ZimaOS عبر وكيل، فحافظ على WebSockets
أظهرت حالة مجتمعية لاحقة في عام 2026 أن لوحة التحكم قد تُحمّل بصريًا عبر Nginx Proxy Manager، بينما تفشل الأدوات المباشرة ومربعات حوار التطبيقات إلى أن يتم تفعيل دعم WebSocket. فتعارض المنافذ وتمرير WebSocket طبقتان منفصلتان.
طريقة أكثر أمانًا لتغيير منفذ WebUI
- سجّل المنفذ الأصلي.
- غيّر منفذ WebUI من خلال الواجهة المدعومة متى كانت متاحة.
- تحقق من الوصول المباشر عبر المتصفح باستخدام عنوان IP والمنفذ الجديدين.
- أعد تشغيل ZimaClient أو حدّثه، وتحقق من نجاح الاكتشاف.
- بعد ذلك فقط، خصص المنفذين 80/443 للوكيل العكسي.
- احتفظ بمسار استعادة محلي في حال تعطل كل من الوكيل والعميل.
الأسئلة الشائعة حول تغيير منفذ ZimaClient
هل عثر مستخدم المصدر على إعداد يدوي لمنفذ مخصص في Zima App؟
لا. انتهى النقاش بإصلاح المشكلة من خلال تحديث نظام التشغيل.
ما الإصدار الذي أصلح حالة المصدر؟
أفاد المستخدم صراحةً بأن ZimaOS 1.5 أصلح المشكلة.
هل ينبغي للمستخدمين الحاليين افتراض استمرار سلوك ZimaClient 2.3.0؟
لا. إن آليات الاتصال الحالية في ZimaClient وZimaOS أحدث بكثير.
