الحقيقة المهمة في هذا النقاش من ديسمبر 2025 هي أنه لم ينتهِ بتثبيت عملي لـ AdGuard Home على ZimaBoard 2. جرّب المستخدم الأصلي اقتراحات المجتمع، ثم أفاد بأن AdGuard Home عمل على خادم Umbrel منفصل، بينما ظلّ نشره على ZimaOS غير متاح. لذلك، فهذه مقالة لاستكشاف الأخطاء وإصلاحها، وليست وصفة تثبيت ناجحة.
ومع ذلك، تكشف لقطات الشاشة والردود عن عدة فحوصات مفيدة: كان للتطبيق تعيينات منفصلة لمنافذ DNS وواجهة الويب، وكان يعمل ضمن وضع الشبكة الجسرية، وركّز المجتمع على تعارضات المنافذ بدلاً من بوابة UniFi.
ما الذي تخبرك به رسالة «الخدمة غير متاحة» وما الذي لا تخبرك به
تثبت صفحة «الخدمة غير متاحة» أن مسار HTTP ما قد استجاب، لكنها لا تحدد ما إذا كانت عملية AdGuard قد أكملت التهيئة، أو ما إذا كان المسار العكسي يشير إلى المنفذ الداخلي الصحيح، أو ما إذا كان منفذ DNS 53 قد ارتبط بنجاح.
لا تبدأ بتغيير إعدادات الموجّه عندما لا تكون الخدمة نفسها سليمة حتى على مضيف ZimaOS المحلي.
نشر الإعداد المصدر منافذ DNS والويب بشكل منفصل
يستخدم إعداد AdGuard Home لأول مرة المنفذ 3000
تميّز إرشادات Docker الحالية الخاصة بـ AdGuard Home بين معالج الإعداد الأولي وواجهة الإدارة العادية. في الحاوية الجديدة، يُستخدم منفذ TCP 3000 لمسار الإعداد الأولي. بعد إتمام الإعداد، تستخدم واجهة HTTP العادية عادةً المنفذ 80 ما لم يغيّره المستخدم.
هذه نقطة مهمة غابت عن الرد المختصر في المجتمع. فقد يكون تعيين مضيف مثل 8080:80 صحيحًا لواجهة المستخدم بعد الإعداد، لكنه يظل لا يعرِض نقطة الإعداد الأولية التي تتوقعها الحاوية الجديدة.
قارن التطبيق مع متطلبات المنافذ ووحدات التخزين الحالية في Docker الخاصة بـ AdGuard Home قبل تغيير الموجّه.
يتطلب DNS المنفذ 53 عبر TCP وUDP معًا
أشار مُجيب المجتمع بشكل صحيح إلى أن AdGuard Home يحتاج إلى المنفذ 53 لخدمة DNS العادية. يجب إتاحة كلٍّ من TCP وUDP عندما تكون الحاوية متوقعة لتوفير DNS لشبكة LAN.
إذا كان Pi-hole أو AdGuard أو محلّل النظام أو حاوية DNS أخرى تستخدم المنفذ 53 بالفعل، فلن تتمكن الخدمة الجديدة من الارتباط به بشكل طبيعي. ويُعد فحص المضيف بحثًا عن مستمع موجود أكثر فائدة من تغيير منفذ WebUI مرارًا.
منفذ WebUI ومنفذ DNS مشكلتان مختلفتان
قد يمنع تعارض على المنفذ 80 أو 3000 فتح واجهة الإدارة، بينما تظل خدمة DNS نفسها سليمة. وقد يمنع تعارض على المنفذ 53 بدء خدمة DNS حتى عندما تفتح لوحة المعلومات. أبقِ هذين المسارين منفصلين أثناء التشخيص.
اقتُرح وضع المضيف، لكن لم يُثبت أنه ضروري
أوصى مُجيب المجتمع بتجربة وضع شبكة المضيف، بحجة أن الوضع الجسري قد يعقّد أحيانًا منافذ DNS. ولم يعد صاحب المنشور الأصلي بنتيجة ناجحة على ZimaOS بعد ذلك التغيير.
لذلك، لا تقدّم شبكة المضيف على أنها إلزامية. يدعم نشر AdGuard Home المُصان عبر Docker تعيينات المنافذ الصريحة. ويمكن أن يعمل الوضع الجسري عندما تكون المنافذ المطلوبة متاحة ومُعيّنة بشكل صحيح.
لم يُحدَّد أن بوابة UniFi Cloud Gateway هي السبب
سأل المستخدم تحديدًا عما إذا كانت UniFi Cloud Gateway Max تحتاج إلى تغييرات. وكانت إجابة المجتمع أنه لا ينبغي أن تكون هناك حاجة إلى تغيير في الموجّه لمجرد فتح AdGuard Home وتهيئته محليًا.
تأتي تغييرات الموجّه لاحقًا، عندما تقرر جعل عملاء LAN يستخدمون AdGuard Home لخدمة DNS أو DHCP. وهي لا تصلح حاوية لا تستطيع إكمال التهيئة المحلية.
حافظ على استمرار /opt/adguardhome/work و/opt/adguardhome/conf
يخزّن AdGuard Home بيانات وقت التشغيل والإعدادات في مجلدات دائمة. وإذا أُعيد إنشاء هذه المسارات، أو تم تركيبها للقراءة فقط، أو أُشير بها إلى مكان غير متوقع، فقد تتصرف الحاوية كتثبيت جديد أو تفقد إعداداتها بعد إعادة إنشائها.
أظهرت لقطات الشاشة المصدرية وحدات تخزين دائمة بالفعل، لذا ينبغي عند إعادة التثبيت بالكامل التحقق مما إذا كانت تلك المجلدات الموجودة يُعاد استخدامها، بدلاً من افتراض أن التطبيق يبدأ كتثبيت نظيف.
ترتيب تشخيص أفضل
- تحقق من سجل الحاوية بحثًا عن أخطاء بدء التشغيل أو الارتباط.
- تأكد مما إذا كان منفذ الإعداد الأولي 3000 مطلوبًا.
- تحقق من تعيين WebUI العادي بشكل منفصل.
- تحقق من خلو منفذَي TCP وUDP 53 على المضيف.
- تحقق من أن وحدتَي تخزين الإعدادات والعمل الدائمتين قابلتان للكتابة.
- بعد ذلك فقط، جرّب التبديل بين الشبكة الجسرية وشبكة المضيف.
- أجّل تغييرات DNS على الموجّه إلى أن تصبح الخدمة المحلية سليمة.
ظلت الحالة المصدرية دون حل على ZimaOS
في 24 ديسمبر، أفاد المستخدم بأنه جعل AdGuard Home يعمل على خادم Umbrel، لكنه ظل غير قادر على تشغيل النشر على ZimaBoard 2. وأغلق طلب المساعدة لأن الخدمة أصبحت متاحة في مكان آخر، لا لأن تثبيت ZimaOS قد أُصلح.
الأسئلة الشائعة حول عدم توفر خدمة AdGuard Home
ما المنفذ المستخدم للإعداد الأولي؟
تستخدم تعليمات Docker الحالية الخاصة بـ AdGuard Home منفذ TCP 3000 لمعالج الإعداد الأولي.
ما المنافذ المستخدمة لخدمة DNS العادية؟
المنفذ 53 عبر TCP وUDP معًا.
هل يتطلب AdGuard Home استخدام شبكة المضيف على ZimaOS؟
لم يثبت النقاش المصدر ذلك. كان هذا مجرد اقتراح لاستكشاف الأخطاء وإصلاحها من المجتمع.
هل حُلّت حالة ZimaOS الأصلية؟
لا. نقل المستخدم الخدمة إلى خادم آخر وأنهى النقاش من دون إعداد عملي لـ ZimaOS.
