عندما يُبلغ Zimbra عن "توقف خدمة Nginx Proxy"، فهذا يعني أن عملية البروكسي متوقفة أو أن فحص حالتها لا يُؤكد تشغيلها. يُمكن إعادة تشغيلها لاستعادة الوصول إذا كان التوقف مؤقتًا، ولكن قد تظهر الرسالة نفسها إذا لم يتمكن NGINX من تحميل إعداداته المُولّدة، أو ربط منفذ مطلوب، أو قراءة شهادة، أو الوصول إلى خادم مصدر صالح. والنتيجة المُفيدة ليست مجرد ظهور الحالة باللون الأخضر: يجب أن يستمر البروكسي في العمل، ويجب تحميل بريد Zimbra الإلكتروني عبر عنوان URL العام المقصود، ويجب ألا تُظهر سجلات البروكسي فشل بدء التشغيل.
ينطبق هذا الدليل على عمليات نشر Zimbra التي تستخدم خدمة Zimbra Proxy المدمجة. قد تختلف الأوامر الدقيقة وتفاصيل التكوين باختلاف إصدار Zimbra وبنيته. في حالة التثبيت على عدة خوادم، قم بإجراء فحوصات على عقدة الوكيل، ولا تقم بتفعيل الوكيل على عقدة صندوق البريد أو خادم نقل البريد (MTA) لمجرد أن خادمًا آخر أبلغ عن توقفه. يصف دليل Zimbra Proxy ومرجع واجهة سطر الأوامر (CLI) للوكيل الخدمة وملفات التشخيص الخاصة بها. بعض صفحات استكشاف الأخطاء وإصلاحها في مركز الدعم الفني مُصنّفة على أنها قيد التطوير، لذا استخدمها جنبًا إلى جنب مع وثائق الإصدار المُثبّت لديك.
اتصل بخادم Zimbra الذي يستضيف الخادم الوكيل، ثم انتقل إلى حساب Zimbra. تحقق من قائمة الخدمات العامة وحالة الخادم الوكيل تحديدًا.
su - zimbra
zmcontrol status
zmproxyctl status
zmprov gs `zmhostname` zimbraServiceEnabledابحث عن proxyالخدمات المُفعّلة وعن عملية NGINX قيد التشغيل في مخرجات الحالة. تُوثّق Zimbra الإجراءات zmproxyctlباستخدام startو stopو restartو reloadو و status. إذا كان هذا المضيف عبارة عن عقدة بريد فقط أو خادم نقل بريد فقط، فقد يكون الخادم الوكيل متوقفًا. تأكد من دور الخادم في بيئة النشر قبل محاولة تشغيله.
إذا كان من المفترض أن يكون الخادم الوكيل نشطًا وكانت حالته متوقفة، فقم بتسجيل الحالة الحالية قبل إجراء أي تغيير. يساعد هذا في التمييز بين إعادة التشغيل الفاشلة والخدمة التي لم يتم تفعيلها على العقدة.
/opt/zimbra/log/nginx.logيُحدد دليل استكشاف أخطاء بروكسي Zimbra /opt/zimbra/log/nginx.access.logملفات سجلات البروكسي الرئيسية. تحقق من إدخالات الأخطاء الأخيرة وما إذا كان ملف التكوين الرئيسي موجودًا.
tail -n 100 /opt/zimbra/log/nginx.log
tail -n 50 /opt/zimbra/log/nginx.access.log
ls -l /opt/zimbra/conf/nginx.conf
يشير نص الخطأ عادةً إلى الفحص التالي. nginx.confيشير غياب عنصر ما إلى ضرورة مراجعة التكوين المُنشأ. يشير "منفذ غير صالح" في listenالتوجيه إلى منفذ أو إعداد ربط. يشير خطأ المفتاح الخاص أو الشهادة إلى مواد SSL. يشير فشل الربط إلى أن عملية أخرى قد تكون تمتلك العنوان والمنفذ بالفعل.
لا تقم بحذف ملفات تهيئة NGINX أو تعديل الملفات المُنشأة لإخفاء الخطأ. تُنشئ Zimbra تهيئة NGINX الخاصة بها من قوالب وقيم مُخزّنة في دليل التهيئة وLDAP. يشرح دليل تهيئة الوكيل والقوالب الخاص بالمورّد نموذج الإنشاء هذا. قد تُستبدل التعديلات اليدوية على الملفات المُنشأة أثناء إعادة التشغيل أو تحديث التهيئة لاحقًا.
إذا لم تُشر السجلات إلى وجود خطأ مستمر في التكوين أو الشهادة، فأعد تشغيل الخدمة من خلال وحدة تحكم Zimbra بصفتك مستخدم Zimbra:
zmproxyctl restart
zmproxyctl statusثم تحقق من قائمة الخدمات الكاملة مرة أخرى:
zmcontrol statusالنتيجة الناجحة هي أن يُبلغ الخادم الوكيل عن تشغيله ويستمر في العمل بعد اكتمال الأمر. تُوضح وثائق خادم Zimbra الوكيل zmproxyctl restartأن هذه العملية هي التي تستدعي أيضًا إنشاء التكوين. تجنب استخدام خادم وكيل systemctl restart nginxعلى مستوى النظام كبديل: إذ تُدير Zimbra تكوين الخادم الوكيل وخدمته بنفسها. إذا فشلت إعادة التشغيل، فارجع إلى أحدث خطأ في سجل الأخطاء nginx.log؛ فإعادة التشغيل المتكررة دون قراءة الخطأ عادةً لا تُصلح السبب.
توضح ملاحظة استكشاف الأخطاء وإصلاحها الخاصة بـ Zimbra لحالة فقدان أحد العناصر، /opt/zimbra/conf/nginx.confالحالات التي يفشل فيها إنشاء تكوين الوكيل بسبب احتواء سمة المصدر على خادم غير موجود أو خادم ليس خادم علب بريد. تحقق أولاً من القيم ذات الصلة على مستوى الخادم والقيم العامة.
zmprov -l gs `zmhostname` zimbraReverseProxyAvailableLookupTargets
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamEwsServers
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamLoginServers
zmprov -l gcf zimbraReverseProxyAvailableLookupTargets
zmprov -l gcf zimbraReverseProxyUpstreamEwsServers
zmprov -l gcf zimbraReverseProxyUpstreamLoginServersقارن كل اسم مضيف مع قائمة الخوادم الفعلية وتصميم التوجيه المُعتمد. صحّح الإدخالات القديمة أو غير الصالحة فقط بعد التأكد من الخادم المُخصّص لاستقبال حركة البيانات. لا تنسخ اسم مضيف نموذجي من صفحة المورّد إلى بيئة الإنتاج. توضح ملاحظة استكشاف الأخطاء وإصلاحها الرسمية "فشل بدء تشغيل Nginx" أمر مُولّد التكوين لنمط خطأ التكوين المفقود/المولد المحدد.
/opt/zimbra/libexec/zmproxyconfgen -s `zmhostname`
zmproxyctl restartاستخدم هذا الخيار فقط عندما يتطابق الخطأ الملاحظ مع هذا النمط وبعد مراجعة القيم ذات الصلة. إذا استمر المُولِّد في إظهار استثناء أو ظل الملف مفقودًا، فتوقف وتحقق من تتبع المكدس الكامل وخصائص الخادم بدلاً من إعادة تشغيله بشكل متكرر.
حدد أولًا المستمع المُكوّن الذي يُعاني من عطل. تحقق من قيم منافذ خدمة Zimbra والوكيل لهذه العقدة، ثم افحص ما إذا كانت عملية أخرى تستمع بالفعل على العنوان المتأثر. على سبيل المثال، إذا أشارت الرسالة إلى المنفذ 443، فتحقق مما إذا كان مستمع HTTPS العام مملوكًا لـ Zimbra NGINX أو لخادم ويب منفصل أو وكيل موازنة أحمال. لا تُنهِ عملية غير معروفة أو تُعيّن منفذًا جديدًا حتى تفهم كيفية وصول العملاء إلى الخدمة.
لا يُعدّ ظهور خطأ كهذا invalid port ...:0سببًا لتخمين رقم المنفذ. فقد يشير إلى إعدادات غير متناسقة للوكيل أو التكوين المُنشأ. قارن القيمة مع البنية المتوقعة، وراجع التغييرات الأخيرة، وصحّح إعدادات المصدر باستخدام الأدوات المدعومة من Zimbra. ثم أعد التشغيل zmproxyctlوتأكد من صحة المُستمع المُنشأ.
اقرأ رسالة خطأ SSL كاملةً وحدد مسار الشهادة المذكور فيها. تأكد من أن الشهادة والمفتاح الخاص مرتبطان ببعضهما، وأن حساب الخدمة المتوقع قادر على قراءتهما، وأن صلاحيتهما لم تنتهِ. تتضمن وثائق استكشاف أخطاء خادم Zimbra الوكيل حالةً يتعذر فيها على الخادم الوكيل تحميل بيانات المفتاح. اتبع إجراءات نشر الشهادة الخاصة بإصدار Zimbra لديك بدلاً من استبدال الملفات عشوائياً. من المفترض أن تؤدي إعادة التشغيل الناجحة إلى إزالة خطأ بدء تشغيل SSL، وأن يعرض المتصفح الشهادة المتوقعة لاسم مضيف البريد الإلكتروني العام.
لا يُعدّ تشغيل خادم وكيل دليلاً قاطعاً على سلامة خوادم البريد. في حالة ظهور رسالة "لا يوجد مسار إلى المضيف"، توصي Zimbra بالتحقق من تحليل نظام أسماء النطاقات (DNS) من عقدة الوكيل، ومن إمكانية الوصول إلى الخادم المقصود عبر المنفذ. أما في حالة ظهور خطأ 502 أو 503، فيُرجى التحقق من خدمة البريد والمضيف والمنفذ الرئيسيين؛ إذ يُشير دليل الوكيل إلى أن عدم توفر عملية البريد قد يتسبب في ظهور خطأ 503. استخدم الخادم والمنفذ المُطابقين لإصدارك وبنيتك، وتحقق من سجلات خادم البريد قبل تغيير مهلة الوكيل أو عتبات الفشل.
بعد إجراء الإصلاح المحدد، تأكد من كل ما يلي:
zmproxyctl statusيُبلغ عن تشغيل الخادم الوكيل.zmcontrol statusيعرض الخدمات المتوقعة لهذه العقدة./opt/zimbra/log/nginx.logلا تكرر الأسطر الأخيرة نفس فشل بدء التشغيل.ss -ltnp`ls`؛ وتختلف الأذونات وتفاصيل الإخراج باختلاف التوزيعة.تُحدد هذه الفحوصات عملية استعادة فعّالة: الخدمة تعمل، والمستمع موجود، ومسار المتصفح يعمل، ولم يعُد العطل فورًا. إذا كانت حالة الخدمة جيدة ولكن البريد الإلكتروني لا يزال معطلاً، فانتقل إلى فحص نظام أسماء النطاقات (DNS)، وبروتوكول أمان طبقة النقل (TLS)، وقواعد جدار الحماية، وتوجيه موازن الأحمال، أو سلامة خادم البريد. إذا توقفت الخدمة مرة أخرى، فاحتفظ بسجلات النظام الجديدة ومخرجات مُولِّد التكوين؛ فهي أكثر فائدة من إعادة تشغيل عشوائية.
إذا لم تُفسّر السجلات العادية عطلاً مستمراً، تُوثّق Zimbra زيادة مؤقتة لمستوى سجلات خادم NGINX الوكيل. قد يكشف تسجيل التصحيح معلومات حساسة، بما في ذلك رموز المصادقة، لذا تجنّب تفعيله على نظام الإنتاج إلا عند الضرورة. إذا أوصى فريق الدعم باستخدامه، فقيّد الوصول إلى السجلات، واجمع البيانات المطلوبة فقط، ثم أعد الإعداد إلى قيمته السابقة، وتعامل مع سجلات التصحيح وفقاً لسياسة الأمان الخاصة بك. راجع تعليمات Zimbra لتسجيل تصحيح NGINX لمعرفة الأمر المناسب للإصدار.
في حال استمرار فشل إنشاء التكوين، أو تعذر التحقق من صحة شهادة الوكيل، أو إذا كان الخطأ يشير إلى مستمع غير معروف، أو إذا كان دور العقدة غير واضح، يُرجى تصعيد المشكلة إلى مسؤول Zimbra أو دعم المورّد. يمكن لوحدة تحكم الخدمة إعادة تشغيل التكوين السليم، ولكنها لا تستطيع تحديد مسار البريد الصحيح، أو إصلاح شهادة غير صالحة، أو حل مشكلة مسار الشبكة المعطوب تلقائيًا.
تمت مراجعة المصادر في 6 أكتوبر 2026. تتضمن صفحات مركز زيمبرا التقني المشار إليها هنا أمثلة قديمة وبعضها مصنف على أنها أعمال قيد التقدم؛ تأكد من الأوامر مقابل إصدار زيمبرا المثبت على خادمك قبل تغيير تكوين الإنتاج.
قارن بين 10 أدوات مسح الشبكة المحلية (Ping) لاكتشاف الشبكات المحلية بسرعة، وإجراء مسح شامل للأنظمة الأساسية المختلفة، وإدارة عناوين IP. تعرّف على ما يمكن أن يكشفه لك المسح وما لا يمكنه كشفه.
قارن بين ست أدوات لإدارة الشبكة لمراقبة الأداء، بما في ذلك تغطية SNMP، ورسم الخرائط، والتنبيهات، ونماذج النشر، والمفاضلات المتعلقة بالتكلفة.
قارن بين أفضل برامج تحليل شبكة Wi-Fi لأنظمة Windows و iPhone و Android، بما في ذلك أدوات ازدحام القنوات وتغطية الإشارة والخرائط الحرارية واستكشاف أخطاء الشبكة وإصلاحها.
قارن بين سبعة برامج مراقبة زمن الاستجابة المجانية والمفتوحة المصدر، بدءًا من مجموعات الشبكة الكاملة وحتى مجسات زمن الاستجابة المركزة، واختر البرنامج المناسب من حيث التوافر وفقدان الحزم والسجل.
تعرف على معنى جودة الخدمة في الشبكات، وكيف تحدد علامات DSCP وقوائم انتظار حركة المرور أولويات تطبيقات الصوت والفيديو والأعمال، وما لا تستطيع جودة الخدمة إصلاحه.
قم ببناء نظام مراقبة شبكة عملي مع تغطية واضحة للأجهزة، ومقاييس أداء مفيدة، وتنبيهات قابلة للتنفيذ، ومقارنة بين SolarWinds NPM وPRTG وOpManager.
قارن بين برامج خوادم SFTP الموثوقة لأنظمة ويندوز ولينكس، بما في ذلك OpenSSH وBitvise وSolarWinds وSFTPGo. اعثر على الخيار الأمثل الذي يلبي احتياجاتك الأمنية واحتياجات نقل الملفات.
قارن بين سبع أدوات لإدارة عناوين IP لاكتشاف الشبكات الفرعية، وتنسيق DNS وDHCP، وجرد الشبكة، وIPAM مفتوح المصدر.
قارن بين أدوات فحص الشبكة لاكتشاف الأجهزة بسرعة، وعمليات فحص IP عبر الأنظمة الأساسية، وإدارة عناوين IP للمؤسسات، مع إرشادات حول مطابقة كل خيار مع شبكتك.
استخدم خيار --traceroute في Nmap لرسم خرائط القفزات إلى مضيف مصرح به، وفهم مخرجات القفزة وRTT، واستكشاف الأخطاء وإصلاحها في الاستجابات المفقودة دون الإفراط في المسح.
