دليل استكشاف أعطال خوادم الويب في ServBay

يدعم ServBay استخدام Caddy أو NGINX أو Apache كـ خادم ويب افتراضي، ليمنحك بيئة تطوير محلية مرنة. وخلال العمل، قد تواجه مشاكل مثل عدم إمكانية الوصول إلى الموقع، بطء التحميل، أو ظهور أخطاء (مثل 500 خطأ داخلي في الخادم). الهدف من هذا الدليل هو مساعدتك على تشخيص وحل الأعطال الشائعة المتعلقة بخوادم الويب ضمن بيئة ServBay.

استخدام أداة التشخيص المدمجة في ServBay

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

افتح تطبيق ServBay، ثم انقر على "تشخيص الأعطال" في شريط التنقل الجانبي للوصول إلى واجهة أداة التشخيص.

تقوم الأداة بفحص حالة مكونات ServBay الأساسية، واستخدام المنافذ، وصحة ملفات الإعداد، وتعرض لك ما تحتاجه من إشعارات واقتراحات لمساعدتك في تحديد مصدر المشكلة بسرعة.

فحص ملفات إعداد خادم الويب

الأخطاء في ملفات إعداد خادم الويب من الأسباب الشائعة لعدم عمل المواقع بشكل سليم. يوفر ServBay أدوات مخصصة للتحقق من صحة الصياغة لكل خادم ويب.

فحص Caddyfile

استخدم أمر validate المدمج في Caddy للتحقق من صحة ملف إعدادات Caddyfile:

/Applications/ServBay/bin/caddy validate -c /Applications/ServBay/etc/caddy/Caddyfile

إذا كانت الصياغة صحيحة، سترى نتيجة Valid configuration. في حال وجود خطأ، ستظهر رسالة توضح نوع الخطأ وكيفية التعامل معه.

ملاحظة: قد يعرض أمر caddy validate العديد من رسائل INFO أو WARN، وهذه غالبًا معلومات أثناء تحميل Caddy وليست أخطاء فعلية. طالما ظهرت رسالة Valid configuration في النهاية، فإن الصياغة سليمة.

أمثلة على أخطاء Caddyfile الشائعة:

• خطأ في مسار ملف الشهادة:

  2024/12/09 17:24:16.970 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  ... (معلومات INFO/WARN أخرى) ...
  Error: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open /Applications/ServBay/ssl/private/tls-certs/mail.servbay.host/mail.servbay.host.1crt: no such file or directory

  ظهور رسالة مثل loading certificates: open xxxxx: no such file or directory تعني أن مسار ملف شهادة SSL المحدد في Caddyfile غير صحيح أو أن الملف غير موجود أصلًا. تحقق من المسارات المخصصة للشهادة (.crt/.cer/.pem) ومفتاحها (.key) في إعدادات موقعك، وتأكد من أن الملفات بالفعل في مواقعها. يدعم ServBay استيراد الشهادات يدويًا أو الحصول عليها تلقائيًا عبر ACME؛ تحقق من إعدادات SSL ذات الصلة.

• خطأ في مسار مجلد الجذر للموقع (يحتوي على فراغ):

  2024/12/09 17:26:37.371 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  Error: adapting config using caddyfile: parsing caddyfile tokens for 'root': too many arguments; should only be a matcher and a path, at /Applications/ServBay/etc/caddy/Caddyfile:1388

  هذا الخطأ parsing caddyfile tokens for 'root': too many arguments يحدث غالبًا إذا كان مسار المجلد يحتوي على فراغات، مثل: root * /Applications/ServBay/www/public web، حيث سيتم اعتبار public web كوسيطين منفصلين. الحل هو وضع المسار كاملًا بين علامات اقتباس مزدوجة، مثل: root * "/Applications/ServBay/www/public web".

  نصيحة: لتفادي هذه المشاكل، ينصح بعدم استخدام الفراغات أو الرموز الخاصة في أسماء الملفات والمجلدات. استخدم الشرطتين (-) أو الشرطة السفلية (_) للفصل بين الكلمات، مثل: public-folder أو public_dir.

• خطأ في قواعد Rewrite:

  استخدام صياغة غير صحيحة لقواعد إعادة الكتابة (Rewrite) في Caddyfile، أو نسخ قواعد من NGINX بشكل مباشر دون تعديل، يؤدي لفشل التحقق من الإعدادات. ارجع إلى توثيق وحدة إعادة كتابة Caddy أو دليل نقل مواقع NGINX إلى ServBay لضبط الصياغة بالشكل الصحيح.

التحقق من إعدادات NGINX

استخدم معامل -t مع NGINX لاختبار صحة وصياغة ملفات الإعداد:

/Applications/ServBay/bin/nginx -t

إذا كانت الإعدادات صحيحة، ستظهر الرسائل التالية:

nginx: the configuration file /Applications/ServBay/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /Applications/ServBay/etc/nginx/nginx.conf test is successful

في حال وجود أخطاء، سيعرض NGINX اسم الملف ورقم السطر المحتوي على الخطأ. الأخطاء الشائعة تشمل:

1. أخطاء الصياغة: كنسيان الفاصلة المنقوطة ; أو عدم تطابق الأقواس {}.
2. أخطاء مسارات الملفات: كإدراج ملف غير موجود أو خطأ في مسار معين ضمن تعليمة include.
3. تعارض المنافذ: كأن يكون المنفذ المطلوب عليه خادم آخر بالفعل.

التحقق من إعدادات Apache

استخدم أمر apachectl configtest مع Apache لفحص صحة ملفات الإعداد:

/Applications/ServBay/bin/apachectl configtest

سيظهر Syntax OK إذا كانت الصياغة صحيحة، وإلا ستحصل على تفاصيل الخطأ. أخطاء Apache الشائعة:

1. فشل تحميل الوحدات: كأن يكون المسار غير صحيح أو الوحدة نفسها غير متوفرة (تعليمة LoadModule).
2. أخطاء في ملف .htaccess: وجود ملف .htaccess يحتوي على أخطاء في الصياغة قد يؤدي لفشل الفحص أو منع الوصول لدليل معين.
3. إعدادات صلاحيات المجلد غير صحيحة: كاستخدام تعليمات Directory أو Files مع إعدادات (Require, Allow, Deny) تمنع طلبات الوصول لملفات الموقع.

معالجة خطأ 500 الداخلي في الخادم

الخطأ 500 (Internal Server Error) هو رمز تشفير HTTP عام، يشير إلى حدوث مشكلة غير متوقعة بالخادم أثناء معالجة الطلب. غالبًا ما يعني ذلك تعطل سكريبت في الخلفية (مثل PHP أو Python أو Node.js).

خطوات الفحص العامة

عند ظهور خطأ 500، اتبع الخطوات التالية:

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

   • Caddy: /Applications/ServBay/var/logs/caddy/error.log
   • NGINX: /Applications/ServBay/var/logs/nginx/error.log
   • Apache: /Applications/ServBay/var/logs/apache/error.log راجع أحدث الإدخالات وابحث عن الكلمات مثل error أو critical.

2. تأكد من تشغيل الخدمات الخلفية (مثلا PHP-FPM): إذا كان موقعك يعتمد على PHP، تحقق من أن خدمة PHP-FPM نشطة.

   ps aux | grep php-fpm

   ابحث عن خطوط تحتوي على php-fpm: master process أو php-fpm: pool www. إذا لم تجدها، يعني أن الخدمة متوقفة أو تعطلت. يمكنك إعادة تشغيل PHP-FPM من الواجهة الرسومية أو باستخدام أمر servbayctl.

3. فحص سجل أخطاء السكريبتات الخلفية (مثلا PHP): إذا أشار سجل خوادم الويب إلى مشاكل FastCGI أو السكريبتات، توجه إلى سجل الأخطاء الخاص بلغتك البرمجية الأساسية.

   • PHP: /Applications/ServBay/var/logs/php/php_error.log ابحث عن عبارات مثل Fatal error, Parse error, Warning, Notice خاصة بتلك السكريبتات. يُفضل في بيئة التطوير تفعيل عرض الأخطاء (display_errors في ملف php.ini) للاطلاع على التفاصيل.

4. التحقق من صلاحيات الملفات والمجلدات: غالبًا ما تعمل خوادم الويب تحت مستخدم محدد (مثل _www) ويلزم توفر صلاحيات كافية لقراءة ملفات الموقع وكتابة ملفات الرفع أو السجلات.

   ls -la /Applications/ServBay/www/your-site/

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

نقاط فحص خطأ 500 خاصة بكل خادم ويب

• Caddy:

  1. إعداد FastCGI: تحقق من تعليمة php_fastcgi أو reverse_proxy في Caddyfile وتأكد من صحة عنوان الإستماع لـPHP-FPM (عادة 127.0.0.1:9000 أو unix:/path/to/php-fpm.sock).
  2. حالة PHP-FPM: تحقق من تشغيل نسخة PHP المطلوبة مع PHP-FPM ضمن ServBay.
  3. إعدادات العكس الوكيل: إذا كنت تستخدم reverse_proxy لتوجيه الطلبات لخادم خلفي آخر (مثلاً Node.js)، تحقق من صحة العنوان والمنفذ وحالة الخدمة الخلفية.

• NGINX:

  1. إعداد fastcgi_pass: راجع ملف nginx.conf أو إعدادات الموقع للتحقق من صحة إعداد fastcgi_pass.
  2. إعداد client_max_body_size: إذا واجهت أخطاء عند تحميل ملفات كبيرة، قد يكون السبب ضيق هذا الإعداد ووجوب زيادته.
  3. تعليمة try_files: اضمن أن تعليمة try_files مضبوطة بشكل صحيح لتحويل الطلبات إما لملف صحيح أو إلى FastCGI بدون أخطاء.

• Apache:

  1. وحدة mod_rewrite: إذا كنت تستخدم إعادة كتابة عناوين url في .htaccess، تأكد أن وحدة mod_rewrite مفعلة.
  2. صياغة .htaccess: أي خطأ ضمن هذا الملف يؤدي مباشرة إلى ظهور خطأ 500. راجع إخطاء الصياغة لاسيما في قواعد RewriteRule.
  3. إعداد AllowOverride: تأكد أن إعداد AllowOverride في ملف إعدادات Apache يسمح لأوامر .htaccess بأن تعمل (غالبًا All أو على الأقل FileInfo وLimit).

إدارة الخدمات

بعد تعديل ملف إعداد أو حل مشكلة خلفية، غالبًا يجب إعادة تشغيل خادم الويب أو الخدمة ذات الصلة حتى تدخل التعديلات حيز التنفيذ.

إعادة تشغيل خدمة

استخدم الأمر servbayctl restart لإعادة تشغيل خدمة خادم الويب المطلوبة:

# إعادة تشغيل خدمة Caddy
servbayctl restart caddy -all

# إعادة تشغيل خدمة NGINX
servbayctl restart nginx -all

# إعادة تشغيل خدمة Apache
servbayctl restart apache -all

معامل -all يحاول أيضًا إعادة تشغيل الخدمات المساندة مثل PHP-FPM تلقائيًا مع إعادة تشغيل Caddy أو NGINX أو Apache.

التحقق من حالة الخدمة

لمعرفة حالة الخدمة الحالية، استخدم أمر servbayctl status:

# فحص حالة كادي
servbayctl status caddy -all

# فحص حالة NGINX
servbayctl status nginx -all

# فحص حالة Apache
servbayctl status apache -all

ستعرض نتيجة الأمر ما إذا كانت الخدمة running (نشطة)، أو stopped (متوقفة)، أو حالة أخرى. ذلك يسمح بتحديد ما إذا تم تشغيل الخدمة بنجاح.

خطوات استكشاف متقدمة

إذا لم تستطع حل المشكلة بهذه الطرق، جرب مراحل فحص أكثر تقدمًا:

1. فحص أدوات مطوري المتصفح: افتح أدوات المطور (غالبًا بالضغط على F12)، وانتقل إلى علامات التبويب "Console" و"Network" لتحليل أخطاء JavaScript أو طلبات الشبكة أو التحقق من حالة الاستجابة بالتفصيل.
2. استخدام أمر curl -v: في الطرفية، نفذ curl -v your-website.servbay.demo. سيظهر كل تفاصيل الطلب والاستجابة وتشمل الرؤوس والإتصال بـSSL/TLS وغيرها. استبدل your-website.servbay.demo بنطاق موقعك الفعلي في ServBay.
3. تعطيل الجدار الناري مؤقتًا: قد يحجب جدار الحماية المحلي (مثل جدار macOS) أو برنامج حماية آخر اتصالات معينة. قم بإيقاف الجدار مؤقتًا لفحص المشكلة، وإذا اختفت المشكلة راجع إعدادات الجدار واسمح للمنافذ (80، 443، إلخ.) اللازمة لـServBay بالمرور.
4. جرب من متصفحات/أجهزة أخرى: اختبر الموقع من متصفح أو جهاز آخر لاستبعاد أسباب تتعلق بذاكرة التخزين المؤقت أو ضبط الجهاز المستخدم.
5. تحقق من إعداد DNS المحلي أو ملف hosts: إذا استخدمت نطاقات مخصصة بدلًا من localhost أو الـIP، تحقق من ملف /etc/hosts أو إعدادات DNS المحلية وتأكد أن الدومين يوجه إلى 127.0.0.1 أو ::1.

الخلاصة

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