قد تظهر رسالة "تم قطع الاتصال" في مكالمة Jitsi Meet عند انقطاع اتصال الإشارة الخاص بالاجتماع، أو عندما يتعذر وصول بيانات وسائط WebRTC إلى جسر الفيديو، أو عند انقطاع الجلسة بسبب شبكة محلية أو متصفح. ابدأ بالتحقق مما إذا كانت المشكلة تؤثر على مشارك واحد أو على جميع المشاركين. عادةً ما يُساعدك هذا التمييز على تحديد ما إذا كان عليك استكشاف أخطاء الجهاز والشبكة أو خادم Jitsi وإصلاحها.
| ما تلاحظه | التحقق الأول | من المحتمل أن تكون هذه المنطقة مناسبة للتحقيق |
|---|---|---|
| شخص واحد فقط يقوم بقطع الاتصال | إعادة الانضمام من شبكة أو جهاز آخر | شبكة Wi-Fi الخاصة بالمشارك، أو VPN، أو متصفح، أو تطبيق، أو جدار حماية محلي |
| قام العديد من الأشخاص بفصل الاتصال في وقت واحد | اسأل عما إذا كانوا يستخدمون نفس مضيف Jitsi | عطل في الخادم، أو الخادم الوكيل العكسي، أو جدار الحماية، أو اتصال الإنترنت، أو الخدمة |
| يبقى الاجتماع مفتوحًا، لكن الصوت/الفيديو يتجمدان. | أطفئ الكاميرا لفترة وجيزة وتحقق مما إذا كان الصوت قد عاد | مسار الوسائط، أو عرض النطاق الترددي، أو تصفية UDP، أو حمل الجهاز |
| يحدث الانقطاع فقط على شبكة شركة واحدة أو شبكة مدرسة واحدة | كرر ذلك مرة واحدة باستخدام نقطة اتصال معتمدة | سياسة الشبكة، أو الخادم الوكيل، أو الشبكة الافتراضية الخاصة (VPN)، أو حركة مرور WebRTC المحظورة |
| تبدأ المشكلة بعد تغيير الخادم أو الوكيل | تحقق من سجلات التكوين والخدمة الحديثة | إعدادات إشارات Jitsi المستضافة ذاتيًا، وTLS، وNAT، أو جدار الحماية |
لا تقم بتغيير عدة إعدادات في وقت واحد. اختبر تغييراً واحداً، ثم انضم إلى الاجتماع نفسه مرة أخرى إن أمكن، ولاحظ ما إذا كان العرض قد تغير.
يستخدم Jitsi Meet تقنية WebRTC لنقل الصوت والفيديو في الوقت الفعلي. ولا يقتصر نجاح الاجتماع على تحميل الصفحة فحسب، بل يجب على المتصفح الحفاظ على التواصل مع الخادم وإنشاء مسار وسائط إلى Jitsi Videobridge. قد يبقى أحد المشاركين مرئيًا في الغرفة أحيانًا بينما تتوقف الوسائط عن العمل؛ وقد تشير رسالة "تم قطع اتصالك" إلى انقطاع أوسع في الجلسة أو الإشارة. ولا يمكن تحديد السبب الدقيق للمشكلة من هذه الرسالة وحدها.
دوّن وقت انقطاع الاتصال، وما إذا كان المتصفح قد عرض رسالة إعادة الاتصال، وما إذا كان مشاركون آخرون قد تأثروا، وما إذا كان الاجتماع مُستضافًا على meet.jit.si أو على نطاق Jitsi خاص. تجنّب نشر رابط الاجتماع الخاص، أو اسم الغرفة، أو رمز الوصول، أو سجلات النظام غير المُنقّحة علنًا.
استخدم خيار إعادة الاتصال الظاهر على الشاشة إن ظهر. إذا لم يُستأنف الاجتماع، فافتح رابط الدعوة الأصلي في علامة تبويب جديدة وانضم مجددًا. تأكد من تطابق اسم الغرفة ونطاق المضيف مع الدعوة؛ فقد يؤدي خطأ إملائي أو رابط قديم إلى غرفة أو مضيف مختلف. إذا انقطع اتصال الجميع، انتظر قليلًا واسأل منظم الاجتماع عما إذا كانت الخدمة لا تزال متاحة قبل تحديث الصفحة بشكل متكرر.
قم بتحديث المتصفح، ثم أغلقه تمامًا، وحاول إجراء الاجتماع مرة أخرى. إذا تكرر انقطاع الاتصال، فجرّب متصفحًا آخر مدعومًا من Jitsi. يُدرج دليل المتصفحات المدعومة من Jitsi معلومات حول دعم المتصفحات وملاحظات النظام الأساسي؛ راجع تلك الصفحة لأن تفاصيل الدعم قابلة للتغيير. على أجهزة iPhone وiPad، تستخدم مختلف أنواع المتصفحات نفس محرك المتصفح الأساسي، لذا قد لا يؤدي تجربة متصفح آخر إلى تحديد المشكلة المتعلقة بمحرك المتصفح.
لإجراء مقارنة دقيقة، جرّب استخدام نافذة خاصة أو عطّل مؤقتًا الإضافات التي تُصفّي البرامج النصية، أو تحظر أدوات التتبع، أو تُعدّل طلبات الشبكة. إذا أدى ذلك إلى حل المشكلة، فأعد تفعيل الإضافات واحدة تلو الأخرى لتحديد التعارض. لا تترك إجراءات الحماية الأمنية معطّلة كحل دائم.
اقترب من نقطة وصول الواي فاي، وأوقف التنزيلات الكبيرة أو النسخ الاحتياطية السحابية مؤقتًا، ثم اختبر الاتصال مرة أخرى على شبكة أخرى مصرح لك باستخدامها. يمكن أن تساعدك نقطة اتصال الهاتف في التمييز بين مشكلة في شبكة المنزل أو مكان العمل ومشكلة في المتصفح أو الخادم. إذا كان Jitsi يعمل على الشبكة البديلة ولكنه ينقطع بشكل متكرر على الشبكة الأصلية، فأبلغ مسؤول الشبكة بوقت الاختبار واسأله عما إذا كانت حركة مرور WebRTC في الوقت الفعلي تخضع للتصفية.
قد يؤدي استخدام شبكة افتراضية خاصة (VPN) أو خادم وكيل أو بوابة تسجيل دخول أو جدار حماية إلى انقطاع الإشارات أو الوسائط. إذا كانت مؤسستك تتطلب استخدام VPN، فلا تتجاوز سياستها؛ استفسر من قسم تقنية المعلومات عما إذا كان مسموحًا باستخدام خادم Jitsi. إذا سُمح لك بإجراء مقارنة مع انقطاع اتصال VPN، فافعل ذلك لفترة وجيزة فقط ثم أعد تفعيله بعد ذلك.
على الهاتف، أبقِ تطبيق Jitsi أو المتصفح مفتوحًا أثناء الاختبار، وعطّل قيود توفير الطاقة لهذا الاختبار إذا كان جهازك يسمح بذلك. قد تُعلّق أنظمة تشغيل الهواتف المحمولة نشاط الشبكة في الخلفية. تأكد أيضًا من تحديث التطبيق ونظام التشغيل، ثم أعد تشغيل الجهاز إذا استمر انقطاع الاتصال. عادةً ما تؤثر مشكلة أذونات الميكروفون أو الكاميرا على الوصول إلى الجهاز بدلًا من إثبات انقطاع الشبكة، لذا تعامل مع هذه الأعراض بشكل منفصل.
أوقف تشغيل الكاميرا مؤقتًا وتحقق من استقرار الصوت. قد يُقلل هذا من استهلاك النطاق الترددي، ولكنه لا يُصلح مسار الخادم المعطل. إذا انقطع الصوت والفيديو معًا على شبكة واحدة، بينما يعملان بشكل طبيعي على شبكة أخرى، فتحقق من قيود جدار الحماية أو NAT. يُحدد دليل الاستضافة الذاتية لـ Jitsi منفذ TCP 443 للوصول العام إلى الإنترنت، ومنفذ UDP 10000 لاجتماعات الصوت/الفيديو العادية، ومنفذ TCP 5349 كخيار احتياطي عند حظر UDP؛ وقد يتضمن استخدام STUN الاختياري أيضًا منفذ UDP 3478. هذه متطلبات نشر من جانب الخادم، وليست منافذ يجب على المشارك فتحها على جهازه الشخصي. راجع إرشادات Jitsi الحالية لجدار الحماية وNAT .
إذا نجح الاجتماع عبر اتصال مختلف، فأبلغ مسؤول الشبكة بهذه المقارنة. واطلب منه مراجعة قواعد المؤسسة المتعلقة باسم مضيف Jitsi وحركة مرور WebRTC بدلاً من طلب إيقاف جدار الحماية بشكل كامل.
تأكد من أن اسم نظام أسماء النطاقات العام يُشير إلى الخادم المطلوب، وأن شهادة TLS صالحة، وأن حركة البيانات المطلوبة تصل إلى المضيف الصحيح. إذا كان الخادم خلف جهاز توجيه أو جدار حماية سحابي، فافحص جدار حماية المضيف ومجموعة الأمان أو قواعد إعادة توجيه المنافذ. لن تُجدي قاعدة في UFW نفعًا إذا كان جدار الحماية السحابي لا يزال يحظر حركة البيانات نفسها.
sudo ufw status verbose
sudo ss -lntupتُظهر هذه الأوامر قواعد جدار الحماية المحلي ومنافذ الاستماع، لكنها لا تُثبت إمكانية وصول المشاركين الخارجيين إلى الخدمة. اختبر الخدمة من شبكة خارجية وتأكد من أن جهاز التوجيه أو مزود الخدمة يُعيد توجيه حركة البيانات ذات الصلة إلى Jitsi Videobridge. تُشير Jitsi إلى أن عمليات النشر خلف جدار الحماية (NAT) قد تتطلب تعيينًا صحيحًا للعناوين العامة والمحلية عندما لا تعمل المكالمات من الخارج.
في حالة نشر خادم وكيل عكسي، تأكد من عمل بروتوكول HTTPS وأن الخادم الوكيل يُعيد توجيه إشارات WebSocket بشكل صحيح. يُوثّق دليل Docker/xmpp-websocket الرسمي المسار والعناوين المطلوبة لمثال Nginx الخاص به. قد يؤدي الخادم الوكيل الذي يُقدّم الصفحة ولكنه يُسقط WebSocket إلى عدم تمكّن المستخدمين من الحفاظ على جلسة الاجتماع.
عند استخدام Docker Compose، تأكد من PUBLIC_URLتطابق المنافذ المُستخدمة فعليًا من قِبل زوار النطاق العام، وأن منافذ المضيف المنشورة تتوافق مع إعدادات جدار الحماية والخادم الوكيل لديك. يُحذّر دليل Jitsi من أن بث اجتماع حقيقي مباشرةً عبر HTTP بدلاً من HTTPS قد يُسبب مشاكل في WebRTC. تجنّب نسخ أجزاء من إعدادات Jitsi من إصدار آخر دون التحقق من الإصدار وطريقة النشر المُستخدمة.
قارن وقت انقطاع الاتصال بسجلات الخدمة. في عمليات تثبيت حزم Debian أو Ubuntu، يوثق Jitsi ملفات السجل، بما في ذلك /var/log/jitsi/jvb.logملفات . /var/log/jitsi/jicofo.logأما /var/log/prosody/prosody.logفي عمليات نشر Docker، فيتم تخزين السجلات من خلال حاوياتها، لذا افحص مخرجات الحاوية ذات الصلة ودليل التكوين الخاص بالإصدار المثبت لديك.
sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.logابحث في محيط وقت وقوع الحادث عن عمليات إعادة تشغيل الخدمة، وتغييرات تسجيل الجسر، وأعطال WebSocket، وأخطاء الشهادات، أو انقطاعات الاتصال المتكررة. قم بإخفاء مُعرّفات المشاركين، وأسماء الغرف، وعناوين IP، والرموز المميزة قبل مشاركة السجلات. كما يُوصي دليل الاستضافة الذاتية لأنظمة Debian/Ubuntu بتجربة متصفح آخر، والتحقق من دعم WebRTC، ومراجعة قواعد جدار الحماية/NAT كخطوات أساسية لتصحيح الأخطاء.
انضم إلى اجتماع تجريبي من الجهاز والشبكة الأصليين، وابقَ متصلاً لفترة كافية لتغطية الفترة التي يحدث فيها العطل عادةً، وتأكد من استمرار عمل الصوت والفيديو. كرر العملية مع مشارك آخر إذا أثرت المشكلة على الجميع. في حالة النشر المُستضاف ذاتيًا، تحقق من إشارات المتصفح والوسائط من خارج شبكة الخادم. لا يكفي تحميل الصفحة بنجاح فقط؛ يجب أن يبقى الاجتماع متصلاً وأن يتمكن المشاركون من تبادل الصوت والفيديو.
قم بتشخيص ارتفاعات وحدة المعالجة المركزية في متصفح Jitsi Meet وقلل من حمل العميل عن طريق فحص مربعات الفيديو وتأثيرات الكاميرا ورسومات المتصفح وإعدادات المضيف.
تتبع حالة Jitsi Videobridge، وحمل المؤتمرات، وحركة المرور باستخدام نقطة نهاية Prometheus المدمجة، ثم استكشف البيانات وارسمها بيانيًا في Grafana.
قم بتكوين نطاق مخصص لـ Jitsi Meet Docker باستخدام DNS و PUBLIC_URL و HTTPS و Let's Encrypt ومنافذ جدار الحماية وإعدادات NAT والتحقق من طرف إلى طرف.
قم بإصلاح أخطاء 404 في وحدة تحكم إدارة Zimbra بعد تجديد شهادة SSL عن طريق التحقق من عنوان URL والمنفذ الصحيحين، وتوجيه الوكيل، وحالة الخدمة، والشهادات المنشورة، والسجلات.
تعرف على كيفية تشخيص وإصلاح تحذير تكوين PHP OPcache الخاص بـ Nextcloud عن طريق التحقق من إعدادات PHP SAPI النشطة، وحدود الحجم، والتعليقات، وإعادة التحقق.
قم باستكشاف أخطاء ترحيل قاعدة بيانات Kopano وإصلاحها بعد ترقية MySQL أو MariaDB عن طريق التحقق من النسخ الاحتياطية، وإصدارات الخادم، وأوضاع SQL، ومجموعة الأحرف، وحالة المخطط، والسجلات.
قم بتوصيل Nextcloud بـ LDAP أو Active Directory باستخدام النقل الآمن، وفلاتر المستخدم والمجموعة، وسمات تسجيل الدخول، وعملية نشر تم اختبارها.
إصلاح إشعارات Element Android على الهواتف التي تم إلغاء خدمة Google منها عن طريق تكوين UnifiedPush، وأذونات Android، وإعدادات البطارية، واختبارات التحقق الموثوقة.
قم بإزالة تحذير فهارس قاعدة البيانات المفقودة في Nextcloud باستخدام أمر occ الرسمي. قم بعمل نسخة احتياطية أولاً، ثم استعرض التغييرات، وقم بتشغيل عملية الإصلاح، وتحقق من النتيجة.
قم بتكوين Keycloak SSO لـ Element Web عن طريق ربط OIDC بـ Synapse، وتعيين عنوان URL لإعادة الاتصال بدقة، وتعيين مطالبات المستخدم، واختبار تسجيل الخروج.
