أسهل طريقة لإنشاء نطاق مخصص لـ Jitsi Meet Docker هي توجيه اسم مضيف DNS إلى مضيف Docker، وتعيينه PUBLIC_URLإلى عنوان URL النهائي لبروتوكول HTTPS، وتكوين TLS موثوق به لنفس اسم المضيف، والتأكد من إمكانية وصول وسائط WebRTC إلى Jitsi Videobridge. للتثبيت المباشر على الإنترنت، يدعم إعداد Docker الرسمي أتمتة الشهادات المدمجة من خلال [أدخل أسماء النطاقات ENABLE_LETSENCRYPTهنا LETSENCRYPT_DOMAIN] LETSENCRYPT_EMAIL.
يستخدم هذا الدليل meet.example.comمثالًا عمليًا ويفترض استخدام مشروع docker-jitsi-meet القياسي . استبدل اسم المضيف وعنوان البريد الإلكتروني وعنوان IP المذكورين في المثال بقيمك الخاصة. تمت مراجعة الإعدادات الموضحة هنا ومقارنتها بدليل Jitsi Docker الرسمي والمشروع الحالي env.exampleبتاريخ 7 أكتوبر 2026.
يعمل النطاق المخصص بشكل أفضل عند تحديد اسم المضيف قبل طلب الشهادة. على سبيل المثال، إذا كان ينبغي للمستخدمين فتح نطاق معين https://meet.example.com، PUBLIC_URLفيجب أن يستخدم كل من نظام أسماء النطاقات (DNS) وشهادة TLS نفس النطاق meet.example.com. يُعدّ الخلط jitsi.example.comبين النطاقين meet.example.comسببًا شائعًا لظهور تحذيرات الشهادة أو عمليات إعادة التوجيه إلى المضيف الخاطئ.
docker-jitsi-meetوملفه .env.ينص دليل Jitsi Docker الرسمي على PUBLIC_URLضرورة ضبط النطاق على النطاق الحقيقي لنشر بيئة الإنتاج. كما يوثق الدليل استخدام المنافذ 80/TCP و443/TCP و10000/UDP كمنافذ خارجية أساسية للإعداد المباشر القياسي. راجع دليل الاستضافة الذاتية لـ Jitsi Docker .
أنشئ سجل A لاسم المضيف الذي ترغب باستخدامه. في هذا المثال، meet.example.comيشير إلى عنوان IPv4 العام للخادم. إذا كان خادمك يتمتع باتصال IPv6 مستقر، يمكنك أيضًا إضافة سجل AAAA يشير إلى عنوان IPv6 العام الخاص به.
Type: A
Name: meet
Value: YOUR_PUBLIC_IPV4
TTL: 300لا تنسخ 203.0.113.10من الرسم التوضيحي إلى بيئة تشغيل حقيقية؛ فهذا العنوان مخصص للتوثيق. إذا كنت تستخدم موفر خدمة DNS مع وضع وكيل/شبكة توصيل محتوى (CDN)، فابدأ بحلّ DNS العادي فقط ما لم تتأكد من أن الوكيل يدعم نمط حركة مرور Jitsi الذي تنوي استخدامه.
افتح .envالملف في المجلد الذي استنسخته أو استخرجت الملفات إليه docker-jitsi-meet. بالنسبة للنشر المباشر حيث يستمع حاوية Jitsi للويب بشكل علني على المنفذين 80 و443، فإن الإعدادات المهمة هي:
PUBLIC_URL=https://meet.example.com
HTTP_PORT=80
HTTPS_PORT=443
ENABLE_HTTP_REDIRECT=1
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
LETSENCRYPT_EMAIL=admin@example.com
LETSENCRYPT_ACME_SERVER=letsencryptPUBLIC_URLالأمر ليس مجرد إجراء شكلي. يستخدمه جيتسي أثناء بناء إعدادات فعّالة، لذا فإن تركه على localhost أو على اسم مضيف قديم قد يؤدي إلى روابط معطّلة وسلوك غير متناسق. كما يشير مثال المشروع الحالي إلى أنه إذا استخدمتَ منفذ HTTPS غير قياسي عمدًا، فيجب أن يكون هذا المنفذ ضمن PUBLIC_URL.
يُحدد النموذج الرسمي حاليًا ZeroSSL كخادم ACME افتراضي، ويسمح باستخدام LETSENCRYPT_ACME_SERVER="letsencrypt"Let's Encrypt عند الرغبة في ذلك تحديدًا. إذا كان تثبيتك الحالي يحصل بالفعل على شهادة موثوقة بنجاح، فاحتفظ بإعدادات ACME التي تتوافق مع بيئة عملك بدلًا من تغيير مزود الخدمة دون سبب وجيه.
بالنسبة لنشر Docker المباشر عبر الإنترنت الموضح أعلاه، اسمح بالوصول إلى المنافذ 80/TCP و443/TCP و10000/UDP. أبقِ منفذ إدارة SSH مفتوحًا أيضًا. على مضيف Ubuntu يستخدم UFW، إليك مثال بسيط:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw status verboseتُستخدم منافذ الويب لخدمة الموقع وتحدي الشهادة. يُعد منفذ UDP 10000 المنفذ الافتراضي لبروتوكول Jitsi Videobridge. قد يتم تحميل الصفحة بنجاح بينما تفشل الاجتماعات أو تفقد الصوت/الفيديو في حال حظر منفذ الوسائط، لذا فإن التحقق من HTTPS فقط غير كافٍ.
إذا كان جهازك المضيف خلف جدار حماية NAT، فراجع أيضًا الدليل JVB_ADVERTISE_IPSالرسمي. يشرح الدليل الرسمي أن هذا المتغير يتحكم في عنوان IP الذي يعلنه Jitsi Videobridge للوسائط، وهو مطلوب في العديد من عمليات نشر الشبكات المحلية (LAN) أو تطبيقات NAT. مثال نموذجي على الإنترنت العام هو:
JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4
احفظ التغييرات .env، ثم أعد إنشاء الحاويات لتطبيق تغييرات البيئة:
docker compose down
docker compose up -d
docker compose psلا يُعدّ استخدام حل بسيط restartالخيار الأمثل بعد تغيير متغيرات البيئة، لأن تعريف الحاوية الحالي قد لا يزال يحتوي على البيئة السابقة. إعادة إنشاء المكدس يجعل PUBLIC_URLقيم المنافذ وإعدادات الشهادة الجديدة واضحة.
إذا كنت تبدأ بنسخة جديدة من المشروع، فاتبع خطوات البدء السريع الرسمية أولاً، بما في ذلك إنشاء كلمات المرور المطلوبة وإنشاء مجلدات التكوين. تعمل إصدارات Jitsi الحديثة للحاويات على تشغيل الخدمات كمستخدم غير مميز وتتطلب مساحة تخزين قابلة للكتابة ومجلدات مؤقتة، لذا يجب أن يتبع التثبيت الجديد تمامًا أوامر المجلدات في الدليل الحالي بدلاً من دليل قديم من جهة خارجية.
بمجرد نشر نظام أسماء النطاقات (DNS)، تحقق من أن اسم المضيف يُحل إلى العنوان العام المتوقع:
dig +short meet.example.comثم اختبر نقطة نهاية HTTPS:
curl -I https://meet.example.comتُثبت الاستجابة الناجحة أن نظام أسماء النطاقات (DNS) وبروتوكول TCP 443 وخدمة الويب تعمل معًا. لكنها لا تُثبت بعدُ عمل الوسائط متعددة الأطراف، لذا فهي بمثابة فحص مؤقت وليست النتيجة النهائية.
إذا digأعاد عنوانًا قديمًا، فانتظر حتى ينتهي وقت صلاحية DNS أو صحّح السجل. إذا كان DNS صحيحًا ولكن curlانتهت مهلة الاتصال، فافحص مجموعات أمان السحابة، وجدار حماية المضيف، وقواعد الموجّه/NAT، وما إذا كانت خدمة أخرى تستخدم المنفذ 443 بالفعل.
إذا استمر المتصفح في عرض تحذير بشأن الشهادة، فافحص سجلات حاوية الويب بدلاً من حذف التكوين بشكل متكرر وطلب شهادة أخرى:
docker compose logs --tail=200 webابحث عن أخطاء التحقق من صحة ACME، أو فشل ربط المنافذ، أو عدم تطابق اسم المضيف. يحذر دليل Jitsi من حدود معدل طلبات سلطة إصدار الشهادات، ويوصي بالاحتفاظ بمساحة تخزين التكوين التي تحتوي على الشهادات الصادرة. أثناء تجارب الإعداد المتكررة، قد يكون استخدام بيئة الاختبار مفيدًا، ولكن بعد التوقف عن استخدامها، يشير الدليل إلى أنه قد يلزم مسح بيانات شهادات بيئة الاختبار القديمة من مساحة تخزين الويب قبل طلب شهادة الإنتاج.
إذا كان لديك بالفعل شهادة موثوقة من مصدر آخر، فإن Jitsi يدعم أيضًا ربط سلسلة الشهادات الكاملة والمفتاح الخاص الموجودين بخدمة الويب بدلاً من تفعيل آلية ACME المدمجة. اتبع مثال ربط الشهادة في قسم الشهادات الموجودة الرسمي .
قم بزيارة الموقع https://meet.example.comباستخدام متصفح حديث. ستظهر لك صفحة Jitsi الرئيسية تحت اسم المضيف الذي اخترته مع مؤشر TLS صالح. أنشئ غرفة اختبار باسم مؤقت.
استخدم بروتوكول HTTPS للاجتماعات الحقيقية. يحذر دليل Docker الرسمي تحديدًا من أن الوصول المباشر عبر HTTP قد يتسبب في تعطل واجهات برمجة تطبيقات WebRTC في المتصفح، مثل الوصول إلى الميكروفون والكاميرا. لذا، يُعدّ HTTPS جزءًا من الإعدادات الوظيفية، وليس مجرد إجراء أمني إضافي.
انضم إلى نفس الغرفة من جهازين أو شبكتين منفصلتين إن أمكن. تأكد من قدرة كل مشارك على إرسال واستقبال الصوت والفيديو. يُعد اختبار المتصفحين مهمًا، إذ قد يعمل الموقع الإلكتروني بشكل صحيح حتى لو كان عنوان Videobridge أو مسار UDP غير صحيح.
بالنسبة للأنظمة المثبتة خلف جدار الحماية NAT، من الأعراض الشائعة أن الاتصال الأول يبدو طبيعيًا، لكن الوسائط تفشل عند انضمام المزيد من المشاركين. في هذه الحالة، أعد التحقق من JVB_ADVERTISE_IPSتعيين NAT العام، وUDP 10000. يشير دليل Jitsi صراحةً إلى أن عنوان وسائط Videobridge يظل صالحًا حتى عند معالجة حركة مرور HTTP بواسطة خادم وكيل عكسي.
يكون التكوين المباشر المذكور أعلاه مناسبًا عندما يكون بإمكان حاوية الويب Jitsi امتلاك المنافذ العامة 80 و443. إذا كان الخادم نفسه يشغل بالفعل Nginx أو Apache أو Caddy أو Traefik أو أي وكيل آخر على تلك المنافذ، فلا تحاول ربط Jitsi بها في نفس الوقت.
بالنسبة لخادم وكيل عكسي على نفس المضيف، يوصي دليل Jitsi Docker الرسمي بتعطيل HTTPS داخل حاوية Jitsi، وتجنب كشف منافذ الويب الداخلية الخاصة بها للعامة، وإعادة توجيه الطلبات إلى مدخل HTTP الخاص بالحاوية. يجب أن يدعم الخادم الوكيل أيضًا إعادة توجيه WebSocket /xmpp-websocket. بيئة Jitsi النموذجية هي:
DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0
PUBLIC_URL=https://meet.example.comثم قم بإنهاء الشهادة الموثوقة على خادم الوكيل العكسي. يُعد هذا الخيار الأمثل عندما يدير خادم وكيل واحد شهادات لعدة تطبيقات. ولا يُعد هذا سببًا لتغيير النطاق الظاهر PUBLIC_URLللمستخدمين؛ إذ يجب أن يظل نطاق HTTPS النهائي ظاهرًا لهم.
أعد إنشاء الحاويات باستخدام docker compose downالأمر ` docker compose up -d.` ثم تحقق أيضًا من أنك قمت بتحرير .envالملف المستخدم بواسطة مشروع Compose الذي تقوم بتشغيله فعليًا.
تأكد من أن سجلات DNS A/AAAA تشير إلى الخادم الذي يستقبل التحدي، وأن المنفذ العام 80 متاح عند استخدام آلية الشهادة المباشرة المدمجة. تحقق docker compose logs webمن خطأ ACME المحدد قبل إرسال طلب آخر.
تحقق من منفذ UDP 10000، وفي حالة نشر NAT، اضبط القيمة الصحيحة JVB_ADVERTISE_IPS. تذكر أن الخادم الوكيل العكسي يتعامل مع حركة مرور الويب؛ فهو لا يحل محل مسار وسائط Videobridge.
تحقق من سلسلة الشهادات. يشير دليل Jitsi Docker إلى أن تطبيقات الجوال لا تعمل مع الشهادة الذاتية التوقيع الافتراضية. استخدم شهادة موثوقة علنًا أو بنية تحتية تتلقى فيها التطبيقات سلسلة شهادات موثوقة.
meet.example.comيُحال إلى العنوان العام المقصود.PUBLIC_URL=https://meet.example.comيطابق عنوان URL الخاص بالمتصفح تمامًا.meet.example.com...JVB_ADVERTISE_IPSيكون هذا صحيحًا عندما يكون الخادم خلف جدار الحماية NAT أو يحتاج إلى عناوين معلنة صريحة.docker compose psيعرض الحاويات المطلوبة قيد التشغيل.بمجرد اجتياز تلك الفحوصات، فإن النطاق المخصص لا يشير فقط إلى Jitsi، بل يتم تكوينه للأجزاء المهمة بالفعل في اجتماع حقيقي: HTTPS، والإشارات، ونقل الوسائط.
قم بتشخيص ارتفاعات وحدة المعالجة المركزية في متصفح 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 لإعادة الاتصال بدقة، وتعيين مطالبات المستخدم، واختبار تسجيل الخروج.
