قد يبدو Collabora Online سليمًا للوهلة الأولى، ولكنه قد يتعطل بمجرد محاولة المحرر إنشاء اتصال WebSocket مباشر. تتمثل الأعراض الشائعة في بدء تحميل المستند ثم ظهور رسالة تفيد بإغلاق اتصال WebSocket بشكل غير متوقع، مصحوبة أحيانًا بفشل wss://الطلب في المتصفح. في إصدار 2026، ثمة سبب خاص بهذا الإصدار يستدعي التحقق قبل إجراء أي تغييرات أخرى: فقد قدم فرع 26.04 عنوان URL أكثر اختصارًا لـ WebSocket، وقد تتعارض قواعد الوكيل العكسي القديمة معه.
تشير ملاحظات إصدار CODE 26.04 الرسمية من Collabora إلى أن الإصدار 26.04.1، الصادر في 8 يونيو 2026، كان يتطلب من مستخدمي خادم Apache2 العكسي تغيير قاعدة ProxyPass الخاصة بهم لتتوافق مع عنوان URL الجديد المُختصر لـ WebSocket. وتشير ملاحظات الإصدار 26.04.2.x اللاحقة إلى أن CODE يمكنه الرجوع إلى عنوان URL القديم في حال تعذر استخدام المسار الجديد، ويُصدر تحذيرًا يُوجه المسؤولين إلى توصيات الوكيل الحالية. كما أن فرع Collabora Online 26.04 الخاص بالمؤسسات مُحدّث حتى عام 2026، لذا ينبغي على المسؤولين مقارنة أي إعدادات وكيل منسوخة من دليل الإصدار 24.04 أو 25.04 الأقدم مع أحدث وثائق المورّد قبل اعتبار المشكلة عطلًا عشوائيًا في الشبكة.
لا تُحدد الرسالة سببًا جذريًا واحدًا. هذا يعني أن اتصال WebSocket بين المتصفح وCollabora إما لم يُحدَّث بنجاح أبدًا، أو أنه تم إنشاؤه ثم توقف بشكل غير متوقع. هذا التمييز مهم لأن الحلول تختلف.
| السلوك الملحوظ | أهم فحص أولي مفيد | الأسباب النموذجية |
|---|---|---|
| يفشل فور فتح المستند | شبكة المتصفح > سجلات الوصول/الأخطاء لخدمات الويب والخوادم الوكيلة العكسية | مسار خاطئ /cool/، رؤوس الترقية مفقودة، قاعدة أباتشي غير متوافقة مع الإصدار 26.04، عدم تطابق المضيف/الأصل |
| يعمل لفترة وجيزة، ثم ينقطع الاتصال على فترات زمنية قابلة للتكرار | مهلة الخمول للوكيل، وبوابة الدخول، وموازن الأحمال، وجدار الحماية | مهلة الاتصال قصيرة جدًا بالنسبة لبروتوكول WebSocket طويل الأمد |
| الاكتشاف ناجح لكن التحرير فاشل | اختبر WebSocket بشكل منفصل عن/hosting/discovery | يمكن الوصول إلى نقاط نهاية HTTP بينما لا يمكن الوصول إلى مسار WebSocket |
| يفشل متصفح واحد أو مسار شبكة واحد فقط | قارن بين بروتوكول الطلب وسلوك الوكيل | معالجة بروتوكول HTTP/2 أو HTTP/3، وإعادة توجيه CONNECT، وتصفية الوسطاء |
| سجل الخادم يرفض الترقية صراحةً | اقرأ الخطأ الكامل لـ coolwsd | عدم تطابق في إعدادات المصدر، أو المضيف، أو المنفذ، أو مضيف WOPI، أو الوكيل |
إذا ظهرت المشكلة مباشرةً بعد الترقية من الإصدار 25.04 أو إصدار أقدم من CODE إلى الإصدار 26.04، فاعتبر الخادم الوكيل العكسي هو السبب الرئيسي. هذا ليس مجرد تخمين، فقد وثّقت شركة Collabora تغيير عنوان URL المُختصر لبروتوكول WebSocket في ملاحظات الإصدار 26.04، كما أبلغت إحدى المشكلات الرسمية في المشروع عن فشل بروتوكولات WebSocket بعد الترقية إلى الإصدار 26.04.1 إلى حين تعديل قواعد خادم Apache الوكيل.
لا تحلّ هذه المشكلة بالرجوع إلى إصدار أقدم دون تعديل الخادم الوكيل القديم. قد يكون الرجوع إلى الإصدار السابق إجراءً مؤقتًا، لكن الحل الدائم هو مواءمة الخادم الوكيل مع الإصدار الذي تنوي تشغيله. بالنسبة إلى Apache، استخدم إعدادات خادم Collabora Online الوكيل الحالية بدلاً من نسخة أقدم من الإصدار 26.04. يُوثّق سجل مشكلات WebSocket الخاص بـ Collabora (الإصدار 26.04) حالةً تم فيها استعادة التشغيل بعد تحديث قواعد Apache.
اختبر نقاط نهاية Collabora العادية أولاً:
curl -I https://office.example.com/hosting/discovery
curl -I https://office.example.com/hosting/capabilitiesتُثبت الاستجابة الناجحة إمكانية الوصول إلى نظام أسماء النطاقات (DNS) وبروتوكول أمان طبقة النقل (TLS) وخادم الوكيل الأمامي وجزء على الأقل من خدمة Collabora. لكنها لا تُثبت عمل خاصية تحرير المستندات، إذ يعتمد المحرر على مسار WebSocket ضمن نطاق معين /cool/، والذي يتطلب متطلبات مختلفة لخادم الوكيل.
بعد ذلك، افتح أدوات مطوري المتصفح، وكرر الخطأ، وافحص لوحة الشبكة باستخدام مُرشِّح WS. عادةً ما تُحسِّن عملية المصافحة الناجحة لـ WebSocket اتصال HTTP؛ ويُعرِّف RFC 6455 استجابة الخادم بأنها حالة HTTP 101 عند نجاح التحسين. إذا رأيت بدلاً من ذلك 400 أو 404 أو 405 أو 502، أو طلبًا فاشلاً فوريًا، فاربط الطابع الزمني لهذا الحدث بسجلات الخادم الوكيل العكسي وcoolwsd.
بالنسبة لـ Nginx، فإن الخصائص المهمة واضحة: يجب أن يصل الطلب إلى /cool/مسار Collabora، ويجب أن يستخدم الوكيل HTTP/1.1 لتدفق ترقية WebSocket الكلاسيكي، ويجب إعادة توجيه Upgradeالرؤوس Connection، ويجب الحفاظ على المضيف الأصلي، ويجب أن تكون مهلة القراءة طويلة بما يكفي لجلسة التحرير.
لطالما أظهر دليل Collabora SDK موقعًا مخصصًا لبروتوكول WebSocket مع Upgradeو Connectionو Hostو و proxy_read_timeout. كما أشارت إحدى وثائق مشروع Collabora الرسمية إلى ضرورة وجود رؤوس WebSocket على /coolالمسار الأوسع. النمط الأمثل المتوافق مع الإصدار 26.04 هو:
location ^~ /cool/ {
proxy_pass http://127.0.0.1:9980;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 3600s;
}لا تقم بنسخ هذا الملف ولصقه فوق إعدادات الإنتاج الحالية دون تعديل عنوان المصدر، ونموذج TLS، ومعالجة المسار، وأي ضوابط أمنية موجودة. الخيار الأمثل هو الحفاظ على بنية الشبكة مع مراعاة متطلبات التوجيه والرأس الحالية في Collabora.
جلسات التحرير عبر WebSocket طويلة الأمد. توضح قيم Helm الحالية لمشروع Collabora هذا الأمر صراحةً، وتستخدم مهلة طويلة لخادم Nginx الوكيل المدمج. إذا قام موازن التحميل الطرفي، أو مدخل Kubernetes، أو شبكة توصيل المحتوى (CDN)، أو جدار الحماية، أو الخادم الوكيل العكسي بإغلاق الاتصالات الخاملة قبل الموعد المتوقع للتطبيق، فسيتمكن المستخدمون من التحرير بشكل طبيعي لفترة من الوقت، ثم يتم قطع اتصالهم على فترات منتظمة.
عندما يحدث العطل بعد عدد متقارب من الثواني في كل مرة، يتم فحص كل وسيط في المسار بدلاً من زيادة مهلة Nginx فقط. يتم اعتماد أقصر مهلة.
في عملية النشر الشائعة، يتم إنهاء بروتوكول HTTPS عند Nginx أو Apache أو HAProxy أو Traefik أو وحدة تحكم الدخول، ثم يتم توجيه بروتوكول HTTP العادي إلى Collabora على المنفذ 9980. في هذا التصميم، يتطلب التكوين الرسمي لـ Collabora أن يعرف النظام الخلفي أن بروتوكول TLS يتم إنهاؤه بواسطة الوكيل. ssl.enable=falseويوثق دليل SDK ssl.termination=trueهذا النموذج.
بالنسبة لنشر Docker، يتم التعبير عن ذلك عادةً من خلال المعلمات الإضافية لـ Collabora:
--o:ssl.enable=false --o:ssl.termination=trueاستخدم هذه الخيارات فقط عندما يتم إنهاء بروتوكول TLS فعليًا في الخادم الرئيسي. إذا كان الخادم الوكيل يتصل بـ Collabora عبر HTTPS، فقم بضبط هذه البنية بشكل متسق بدلاً من دمج النموذجين. قد يؤدي عدم التوافق إلى ظهور مخططات خاطئة، أو عناوين URL غير صحيحة لـ WebSocket، أو فشل في الشهادات، أو عمليات إعادة توجيه تُعطّل عملية الترقية.
يتحقق Collabora من مصادر WebSocket. إذا احتوى السجل على عبارات مثل " Rejecting WebSocket upgradeمُتبوع بمصدر ومضيف متوقع"، فقم بتصحيح علاقة اسم المضيف/المنفذ الخارجي بدلاً من إضافة رؤوس مُتساهلة بشكل عشوائي. يحتوي نظام تتبع المشكلات الرسمي لـ Collabora على مثال موثق حيث :443لم يتطابق اسم الخادم المُكوّن، بما في ذلك، مع مصدر المتصفح بدون هذا المنفذ الصريح.
تعتمد الأوامر المفيدة على نظام التثبيت الخاص بك:
docker logs collabora --tail 200
journalctl -u coolwsd --since "10 minutes ago"
nginx -t
apachectl configtestابحث عن الخطأ الأول بالتزامن مع فشل طلب خدمة الويب. الرسائل المتعلقة بالترقيات المرفوضة، أو بنية عنوان URI غير الصحيحة، أو مضيف غير متوقع، أو مصدر غير متاح، تُعدّ أكثر فعالية من نافذة المتصفح المنبثقة العامة.
هذه حالة محدودة، لكن يجدر التحقق منها قبل إعادة بناء الخادم. وثّق مشروع Collabora حالةً متعلقةً بمتصفح Chromium حيث مرّر خادم وسيط طلب HTTP/2 CONNECT WebSocket مباشرةً إلى coolwsd، فاستقبل الخطأ 405 (الطريقة غير مسموحة). كما سجّلت مشكلة أخرى حالات فشل تحميل المستندات المتعلقة ببروتوكول HTTP/3/QUIC في مسار خادم وسيط مُحدد. لا تعني هذه التقارير ضرورة تعطيل HTTP/2 أو HTTP/3 دائمًا، بل تعني أن على الوسيط ترجمة سلوك العميل إلى اتصال WebSocket يدعمه Collabora.
إذا كان متصفح فايرفوكس يعمل بينما يفشل متصفح كروم على نفس الحساب والمستند، فقم بتسجيل البروتوكول ورمز الحالة عند الخادم الوكيل. يُفضّل تصحيح سلوك الخادم الوكيل/الوصول بدلاً من تعطيل البروتوكولات الحديثة بشكل عام، إلا إذا لم يكن لديك بديل متوافق في بيئتك.
اختبر بنية الخادم الوكيل أولاً. ثم أعد تحميله بدلاً من إعادة تشغيله بشكل متكرر دون فهم.
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2بالنسبة للحاويات، أعد تشغيل خدمة Collabora فقط عند تغيير بيئتها أو coolwsdإعداداتها. عادةً ما يتطلب تغيير إعدادات الوكيل فقط إعادة تحميل الوكيل.
استخدم سلسلة تحقق قصيرة بدلاً من الاعتماد على فتح مستند واحد ناجح:
/hosting/discoveryيمكن الوصول إلى هذه المعلومات /hosting/capabilitiesمن خلال نفس اسم المضيف العام الذي يستخدمه المستخدمون.إذا قمتَ بالترقية إلى الإصدار 26.04 وتستخدم Apache، فإن تحديث قواعد البروكسي هو الإجراء ذو الأولوية القصوى لأن Collabora وثّقت هذا التغيير بشكلٍ صريح. إذا حدث انقطاع الاتصال بعد فترة زمنية محددة، فركّز على إعدادات مهلة الاتصال في جميع نقاط الشبكة. إذا كان العطل فوريًا على جميع المتصفحات، فتحقق من /cool/التوجيه، وتحديث الرؤوس، وتناسق المضيف/الأصل، وإنهاء TLS. إذا تعطلت مجموعة متصفحات واحدة فقط، فقارن معالجة بروتوكول HTTP قبل إجراء أي تغييرات على Collabora نفسها.
يكمن الحل في تجنب اعتبار رسالة "انقطاع اتصال المقبس بشكل غير متوقع" بمثابة عطل في تطبيق Collabora بشكل افتراضي. في العديد من عمليات النشر، يكون كل من المحرر ونقطة نهاية الاكتشاف ومضيف WOPI سليمين، بينما يُسيء الخادم الوكيل العكسي التعامل مع نوع الاتصال الأكثر أهمية للتحرير المباشر: اتصال WebSocket طويل الأمد.
قم بتوصيل محرري سطح المكتب ONLYOFFICE بخادم ownCloud الخاص بك، وقم بتسجيل الدخول، وافتح ملفات السحابة، وقم بإدارة الاتصال، وقم باستكشاف أخطاء الإعداد الشائعة وإصلاحها.
قم باستكشاف أخطاء استخدام وحدة المعالجة المركزية العالية في Collabora Online وإصلاحها من خلال تحديد عمليات مجموعة الأدوات المشغولة، والتحقق من المقاييس والسجلات، وضبط التزامن والتنظيف، والتحقق من الإصلاحات بأمان.
تعرف على كيفية تخصيص العلامة التجارية لـ ONLYOFFICE Docs بشعار رأس الصفحة وألوان الواجهة، بما في ذلك حدود الترخيص، وإعداد JSON الخاص بالسمات، ومسارات Docker، والاختبار.
قم بإصلاح النصوص التي يصعب قراءتها في LibreOffice Calc عن طريق التحقق من سمة التطبيق، وخط الخلية وألوان التعبئة، والأنماط، والتنسيق الشرطي - ثم تحقق من مخرجات الطباعة.
قم بإزالة تحذير قفل المستخدم غير المعروف من LibreOffice بأمان. تحقق من الجلسات النشطة، واحمِ نسخة، وأزل القفل القديم الذي تم التحقق منه فقط، واختبر المستند.
أصلح النصوص العربية أو العبرية التي تتدفق أو تتماشى أو تختلط مع الإنجليزية بشكل غير صحيح في برنامج LibreOffice Writer. فعّل تخطيط النص المعقد، وحدد اتجاه الفقرة، وتحقق من النتيجة.
تعلم VLOOKUP و XLOOKUP في LibreOffice Calc، بما في ذلك التطابقات التامة، والبحث الأيسر، ونتائج عدم العثور، والبحث العكسي، وبدائل INDEX/MATCH، والأخطاء الشائعة.
قم باستكشاف أخطاء التحقق من صحة إثبات WOPI في Collabora Online وإصلاحها عن طريق التحقق من مفاتيح الاكتشاف، وتدوير المفاتيح، وعناوين URL للوكيل، والطوابع الزمنية، وقوائم السماح للمضيف.
قم بتمكين ميزة تتبع التغييرات للجميع في مستند ONLYOFFICE، واحتفظ بها نشطة بعد إعادة فتحه، وافهم حدود الإعداد الافتراضي العام.
قارن بين إعدادات Collabora Online الخاصة بكل عرض، وعدم التركيز، وخمول المستند، والحفظ التلقائي، ومهلات الوكيل، ثم اختر الإعدادات المناسبة لعملية النشر الخاصة بك وتحقق منها.
