يعمل Jellyfin عبر شبكة Wi‑Fi لكنه يفشل عبر Ethernet أو VPN

إذا كان Jellyfin يعمل عبر Wi‑Fi لكنه يفشل عبر Ethernet أو من خلال VPN، فعادةً ما يكون الخادم سليمًا؛ إذ إن المسار المؤدي إليه قد تغيّر. وأكثر الاحتمالات شيوعًا هي اختلاف عنوان IP أو الشبكة الفرعية أو استجابة DNS، أو وجود مسار يفضّل الواجهة الخاطئة، أو قواعد جدار حماية/شبكة محلية تصنّف الاتصال بطريقة مختلفة، أو تداخل مسار VPN مع شبكة LAN.

استخدم عنوان URL واحدًا معروفًا لعمل Jellyfin، واختبر من العميل المتأثر على مراحل. أثبت أولًا عنوان IP والمنفذ الوجهة، ثم قارن المسارات، وبعد ذلك تحقّق من جدار الحماية وإعداد Local Networks في Jellyfin، وفقط بعد ذلك افحص سلوك الشبكة الفرعية أو عقدة الخروج الخاصة بـ VPN. لا تُعد تثبيت Jellyfin ما دام الخادم نفسه يمكن الوصول إليه عبر واجهة أخرى، لأن هذا الدليل يشير بالفعل إلى أن المشكلة في الشبكة لا في حالة التطبيق.

قارن عنوان الوجهة على Wi‑Fi وEthernet

على اتصال Wi‑Fi العامل، سجّل اسم مضيف Jellyfin وعنوان IP الذي تم حله والشبكة الفرعية للعميل والمنفذ. انتقل إلى Ethernet وكرّر الفحوص نفسها. إذا حُلّ اسم المضيف إلى عنوان مختلف أو يتعذر الوصول إليه، فأصلح DNS أو مسار العميل قبل تغيير إعدادات Jellyfin.

توضح وثائق الشبكات في Jellyfin أن الوصول العادي يستخدم عنوان IP للمضيف ومنفذ HTTP(S) المُعدّ، بينما يقتصر الاكتشاف المحلي على الشبكة الفرعية المحلية. راجع سلوك الشبكة المحلية عندما يكون العميل السلكي على VLAN أو شبكة فرعية مختلفة عن شبكة Wi‑Fi.

اختبر عنوان IP للخادم مباشرةً من Ethernet. إذا عمل عنوان IP وفشل اسم المضيف، فالمشكلة في DNS. وإذا فشل كلاهما، فتابع فحوص المسار وجدار الحماية؛ أما إذا اتصل منفذ TCP لكن سلوك التطبيق اختلف، فتحقّق من تصنيف Jellyfin للاتصال المحلي/البعيد.

تحقّق من الواجهة والمسار المستخدمين فعليًا من العميل

يمكن لجهاز مزود بـ Wi‑Fi وEthernet ومهايئات VPN أن يحتفظ بعدة مسارات في الوقت نفسه. عند توصيل Ethernet، قد يفضّل نظام التشغيل مسارًا افتراضيًا جديدًا أو مسارًا أكثر تحديدًا للشبكة الفرعية، فيرسل حركة Jellyfin إلى مكان مختلف عن مسار Wi‑Fi العامل.

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

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

تحقّق من قواعد جدار الحماية وLocal Networks في Jellyfin

قارن سياسة جدار الحماية للشبكة الفرعية لـ Ethernet وشبكة VPN وشبكة Wi‑Fi. فكثيرًا ما تطبّق أجهزة التوجيه المنزلية والمفاتيح المُدارة قواعد VLAN أو شبكة ضيوف مختلفة، حتى عندما تكون الاتصالات الثلاثة داخل المنزل نفسه فعليًا.

في Jellyfin، راجع قيم CIDR في Local Networks وسياسة الوصول عن بُعد. قد يُعامل العميل القادم من شبكة فرعية غير مدرجة على أنه عميل بعيد، مما قد يغيّر السماح بالوصول لهذا المستخدم رغم أن الخادم يستمع بشكل طبيعي.

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

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ابحث عن تداخل الشبكات الفرعية في VPN أو سلوك عقدة الخروج

عندما يظهر الفشل فقط مع تفعيل VPN، قارن مسارات VPN بشبكة LAN الفعلية. قد تتسبب شبكتان تستخدمان الشبكة الفرعية الخاصة نفسها في إرسال العميل حركة Jellyfin داخل النفق، رغم أن الخادم قريب فعليًا.

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

عطّل مؤقتًا قبول مسارات VPN أو عقدة الخروج، ثم أعد اختبار عنوان IP نفسه لـ Jellyfin. إذا عاد الوصول فورًا، فاترك خادم Jellyfin دون تغيير، وأصلح توجيه VPN أو سياسة الوصول إلى LAN بدلًا من ذلك.

أعد اختبار مسار العميل الأصلي بعد كل إصلاح شبكي

بعد تحديد الفرع المسؤول، طبّق التغيير المطابق فقط: صحّح DNS، أو عدّل مقاييس المسارات أو بادئاتها، أو اسمح بالشبكة الفرعية لـ Ethernet/VPN في جدار الحماية، أو أصلح إدخال Local Networks في Jellyfin. ثم أعد جميع الواجهات إلى وضعها الطبيعي وكرّر طريقة الاتصال الأصلية.

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

لا تصعّد المشكلة إلا إذا كان عنوان IP الوجهة والمسار وجدار الحماية وتصنيف Local Networks صحيحة جميعًا، ومع ذلك تفشل الواجهة نفسها. التقط جداول المسارات العاملة والفاشلة وعناوين IP للعملاء وسجلات الخادم من محاولة واحدة؛ فهذه الأدلة أكثر فائدة بكثير من إعادة تثبيت Jellyfin أو إعادة ضبط جميع إعدادات الشبكة دفعة واحدة.