بعد تغيير مزوّد خدمة الإنترنت وإعادة تثبيت ZimaOS، اكتشف أحد أفراد المجتمع أن المضيف كان يستطيع تنفيذ اختبار اتصال مع مواقع الإنترنت وتنزيل صور متجر التطبيقات، بينما لم تتمكن التطبيقات داخل الحاويات من الوصول إلى الخدمات الخارجية. لم يتمكن qBittorrent من التنزيل، ولم يتمكن Jellyfin من جلب البيانات الوصفية.
تم حل الحالة الأصلية بنقل الحاويات المتأثرة من شبكة الجسر إلى وضع المضيف. ووثّقت الردود اللاحقة حالة ثانية بأعراض مشابهة ولكن بسبب مختلف: إذ أُدخل عنوان WAN عام كبوابة، كما تطلّب مسار مزوّد خدمة الإنترنت لدى المستخدم استخدام IPv6 إلى جانب IPv4 لكي يعمل Jellyfin.
اتصال المضيف لا يثبت اتصال الحاويات
تمكّن الكاتب من استخدام الطرفية على الويب في ZimaOS وتثبيت التطبيقات، مما أثبت أن نظام التشغيل نفسه يمتلك مسارًا صالحًا للاتصالات الصادرة. لكن ذلك لم يثبت أن لكل شبكة Docker توجيهًا صحيحًا. لذلك كان ينبغي اختبار أعطال التطبيقات من داخل الحاوية بدلًا من استنتاج حالتها من المضيف.
اقترح عضو فريق Zima، Giorgio، اختبار الاتصال عبر حاوية متصفح وتجربة وضع شبكة آخر من لوحة إعدادات التطبيق. ويشير المنشور أيضًا إلى أن المتاجر الخارجية والتثبيت باستخدام YAML والتثبيت عبر واجهة سطر الأوامر يمكن أن توفر تطبيقات تشخيصية، إلا أن هذه خيارات وليست متطلبات مؤكدة.
حلّ وضع المضيف حالة شبكة الجسر الأصلية
نقل الكاتب جميع الحاويات المتأثرة إلى وضع المضيف، وأفاد بأن الوصول إلى الإنترنت بدأ يعمل. ولا تحدد المناقشة سبب فشل وضع الجسر بعد التثبيت النظيف، لذلك ينبغي تسجيل وضع المضيف بوصفه التغيير الناجح لهذا الإعداد، لا بوصفه دليلًا على وجود خلل عام في شبكة الجسر.
أشار مشارك لاحق إلى أثر جانبي مهم: بعد تبديل الأوضاع، قد يظل رابط لوحة المعلومات يشير إلى منفذ المضيف المنشور القديم. وبالنسبة إلى Jellyfin، اضطر المشارك إلى الانتقال مباشرةً إلى المنفذ 8096 بعد أن واصلت لوحة المعلومات فتح المنفذ 8097.
كشفت حالة لاحقة عن بوابة غير صحيحة
احتوت سجلات Jellyfin لدى المستخدم الثاني على No route to host أثناء الاتصال بخدمة خارجية للبيانات الوصفية. وأوصى أعضاء المجتمع بإجراء الاختبار من دون VPN والتحقق من البوابة الظاهرة في إعدادات شبكة ZimaOS.
كشفت لقطة شاشة أن البوابة المكوّنة كانت عنوان WAN العام للمستخدم. وأوضحت الردود أن البوابة ينبغي أن تكون عنوان الموجّه المحلي على الشبكة الفرعية المحلية نفسها. صحح المستخدم البوابة، ومكّن IPv6 إلى جانب IPv4 في Jellyfin لأن اتصال AT&T لديه كان يفضّل IPv6. ثم أكد أن جلب البيانات الوصفية والصور أصبح يعمل.
افصل بين نتيجتي المجتمع
- الحالة الأصلية في أكتوبر 2025: فشلت شبكة الجسر في حاويات الكاتب؛ وأعاد وضع المضيف الوصول.
- حالة المتابعة في يناير 2026: كانت البوابة مكوّنة على هيئة عنوان IP عام، كما احتاج Jellyfin إلى تمكين IPv6 لمسار مزوّد خدمة الإنترنت ذلك.
أنتجت الحالتان العرض العام نفسه، وهو «تعذر على التطبيقات الوصول إلى الإنترنت»، لكنهما لم تشتركا في سبب جذري واحد تم التحقق منه. وتدعم المناقشة فحص وضع الشبكة، والعنوان المستخدم بعد تغيير الوضع، وإعداد البوابة، وتأثير VPN، وتوفر البروتوكول بوصفها مسارات منفصلة للتحقيق.
الأسئلة الشائعة
لماذا يستطيع ZimaOS تنزيل التطبيقات بينما تظل الحاوية غير متصلة؟
يمكن للمضيف وحاوية Docker استخدام إعدادات توجيه وشبكة مختلفة. في الحالة الأصلية، ظل اتصال المضيف سليمًا بينما فشلت التطبيقات التي تستخدم شبكة الجسر.
هل يؤدي تغيير Jellyfin إلى وضع المضيف إلى الاحتفاظ بمنفذ لوحة المعلومات القديم؟
ليس بالضرورة. وجد أحد المشاركين أن لوحة المعلومات ظلت تربط بالمنفذ 8097، بينما كان الوصول إلى Jellyfin في وضع المضيف ممكنًا مباشرةً عبر المنفذ 8096.
