يغطي موضوع الدعم الطويل هذا العديد من مواضيع المبتدئين، لكن أكثر نتيجة مفيدة وقابلة للبحث تبدو في الصفحة 3: كان خادم Jellyfin يعمل محليًا، وكان DuckDNS يُحلّ بشكل صحيح، وكانت شهادة SSL موجودة، ومع ذلك كان النطاق العام يعرض الخطأ 502 Bad Gateway. وفي النهاية فصل المجتمع المشكلة إلى ثلاث طبقات: وصول Nginx Proxy Manager إلى Jellyfin، وإعداد TLS، واستحواذ جهاز التوجيه على المنفذ 443.
حدث الاختراق النهائي عندما عطّل المستخدم خدمة NAS الخاصة بجهاز التوجيه على المنفذ 443. بعد ذلك، أصبح كل من HTTP وHTTPS يصلان إلى Jellyfin.
كان خطأ 502 يعني أن الوكيل تعذّر عليه الوصول إلى Jellyfin
ركّز استكشاف الأخطاء وإصلاحها في المجتمع أولًا على الهدف الأساسي في Nginx Proxy Manager. كانت خدمة HTTP العادية في Jellyfin تعمل على المنفذ 8096؛ وكان يتعين على الوكيل إعادة التوجيه إلى حاوية Jellyfin عبر HTTP بدلًا من التعامل مع منفذ HTTPS الاختياري في Jellyfin باعتباره المصدر الأساسي.
تستخدم إرشادات Jellyfin الحالية النموذج نفسه: تُعيد أمثلة الوكيل العكسي في Nginx توجيه حركة المرور العادية وWebSockets إلى Jellyfin على المنفذ 8096.
يحتاج الوكيل وJellyfin إلى مسار Docker يمكن الوصول إليه
في مرحلة ما، لم ينجح استخدام اسم الحاوية، لذلك حوّل أحد أعضاء المجتمع الوكيل إلى عنوان Docker الداخلي لـ Jellyfin. أدى ذلك إلى بدء عمل مسار HTTP.
إن استخدام عنوان IP الداخلي المتغير لحاوية أقل متانة من وضع الخدمتين على شبكة Docker مشتركة وتحت إدارة جيدة، مع حل ثابت لأسماء الخدمات. يوثّق الموضوع الأصلي ما نجح في ذلك التثبيت، وليس تصميم Compose مثاليًا لكل خادم.
أصلح توجيه HTTP قبل إضافة SSL
كان تغيير خيارات TLS بينما لا يزال الوكيل عاجزًا عن الوصول إلى Jellyfin مصدرًا رئيسيًا للارتباك. أزال تسلسل استكشاف الأخطاء في المجتمع SSL مؤقتًا من مضيف الوكيل، وتحقق أولًا من توجيه HTTP العادي، ثم أعاد الشهادة وفرض HTTPS.
ترتيب استكشاف الأخطاء هذا أهم من نسخ أي عنوان IP بعينه: أثبت توجيه المصدر الأساسي أولًا، ثم شخّص TLS.
كان جهاز التوجيه يستحوذ على المنفذ 443
بعد أن أصبح Jellyfin يُفتح عبر HTTP أخيرًا، أدى تفعيل HTTPS مجددًا إلى توجيه المستخدم إلى صفحة تسجيل الدخول الخاصة بجهاز التوجيه. كان ذلك أقوى دليل في الموضوع: كان جهاز التوجيه يتولى معالجة المنفذ 443 الوارد عبر ميزة NAS/الإدارة الخاصة به بدلًا من إعادة توجيهه إلى Nginx Proxy Manager.
عطّل المستخدم خدمة NAS الداخلية في جهاز التوجيه على المنفذ 443، ثم أكد أن HTTPS أصبح يعمل.
لم يضمن عمل HTTPS عن بُعد اكتشاف التطبيقات محليًا
استكشف الموضوع لاحقًا عملاء Roku والهواتف. كان الوصول عبر المتصفح باستخدام النطاق العام يعمل، لكن الاكتشاف التلقائي محليًا وسلوك hairpin/NAT loopback ظلا غير متسقين. وفي النهاية استخدم المجتمع DLNA كحل عملي بديل لـ Roku.
لا ينبغي خلط هذه المتابعة بمسار 502/HTTPS الذي جرى حله. فتوجيه الوكيل العكسي عن بُعد واكتشاف الأجهزة محليًا سلوكان منفصلان للشبكة.
كانت هذه مساعدة شبكية من المجتمع، وليست وصفة أمان من IceWhale
جاءت خطوات الوكيل العكسي التفصيلية من أعضاء المجتمع. يتطلب إتاحة Jellyfin عبر نطاق عناية بإعدادات جهاز التوجيه وTLS والمصادقة والتحديثات. لا تنشر خدمات الإدارة غير المرتبطة بـ ZimaOS لمجرد إعادة توجيه المنفذ 443 إلى وكيل عكسي.
الأسئلة الشائعة حول Jellyfin وNPM
ما سبب خطأ 502 Bad Gateway؟
تعذّر على Nginx Proxy Manager في البداية الوصول إلى المصدر الأساسي لـ Jellyfin بطريقة صحيحة. وبعد تصحيح التوجيه، تم تحميل Jellyfin عبر HTTP.
لماذا فتحت HTTPS صفحة تسجيل الدخول إلى جهاز التوجيه؟
كان جهاز التوجيه نفسه يستخدم المنفذ 443. سمح تعطيل خدمة جهاز التوجيه أو نقلها للمنفذ 443 بالوصول إلى Nginx Proxy Manager.
هل ينبغي لـ NPM أن يمرر Jellyfin داخليًا عبر HTTP أم HTTPS؟
يستخدم إعداد الموضوع الناجح وأمثلة Nginx الحالية في Jellyfin بروتوكول HTTP للوصول إلى خدمة Jellyfin على المنفذ 8096، مع إنهاء TLS عند الوكيل العكسي.
هل يجعل HTTPS عن بُعد Jellyfin يكتشف نفسه تلقائيًا على Roku؟
لا. فاكتشاف العميل، وعزل شبكة Wi-Fi، وشبكات Docker، وNAT loopback مشكلات منفصلة.
