كيفية اختبار ما إذا كان DNS يتسبب في فشل اتصال Plex

أثبت أولًا إمكانية الاتصال المباشر عبر عنوان IP؛ ولا تتحرَّ عن DNS إلا عندما يعمل Plex باستخدام العنوان ويفشل عبر اسم المضيف المعتاد أو اكتشاف التطبيق أو مسار الاتصال الآمن.

قد يتعطل DNS في Plex بسبب محلّل يوفره جهاز التوجيه، أو بسبب Pi-hole أو Unbound، أو إجابات قديمة مخزنة لدى العميل، أو قواعد DNS المنفصل، أو حماية إعادة الربط حول `plex.direct`. وقد تبدو هذه الأعطال كأنها توقف في الخادم، بينما تكون الخدمة قابلة للوصول عبر عنوان IP. استخدم عميلًا واحدًا متعطلًا، وعنوان خادم معروفًا، ومحلّلًا بديلًا واحدًا لعزل مشكلة حل الأسماء قبل تعديل إعادة توجيه المنافذ أو المكتبات أو إعدادات الحاويات.

أثبت إمكانية الاتصال عبر IP قبل اختبار DNS

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

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

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

قارن إجابات المحلّلات وسلوك إعادة الربط

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

قد يُحل `plex.direct` إلى عنوان خادم خاص، ولذلك قد تحظر حماية إعادة ربط DNS الاستجابة، حتى عندما يكون مضيف Plex سليمًا. راجع سجلات المحلّل بحثًا عن استعلامات مرتبطة بـ Plex تم حظرها أو إعادة كتابتها، بدلًا من تعطيل حماية إعادة الربط عالميًا.

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

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

افصل بين عطل DNS المحلي وعطل الوصول البعيد

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

يمكن لـ استثناء النطاق الخاص إصلاح سلوك المحلّل المحلي، لكنه لا ينشئ مسارًا واردًا من الإنترنت؛ لذلك يظل العطل الخاص بالوصول البعيد مرتبطًا بـ NAT أو جدار الحماية أو بنية مزود خدمة الإنترنت.

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

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

لا تُبقِ الإصلاح إلا إذا صمد أمام تغييرات التخزين المؤقت وإعادة التشغيل

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

قد تتداخل إعادة ربط DNS وإعدادات NAT، لذا وثّق التغيير الوحيد الذي يحل الاختبار المتعطل، بدلًا من الإبقاء على عدة استثناءات غير ضرورية.

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