كيفية إصلاح رسائل خطأ Nginx الشائعة: دليل خطوة بخطوة

كيف يمكنني إصلاح خطأ NGINX؟

الآن بعد أن رأيت بعض أخطاء NGINX الشائعة ، قد يكون لديك سؤال في الاعتبار: "كيف يمكنني إصلاح خطأ NGINX؟"

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

هناك ثلاثة أوامر أساسية يمكن أن تساعدك في بدء رحلة استكشاف الأخطاء وإصلاحها لأخطاء NGINX.

• احصل على سجل الأخطاء وتفاصيل المشكلة باستخدام هذا الأمر: sudo cat /var/log/nginx/error.log
• لفحص حالة Nginx النشطة: sudo systemctl status nginx
• لفحص أخطاء بناء الجملة في ملف التكوين: sudo nginx -t

1. استكشاف أخطاء Nginx وإصلاحها باستخدام سجلات الأخطاء

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

يعتمد كل هذا على كيفية تكوين إعداد NGINX الخاص بك والموقف المحدد الذي تواجهه.

للحصول على فهم أفضل لأخطاء NGINX التي تحدث ، يمكنك تشغيل أمر لعرض قائمة بهذه الأخطاء. هذا هو الأمر:

sudo cat /var/log/nginx/error.log

لتشغيل هذا الأمر ، يجب أن تكون مستخدمًا ذا امتياز. من المستحسن أن يكون لديك وصول sudo بدلاً من استخدام مستخدم الجذر.

يسمح لك هذا الأمر بقراءة محتويات الملف /var/log/nginx/error.log بالكامل ، والذي يحتوي على سجلات أخطاء NGINX. سيعرض هذه السجلات في نافذة جهازك.

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

فيما يلي مثال على سجل أخطاء للرجوع إليه ،

2023/05/31 10:15:23 [error] 1234#0: *1 open() "/var/www/html/missing-page.html"
failed (2: No such file or directory), client: 192.168.0.1, server: example.com,
request: "GET /nonexistent-page HTTP/1.1", host: "example.com"

2023/05/31 12:45:57 [error] 1234#0: *2 upstream timed out (110: Connection timed out)
while reading response header from upstream, client: 192.168.0.2, server:
example.com, request: "GET /api/data HTTP/1.1", upstream:
"http://127.0.0.1:8000/api/data", host: "example.com"

2023/05/31 15:22:10 [error] 1234#0: *3 rewrite or internal redirection cycle while internally redirecting to "/index.php", client: 192.168.0.3, server: example.com, request: "GET /category/products/ HTTP/1.1", host: "example.com"

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

• الطابع الزمني: يُظهر الجزء الأول من كل سطر التاريخ والوقت اللذين حدث فيهما الخطأ ، بتنسيق YYYY/MM/DD HH:MM:SS .
• مستوى الخطأ: تشير العلامة [error] إلى أن هذا السطر يمثل خطأ.
• معرّف العملية: الرقم بعد الرمز # (على سبيل المثال ، 1234#0 ) يمثل معرّف عملية NGINX الذي يعالج الطلب.
• رسالة الخطأ: توفر رسالة الخطأ تفاصيل حول الخطأ المحدد. يتضمن معلومات مثل ملف أو فشل الوصول إلى المورد أو مهلات الاتصال الأولية أو مشكلات إعادة التوجيه الداخلية.
• عنوان IP للعميل: يعرض حقل client عنوان IP الخاص بالعميل الذي يقوم بالطلب إلى الخادم.
• اسم الخادم: يشير حقل server إلى اسم الخادم أو المضيف الظاهري الذي حدث فيه الخطأ.
• تفاصيل الطلب: يعرض حقل request طريقة HTTP وعنوان URL المطلوب وإصدار البروتوكول المستخدم من قبل العميل.
• المضيف: يحدد حقل host اسم المضيف أو عنوان IP المستخدم في الطلب.

يساعد كل إدخال في سجل الأخطاء في تشخيص المشكلات واستكشاف الأخطاء وإصلاحها من خلال توفير معلومات حول نوع الخطأ والمورد المتأثر وعنوان IP للعميل والتفاصيل الأخرى ذات الصلة.

2. استكشاف أخطاء NGINX وإصلاحها عن طريق التحقق من حالتها

هناك طريقة أخرى يمكنك محاولة استكشاف أخطاء NGINX بها وإصلاحها وهي التحقق من حالتها ، أي ما إذا كانت نشطة أم لا. هناك احتمال أنه ، لأسباب معينة ، لا يمكن إكمال عملية التثبيت أو أن الخدمة ليست نشطة بعد.

للتحقق من حالة خدمة NGINX ، استخدم الأمر التالي:

sudo systemctl status nginx

إذا كانت خدمة NGINX نشطة ، فسيكون الإخراج كما يلي ؛

nginx.service - The NGINX HTTP and reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:
enabled)
Active: active (running) since Mon 2023-05-31 14:30:00 UTC; 5min ago
Docs: http://nginx.org/en/docs/
Process: 1234 ExecStart=/usr/sbin/nginx -g daemon on;
master_process on;
(code=exited, status=0/SUCCESS)
Main PID: 1234 (nginx)
Tasks: 2 (limit: 2319)
Memory: 3.9M
CGroup: /system.slice/nginx.service
├─1234 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
└─5678 nginx: worker process

وإذا كانت حالة NGINX غير نشطة ، فسيتم إخراج حالة sudo systemctl nginx ، سيشير الأمر إلى أن الخدمة غير نشطة أو متوقفة على النحو التالي.

nginx.service - The NGINX HTTP and reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: http://nginx.org/en/docs/

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

sudo systemctl restart nginx

بعد ذلك ، يمكنك استخدام الأمر status مرة أخرى للتحقق مما إذا كانت خدمة NGINX نشطة الآن أم لا.

3. استكشاف أخطاء NGINX وإصلاحها عن طريق التحقق من خطأ في بناء الجملة

تعتبر الأخطاء النحوية مشكلة شائعة يمكن أن تظهر عند كتابة البرامج النصية أو الرموز أو تكوين ملفات Nginx.

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

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

للتحقق من وجود أي خطأ في بناء الجملة في ملف تكوين Nginx ، استخدم الأمر التالي.

sudo nginx -t

إذا تبين أن بناء الجملة صحيح ، فسيكون الإخراج ،

nginx: configuration file /etc/nginx/nginx.conf test is successful

ومع ذلك ، إذا كانت هناك مشكلة في بناء الجملة ، فسيتم عرض الإخراج على شكل ،

nginx: [emerg] unexpected end of file, expecting ";" or "}" in
/etc/nginx/nginx.conf:42
nginx: configuration file /etc/nginx/nginx.conf test failed

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