استعادة اتصال WebSocket الخاص بـ Collabora عبر الوكيل

عندما يُبلغ Collabora Online عن إغلاق اتصال Socket بشكل غير متوقع، تحقق أولاً مما إذا كان طلب WebSocket الخاص بالمتصفح يصل coolwsdعبر الخادم الوكيل العكسي. طابق مسار الخادم الوكيل مع إصدار Collabora، واحتفظ بترقية WebSocket ومسار عنوان URL، ثم اختبر مستندًا واحدًا مع مراقبة لوحة الشبكة وسجلات الخادم في المتصفح. إذا بدأت المشكلة بعد ترقية CODE 26.04 خلف Apache، فتحقق من ProxyPassقواعد Apache أولاً: تشير ملاحظات إصدار Collabora 26.04 إلى تغيير في عنوان URL المُختصر لـ WebSocket.

يُعدّ WebSocket اتصالاً ثنائي الاتجاه طويل الأمد تستخدمه Collabora بين المتصفح وخادمها أثناء فتح المستند. أما الخادم الوكيل العكسي فهو الخدمة التي تستقبل الطلب العام وتُعيد توجيهه إلى Collabora. تشير رسالة الخطأ إلى هذا الاتصال، لكنها لا تُثبت بالضرورة أن الخادم الوكيل هو السبب؛ فقد يؤدي رفض مضيف WOPI، أو عنوان URL عام غير صحيح، أو عدم تطابق بروتوكول TLS، أو استخدام خادم خلفي خاطئ، إلى توقف الجلسة.

قبل تغيير أي شيء، حدد مسارك

دوّن إصدار Collabora أو علامة الصورة، وبرنامج الوكيل، واسم مضيف Collabora العام، وما إذا كان بروتوكول TLS ينتهي عند الوكيل أو عند Collabora. تحقق من اسم الخدمة والصورة الحالية دون تغيير عملية النشر.

docker compose ps collabora
docker compose images collabora

استبدل collaboraاسم الخدمة في ملف Compose الخاص بك. بالنسبة للحاويات غير المُنشأة باستخدام Compose، استخدم docker psو docker inspectلتحديد الحاوية والصورة. لا تفترض أن latestالوسم لا يزال يشير إلى نفس الإصدار الذي اختبرته الأسبوع الماضي.

1. انظر إلى أين تتوقف عملية المصافحة في WebSocket

في المتصفح، افتح أدوات المطوّرين، ثمّ اختر الشبكة ، وحدّد خيار WS أو WebSocket، ثمّ أعد محاولة فتح أحد المستندات. يجب استخدام عنوان URL للطلب wss://عندما تكون الصفحة العامة تستخدم HTTPS. حدّد الطلب الفاشل وسجّل حالته ومسار URL الخاص به وعناوين الاستجابة. عادةً ما تُنهي عملية المصافحة الناجحة العملية بنجاح 101 Switching Protocolsوتبقى مفتوحة طوال فترة نشاط جلسة المستند.

• لا يظهر أي طلب WebSocket: تحقق من عنوان URL الخاص بتطبيق التكامل Collabora، ووحدة تحكم المتصفح، ونظام أسماء النطاقات (DNS)، وأي خطأ في إعادة التوجيه أو المحتوى المختلط قبل تعديل قواعد الخادم.
• إذا أعاد الطلب رمز 400 أو 404، قارن المسار المطلوب مع المسار الذي يُعيد توجيهه خادمك الوكيل والمسار الذي يدعمه إصدار Collabora المُثبّت. coolwsdقد يعني رمز 400 الذي يشير إلى "طلب غير صالح أو غير معروف" أن الطلب وصل إلى Collabora عبر مسار لا يقبله.
• يُرجع الطلب 502 أو 504: تحقق مما إذا كان بإمكان الوكيل الوصول إلى مصدر Collabora المُكوّن، وما إذا كان العنوان والمنفذ يشيران إلى الحاوية أو المضيف الصحيح.
• يُعيد الطلب الرمز 101، ثم يُغلق لاحقًا: افحص مهلة الخمول في الخادم الوكيل، وموازن الأحمال، وجدار الحماية، وشبكة العميل. اتصال WebSocket طويل الأمد، لذا فإن أي وسيط يُغلق الاتصالات الخاملة مبكرًا جدًا قد يُقاطع عملية فتح ناجحة.

2. قارن قاعدة الوكيل مع إصدار Collabora الخاص بك

استخدم إعدادات الخادم الوكيل العكسي الحالية لـ Collabora لبرنامج الخادم الوكيل والإصدار الذي تستخدمه. تأكد من معالجة مسار WebSocket كـ WebSocket، وأن الخادم الوكيل يُعيد توجيه رؤوس الترقية، ويحتفظ بالمسار وسلسلة الاستعلام المشفرة بدلاً من إعادة توجيهها أو إعادة كتابتها. يجب على الخادم الوكيل أيضًا إرسال اسم المضيف العام والبروتوكول بشكل متسق مع اسم الخادم الخارجي المُكوّن في Collabora وإعدادات إنهاء TLS.

بالنسبة لـ Nginx، راجع موقع WebSocket الخاص به وتوجيهات HTTP/1.1 Upgradeوإعادة Connectionالتوجيه في المثال الحالي لـ Collabora. أما بالنسبة لـ Apache، فقارن ProxyPassالقاعدة والترتيب مع المثال الحالي؛ لا تقم بلصق /cool/…/wsتطابق قديم دون تغيير دون التحقق مما يطلبه الإصدار المثبت لديك الآن.

يُعدّ التحقق من هذا الإصدار مهمًا لـ CODE 26.04. تشير ملاحظات إصدار Collabora، المنشورة في 8 يونيو 2026، إلى عنوان URL مُختصر لـ WebSocket، وتُفيد بأن مُستخدمي خادم Apache العكسي بحاجة إلى تعديل ProxyPassإعداداتهم. أضافت التحديثات اللاحقة لـ 26.04 خاصية الرجوع إلى عناوين URL القديمة، لذا قد تعمل قاعدة قديمة على بعض الإصدارات؛ ويُوثّق تقرير Collabora المُحدّث لـ WebSocket 26.04 هذه المُتابعة. لا يُغني الرجوع إلى عنوان URL القديم عن مُطابقة إعدادات الخادم الوكيل الحالية مع الإصدار المُثبّت. يُرجى قراءة ملاحظات إصدار CODE 26.04 ومثال SDK المُحدّث معًا.

3. رصد حالة فشل واحدة وإجراء تغيير محدد واحد

ابدأ بتسجيل قصير قبل إعادة محاولة حفظ المستند. --sinceيحد خيار Docker من الإخراج الأولي، بينما --followيقوم خيار آخر بتسجيل أسطر جديدة؛ راجع مرجع سجلات Docker Compose .

docker compose logs --since=2m --follow collabora

سجّل وقت الاختبار وابحث عن الطلب نفسه في سجلات Collabora والخادم الوكيل. إذا طلب المتصفح مسارًا يُعيد توجيهه الخادم الوكيل إلى خادم خلفي خاطئ، فحدّث مسار WebSocket هذا فقط باستخدام مثال Collabora المتوافق مع الإصدار. إذا وصل الطلب إلى Collabora ولكن تم رفض المضيف أو المصدر أو البروتوكول، فقارن اسم المضيف العام والمنفذ مع اسم الخادم المُكوّن والعناوين المُعاد توجيهها. إذا أظهر السجل بدلاً من ذلك رفضًا لمضيف WOPI أو فشلًا في طلب معلومات الملف، فتحقق من المضيف المسموح به لخادم التكامل وإمكانية الوصول إليه من حاوية Collabora؛ وهذه خطوة منفصلة عن مصافحة WebSocket في المتصفح.

أعد تحميل الخادم الوكيل بعد التحقق من صحة إعداداته باستخدام أمر التحقق من بناء الجملة الخاص به. تجنب تغيير إنهاء بروتوكول TLS، وقوائم السماح للمضيفين، وإعادة كتابة عناوين URL في الوقت نفسه: تغيير سبب واحد لكل اختبار يجعل النتيجة التالية قابلة للتفسير. لا تُعطّل التحقق من بروتوكول TLS أو تسمح لكل مضيف WOPI كاختصار.

4. تحقق من الإصلاح من المتصفح إلى المستند

أعد محاولة الوصول إلى نفس المستند. في أدوات المطورين، تأكد من استجابة طلب WebSocket 101 Switching Protocolsوبقاء الاتصال مفتوحًا. تأكد من اكتمال تحميل المستند، وبقاء الاتصال قائمًا، وقبول تعديل بسيط يتم حفظه بنجاح. لا يكفي وجود اتصال سليم وحده إذا استمر فشل الوصول إلى ملف WOPI أو حفظه.

إذا استمر فشل عملية المصافحة، قارن مسار طلب المتصفح، وسطر الوصول/الخطأ الخاص بالوكيل، وإدخال coolwsdالسجل المطابق في نفس الطابع الزمني. تُظهر هذه المقارنة الثلاثية ما إذا كان المتصفح، أو الوكيل، أو مسار Collabora، أو مضيف WOPI هو المكان التالي الذي يجب التحقق منه. عند طلب المساعدة، احجب رموز الوصول، ومعرّفات المستندات، وأسماء المستخدمين، وأسماء المضيفين الخاصة من تفاصيل المتصفح وسجلات النظام.