تتابع الصفحة الرابعة من نقاش دعم طويل حول ZimaOS إخفاقات المستخدم المتكررة في Jellyfin وNginx Proxy Manager بعد أول إعداد ناجح للوصول عن بُعد. والدرس المفيد ليس منفذًا سحريًا واحدًا: فقد يعود خطأ 502 كلما تغير هدف الوكيل العكسي أو تعيين منافذ Jellyfin أو شبكة Docker أو حالة التطبيق.
تركز هذه الصفحة فقط على المنشورات 61–80. ولا تكرر إعداد DuckDNS والشهادة السابق المشروح في موضع آخر من النقاش نفسه.
افصل رسالة واجهة برمجة تطبيقات NPM عن خطأ 502 في Jellyfin
رأى المستخدم أولًا «فشل الاتصال بواجهة برمجة التطبيقات، هل يعمل NPM بشكل صحيح؟». وأظهرت مراجعة سجلات المجتمع أن Nginx Proxy Manager كان يعمل وأن تجديد Let's Encrypt قد نجح. لذلك قد تكون رسالة واجهة برمجة التطبيقات المؤقتة ناتجة عن جلسة متصفح قديمة أو انقطاع وجيز بين الواجهة والواجهة الخلفية، بينما ظل خطأ 502 العام مشكلة منفصلة بين الوكيل وJellyfin.
أبقِ أنواع العناوين الثلاثة منفصلة
| نوع العنوان | مثال على الدور | هل ينبغي لـ NPM إعادة التوجيه إليه؟ |
|---|---|---|
| عنوان WAN العام | عنوان موجّه إلى مزود خدمة الإنترنت ومحدَّث بواسطة DuckDNS | لا |
| عنوان ZimaOS على الشبكة المحلية | عنوان مستقر على الشبكة المنزلية مثل 192.168.1.50
|
نعم، عندما ينشر Jellyfin منفذًا على المضيف |
| عنوان حاوية Docker أو اسمها | نقطة نهاية داخلية مثل jellyfin:8096
|
نعم، فقط عندما يتمكن NPM من الوصول إلى شبكة Docker نفسها |
تبدّل النقاش مرارًا بين اسم حاوية وعنوان مضيف على الشبكة المحلية وعنوان Docker داخلي. وهذه ليست بدائل متكافئة. اختر مسارًا مدعومًا واحدًا واختبره من داخل حاوية NPM قبل تغيير TLS أو DNS.
اقرأ تعيين المنافذ بالاتجاه الصحيح
أظهرت إعدادات Jellyfin أن منفذ المضيف 8097 مُعيَّنًا إلى منفذ الحاوية 8096. عندما يتصل NPM عبر عنوان ZimaOS على الشبكة المحلية، يجب أن يستخدم منفذ المضيف المنشور. وعندما يتصل مباشرةً باسم الحاوية عبر شبكة Docker مشتركة، فإنه يستخدم عادةً المنفذ الداخلي لـ Jellyfin.
أظهرت إعادة تعيين الاتصال من داخل NPM أن المسار المحدد لم يُنتج بعد استجابة صالحة من Jellyfin. وهذه أدلة أكثر فائدة من مجرد إعادة تشغيل الحاويتين.
استخدم ترتيبًا تشخيصيًا متعدد الطبقات
- افتح Jellyfin محليًا وتحقق من التشغيل قبل العبث بالوكيل.
- تأكد من أن حاوية Jellyfin قيد التشغيل، واقرأ تعيين المنفذ المحفوظ بين المضيف والحاوية.
- اختر إما عنوان LAN ثابتًا لـ ZimaOS مع منفذ مضيف منشور، أو اسم حاوية مع منفذ داخلي على شبكة مشتركة.
- اختبر نقطة النهاية الدقيقة تلك من بيئة NPM.
- بعد نجاح توجيه HTTP فقط، أعد تفعيل TLS واختبر النطاق العام.
- بعد أي تعديل على تطبيق أو إعادة تشغيل، كرر الاختبارات المحلية واختبارات الوكيل قبل تغيير DNS.
قد يؤدي تعديل مسار الوسائط إلى حدوث عطل مختلف
لاحقًا، تمكن المستخدمون عن بُعد من تصفح Jellyfin، لكنهم لم يتمكنوا من تشغيل الوسائط. غيّر المالك إعدادات حاوية Jellyfin، فتوقف الموقع العام عن الاستجابة. ثم أظهرت مراجعة سجلات المجتمع أن Jellyfin كان يعمل ويفحص /Media/Movies، مع إعادة توجيه الانتباه إلى هدف الوكيل العكسي. يوضح هذا سبب ضرورة تسجيل كل تغيير واختباره بشكل مستقل.
مسارات Linux حساسة لحالة الأحرف أثناء النسخ الاحتياطي
فشلت نسخة احتياطية للإعدادات لأن الأمر أشار إلى /DATA/AppData/duckdns، بينما كان المجلد الفعلي هو /DATA/AppData/DuckDNS. يتعامل Linux مع هذه المسارات على أنها مسارات مختلفة. اقترح الموضوع الأصلي أمر أرشفة أنشأه المجتمع، لكنه لم تُقدّمه IceWhale، لذلك لم يُعَد إنتاجه هنا باعتباره إجراءً رسميًا للنسخ الاحتياطي.
قبل أرشفة AppData، اعرض أسماء المجلدات الدقيقة، وأوقف التطبيقات عندما تتطلب قواعد بياناتها لقطة متسقة، وتحقق من الأرشيف باستعادة نسخة منه إلى موقع مؤقت.
الوصول عن بُعد المدعوم حاليًا
للإدارة والوصول إلى الملفات، توثّق ZimaOS حاليًا الوصول المشفّر من نظير إلى نظير عبر الوصول عن بُعد إلى ZimaClient. ويظل إعداد وكيل عكسي عام لـ Jellyfin إجراءً متقدمًا من جهة خارجية، وينبغي أن يتيح خدمة الوسائط فقط، لا لوحة معلومات ZimaOS.
الأسئلة الشائعة حول خطأ 502 في Jellyfin
هل يثبت ظهور «فشل NPM API» أن NPM متوقف؟
لا. في الموضوع، كانت سجلات NPM وتجديد الشهادة يعملان بشكل سليم، بينما كان المتصفح يعرض تلك الرسالة.
هل ينبغي أن يستخدم NPM المنفذ 8096 أم 8097؟
استخدم المنفذ الداخلي مع شبكة الحاويات المباشرة، أو منفذ المضيف المنشور عند إعادة التوجيه إلى عنوان LAN الخاص بـ ZimaOS.
لماذا قالت النسخة الاحتياطية إن DuckDNS غير موجود؟
كان مجلد AppData الفعلي يستخدم حرف D كبيرًا وDNS؛ ومسارات Linux حساسة لحالة الأحرف.
