لماذا يفقد Jellyfin الجلسات بعد تغيير الوكيل أو نظام أسماء النطاقات؟

لا ينبغي أن يؤدي تغيير الوكيل أو DNS تلقائيًا إلى إتلاف كل عمليات تسجيل الدخول إلى Jellyfin. يظهر فقدان الجلسة عادةً عندما يغيّر التغيير أيضًا اسم المضيف أو المخطط أو المسار أو هوية الخادم الخلفي أو طبقة المصادقة أو مسار العميل الذي تتوقعه حالة تسجيل الدخول الحالية.

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

حدّد أولًا ما إذا كان المصدر العام قد تغيّر فعلًا

دوّن المخطط واسم المضيف والمنفذ والمسار الأساسي ومسار الوكيل القديم والجديد. يمكن لسجل DNS من النوع A أو AAAA أن يوجّه اسم المضيف نفسه إلى عنوان مختلف من دون تغيير مصدر المتصفح، بينما يؤدي الانتقال من اسم مضيف إلى آخر أو تغيير المسار الأساسي للتطبيق إلى إنشاء حد مختلف للعميل. تتطلب عمليات ترحيل النطاقات المخصصة أيضًا توافق التطبيق ومسار المصادقة مع النطاق الجديد؛ وتوضح قائمة التحقق من ترحيل النطاق المخصص هذا الترابط بين DNS والتطبيق بوضوح.

تتأثر حالة المصادقة بالمكان الذي تُقدَّم فيه. تبدأ قائمة التحقق من نطاق ملفات تعريف ارتباط الجلسة المفيدة بتحديد النطاق والمسار المرتبطين بكل آلية مصادقة. لا تخزّن عملاء Jellyfin الحالة بالطريقة نفسها تمامًا، لذا اختبر العميل المتأثر بدل افتراض أن سلوك المتصفح يصف كل تطبيق.

إذا كان اسم المضيف القديم لا يزال يعمل بينما يطلب اسم المضيف الجديد تسجيل الدخول، فاعتبر ذلك ترحيلًا متوقعًا للمصدر إلى أن يثبت العكس. وإذا كان اسم المضيف نفسه يسجّل خروج الجميع فقط بعد تغيير الوكيل، فأبقِ اسم المضيف كما هو وانتقل إلى فحص الهوية الواردة والعناوين والمصادقة على مستوى الوكيل.

تحقق من أن DNS لا يزال يصل إلى مثيل Jellyfin المقصود نفسه

حلّل اسم المضيف من عميل على الشبكة المحلية، وإذا كان الوصول عن بُعد مهمًا فاختبره أيضًا من محلّل خارجي. تأكد من أن العنوان المُعاد يصل إلى الوكيل العكسي المقصود، وأن الوكيل يوجّه إلى خدمة Jellyfin المتوقعة، لا إلى حاوية قديمة أو مثيل تجريبي أو نسخة مستعادة أو خادم ثانٍ بقاعدة بيانات دائمة مختلفة.

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

ويُعد سير عمل ZimaSpace المرتبط بـ فصل دورات حياة الوكيل عن خدمات حالة الجلسة مفيدًا هنا: إذ ينبغي ألا تؤدي إعادة تشغيل نقطة الدخول إلى استبدال هوية التطبيق أو الحالة التي تتحقق من الجلسات الحالية بصمت.

قارن المضيف والمخطط والمسار المُمرَّرة ومصادقة الوكيل

سجّل إعداد الوكيل الفعلي بعد التغيير. قارن قيمة Host العامة والمخطط المُمرَّر وعنوان العميل ومسار ترقية WebSocket وإعادة التوجيه وأي وسيط مصادقة بالإعداد الأخير الذي كان يعمل. قد تؤدي إعادة التوجيه من HTTPS إلى HTTP غير متوقع أو إلى عنوان مضيف بديل إلى جعل تسجيل دخول صالح يبدو وكأنه اختفى.

إذا كانت هناك طبقة مصادقة أخرى أمام Jellyfin، فأبقِ مفتاح التوقيع واسم ملف تعريف الارتباط ونطاقه ومخزن الجلسات ثابتة أثناء استبدال الوكيل. تستخدم تصميمات موازنة التحميل حالة الجلسات الثابتة والتوجيه لإبقاء الطلب على الخلفية المقصودة؛ وقد يؤدي تغيير هذه الطبقة إلى تسجيل خروج أو حلقة إعادة توجيه حتى يظل Jellyfin نفسه سليمًا.

لا تنسخ العناوين من مثال وكيل غير ذي صلة من دون تحقق. غيّر قيمة واحدة فقط عندما يثبت الطلب الفاشل أو إعادة التوجيه أن القيمة الحالية خاطئة. أكثر إعدادات الوكيل أمانًا هو أصغر إعداد يحافظ على المصدر العام ويوصل باستمرار إلى الخلفية الصحيحة.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

استخدم اختبارًا نظيفًا للعميل من دون محو الدليل الأصلي

قبل مسح أي شيء، احفظ وقت الفشل وإصدار المتصفح أو التطبيق وحالة الطلب وسلسلة إعادة التوجيه وسطر سجل الوكيل وإدخال سجل Jellyfin. ثم استخدم نافذة تصفح خاصة أو جهاز اختبار ثانٍ لتسجيل الدخول عبر المسار الجديد. يثبت نجاح تسجيل دخول جديد إمكانية الوصول، لكنه لا يفسر سبب تعذر استخدام الحالة القديمة.

قارن المسارات الثلاثة بالترتيب: عنوان Jellyfin المباشر على الشبكة المحلية، واسم المضيف المعتاد من الشبكة المحلية، واسم المضيف المعتاد من خارج الشبكة المحلية. إذا نجح الوصول المباشر بينما فشل اسم المضيف، فأبقِ المستخدمين وحالة قاعدة البيانات كما هما وافحص DNS أو TLS أو الوكيل أو الوسيط. وإذا رفضت جميع المسارات الحساب المعروف والصالح نفسه، فقد عادت المشكلة إلى داخل Jellyfin أو حالته الدائمة.

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

تحقق من التغيير عبر انتهاء DNS وإعادة تشغيل الوكيل وإعادة التشغيل

بعد تطبيق الإصلاح المتوافق، انتظر انتهاء فترة TTL السابقة لـ DNS، ثم أعد تشغيل الوكيل فقط، وبعد ذلك أعد تشغيل خدمة Jellyfin وأخيرًا أعد تشغيل المضيف. كرر اختبارات تسجيل الدخول وتسجيل الخروج وبدء التشغيل والتنقل داخل المحتوى وإعادة الاتصال عبر اسم المضيف نفسه بعد كل حدث.

تعني النتيجة المستقرة أن اسم المضيف يواصل الحل إلى الوكيل المقصود، وأن الوكيل يعيد الاتصال بمثيل Jellyfin المقصود، وأن الجلسات الحالية تبقى صالحة بعد عمليات إعادة التشغيل العادية للمكونات عندما يكون ذلك متوقعًا، وأن تسجيل الدخول الجديد يظل صالحًا. إذا ظهرت الأعطال فقط أثناء إقلاع المكدس بالكامل، فاستخدم مسار استعادة الاتصال بين الوكيل والخلفية للفصل بين الجاهزية والمصادقة.

سجّل اسم المضيف النهائي واسم الوجهة الخلفية للوكيل والمسار الأساسي ومصدر الشهادة وأي سر جلسة على مستوى الوكيل في ملاحظات النشر. وبذلك يمكن اختبار تغييرات DNS أو الوكيل مستقبلًا وفق عقد هوية معروف بدل إعادة اكتشافه من أعراض المتصفح.

الأسئلة الشائعة

هل يؤدي تغيير سجل DNS وحده إلى إبطال جلسات Jellyfin؟

عادةً لا، ما دام اسم المضيف والمخطط والمسار ومثيل Jellyfin نفسه قيد الاستخدام. يصبح تغيير DNS ذا صلة بالجلسة عندما يرسل العملاء إلى خلفية مختلفة، أو يغير المصدر العام، أو يعدّل TLS أو عمليات إعادة التوجيه، أو يغيّر طبقة مصادقة أمام Jellyfin.

هل ينبغي أن ألغي كل جلسات Jellyfin بعد تغيير الوكيل؟

ليس كإجراء إصلاح أول. احتفظ بعميل واحد فاشل كدليل، وتأكد من أن المسار الجديد يصل إلى الخادم المقصود، واختبر تسجيل دخول جديدًا بشكل منفصل. ألغِ الجلسات فقط عند تدوير بيانات الاعتماد عمدًا، أو الاشتباه في انكشاف الرموز، أو التأكد من أن حالة العميل القديمة لم تعد موثوقة.