يعمل Plex عبر شبكة Wi‑Fi لكنه يفشل عبر Ethernet أو VPN: كيفية عزل المسار
إذا كان Plex يعمل عبر مسار شبكي واحد لكنه يفشل عبر مسار آخر، فأبقِ إعدادات الخادم ثابتة واختبر المسار المتغير.
يمكن لواجهات Wi‑Fi وEthernet وVPN استخدام عناوين IP وخوادم DNS ومسارات ووحدات MTU وشبكات VLAN وسياسات جدار حماية مختلفة، حتى على العميل نفسه. ويُعد تغيير إعداد على مستوى الخادم خطوة أولى غير مناسبة عندما تعمل الوسائط والحساب نفسهما عبر مسار واحد. قارن إمكانية الوصول المباشر إلى الخادم، وحل أسماء DNS، واختيار المسار، ووضع التشغيل على كل واجهة.
قارن العنوان والمسار قبل إعدادات Plex
قد تصل الواجهة المتعثرة إلى شبكة فرعية مختلفة أو تختار مسارًا افتراضيًا مختلفًا. تحقّق من عنوان IP للخادم والمسار من العميل بدلًا من الاعتماد على اسم الشبكة.
عند تفعيل Ethernet وWi‑Fi معًا، يمكن أن تجعل مقاييس المسارات الواجهات تختار مسارات مختلفة إلى الوجهة نفسها، لذا اجعل التشخيص الأول متعلقًا بالتوجيه وسياسة الواجهة، لا بإعدادات Plex.
نفّذ اختبار ping أو اتصل بعنوان الخادم عبر كلا المسارين، وقارن عنوان IP والشبكة الفرعية للعميل، وافحص المسار المستخدم للمنفذ 32400. إذا تعذر على Ethernet الوصول إلى الخادم مباشرة، فأبقِ الإصلاح في طبقة الشبكة.
تحقق من DNS وتوجيه VPN بشكل منفصل
يمكن لـ VPN تغيير أولوية المسار وDNS معًا من دون تغيير تطبيق Plex. كما قد يؤدي تقسيم النفق إلى إرسال الردود عبر واجهة مختلفة عن الواجهة التي استقبلت الطلب.
قد يفشل تقسيم النفق عندما تغادر حركة الرد عبر مسار VPN بدلًا من الواجهة التي استقبلت الطلب، مما يؤدي إلى قطع مسار Plex صالح بخلاف ذلك.
عطّل VPN فقط للمدة اللازمة لإنشاء نتيجة مرجعية، ثم أعد تفعيله وقارن جداول التوجيه. أصلح التوجيه غير المتماثل أو سياسة تقسيم النفق قبل تعديل إعدادات الوسائط أو قاعدة البيانات.
اختبر MTU عندما تعمل الطلبات الصغيرة لكن تتوقف التدفقات
قد يمرر المسار حركة التحكم الصغيرة بينما تتجزأ الحزم الأكبر أو تنتهي مهلتها. ويكون هذا النمط مهمًا خصوصًا عبر أنفاق VPN وبعض روابط الهاتف المحمول أو مزودي خدمة الإنترنت.
قد يحدث الاتصال الجزئي بسبب أعطال Plex الحساسة لـ MTU عبر ناقل واحد بينما يعمل مسار آخر، مما يجعل حجم الحزمة اختبارًا محدودًا للتوقفات الخاصة بـ VPN أو مزود خدمة الإنترنت.
استخدم اختبار MTU للمسار أو خفّض MTU للنفق مؤقتًا بطريقة مضبوطة. إذا أصبح التشغيل مستقرًا من دون أي تغيير في Plex، فأبقِ التشخيص في طبقة النقل.
أعِد اختبار Plex فقط بعد استقرار الاتصال الأساسي
بعد اتساق إمكانية الوصول المباشر والمسار وDNS وMTU، اختبر عنصر Plex والجودة نفسيهما عبر كل مسار. يمنع ذلك الخلط بين إصلاح الشبكة وتغيير تحويل الترميز لدى العميل.
قبل العودة إلى إعدادات Plex، تأكد من غياب أخطاء الشبكة والتشبع على المسار الذي تم إصلاحه؛ ثم أعد تشغيل العنصر والجودة نفسيهما مع إبقاء متغير الشبكة ثابتًا.
إذا كان مسار الشبكة مستقرًا لكن أحد العملاء لا يزال يفشل، فتابع فحص توافق العميل أو الحالة المخزنة مؤقتًا. احتفظ بمسار معروف للبث البعيد عبر Plex كمرجع، بدلًا من إعادة فتح إعدادات الشبكة على مستوى الخادم.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل ينبغي نسخ Jellyfin احتياطيًا أثناء تشغيله أم إيقاف الخدمة أولًا؟
للتبسيط، يُفضَّل استخدام النسخ الاحتياطية للخدمات المتوقفة؛ ولا تستخدم اللقطات الحية إلا عندما تكون حالة التطبيق ملتقطة بشكل متسق وتكون عمليات الاستعادة قد اختُبرت.
لماذا يعمل Jellyfin بدرجة حرارة مرتفعة أو بضوضاء عالية عندما لا يشاهد أحد أي محتوى؟
تعني الحرارة أثناء الخمول عادةً وجود عمل في الخلفية أو عبء عمل على مضيف مشترك، لذا حدّد العملية النشطة والمهمة المجدولة قبل تغيير التبريد...
متى ينبغي إعادة بناء Jellyfin بدلًا من إصلاحه؟
اختر إعادة البناء بدلًا من الإصلاح عندما يكون انجراف بيئة التشغيل هو المشكلة وتكون الحالة الدائمة قد نُسخت احتياطيًا؛ لا تُجرِ «إعادة بناء» بحذف...
