كيفية إصلاح خطأ "فشل الاتصال بالجسر" في Jitsi Meet
عند فتح غرفة Jitsi Meet، يتم تحميل الصفحة بشكل طبيعي، وقد يبدو أن الإشارات تعمل، لكن المؤتمر لا يُنشئ اتصالاً بالوسائط. بدلاً من ذلك، يُبلغ Jitsi عن "فشل الاتصال بالجسر" أو ينقطع الاتصال بشكل متكرر أثناء محاولة الانضمام. في حالة النشر المُستضاف ذاتيًا، تشير هذه الرسالة عادةً إلى وجود مشكلة بين المتصفح و Jitsi Videobridge (JVB) ، أو بين Jicofo والجسر نفسه.
أسرع طريقة لحل المشكلة هي البدء من الخادم: تأكد من تشغيل JVB وتسجيله، وتأكد من إمكانية الوصول إلى منفذ الوسائط الخاص به، وتحقق من معالجة NAT/العنوان العام، ثم ابحث عن قيود الشبكة من جانب العميل. يُشير دليل الاستضافة الذاتية الرسمي لـ Jitsi إلى أن منفذ UDP 10000 هو مسار الوسائط الافتراضي، بينما يتولى Jicofo مسؤولية اختيار جسر الفيديو لكل مؤتمر.
قد يظهر خطأ في اتصال الجسر حتى لو تم تحميل واجهة الويب الخاصة بـ Jitsi بنجاح.
ما يعنيه الخطأ عادةً
يتكون Jitsi Meet من عدة مكونات. تتولى واجهة الويب وProsody معالجة الإشارات، بينما ينسق Jicofo المؤتمرات، ويقوم Jitsi Videobridge بإعادة توجيه تدفقات الصوت والفيديو. إذا تمكن المتصفح من الوصول إلى صفحة الويب ولكنه لم يتمكن من إنشاء اتصال عبر JVB، أو إذا لم يكن لدى Jicofo جسر اتصال سليم متاح، فقد يفشل الاجتماع في مرحلة إنشاء الجسر.
بالنسبة لأنظمة Debian/Ubuntu الحالية، تُوثّق Jitsi متطلبات الشبكة التالية: منفذ TCP 80 للتحقق من الشهادات وتجديدها، ومنفذ TCP 443 للوصول إلى الويب، ومنفذ UDP 10000 للصوت والفيديو بشكل عام، ومنفذ UDP 3478 لاستعلامات STUN الاختيارية، ومنفذ TCP 5349 لوسائط النسخ الاحتياطي القائمة على بروتوكول coturn في حال حظر UDP. راجع دليل الاستضافة الذاتية الرسمي لـ Jitsi على Debian/Ubuntu . يُظهر التكوين المرجعي الحالي لـ JVB أيضًا منفذ UDP 10000 كمنفذ ICE/UDP الافتراضي في التكوين المرجعي لـ Jitsi Videobridge .
1. تأكد من أن تطبيق Jitsi Videobridge قيد التشغيل
ابدأ بالمكون المذكور في الخطأ. في حالة التثبيت القياسي القائم على الحزم، قم بتشغيل:
sudo systemctl status jitsi-videobridge2
تريد أن ترى active (running). إذا تعطلت الوحدة، فقد تؤدي إعادة تشغيلها إلى استعادة الخدمة مؤقتًا، ولكن لا تتوقف عند هذا الحد - تحقق من السجلات لمعرفة سبب توقفها:
يجب أن يُظهر تثبيت الحزمة السليم وحدة jitsi-videobridge2 systemd على أنها نشطة وتعمل.
ابحث عن حالات فشل الربط، وأخطاء المصادقة، وفشل اتصال XMPP، ومشاكل ICE المتكررة، أو الرسائل التي تشير إلى عدم توفر عنوان صالح. لا تفترض أن حالة systemd النشطة تثبت إمكانية استخدام JVB: فقد تكون عملية Java قيد التشغيل بينما يكون اتصال الوسائط أو تسجيل XMPP معطلاً.
تُعد سجلات JVB هي المكان التالي الذي يجب البحث فيه عندما تكون الخدمة قيد التشغيل ولكن المؤتمرات لا تزال غير قادرة على الحصول على جسر عمل.
2. تحقق من أن منفذ UDP 10000 يستمع ومسموح له بالمرور عبر جدار حماية المضيف
منفذ الوسائط الافتراضي لـ Jitsi في JVB هو UDP 10000. تأكد أولاً من أن الخادم يستمع:
sudo ss -lunp | grep ':10000'
إذا لم يكن هناك أي منفذ يستمع، فافحص /etc/jitsi/videobridge/jvb.confسجلات JVB قبل تغيير قواعد جدار الحماية. إذا كان المنفذ يستمع، فتحقق من جدار حماية المضيف.
sudo ufw status verbose
إذا كان UDP 10000 غائبًا عن قواعد جدار الحماية المضيف، فسيظل بإمكان صفحة الويب التحميل بينما تفشل وسائط المؤتمر.
على خادم أوبونتو الذي يستخدم UFW، يستخدم دليل Jitsi الخاص ما يلي:
sudo ufw allow 10000/udp
sudo ufw status verbose
بعد إضافة القاعدة، تحقق من السماح بـ UDP 10000؛ لا تعتمد فقط على رسالة النجاح من أمر جدار الحماية.
إذا كنت تستخدم firewalld أو nftables أو iptables أو جدار حماية سحابي بدلاً من UFW، فأضف قاعدة UDP الواردة المكافئة هناك. من الأخطاء الشائعة فتح منفذ UDP 10000 في أوبونتو مع تركه محظورًا بواسطة مجموعة أمان AWS أو مجموعة أمان شبكة Azure أو جدار حماية Google Cloud VPC أو جدار حماية موفر VPS أو جدار حماية الأجهزة الخاص بالشبكة.
3. تحقق من إعادة توجيه منفذ جهاز التوجيه عندما يكون الخادم خلف جدار حماية NAT
إذا كان Jitsi يعمل على عنوان خاص مثل `@` 192.168.x.x، فإن فتح جدار الحماية UFW لا يكفي. يجب على جهاز التوجيه الطرفي الخاص بك إعادة توجيه منفذ وسائط UDP الخارجي إلى الجهاز الذي يُشغل JVB. في تثبيت بسيط لخادم واحد، يعني هذا عادةً إعادة توجيه UDP 10000 إلى UDP 10000 على خادم Jitsi.
يحتاج خادم Jitsi المستضاف ذاتيًا خلف جهاز التوجيه إلى إعادة توجيه منفذ وسائط JVB إلى المضيف الداخلي الصحيح.
إذا قمت بتغيير منفذ JVB، فاستخدم القيمة المُهيأة بدلاً من فتح المنفذ 10000 بشكل عشوائي. تأكد أيضاً من عدم استخدام جهاز أو حاوية أخرى لهذا المنفذ. تختلف شاشات إعادة توجيه المنافذ باختلاف أجهزة التوجيه، لذا اعتبر الرسم التوضيحي مثالاً على التكوين وليس خريطة واجهة مستخدم دقيقة لجهازك.
4. إصلاح ربط العناوين العامة/الخاصة
قد يتسبب NAT في عطل أكثر دقة: فقد يُعلن JVB عن عنوان IP خاص لعملاء الإنترنت حتى لو كان جهاز التوجيه يُعيد توجيه المنفذ الصحيح. تُظهر وثائق البدء السريع الحالية لـ Jitsi تعيينًا ثابتًا /etc/jitsi/videobridge/jvb.confللأنظمة التي تحتاج إلى ترجمة صريحة من العنوان المحلي إلى العنوان العام.
استبدل العناصر النائبة بعنوان المضيف الخاص الفعلي لـ JVB والعنوان العام الذي يمكن للعملاء البعيدين الوصول إليه. ثم أعد تشغيل JVB.
sudo systemctl restart jitsi-videobridge2
استخدم هذا الخيار فقط عندما يتوافق مع بنية شبكتك. قد تحتاج الخوادم ذات عناوين الشبكة العامة المباشرة، أو عمليات نشر Docker، أو بطاقات الشبكة المتعددة، أو IPv6، أو تقنية NAT الأكثر تعقيدًا، إلى إعدادات مختلفة. تجد المثال المرجعي في قسم NAT للبدء السريع في Jitsi .
5. بالنسبة لـ Docker، تحقق من أن منفذ JVB UDP منشور بالفعل
في Docker، لا تُجدي قاعدة جدار الحماية الصحيحة على المضيف نفعًا إذا لم ينشر حاوية JVB منفذ الوسائط الخاص بها. تشير وثائق Docker الخاصة بـ Jitsi JVB_PORTإلى أن القيمة الافتراضية هي 10000، وتوجه المسؤولين بفتح منفذ UDP 10000 على المضيف. تحقق من عملية النشر الحالية لديك.
ثم افحص ملفات Compose وبيئة التشغيل لديك، وتأكد من أن خدمة JVB تعرض منفذ UDP المقصود. إذا أجريت أي تغييرات JVB_PORT، فيجب أن تتطابق جميع إعدادات ربط المضيف وقاعدة جدار الحماية وأي توجيه NAT. يُنصح بالرجوع إلى دليل Jitsi Docker الرسمي للاستضافة الذاتية بدلاً من نسخ جزء قديم من Compose من دروس خارجية.
6. تأكد من أن Jicofo يستطيع رؤية جسر الفيديو
لا يكفي وجود منفذ UDP قابل للوصول إليه تمامًا إذا لم يتم تسجيل JVB في لوحة تحكم XMPP. يختار Jicofo جسر فيديو للمؤتمر، ويوصي دليل نشر Jitsi القابل للتوسع بمراجعة سجلات كل من Prosody وJicofo بعد إعادة تشغيل الخدمات للتأكد من اتصال الجسور وتفعيلها.
إذا قمت بتخصيص نطاقات XMPP أو تشغيل عدة عُقد، فتأكد من أن Jicofo وJVB يستخدمان نفس خادم الدردشة الجماعية (MUC) الخاص بـ "brewery" الخاص بالجسر. تنص وثائق Jitsi Videobridge MUC الرسمية على أنه يجب أن يشير Jicofo jicofo.bridge.brewery-jidإلى نفس خادم الدردشة الجماعية (MUC) الذي تستخدمه مثيلات Videobridge.
يُعدّ هذا الأمر بالغ الأهمية، خاصةً بعد تغييرات اسم المضيف، أو عمليات النقل، أو نشر البرامج على مضيفين منفصلين، أو تعديلات التكوين اليدوية. بالنسبة لعمليات تثبيت الحزم القياسية التي تم إنشاؤها باستخدام المثبّت الرسمي، تجنّب إعادة كتابة تكوين XMPP إلا إذا أشارت سجلاتك بالفعل إلى وجود مشكلة في التسجيل أو المصادقة.
7. استبعد وجود شبكة عميل مقيدة أو شبكة افتراضية خاصة (VPN) أو خادم وكيل (Proxy).
إذا كان الخادم يعمل لدى بعض المستخدمين دون غيرهم، فاختبره من شبكة مختلفة قبل تغيير إعداداته. قد تحظر شبكات الشركات، وشبكات الواي فاي الخاصة بالضيوف، وشبكات VPN، والخوادم الوكيلة الصارمة بروتوكول UDP. يُعدّ فصل اتصال VPN أو الخادم الوكيل مؤقتًا اختبارًا تشخيصيًا مفيدًا؛ أعد توصيله لاحقًا إذا تطلّب الأمر ذلك في مؤسستك.
يمكن أن يساعد الاختبار المؤقت بدون VPN أو وكيل يدوي في التمييز بين تقييد شبكة العميل وفشل JVB على مستوى الخادم.
يشرح دليل Jitsi لأنظمة Debian/Ubuntu استخدام منفذ TCP 5349 كمسار احتياطي لبروتوكول TURN لنقل الصوت والفيديو عند حظر بروتوكول UDP. إذا كنت بحاجة إلى ضمان اتصال موثوق للمستخدمين على الشبكات ذات القيود، فتحقق من إعدادات TURN/coturn لديك بدلاً من افتراض أن فتح منفذ TCP 443 للموقع الإلكتروني يوفر تلقائيًا مسارًا احتياطيًا للوسائط.
8. أعد المحاولة بجلسة متصفح جديدة فقط بعد اجتياز فحوصات الخادم
من غير المرجح أن يكون سبب المشكلة جلسة متصفح قديمة، بل على العكس، قد يكون مسار JVB معطلاً، خاصةً عندما يواجه جميع المشاركين نفس خطأ الاتصال، ولكن يمكن حل هذه المشكلة بسرعة. أعد تحميل الغرفة، أو جرب نافذة تصفح خاصة، أو امسح بيانات الموقع لنطاق Jitsi الخاص بك، ثم سجل الدخول مرة أخرى إذا كانت المصادقة مفعلة.
تُعد جلسة المتصفح النظيفة فحصًا منخفض المخاطر من جانب العميل، ولكن لا ينبغي أن تحل محل استكشاف أخطاء JVB وجدار الحماية وNAT من جانب الخادم.
إذا تكرر الخطأ عبر متصفحات وشبكات مختلفة، فارجع إلى عمليات التحقق من جانب الخادم بدلاً من مسح بيانات المتصفح بشكل متكرر.
كيفية التحقق من أن الإصلاح قد نجح بالفعل
لا تعتبر المشكلة محلولة لمجرد اختفاء نافذة الخطأ المنبثقة. اختبر مسار الوسائط بالكامل.
أنشئ غرفة جديدة وانضم إليها من جهازين.
ضع الأجهزة على شبكات مختلفة إن أمكن، مثل جهاز متصل بشبكة الإنترنت المنزلية وآخر متصل بشبكة بيانات الهاتف المحمول.
تأكد من استمرار تدفق الصوت والفيديو في كلا الاتجاهين لعدة دقائق.
راقب سجلات JVB و Jicofo أثناء الانضمام وتحقق من تعيين المؤتمر إلى جسر بدون أعطال متكررة في ICE أو فشل صحة الجسر.
أعد تشغيل sudo ss -lunp | grep ':10000'فحص حالة جدار الحماية بعد أي إعادة تشغيل أو تغيير في جدار الحماية.
في حالة تركيبات متعددة الجسور، اختبر أكثر من مؤتمر واحد. يشرح دليل الإعداد القابل للتطوير من Jitsi أن Jicofo يختار جسر فيديو للمؤتمرات الجديدة، لذا قد يتسبب جسر واحد غير سليم في حدوث أعطال متقطعة حتى عندما يعمل جسر آخر.
جدول التشخيص السريع
الأعراض
الفحص التالي الأكثر فائدة
الجميع يواجه خطأ الجسر
خدمة JVB، تسجيل Jicofo، UDP 10000، تعيين NAT/عام
يفشل المستخدمون الموجودون على مكتب واحد أو شبكة واي فاي واحدة فقط
جدار حماية العميل، VPN/الوكيل، حظر UDP، الرجوع إلى TURN
لن تستمر خدمة JVB في العمل
journalctl -u jitsi-videobridge2بالنسبة لأخطاء الربط، أو التكوين، أو JVM، أو XMPP
يعمل على الشبكة المحلية (LAN) ولكنه لا يعمل عبر الإنترنت.
جدار الحماية السحابي، إعادة توجيه جهاز التوجيه، تعيين العناوين العامة/الخاصة
واجهة مستخدم Docker تعمل، لكن لا توجد وسائط
تم نشر منفذ UDP JVB ومطابقتهJVB_PORT
بدأت حالات الفشل بعد تغييرات اسم المضيف/XMPP
مصادقة JVB وتكوين MUC الخاص بالمصنع
خلاصة القول
بالنسبة لخادم Jitsi Meet المُستضاف ذاتيًا، يُفضل التعامل مع رسالة "فشل الاتصال بالجسر" كمشكلة في مسار الوسائط أو تسجيل الجسر أولًا. تأكد من سلامة Jitsi Videobridge، وأن منفذ UDP 10000 يستمع ويمكن الوصول إليه عبر جميع طبقات جدار الحماية/NAT، وأن JVB يُعلن عن عنوان IP عام صالح عند استخدام NAT، وأن Jicofo يتعرف على الجسر. بعد إجراء هذه الفحوصات فقط، يُمكنك مراجعة ذاكرة التخزين المؤقت للمتصفح أو إعدادات العميل الفردية.
يعتمد الحل الأمثل على بنية الشبكة لديك، لذا تجنب استخدام مفاتيح تكوين Jitsi القديمة لمجرد ظهورها في منشورات المنتديات القديمة. تتوافق الأوامر والإعدادات المذكورة أعلاه مع دليل Jitsi الرسمي الحالي ومصادر تكوين Jitsi Videobridge الحالية التي تم التحقق منها في أكتوبر 2026.