إصلاح مشكلة انقطاع جلسات تحرير المستندات بعد 10 دقائق

إذا فُتح مستند Collabora Online Development Edition (CODE) بشكل طبيعي، وسارت التعديلات بنجاح، ثم انقطع اتصال المحرر بعد 10 دقائق تقريبًا، فابدأ بفحص مسار WebSocket بين المتصفح وCODE. يشير انقطاع الاتصال المتكرر بعد 600 ثانية إلى وجود مشكلة في خادم وكيل عكسي، أو وحدة تحكم الدخول، أو موازن الأحمال، أو جدار الحماية، أكثر من كونه مرتبطًا بمؤقتات الخمول الافتراضية الموثقة في CODE.

هذا التمييز مهم لأن تغيير إعدادات الخمول الخاصة بـ CODE أولاً قد يُخفي المشكلة الحقيقية دون إصلاح الاتصال الذي ينقل بيانات التحرير. يُوثّق نموذج تكوين Collabora الحالي مهلة خمول مدتها 15 دقيقة لكل عرض ومهلة خمول مدتها ساعة واحدة للمستند، وليس حدًا زمنيًا لجلسة التحرير مدته 10 دقائق. راجع نموذج coolwsd.xml الأصلي . إذا كان المستخدمون يكتبون بنشاط عند حدوث انقطاع الاتصال، فإن إعداد CODE للخمول فقط يُعد تفسيرًا أضعف.

ماذا يعني انقطاع الاتصال لمدة 10 دقائق عادةً؟

تم التحقق: يستخدم مثال Nginx المنشور من Collabora رؤوس ترقية WebSocket وقيمة طويلة proxy_read_timeout 36000sلـ WebSocket الرئيسي. ويوضح Nginx نفسه أن اتصالات WebSocket المُوَجَّهة عبر الوكيل تُغلق عند عدم استلام أي بيانات خلال مهلة القراءة المُحددة، وقيمتها الافتراضية العامة proxy_read_timeoutهي 60 ثانية. راجع دليل Collabora Online SDK ووثائق وكيل Nginx WebSocket .

يعتمد ذلك على البيئة: قد تُفرض مهلة 600 ثانية من قِبل طبقة وسيطة مختلفة حتى لو بدا خادم Nginx أمام CODE سليمًا. تشمل المواقع الشائعة Kubernetes Ingress، وHAProxy، وموازن تحميل السحابة، وجدار حماية تطبيقات الويب (WAF)، أو خادم وسيط عكسي. وتختلف المهلة الزمنية ومفتاح التكوين باختلاف المكون.

لا يكفي مجرد ظهور العرض لإثبات المشكلة: فعبارة "انقطاع الاتصال بعد 10 دقائق" لا تُثبت أن Nginx هو المكون المسؤول. لذا، يُنصح بتسجيل فشل اتصال WebSocket وربط طابعه الزمني بسجلات الوكيل وسجلات التعليمات البرمجية قبل إجراء أي تغييرات على عدة طبقات في آن واحد.

الإجراء: إعادة إنتاج الفشل مع فتح أدوات مطوري المتصفح وتسجيل مدة استمرار طلب WebSocket بدقة.

الخطوة 1: تأكد من أن WebSocket هو ما يتعطل بالفعل

افتح مستندًا، ثم افتح أدوات مطوري المتصفح وانتقل إلى لوحة الشبكة. فعّل فلتر حركة مرور WebSocket. عادةً ما تتضمن حركة مرور تحرير التعليمات البرمجية اتصال WebSocket ضمن /cool/المسار. أبقِ المستند مفتوحًا بعد نقطة العطل.

عند انقطاع الجلسة، افحص طلب WebSocket. أهم المعلومات هي مدته، وتوقيت إغلاقه، وحالة HTTP أثناء التحديث الأولي، وما إذا كان المتصفح يُبلغ عن خطأ في الشبكة. يشير بدء الاتصال بسلاسة 101 Switching Protocolsثم إغلاقه بعد حوالي 600 ثانية إلى وجود سياسة لعمر الاتصال أو سياسة عدم النشاط في مكان ما ضمن مسار الاتصال.

إذا لم يتم تحديث WebSocket بنجاح، فهذه ليست مشكلة "انقطاع الاتصال بعد 10 دقائق"؛ أصلح توجيه WebSocket ورؤوسه أولاً. إذا ظل WebSocket متصلاً بينما يعرض المحرر خطأً في التخزين أو الحفظ، فابحث في مسار WOPI/storage بدلاً من ذلك.

الإجراء: قم بتدوين وقت البدء ووقت قطع الاتصال، ثم قارن هذه الطوابع الزمنية مع سجلات الوصول/الأخطاء الخاصة بالوكيل العكسي وسجلات حاوية CODE أو سجلات الخدمة.

الخطوة الثانية: تحقق من قاعدة الوكيل العكسي لـ CODE قبل تغيير قيم الخمول لـ CODE

بالنسبة لـ Nginx، الأهم هو أن موقع WebSocket يمرر رؤوس الترقية وأن يكون لديه مهلة قراءة طويلة بما يكفي. يوضح دليل SDK الخاص بـ Collabora هذا النمط لـ WebSocket الرئيسي:

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 36000s;
}

إذا تم إنهاء بروتوكول TLS عند Nginx وكان CODE يستخدم بروتوكول HTTP عاديًا عمدًا، فقد يكون بروتوكول المصدر http://مختلفًا. لا تقم بنسخ البروتوكول بشكل أعمى: يجب أن يتطابق مع كيفية تكوين مثيل CODE الخاص بك.

من المفاهيم الخاطئة الشائعة أن هذا الإعداد proxy_connect_timeoutيتحكم في مدة جلسة التحرير القائمة بالفعل. هذا غير صحيح؛ فهو يُطبّق أثناء إنشاء الاتصال بالخادم الأصلي. الإعداد الأكثر صلةً بجلسة WebSocket مُدارة عبر وكيل، مع فترات انقطاع البيانات من الخادم الأصلي، هو proxy_read_timeout. يوثّق Nginx هذا السلوك في مرجع وحدة وكيل HTTP الخاصة به .

الإجراء: حدد موقع كتلة Nginx الفعلية التي تتطابق مع عنوان URL الخاص بـ CODE WebSocket وتأكد من تعيين المهلة هناك، وليس فقط في مكان غير ذي صلة location.

الخطوة 3: مراعاة تغييرات البروكسي في الإصدار 26.04 من الكود

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

لا يعني هذا أن كل انقطاع اتصال لمدة 10 دقائق ناتج عن تغيير عنوان URL المُختصر. بل يعني أنه في الإصدار 26.04، يجب عليك التحقق من قواعد الخادم الوكيل العكسي لديك ومطابقتها مع وثائق الإصدار الذي تستخدمه فعليًا، خاصةً إذا ظهرت المشكلة بعد الترقية.

الإجراء: تحقق من إصدار الكود الخاص بك في معلومات "حول" المنتج أو علامة صورة الحاوية، ثم قارن إعدادات الوكيل لديك مع إرشادات وكيل Collabora الحالية. لا تفترض أن قاعدة منسوخة من إصدار 24.04 قديم لا تزال مثالية.

الخطوة الرابعة: التحقق من Kubernetes Ingress وHAProxy وApache وغيرها من الأجهزة الوسيطة

إذا كان Nginx طبقة واحدة فقط أمام CODE، فقد لا يكون تمديد مهلة الاتصال كافيًا. بالنسبة لـ Kubernetes الذي يستخدم ingress-nginx، يوثق المشروع التعليقات التوضيحية لكل Ingress المسماة `<Ingress>` nginx.ingress.kubernetes.io/proxy-read-timeoutو` <Ingress nginx.ingress.kubernetes.io/proxy-send-timeout>`. توصي إرشادات WebSocket بقيم تزيد عن ساعة واحدة للاتصالات طويلة الأمد. راجع مرجع التعليقات التوضيحية الرسمي لـ Ingress-Nginx وملاحظات WebSocket .

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

بالنسبة لـ HAProxy، يستخدم مثال SDK الخاص بـ Collabora مهلة نفق طويلة لحركة مرور WebSocket. أما بالنسبة لـ Apache، فيتم التحكم في مهلة الوكيل العامة بواسطة ProxyTimeout، ولكن يتطلب الإصدار 26.04 أيضًا مراعاة نمط WebSocket ProxyPass الحالي. تشرح وثائق mod_proxyProxyTimeout الخاصة بـ Apache عناصر التحكم.

الإجراء: ارسم مسار الاتصال من المتصفح إلى الكود وافحص كل قفزة. قد يؤدي تحديد مدة 600 ثانية في أي قفزة إلى إنهاء الجلسة.

الخطوة 5: التحقق من صحة البروكسي وإعادة تحميله بأمان

بعد تعديل إعدادات Nginx، اختبرها قبل إعادة التحميل:

sudo nginx -t
sudo systemctl reload nginx

إذا كان Nginx يعمل داخل حاوية، فاستخدم إجراءات التحقق وإعادة التحميل المتوافقة مع الحاويات بدلاً من افتراض systemctlوجود الملف. الأهم هو التحقق من صحة الصيغة قبل استبدال الإعدادات الحالية.

الإجراء: قم بتغيير طبقة واحدة في كل مرة، وسجل القيمة السابقة، وتحقق من صحة التكوين، ثم أعد اختبار سير عمل المستند نفسه.

الخطوة 6: إثبات الإصلاح باختبار أطول من الحد الزمني القديم

لا تتوقف عن الاختبار عند إعادة فتح المستند. أبقِ جلسة التحرير نفسها متصلة لفترة أطول بكثير من نقطة العطل السابقة. في حالة ظهور عطل لمدة 10 دقائق، فإن فترة تحقق تتراوح بين 20 و30 دقيقة أكثر فائدة من اختبار سريع لمدة دقيقتين. أبقِ لوحة الشبكة مفتوحة وقم بإجراء تعديلات بين الحين والآخر لتتمكن من التمييز بين التحرير النشط وعلامة تبويب غير نشطة تمامًا.

النتيجة الجيدة لها ثلاث علامات: يبقى اتصال WebSocket قائماً لأكثر من 10 دقائق، ويستمر المحرر في قبول التعديلات دون مطالبات إعادة الاتصال، ولا يظهر أي مهلة زمنية مقابلة في سجلات الوسيط أو سجلات CODE.

إذا استمر إغلاق الاتصال بعد 10 دقائق بالضبط من زيادة مهلة أقرب وكيل، فهذا دليل مفيد على أن قفزة أخرى لا تزال لديها سياسة 600 ثانية.

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

لا تخلط بين مؤقتات الخمول في برنامج CODE وانقطاع الشبكة بعد 10 دقائق

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

يُستحسن التحقق من هذه القيم للتأكد من توافق سلوكك معها، ولكن لا يُفسر أي من القيم الافتراضية انقطاع الاتصال لمدة 600 ثانية بالضبط. إذا قام شخص ما بتخصيص coolwsd.xmlمتغيرات البيئة أو قيم Helm أو معلمات الحاوية مسبقًا، فقد يختلف نشرك عن الإعدادات الافتراضية.

الإجراء: افحص إعدادات الكود الفعّالة فقط بعد تحديد ما إذا كان العطل على مستوى الشبكة أو على مستوى التطبيق. لا تقم بزيادة كل قيمة خاملة كاستجابة أولية.

طاولة التشخيص السريع

خلاصة القول

في حالة انقطاع جلسة تحرير الكود بعد عشر دقائق متكررة، فإن التسلسل الأمثل هو: التأكد من فشل اتصال WebSocket، والتحقق من قاعدة الوكيل العكسي المطابقة، وفحص كل مهلة وسيطة، ومراعاة تغييرات مسار الوكيل في الإصدار 26.04 من الكود، وإعادة التحميل بأمان، والاختبار بعد تجاوز الحد الزمني القديم. لا تُغير إعدادات الخمول في الكود إلا إذا كان السلوك الملاحظ والتكوين الفعلي يشيران إلى ذلك.

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