تتبع المصدر لحل مشكلة Nginx 502 الخاصة بـ ONLYOFFICE
ابحث عما إذا كان Nginx أو شبكة Docker أو خدمة ONLYOFFICE الداخلية تُرجع الخطأ 502، ثم تحقق من المصدر المصحح وفحص الحالة.
ابدأ بفحص الاتصال بين Nginx و ONLYOFFICE Docs، ثم اقرأ سجل الأخطاء المتعلق باستجابة 502. تعني استجابة 502 Bad Gateway أن البوابة لم تتمكن من الحصول على استجابة صحيحة من خادمها الرئيسي؛ ولا تُثبت هذه الاستجابة، بحد ذاتها، أن إعدادات Nginx العامة هي السبب. في Docker، يتمثل الحل المعتاد في توجيه Nginx إلى اسم خدمة خادم المستندات على منفذه الداخلي 80 والتأكد من أن كلا الحاويتين تشتركان في نفس الشبكة.
الخادم الوكيل العكسي هو خادم يستقبل طلبات العملاء ويعيد توجيهها إلى خادم آخر. في بيئة النشر الشائعة، يتولى خادم Nginx العام معالجة بروتوكول HTTPS ويعيد توجيه الطلبات إلى ONLYOFFICE Docs عبر بروتوكول HTTP. كما يُشغّل ONLYOFFICE Docs خادم Nginx خاصًا به داخليًا، لذا قد يتم إنشاء صفحة خطأ 502 بواسطة الخادم الوكيل الخارجي أو بواسطة حاوية خادم المستندات نفسها.
حدد أولاً الخادم الذي أرسل الاستجابة. قارن رأس الخادم والطابع الزمني للصفحة مع سجل الوكيل الخارجي وسجلات خادم المستندات. بالنسبة لإعداد Docker، تحقق من حالة الحاوية ورسائل بدء التشغيل الأخيرة.
docker ps --filter name=onlyoffice-documentserver
docker logs --tail 100 onlyoffice-documentserver

إذا كانت الحاوية قيد إعادة التشغيل أو بدأت للتو، فراجع سجل النظام قبل تغيير إعدادات الوكيل. تشير ONLYOFFICE إلى أن بدء التشغيل الأول قد يستغرق دقيقة أو دقيقتين ريثما يتم تهيئة قاعدة البيانات. بالنسبة لتثبيت Linux أصلي، تحقق ds-docserviceمن ds-converterوجود systemctl statusسجلات خادم المستندات في المسار التالي /var/log/onlyoffice/documentserver/: .
استخدم تعليمات استكشاف الأخطاء وإصلاحها الرسمية المطابقة لنظام التشغيل لينكس ONLYOFFICE في حالة توقف إحدى الخدمات.
اختبر من حاوية Nginx أو من المضيف، وليس فقط من حاسوبك المحمول. لا يمكن للحاويات الموجودة على شبكات Docker منفصلة الوصول إلى بعضها البعض باستخدام اسم الخدمة، حتى عند تشغيل كليهما. عندما تشترك Nginx وONLYOFFICE في شبكة Docker مُعرَّفة من قِبل المستخدم، استخدم اسم خدمة Compose أو اسم حاوية قابل للحل ومنفذ الاستماع الخاص بالحاوية. يُحدد دليل تثبيت Docker الرسمي المنفذ 80 كمنفذ الاستماع الافتراضي لخادم المستندات؛ ولا يُغير منفذ المضيف المنشور، مثل 8080:80، المنفذ الداخلي.
من حاوية الوكيل، قم بتشغيل ما يلي:
curl -I http://onlyoffice-documentserver:80/

استبدل onlyoffice-documentserverاسم خدمة Compose الفعلي. إذا ظهرت رسالة "تعذر تحديد المضيف"، فقم بتوصيل كلا الحاويتين بنفس شبكة Docker أو صحّح اسم المصدر. عادةً ما تعني رسالة "تم رفض الاتصال" أن المضيف المستهدف قد تم تحديده، ولكن لا يوجد أي شيء يقبل الاتصالات على هذا المنفذ، أو أن الحاوية غير جاهزة، أو تم استخدام منفذ خاطئ. إذا كان هذا تثبيتًا أصليًا، فاختبر العنوان المحلي والمنفذ المُكوّن بدلاً من ذلك، على سبيل المثال curl -I http://127.0.0.1/.
يغطي دليل Docker الخاص بـ ONLYOFFICE المنفذ الافتراضي، وتعيينات المنافذ، وتأخير بدء التشغيل، وسجلات الحاويات: تثبيت Docker والتحقق منه .
في ملف المضيف الافتراضي HTTPS لاسم المضيف ONLYOFFICE، قم proxy_passبتوجيهه إلى الخادم المصدر الذي يمكن الوصول إليه. يفترض هذا المثال وجود شبكة Docker مشتركة واسم الخدمة الموضح أعلاه؛ قم بتغييره ليتوافق مع بيئة النشر الخاصة بك.
location / {
proxy_pass http://onlyoffice-documentserver:80;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}

لا تُوجّه خادم وكيل مُحاوي إلى 127.0.0.1:8080خادم المستندات إلا إذا كان خادم المستندات يستمع فعليًا داخل نفس الحاوية، أو إذا تم تكوين عنوان المضيف عمدًا وكان قابلاً للوصول. داخل الحاوية، 127.0.0.1يُقصد بذلك الحاوية نفسها. تجنّب أيضًا إرسال HTTPS إلى المصدر عندما تكون نقطة نهاية خادم المستندات HTTP عادية.
يُحدد البروتوكول المُعاد توجيهه والمضيف عنوان URL العام الذي استخدمه العميل لـ ONLYOFFICE، وتسمح رؤوس الترقية باتصالات WebSocket المستخدمة للتواصل المباشر مع المحرر. يوفر ONLYOFFICE أمثلة مُحدثة لتشغيل Docs خلف خادم وكيل ، بما في ذلك إعداد Nginx HTTPS-to-HTTP . قارن هذا المثال الكامل إذا كانت بيئتك تحتوي على عدة خوادم وكيلة أو تستخدم بادئة مسار URL.
قبل تطبيق التغييرات، تحقق من صحة الإعدادات باستخدام الأمر المناسب nginx -t، ثم أعد تحميل Nginx باستخدام الطريقة المناسبة لمضيفك أو حاويتك. لا تقم بإعادة تشغيل جميع الخدمات دفعة واحدة؛ فإعادة التحميل المُتحكَّم بها تُسهِّل معرفة ما إذا كان الإصلاح المُطبَّق قد غيَّر النتيجة.
إذا تمكن الخادم الوكيل الخارجي من الوصول إلى صفحة الترحيب الخاصة بخادم المستندات ولكنه /healthcheckأعاد رمز الخطأ 502، فقد تكمن المشكلة داخل خادم المستندات نفسه وليس في خادم Nginx العام. تحقق من سجلات حاوية خادم المستندات وسجلات الخدمة الداخلية. بالنسبة لأنظمة Linux المثبتة، راجع أوامر حالة الخدمة ودليل السجلات المذكور أعلاه. إذا /welcome/استجاب الخادم ولكن فحص السلامة لم يستجب، فتعامل مع كليهما كإشارتين منفصلتين: فوجود صفحة ترحيب ثابتة لا يثبت سلامة خدمة المستندات وملحقاتها.
لا تُحاول "إصلاح" هذه المشكلة بتعطيل JWT. يُستخدم التحقق من صحة رمز JSON Web Token (JWT) لمصادقة طلبات التكامل؛ وعادةً ما يتسبب عدم تطابق JWT في خطأ في التفويض، وليس في عدم القدرة على الاتصال بالخادم الرئيسي على مستوى الشبكة. تحقق من إعدادات JWT فقط إذا استجاب الخادم الوكيل ولكن أبلغ التكامل عن خطأ في التفويض أو الرمز المميز.
أخيرًا، تأكد من أن Nginx يوجّه اسم المضيف الصحيح إلى المضيف الظاهري الصحيح. server_nameقد يؤدي خطأ إملائي في اسم المضيف، أو اسم نظام أسماء النطاقات (DNS) الخاص بالخادم، أو المنفذ، إلى توجيه حركة المرور إلى مكان آخر أو خروجها من الخادم الوكيل باستخدام إعدادات قديمة. راجع سجل أخطاء Nginx بحثًا عن أسطر مثل host not found in upstream`<input> connect() failed` أو `<input>` أو upstream timed out`<input>`؛ حيث يشير كل سطر إلى طبقة مختلفة.
أعد اختبار الاتصال من الشبكة الوكيلة، ثم تحقق من نقطة نهاية الصحة العامة وافتح مستندًا من خلال المنصة المتصلة:
curl -I https://docs.example.com/healthcheck

يجب ألا يكون رد فحص السلامة الناجح هو الخطأ 502، ويجب أن يُفتح مستند فعلي ويبقى متصلاً أثناء التحرير. إذا نجح اختبار المصدر ولكن الطلب العام لا يزال يفشل، فركز على المضيف الظاهري Nginx المحدد، وإعداداته المُحمّلة، وسجلاته. إذا كانت صفحة الترحيب العامة تعمل ولكن فحص السلامة لا يزال يُظهر الخطأ 502، فتابع تشخيص الخدمة الداخلي لـ ONLYOFFICE.
للاطلاع على سلوك توجيهات Nginx، يُرجى مراجعة وثائق وحدة Nginx proxy الرسمية . قد تختلف الأوامر وأسماء الخدمات باختلاف مشروع Docker Compose وتوزيعة Linux وإصدار ONLYOFFICE، لذا استبدل الأسماء الفعلية لديك وتحقق من سجلات المكون الذي أنشأ الاستجابة.
ابحث عما إذا كان Nginx أو شبكة Docker أو خدمة ONLYOFFICE الداخلية تُرجع الخطأ 502، ثم تحقق من المصدر المصحح وفحص الحالة.
قم بتشخيص حالات فشل حفظ ملفات ONLYOFFICE عن طريق التحقق من مسار رد الاتصال في Nextcloud، وعمليات إعادة توجيه الوكيل، وسجلات التخزين، ثم تحقق من استمرار الملف الذي تم تعديله.
ابحث عن سبب تعطل ذاكرة ONLYOFFICE، وتحقق من حدود Docker، وقم بتحديد حجم ذاكرة الوصول العشوائي VPS بشكل صحيح، وأضف مساحة التبديل بأمان، وتحقق من فتح المستندات وحفظها.
افصل بين مشاكل التنزيل من المتصفح وأخطاء التحويل من جانب الخادم، واستخدم سجل التحقق أو فحص الوصول المناسبين لجعل عملية تصدير ملف PDF تعمل.
قم بمطابقة سر JWT المستخدم بواسطة ONLYOFFICE Docs و Nextcloud، وقم بتطبيقه بأمان على عمليات تثبيت Docker أو Linux، وتحقق من الاتصال دون إضعاف المصادقة.
قم بتثبيت ONLYOFFICE Workspace Community على Ubuntu 24.04 باستخدام برنامج Docker الرسمي، وتحقق من متطلبات الخادم، وتخطى البريد إذا لزم الأمر، وتحقق من البوابة بأمان.
قم بتكوين أسرار JWT المطابقة لـ ONLYOFFICE Docs وموصلها، مع خطوات آمنة لحزم Linux وعمليات نشر Docker والتحقق.
أضف شعار شركتك وألوان واجهة المستخدم إلى محرر ONLYOFFICE Docs المدمج باستخدام ملف سمة مخصص وإعدادات المحرر. راجع حدود التحرير وفحوصات النشر.
تتبع التعديلات في برنامج Writer، واحتفظ بمصدر ODT قابل للتحرير، وتحقق من ملف DOCX المُصدّر في برنامج Word قبل مشاركته.
اتبع إجراء SP7 الخاص بشركة SUSE لتمكين وضع FIPS، وأعد التشغيل بأمان، وتحقق من السياسة النشطة، وتحقق مما إذا كانت متطلبات الامتثال الخاصة بك تتطلب وحدات تم التحقق من صحتها.