إصلاح خطأ الاتصال "حسنًا، هذا محرج" في Collabora Online

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

يستند هذا الدليل إلى وثائق إدارة Nextcloud 35 الحالية وإرشادات حزمة تطوير البرامج (SDK) الخاصة بـ Collabora Online 25.04 كنقاط مرجعية. وينطبق منطق استكشاف الأخطاء وإصلاحها نفسه على العديد من عمليات التكامل مع ownCloud وWOPI المخصصة، ولكن قد تختلف أسماء الإعدادات الدقيقة باختلاف النظام الأساسي والإصدار.

ما الذي يسبب عادةً خطأ الاتصال هذا في Collabora؟

تعتمد جلسة المتصفح الناجحة على عدة مسارات منفصلة. يجب أن يصل متصفح المستخدم إلى كلٍ من خادم التخزين وCollabora؛ ويجب أن يصل خادم التخزين إلى Collabora؛ ويجب أن تصل Collabora إلى خادم التخزين؛ ويجب أن تكون البروتوكولات والشهادات متوافقة؛ ويجب على الخادم الوكيل العكسي إعادة توجيه مسارات HTTP وWebSocket الخاصة بـ Collabora بشكل صحيح. تُفصّل صفحة استكشاف الأخطاء وإصلاحها الرسمية في Nextcloud متطلبات الوصول ثنائي الاتجاه هذه.

هذا يعني أنه لا يوجد حل واحد صحيح بشكل عام. اختر مسار الإصلاح بناءً على أول اختبار فاشل:

1. تحقق من نقاط نهاية اكتشاف وإمكانيات Collabora

ابدأ بعنوان URL العام لمنصة Collabora الذي يستخدمه التكامل الخاص بك فعليًا. افتح نقاط النهاية هذه في متصفح ومن خادم التخزين:

https://office.example.com/hosting/discovery
https://office.example.com/hosting/capabilities

توصي وثائق استكشاف الأخطاء وإصلاحها الحالية في Nextcloud بإجراء كلا الاختبارين. يجب أن تُعيد نقطة نهاية الاكتشاف بيانات XML، بينما تُعيد نقطة نهاية القدرات بيانات قدرات Collabora. في حال حدوث مهلة زمنية، أو تحذير بشأن الشهادة، أو خطأ 404، أو صفحة خطأ تحمل علامة الوكيل، أو حلقة إعادة توجيه، يجب عليك إصلاح الشبكة أو الوكيل العكسي قبل تعديل إعدادات WOPI.

تحقق أولاً من عناوين URL العامة لاكتشاف وإمكانيات Collabora؛ يجب أن يكون كلاهما قابلاً للوصول من خلال نفس اسم المضيف المستخدم في التكامل.

للحصول على إرشادات موثوقة حول نقاط النهاية، راجع قسم استكشاف أخطاء Nextcloud Office وإصلاحها ودليل Collabora Online 25.04 SDK .

2. اختبر جميع اتجاهات الشبكة الأربعة، وليس المتصفح فقط.

من الأخطاء الشائعة افتراض أن office.example.comبرنامج Collabora، لمجرد فتحه في متصفح سطح المكتب، يستطيع جلب الملفات من خادم التخزين. هذا غير مضمون. اختبر البرنامج من الأجهزة المضيفة أو الحاويات الفعلية.

# From the Nextcloud/storage server
curl -fsS https://office.example.com/hosting/discovery >/dev/null && echo OK

# From the Collabora host/container
curl -fsS https://cloud.example.com/status.php

# Then inspect Collabora logs
docker logs --tail 100 collabora

إذا كان اسم المضيف العام يُحلّل بشكل مختلف داخل Docker أو Kubernetes أو شبكة خاصة، فحدد ما إذا كنت ستصلح نظام أسماء النطاقات الداخلي، أو تضيف تعيينًا مناسبًا للمضيف، أو توجهه عبر نقطة النهاية العامة. عادةً ما يكون نظام أسماء النطاقات الداخلي أكثر سلاسة عند التوسع؛ فإضافة إدخال في ملف المضيفين سريعة في حالة التثبيت الثابت الصغير، ولكنها تصبح أكثر صعوبة في الصيانة.

قم بإجراء اختبارات إمكانية الوصول من الخوادم نفسها، ثم استخدم سجل Collabora لفصل فشل الشبكة عن فشل ثقة WOPI.

3. أصلح الخادم الوكيل العكسي إذا كانت مسارات WebSockets أو Collabora مفقودة

لا يُعدّ Collabora تطبيق ويب ثابتًا عاديًا. يحتاج خادم الوكيل العكسي الخاص به إلى مسارات لموارد المتصفح، واكتشاف/إمكانيات الوصول، وحركة مرور المستندات، وWebSockets. في دليل SDK الخاص بـ Collabora، يُعيد مثال Nginx توجيه /browserمسار WebSocket، وحركة المرور /hosting/discoveryذات الصلة ./hosting/capabilities/cool/.../ws/cool/lool

بالنسبة لمسار WebSocket، يجب على الخادم الوكيل الحفاظ على المضيف واجتياز ترقية HTTP. فيما يلي نموذج مبسط لـ Nginx:

location ~ ^/cool/(.*)/ws$ {
    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 $host;
    proxy_read_timeout 36000s;
}

لا تقم بنسخ هذا بشكل أعمى إذا كنت تُنهي بروتوكول TLS بطريقة مختلفة. توثق Collabora أنماطًا منفصلة لإنهاء TLS وSSL من طرف إلى طرف. إذا تم إنهاء TLS عند Nginx وكان اتصال الواجهة الخلفية HTTP، فيجب أن تتوافق إعدادات SSL الداخلية لـ Collabora مع هذا التصميم. يُعد استخدام HTTPS في كل مكان أسهل للفهم، بينما يُقلل إنهاء TLS عند الوكيل من معالجة الشهادات داخل الحاويات ولكنه يُضيف حدًا آخر للتكوين.

يجب على الخادم الوكيل العكسي الصحيح إعادة توجيه مسارات HTTP الخاصة بـ Collabora والحفاظ على ترقية WebSocket لجلسة المستند.

4. تحقق من اتساق البروتوكول والشهادة واسم المضيف

تنص وثائق إعداد Office الحالية لـ Nextcloud على أن خادم Collabora Online يجب أن يستخدم نفس بروتوكول تثبيت Nextcloud، مع التوصية باستخدام HTTPS. عمليًا، قد تؤدي إعدادات HTTP/HTTPS المختلطة إلى حظر المحتوى، أو توجيهات خاطئة، أو فشل التحقق من صحة شهادة الخادم.

تحقق من هذه العناصر معًا:

• عنوان URL الخاص بـ Collabora المحفوظ في منصة التخزين الخاصة بك هو عنوان URL العام الذي يمكن للمستخدمين الوصول إليه بالضبط.
• الشهادة المقدمة بواسطة اسم المضيف هذا صالحة لاسم المضيف وموثوقة من قبل خادم التخزين.
• بإمكان Collabora التحقق من صحة شهادة HTTPS الخاصة بخادم التخزين.
• يقوم خادم الوكيل العكسي الخاص بك بإعادة توجيه المضيف الأصلي والمخطط بشكل صحيح.
• لا يوجد إعادة توجيه من اسم مضيف Collabora المُكوّن إلى اسم مضيف آخر لا يتوقعه WOPI.

قد تكون الشهادة الموقعة ذاتيًا مقبولة في بيئة معملية إذا تم تكوين كل مكون بشكل صريح للوثوق بها، ولكن هذه الميزة تُضحي بسهولة النقل وتتسبب غالبًا في فشل التحديثات أو إعادة بناء الحاويات لاحقًا. أما في بيئة الإنتاج، فإن سلسلة الشهادات الموثوقة علنًا أو من قِبل المؤسسة هي الخيار الأكثر أمانًا.

5. تصحيح قوائم السماح الخاصة بـ WOPI بدلاً من تعطيلها

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

فيما يخص التخزين، توصي Nextcloud بتقييد طلبات WOPI بعناوين IP الخاصة بخوادم Collabora باستخدام إعداد "قائمة السماح لطلبات WOPI" . أما في Collabora، فيجب أن تتطابق عناوين URL للتخزين المسموح بها لـ WOPI مع عناوين URL للتخزين التي تستقبلها Collabora فعليًا. بالنسبة لنطاقات التخزين المتعددة، توثق حزمة تطوير البرامج (SDK) الحالية لـ Collabora مجموعات أسماء WOPI المستعارة.

حافظ على عنوان URL لخادم Collabora وقائمة السماح لـ WOPI متوافقة مع النشر الفعلي؛ استخدم إدخالات موثوقة ضيقة بدلاً من إيقاف التحقق.

راجع إعدادات Nextcloud Office للاطلاع على عنوان URL الحالي للخادم وإرشادات قائمة السماح لـ WOPI. إذا كنت تستخدم ownCloud Infinite Scale، فإن خدمة التعاون الخاصة به تستخدم COLLABORATION_APP_ADDRعنوان URL لتطبيق Office COLLABORATION_WOPI_SRCومصدر WOPI الذي يمكن الوصول إليه خارجيًا؛ راجع وثائق خدمة التعاون الخاصة بـ ownCloud .

متى يجب عليك استخدام الكود المدمج بدلاً من خادم Collabora منفصل؟

في بيئة Nextcloud صغيرة الحجم، يُقلل خادم CODE المُدمج من عدد المكونات المُدارة خارجيًا. لكن في المقابل، يبقى الأمر مُعتمدًا على قدرة Nextcloud على الوصول إلى نفسه عبر اسم المضيف المُستخدم في المتصفح. تُشير وثائق استكشاف الأخطاء وإصلاحها في Nextcloud إلى هذه النقطة صراحةً، وتقترح حل اسم المضيف بشكل صحيح عندما يتعذر على خادم CODE المُدمج الاتصال.

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

ما لا يجب فعله

• لا تقم بتعطيل التحقق من صحة WOPI كحل أولي. فقد يؤدي ذلك إلى إخفاء عدم تطابق اسم المضيف الفعلي وإضعاف حاجز الأمان.
• لا تُعرّض المنفذ 9980 مباشرةً لمجرد تعطل الخادم الوكيل. أصلح الخادم الوكيل إلا إذا كان التعريض المباشر تصميمًا مقصودًا وآمنًا.
• لا تفترض أن استجابة 200 من الصفحة الرئيسية لـ Collabora تثبت أن تحرير المستندات يعمل. الاكتشاف، والقدرات، والوصول إلى ملفات WOPI، وWebSockets هي مسارات منفصلة.
• لا تُغيّر طبقات متعددة في وقت واحد. اختبر بعد كل تغيير لتحديد ما إذا كان نظام أسماء النطاقات (DNS) أو بروتوكول أمان طبقة النقل (TLS) أو التوجيه عبر الخادم الوكيل أو ثقة WOPI هو السبب الحقيقي.

قائمة التحقق النهائية

بعد إجراء التغيير، تحقق من النظام بهذا الترتيب:

1. افتح /hosting/discoveryمن /hosting/capabilitiesمتصفح الإنترنت.
2. استرجع نفس نقاط النهاية من خادم التخزين.
3. من خادم Collabora، قم بجلب عنوان URL لحالة خادم التخزين.
4. افتح مستندًا أثناء مراقبة سجلات Collabora وسجلات التخزين.
5. تأكد من أن المتصفح يقوم بإنشاء اتصال Collabora WebSocket دون انقطاعات متكررة.
6. تأكد من إمكانية فتح مستخدم ثانٍ لمستند اختبار وتعديله إذا كانت هناك حاجة إلى التحرير التعاوني.

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