جمع هذا النقاش من ديسمبر 2025 بين عدة مشكلات مختلفة في Pi-hole: كان المنفذ 67 قيد الاستخدام بالفعل، وأفادت تحديثات Gravity بأن حلّ DNS غير متاح، وتعارض المنفذ 80 مع لوحة تحكم ZimaOS، ثم تسبب انقطاع كهربائي لاحق في تعطل الإعداد الذي كان يعمل سابقًا.
لم يكن النقاش حلًا نظيفًا من خطوة واحدة. فبعض افتراضات المجتمع المبكرة لم تفسر الأعراض اللاحقة لدى المستخدم، لذا فإن الدرس المفيد هو فصل DHCP وDNS وتعيين واجهة الويب وحلّ الأسماء upstream وحالة الحاوية المستمرة، بدل التعامل معها كلها باعتبارها مشكلة منفذ واحدة.
المنفذ 67 مخصص لـ DHCP، وليس لتصفية DNS العادية
وجد المستخدم أن عملية dnsmasq مرتبطة بالفعل بالمنفذ 67 ولم يتمكن من إنهائها. أوضحت الردود المجتمعية أن Pi-hole يحتاج إلى المنفذ 67 فقط عندما يعمل كخادم DHCP. وبما أن جهاز التوجيه لدى المستخدم كان يوفر DHCP بالفعل، فلم يكن Pi-hole بحاجة إلى تولي هذا الدور.
إذا كنت تستخدم Pi-hole لتصفية DNS فقط، فأبقِ DHCP على جهاز التوجيه، ما لم يكن لديك تصميم شبكي مقصود يتطلب تشغيل DHCP على Pi-hole.
يستخدم DNS المنفذ 53
تستخدم خدمة DNS في Pi-hole المنفذ 53 عبر TCP وUDP. وركز إعداد المجتمع في هذا النقاش على إتاحة DNS على المنفذ 53 مع إبقاء DHCP معطلًا.
ينبغي الرجوع إلى وثائق Pi-hole الخاصة لمعرفة متطلبات الخدمة والمنافذ الحالية، بدل افتراض أن كل قالب حاوية في ZimaOS لعام 2025 لا يزال مطابقًا.
متطلبات خدمة Pi-hole ومنافذه الحالية
كان المنفذ 80 تعارضًا منفصلًا مع لوحة تحكم ZimaOS
عندما حاول المستخدم تثبيت Pi-hole تثبيتًا نظيفًا، أبلغ ZimaOS بأن المنفذ 80 قيد الاستخدام بالفعل. وأكد Zima-Jerry إمكانية تعديل منفذ واجهة الويب في ZimaOS.
كان أحد البدائل الأبسط على مستوى الحاوية، الذي نوقش في النقاش، هو إبقاء لوحة تحكم ZimaOS على منفذها الحالي وتعيين منفذ مضيف مختلف إلى منفذ الويب الداخلي في Pi-hole. يغيّر هذا طريقة الوصول إلى صفحة إدارة Pi-hole فقط، ولا يغيّر حركة DNS على المنفذ 53.
لم يؤدِّ تعيين المنافذ الصحيح تلقائيًا إلى إصلاح Gravity
بعد تنظيف تعيينات المنافذ، ظل المستخدم الأصلي يرى الرسالة «حلّ DNS غير متاح». ثم انتقل النقاش من تعارضات المنافذ إلى إمكانية الوصول إلى خوادم DNS upstream. والتمييز التشخيصي المهم هو:
- يتحكم تعيين المنافذ في إمكانية وصول العملاء إلى خدمة Pi-hole؛
- يتحكم DNS upstream في قدرة Pi-hole نفسه على حل الأسماء وتحديث بيانات Gravity.
لم ينشر النقاش سببًا جذريًا مؤكدًا من IceWhale لكل حالات فشل DNS، لذا تجنب الادعاء بأن المنفذ 67 وحده يفسر فشل تحديث Gravity.
تعطل الإعداد مجددًا بعد انقطاع الكهرباء
أفاد المستخدم لاحقًا بأن Pi-hole كان يعمل بصورة صحيحة قبل انقطاع الكهرباء، ثم تعطل بعده. واقترحت نصائح المجتمع أن AppData المستمر قد يبقى بعد إلغاء التثبيت العادي، وقد ينقل حالة معطوبة إلى عملية إعادة التثبيت.
يُعد حذف دليل AppData إجراءً مدمرًا لأنه يزيل حالة التطبيق المستمرة. وكانت التوصية الواردة في المصدر لاستكشاف الأخطاء وإصلاحها مجتمعية، وليست إجراء استرداد رسميًا من IceWhale. انسخ الإعدادات احتياطيًا وتحقق من مسار التطبيق الدقيق قبل إزالة البيانات المستمرة.
تحقق من سلامة ZimaOS قبل إعادة بناء Pi-hole
أثر انقطاع الكهرباء نفسه أيضًا في سلوك إقلاع الجهاز. وعندما أصبح نظام التشغيل نفسه غير مستقر، فصل النقاش بشكل صحيح بين ذلك وبين مشكلة حاوية Pi-hole. فلا يُتوقع أن تعمل الحاوية بصورة طبيعية بينما يفشل المضيف في الإقلاع أو تكون خدمات Docker غير سليمة.
الأسئلة الشائعة حول Pi-hole على ZimaOS
هل يحتاج Pi-hole إلى المنفذ 67 إذا كان جهاز التوجيه يوفر DHCP بالفعل؟
لا، بالنسبة إلى إعداد تصفية DNS فقط الذي نوقش في هذا الموضوع. يرتبط المنفذ 67 بخدمة DHCP، بينما تستخدم تصفية DNS المنفذ 53.
ماذا أفعل إذا كان ZimaOS يستخدم المنفذ 80 بالفعل؟
أكد Zima-Jerry إمكانية تغيير منفذ واجهة الويب في ZimaOS. وهناك نهج آخر يتمثل في تعيين منفذ الويب الداخلي في Pi-hole إلى منفذ مضيف مختلف.
هل يمكن أن تتسبب قوائم الحظر في ظهور رسالة «حلّ DNS غير متاح»؟
ركز استكشاف الأخطاء وإصلاحها في النقاش على قدرة Pi-hole على الوصول إلى محلل upstream، وليس على محتوى قوائم الحظر.
هل يضمن إلغاء تثبيت Pi-hole إعادة تثبيت نظيفة؟
ليس إذا بقيت AppData المستمرة. تناول النقاش لاحقًا احتمال وجود حالة مستمرة قديمة أو تالفة بعد انقطاع كهربائي مفاجئ، لكن ينبغي اعتبار حذف هذه الحالة خطوة استرداد مدمرة.
