كيفية إصلاح الخطأ 504 Gateway Timeout Error على موقع WordPress الخاص بك
نشرت: 2020-10-26يعد الخطأ 504 Gateway Timeout أحد أكثر أخطاء HTTP 5xx شيوعًا التي يواجهها مالكو مواقع الويب وزوار الموقع. بالنسبة للعديد من مدونات WordPress ومنصات التجارة الإلكترونية ، فإن معرفة كيفية إصلاح أخطاء الخادم مثل هذا أمر بالغ الأهمية لمنع زوارهم الذين اكتسبوا بشق الأنفس من الارتداد إلى مواقع المنافسين.
نظرًا لأن الخطأ 504 Gateway Timeout لا يخبرك عن سبب حدوثه ، فمن الصعب تحديد سبب انتهاء مهلة الخادم. ستساعدك هذه المقالة في فهمها بالتفصيل ، ومعرفة كيفية تشخيص سببها ، ثم إصلاحها.
بعد تجربة جميع الحلول المختلفة المذكورة في المنشور ، يجب أن يكون موقعك جاهزًا للعمل في أي وقت من الأوقات.
مثير للاهتمام؟ دعنا نتعمق!
هل تفضل مشاهدة نسخة الفيديو؟
ما هو خطأ 504 Gateway Timeout؟
في كل مرة تقوم فيها بزيارة موقع ويب في متصفحك ، يرسل المتصفح طلبًا إلى خادم الويب حيث تتم استضافة الموقع. يعالج الخادم الطلب ويستجيب بالموارد المطلوبة.

تتضمن استجابة الخادم أحد أكواد حالة HTTP العديدة للإشارة إلى حالة الاستجابة للمتصفح. ولكن ليست كل رموز حالة HTTP هذه أخطاء. على سبيل المثال ، يعني رمز الحالة 200 OK أن الخادم قام بمعالجة الطلب بنجاح و "كل شيء على ما يرام".
تشير فئة 5xx من أكواد حالة HTTP إلى وجود خطأ ما في الخادم ، وأن الخادم على علم به ، ولا يمكنه تنفيذ طلب العميل. نتيجة لذلك ، يشار إليها أيضًا باسم رموز حالة Server Error 5xx .
رسميًا ، تم تحديد خمسة رموز حالة ضمن فئة 5xx (500 ، 501 ، 502 ، 503 ، 504). قد تجد أيضًا العديد من الرموز غير الرسمية (506 ، 507 ، 509 ، 520 ، إلخ).
تحدد فرقة عمل هندسة الإنترنت (IETF) الخطأ 504 Gateway Timeout على النحو التالي:
يشير رمز الحالة 504 (Gateway Timeout) إلى أن الخادم ، أثناء عمله كبوابة أو وكيل ، لم يتلق استجابة في الوقت المناسب من خادم رئيسي يحتاج إلى الوصول إليه من أجل إكمال الطلب.
لتبسيط الأمر أكثر ، يحدث هذا الخطأ عندما يشترك خادمان في معالجة الطلب. انتهت مهلة الخادم الأول (الخادم الرئيسي عادةً) ، في انتظار استجابة من الخادم الثاني (الخادم الرئيسي).
يظهر الخطأ 504 Gateway Timeout في أشكال مختلفة. فيما يلي بعض الطرق التي تظهر بها عادةً:

يشبه الخطأ 504 Gateway Timeout الخطأ 502 Bad Gateway ، والذي يشير إلى أن الخادم الأول تلقى استجابة غير صالحة من الخادم الثاني (الخادم الرئيسي).

الاختلافات في 504 Gateway Timeout Error
يعرض المتصفح أي خطأ 504 Gateway Timeout بداخله ، تمامًا مثل أي خطأ آخر. نظرًا لوجود العديد من أنظمة التشغيل وخوادم الويب والمتصفحات ووكلاء المستخدم ، يمكن أن تظهر بطرق متعددة.
فيما يلي بعض الاختلافات الشائعة في رسائل الخطأ 504 التي قد تواجهها:
- البوابة 504 انتهى الزمن
- 504 بوابة مهلة NGINX
- مهلة بوابة NGINX 504
- خطأ في مهلة البوابة
- خطأ 504
- خطأ HTTP 504
- خطأ HTTP 504 - بوابة المهلة
- بروتوكول HTTP 504
- 504 خطأ
- مهلة البوابة (504)
- هذه الصفحة لا تعمل - استغرق المجال وقتًا طويلاً للاستجابة
- 504 Gateway Time-out - لم يستجب الخادم في الوقت المناسب
- تم إلغاء طلب الصفحة لأن إكمالها استغرق وقتًا طويلاً
- زوار الموقع: حدثت مشكلة في تلبية طلبك ، يرجى المحاولة مرة أخرى في غضون بضع دقائق.
- مالكو الموقع: انتهت مهلة البوابة. يجب عليك زيارة سجل الأخطاء لمزيد من المعلومات.
- شاشة بيضاء فارغة
تشير جميع استجابات الخطأ المذكورة أعلاه ، على الرغم من صياغتها بشكل مختلف ، إلى نفس خطأ خادم 504 Gateway Timeout.
يمكن لخوادم الويب ومواقع الويب تخصيص كيفية إظهار الخطأ 504 Gateway Timeout للمستخدمين. يمكن أن يكون بعض منهم رائع! إنه تكتيك ممتاز لتهدئة خيبة أمل زوارهم.

تأثير SEO لخطأ 504 Gateway Timeout
تمنع جميع أخطاء 5xx تحميل صفحة ويب ، مما يجعلها ضارة بتجربة المستخدم. ومن ثم ، فإن محركات البحث مثل Google تأخذ هذه الأخطاء على محمل الجد. إذا استمر الخطأ لفترة طويلة ، فقد يؤدي ذلك إلى إلغاء فهرسة صفحة الويب من نتائج محرك البحث.
على سبيل المثال ، عندما تعثر عناكب Google خطأ 503 Service Unavailable ، فسوف يفهمون أنها مشكلة مؤقتة لأنها تستخدم في الغالب لتمكين وضع صيانة الموقع. وبالتالي ، سيحاولون الزحف إلى الصفحة مرة أخرى لاحقًا.
خطأ 504 Gateway Timeout ليس بالضرورة مؤقتًا لأنه قد يكون نتيجة لأسباب متعددة. إذا تعطل موقعك لبضع دقائق فقط ، وإذا كانت العناكب تحاول الزحف إليه عدة مرات كل دقيقة ، فسيحاولون عرض الصفحة من ذاكرة التخزين المؤقت الخاصة بهم. لن يلاحظوا ذلك حتى.
ولكن إذا تعطل موقعك لمدة تزيد عن 6 ساعات أو أكثر ، فستعتبر Google الخطأ 504 مشكلة خطيرة على مستوى الموقع تحتاج إلى إصلاحها في أقرب وقت ممكن. هذا يمكن أن يؤثر سلبًا على مُحسنات محركات البحث.

تعد Google Search Console واحدة من أفضل أدوات تحسين محركات البحث (SEO) لمراقبة أخطاء HTTP 5xx لموقع الويب الخاص بك.
أسباب 504 Gateway Timeout Error
نظرًا لأن الخطأ 504 يرجع إلى انتهاء المهلة بين الخوادم ، فربما لا تكون المشكلة في جهاز العميل أو اتصال الإنترنت. يتضمن ذلك أيضًا جهازك والاتصال.
يشير الخطأ 504 Gateway Timeout إلى أن خادم الويب ينتظر وقتًا طويلاً للاستجابة من خادم آخر و "انتهاء المهلة". يمكن أن يكون هناك العديد من الأسباب لهذه المهلة: الخادم الآخر لا يعمل بشكل صحيح ، أو محملة بشكل زائد ، أو معطلة.
لا يلزم أن يكون الخادم الآخر دائمًا خارجيًا (مثل CDN ، بوابة API). يمكن أن يكون أيضًا كيانًا يشبه الخادم داخل خادم الويب الرئيسي (على سبيل المثال ، خادم وكيل عكسي ، خادم قاعدة بيانات).
كيفية إصلاح خطأ 504 Gateway Timeout
بدون معرفة التفاصيل الدقيقة حول موقع WordPress ، مثل تكوين الخادم وخطة الاستضافة والمكونات الإضافية للجهات الخارجية وحركة المرور التي تجتذبها ، قد تجد أنه من المحبط والمربك إصلاح خطأ 504 Gateway Timeout.
نظرًا لأن العديد من المتغيرات متضمنة ، أوصيك بالبدء في إصلاح مشكلات جانب العميل ، والتي تعد نادرة جدًا ، ثم الانتقال إلى إصلاح مشكلات جانب الخادم. هم عادة الجناة مع 504 أخطاء.
حاول إعادة تحميل صفحة الويب
من أول الأشياء التي يمكنك تجربتها عند مواجهة خطأ 504 Gateway Timeout الانتظار بضع دقائق ومحاولة إعادة تحميل الصفحة.
يمكنك الضغط على اختصار لوحة المفاتيح F5 لتحديث / إعادة تحميل صفحة الويب في معظم المتصفحات. لإزالة ذاكرة التخزين المؤقت لمتصفح الصفحة قبل إعادة التحميل ، يمكنك الضغط على اختصار CTRL + F5 بدلاً من ذلك.

أثناء تواجدك فيه ، يمكنك أيضًا محاولة تحميل الموقع في متصفح مختلف لاستبعاد ذلك باعتباره مشكلة. نظرًا لأن معظم أخطاء 504 ناتجة عن خوادم محملة بشكل زائد مؤقتًا ، فإن استخدام هذا الحل يجب أن يجعل موقعك يعود مباشرة.
إذا لم يؤد الانتظار وإعادة تحميل الموقع إلى إصلاح مشكلة الخطأ 504 ، فيمكنك التحقق مما إذا كان الموقع معطلاً للجميع أم أنت فقط. هناك أداتان مفيدتان عبر الإنترنت لاختبار وقت تعطل أحد المواقع وهما "تعطل للجميع" أو "أنا فقط" وهل تعطل الآن؟

أعد تشغيل أجهزة الشبكة الخاصة بك
في بعض الأحيان ، قد تؤدي مشكلات أجهزة الشبكة مثل المودم أو جهاز التوجيه إلى حدوث خطأ 504 Gateway Timeout. يمكن أن تساعدك إعادة تشغيل هذه الأجهزة في حل المشكلة.
بينما يمكنك إيقاف تشغيل جميع أجهزة الشبكات هذه بأي ترتيب ، فإن ترتيب إعادة تشغيلها أمر مهم. عادةً ، قم بتشغيل هذه الأجهزة من "الخارج إلى الداخل" ، باتباع طلب الاتصال من مزود خدمة الإنترنت إلى جهاز العميل الرئيسي.
تحقق من إعدادات الوكيل الخاصة بك
يوجد خادم وكيل بين جهازك والإنترنت. يتم استخدامه في الغالب لتعزيز الخصوصية عبر الإنترنت عن طريق إخفاء المعلومات الخاصة (مثل موقع الجهاز) من مواقع الويب وخوادم الويب (مثل استخدام VPN).
في حين أنه من النادر أن تتسبب الخوادم الوكيلة في حدوث خطأ 504 ، فقد تكون إعدادات الخادم الوكيل غير الصحيحة هي السبب في بعض الأحيان. يمكنك تعطيل الخادم الوكيل ومحاولة إعادة تحميل صفحة الويب لمعرفة ما إذا كان سيصلح الخطأ أم لا.

لا يستخدم معظم العملاء خدمة الوكيل ، لذا يمكنك تخطي هذه الخطوة إذا كنت واثقًا من أنك لا تستخدم أي خادم وكيل. ومع ذلك ، ربما تكون قد قمت بتعيينه دون علمك بذلك. أقترح عليك التحقق من إعدادات الخادم الوكيل لجهازك والمتصفح لاستبعاد هذا السبب.
قضايا DNS
يمكن أن يحدث خطأ 504 Gateway Timeout أيضًا بسبب مشكلات DNS على جانب الخادم أو جانب العميل (أو كليهما).
السبب الأكثر احتمالاً لمشكلة DNS من جانب الخادم هو أن FQDN (اسم المجال المؤهل بالكامل) لا يحل عنوان IP الصحيح أو أن خادم DNS لا يستجيب . عادةً ما يحدث هذا عندما تقوم بترحيل موقع WordPress الخاص بك إلى خادم أو مضيف جديد. وبالتالي ، من المهم انتظار نشر سجلات DNS الخاصة بالمجال بالكامل ، الأمر الذي قد يستغرق ما يصل إلى 24 ساعة.
يمكنك استخدام أدوات مجانية مثل whatsmydns.net DNS Checker أو DNSMap لمعرفة ما إذا كان DNS الخاص بك قد انتشر في جميع أنحاء العالم.

لإصلاح مشكلات DNS من جانب العميل ، يمكنك محاولة مسح ذاكرة التخزين المؤقت DNS المحلية الخاصة بك. يشبه مسح ذاكرة التخزين المؤقت للمتصفح ، باستثناء أنك تقوم بمسح ذاكرة التخزين المؤقت لنظام أسماء النطاقات من نظام التشغيل.
إذا كنت تستخدم Windows ، فيمكنك مسح ذاكرة التخزين المؤقت لـ DNS عن طريق فتح موجه الأوامر وإدخال التوجيه التالي:
ipconfig /flushdns

يجب أن ترى رسالة "تم مسح ذاكرة التخزين المؤقت لمحلل DNS بنجاح". رسالة إذا نجحت.
لأحدث إصدارات macOS ، يمكنك فتح Terminal وتشغيل الأمر التالي:
sudo killall -HUP mDNSResponder
لن ترى أي إشعار في macOS عند انتهاء العملية ، ولكن يمكنك تغيير ذلك عن طريق إلحاق الأمر برسالتك المخصصة.
sudo killall -HUP mDNSResponder; DNS Cache was cleared successfully
إذا كنت تستخدم إصدارات أقدم من macOS ، فإن الأمر الذي تحتاج إلى إدخاله يختلف بناءً على إصدار macOS الذي تقوم بتشغيله. لمزيد من التفاصيل ، يمكنك الرجوع إلى قسم macOS في البرنامج التعليمي المتعمق لنظام أسماء النطاقات الخاص بـ Kinsta.
إذا كنت تستخدم نظام التشغيل Linux ، فإن العملية تشبه إلى حد كبير نظام macOS حتى أن Linux يستخدم Terminal كواجهة لسطر الأوامر. نظرًا لوجود العديد من توزيعات Linux ، فقد يختلف الأمر الدقيق الذي تحتاج إلى تشغيله من توزيعة إلى أخرى. يمكنك مراجعة دليل Kinsta لمزيد من المعلومات.
أخيرًا ، يمكنك تغيير خوادم DNS الخاصة بالعميل مؤقتًا. بشكل افتراضي ، يقوم موفر خدمة الإنترنت الخاص بك بتعيين خوادم DNS تلقائيًا لك. ولكن يمكنك تغييرها إلى عناوين IP لنظام أسماء النطاقات العامة مؤقتًا.
بعض خوادم DNS الموثوقة التي يمكنك تجربتها هي Google Public DNS و Cloudflare 1.1.1.1 و Quad9 DNS و Cisco OpenDNS.

قم بتعطيل CDN الخاص بموقعك مؤقتًا
في بعض الأحيان ، قد تكون المشكلة أيضًا في شبكة توصيل المحتوى (CDN). إذا لم يكن من الممكن الوصول إلى خادم أصل الموقع ، فستحاول معظم شبكات CDN خدمة صفحة الويب الكاملة من ذاكرة التخزين المؤقت الخاصة بها.
لكن معظم شبكات CDN لا تقوم بتمكين هذه الميزة افتراضيًا نظرًا لأنه من المعقد تخزين الأصول الديناميكية مؤقتًا في معظم المواقع (مثل لوحة تحكم مسؤول WordPress).

هناك طريقة مباشرة لتحرّي الخلل وإصلاحه وهي تعطيل CDN مؤقتًا. على سبيل المثال ، إذا كنت تستخدم البرنامج الإضافي المجاني CDN Enabler WordPress لربط أصول موقعك بعناوين URL لـ CDN ، فيمكنك إلغاء تنشيط المكون الإضافي واختبار إعادة تحميل موقعك.
ينطبق الأمر نفسه على استخدام أي مكون إضافي آخر قد تستخدمه للاتصال بـ CDN الخاص بك (مثل WP Rocket و Breeze و W3 Total Cache).
إذا لم تتمكن من الوصول إلى لوحة تحكم المسؤول في موقعك ، فيمكنك تعطيل المكون الإضافي عبر SFTP عن طريق إعادة تسمية اسم مجلد المكون الإضافي.

تحتوي شبكات CDN مثل Cloudflare أو Sucuri ، التي توفر خدمات بروكسي كاملة ، على جدران حماية إضافية بين خوادم الحافة وخادمك الأصلي. وبالتالي ، قد تواجه أخطاء HTTP 5xx بشكل متكرر أثناء استخدامها. يتم تخزين معظم أخطاء 5xx في ذاكرة التخزين المؤقت التي يتم إرجاعها بواسطة خادمك الأصلي ، لذلك من السهل استكشافها وإصلاحها.
تميل خطة Cloudflare المجانية إلى ظهور خطأ 5xx. لسوء الحظ ، نظرًا لأنها خدمة وكيل كاملة ، فلا توجد طريقة سريعة لتعطيلها. ولكن قبل أن تلوم Cloudflare على ذلك ، اعلم أن Cloudflare يظهر شكلين مختلفين لخطأ 504 Gateway Timeout.
504 Gateway Timeout at Cloudflare (البديل 1)
سيُظهر لك Cloudflare شاشة خطأ 504 Gateway Timeout مخصصة عندما يستجيب الخادم الأصلي لموقعك باستجابة HTTP 504 قياسية.

هنا ، تكمن المشكلة في خادم الويب الخاص بك وليس في Cloudflare. يمكنك محاولة إصلاحه بالحلول الأخرى المذكورة أدناه أو الاتصال بدعم مزود الاستضافة للحصول على المساعدة الفنية.
504 Gateway Timeout at Cloudflare (البديل 2)
إذا تسبب Cloudflare في الخطأ 504 Gateway Timeout ، فستذكر شاشة الخطأ "cloudflare" ، وهو اسم الخادم القياسي حاليًا لجميع أصول Cloudflare. عادةً ما تظهر شاشة الخطأ على النحو التالي:

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

504 Gateway Timeout at Cloudflare بسبب التحميلات الكبيرة
يمكن أن يكون حجم التحميلات إلى موقعك سببًا أيضًا لانتهاء مهلة الخادم. تحد Cloudflare حجم ملف التحميل (لكل طلب HTTP POST) إلى 100 ميجابايت فقط في كل من الخطط المجانية والخطط الاحترافية.

يمكن أن تكون المشكلة في نهاية مضيفك أو مع Cloudflare. يمكنك معرفة السبب الدقيق عن طريق تجاوز Cloudflare بملف مضيفي DNS الخاص بك ومحاولة التحميل مرة أخرى.
إذا كنت تستخدم Cloudflare مع WordPress ، فإنني أوصي باستخدام المكون الإضافي المجاني واستبعاد عناوين URL الهامة من التخزين المؤقت (مثل لوحة تحكم مسؤول WordPress). يمكنك الرجوع إلى منشور Kinsta المفصل حول كيفية تكوين إعدادات Cloudflare لـ WordPress.
قراءة مقترحة: كيفية إعداد Cloudflare APO لـ WordPress.
مشاكل الخادم (تحقق مع مضيفك)
تعد مشكلات الخادم أحد الأسباب الأكثر شيوعًا لمواجهة خطأ 504 Gateway Timeout. نظرًا لأن معظم مواقع WordPress مستضافة على خوادم الويب Nginx أو Apache ، فإن Nginx أو Apache ينتظران ردًا من شيء ما وينتهي المهلة.
يأتي العديد من العملاء إلى Kinsta بسبب هذه المشكلة بالضبط التي يواجهونها في مضيفي WordPress الآخرين. تجري المحادثة على النحو التالي:
نستقبل حوالي 100 ألف زائر شهريًا بأكثر من 200 ألف مشاهدة. حاليًا ، نحن نستضيف ____ ونواجه 504 أخطاء باستمرار بسبب التحميل الزائد على الخادم. لا أحب الطريقة التي تعاملت بها ____ مع المشكلة ، وقد تم إخطارنا أيضًا بأنه سيتعين علينا الانتقال إلى خططهم المخصصة قريبًا ، والتي أعتقد أنها ليست ضرورية.
تعد مواقع التجارة الإلكترونية وحركة المرور العالية أكثر عرضة للحصول على أخطاء 504 بسبب الحمل الزائد للخادم لأنها تولد العديد من الطلبات غير القابلة للتخزين. ومع ذلك ، يمكن قص هذه المشكلة مع أي موقع ، بما في ذلك المدونات البسيطة. سيطلب منك العديد من المضيفين الترقية إلى خطة عالية المستوى لإصلاح المشكلة ، وهو أمر غير ضروري في معظم الحالات.
تستخدم Kinsta مضيفات LXD المُدارة وحاويات برامج LXC مُنسقة لكل موقع. وبالتالي ، يتم وضع كل موقع WordPress في حاوية منعزلة خاصة به مع إمكانية الوصول إلى جميع البرامج المطلوبة لتشغيله (Linux و Nginx و PHP و MySQL). الموارد خاصة بنسبة 100٪ ولا تتم مشاركتها مع أي موقع آخر ، حتى مواقعك.
معظم مضيفي WordPress الذين يقدمون خطط الاستضافة المشتركة ليس لديهم هذه الإمكانية. ومن ثم ، فإن موقعًا ذا حركة مرور عالية مستضاف على نفس الخادم مثل موقعك قد يتسبب في ظهور خطأ 504 في موقعك أيضًا.
بصرف النظر عن عزل كل موقع في حاويته ، صممت Kinsta أيضًا بنيتها التحتية للتعامل مع آلاف الاتصالات المتزامنة بسهولة. حتى أن Kinsta تستضيف قواعد بيانات MySQL على مضيف محلي ، وليس خادمًا بعيدًا. هذا يعني عدم وجود زمن انتقال بين الأجهزة ، مما يؤدي إلى استعلامات أسرع وفرص أقل لحدوث المهلات.
يلاحظ العديد من العملاء الذين يهاجرون إلى Kinsta انخفاضًا كبيرًا في أوقات التحميل الإجمالية.

لا يعد الخادم المحمّل السبب الوحيد لانتهاء مهلة الخادم. يمكن أن يكون هناك العديد من الأسباب الأخرى للخطأ 504:
البنية التحتية للخادم البطيئة
قد لا يحتوي الخادم الذي تستخدمه لاستضافة موقع WordPress الخاص بك على موارد كافية للتعامل مع التحميل. إنه يشبه لعب لعبة فيديو حديثة كثيفة الرسومات على جهاز كمبيوتر عمره عقد من الزمن.
توقف الخادم فقط أثناء محاولته خدمة الموقع. الحل الوحيد لهذه المشكلة هو الترقية إلى خادم ببنية تحتية أفضل. لهذا السبب ، حتى خطة استضافة WordPress الأساسية في Kinsta ستتعامل مع موقع ثابت بحركة مرور متوسطة.
يحتاج إلى المزيد من العاملين في PHP
يتم استخدام عمال PHP لتنفيذ كود موقع WordPress الخاص بك. يحتاج موقع التجارة الإلكترونية الذي يستقبل 50000 زائر شهريًا إلى موارد أكثر بكثير من مدونة بسيطة بنفس القدر من حركة المرور. إذا كان جميع العاملين في PHP بالخادم مشغولين ، فسيقومون بإنشاء قائمة انتظار.
عندما تصبح قائمة الانتظار كبيرة جدًا ، يتجاهل الخادم الطلبات القديمة ، مما قد يتسبب في قيام الخادم بإلقاء خطأ 504 في البوابة. يمكنك أن تطلب من مضيفك زيادة عدد العاملين في PHP. سيسمح هذا لموقعك بتنفيذ طلبات متعددة في وقت واحد.
مشاكل جدار الحماية
قد يحتوي جدار حماية الخادم الخاص بك على بعض الأخطاء أو تكوين غير صحيح. ربما ، تمنع بعض قواعده الخادم من إنشاء اتصال بشكل صحيح. لمعرفة ما إذا كان جدار الحماية الخاص بك هو الجاني ، يمكنك التحقق من سجلات أخطاء الخادم.
مشاكل الاتصال بالشبكة
قد تتسبب مشكلات الاتصال بين الخادم الوكيل وخادم الويب في حدوث تأخيرات في الاستجابة لطلبات HTTP. إذا كنت تستخدم موازن تحميل ، فقد تكون هناك أيضًا مشكلات في الاتصال بالشبكة معه.
مهلة HTTP
يمكن أن تحدث مهلات HTTP عندما يظل الاتصال بين خادم الويب والعميل مفتوحًا لفترة طويلة. مع مواقع WordPress ، يحدث هذا عادةً عند تشغيل واردات WordPress. تتمثل إحدى طرق حل هذه المشكلة في التبديل إلى اتصال إنترنت أسرع.
يمكنك أيضًا استخدام أداة تدعم WP-CLI لتشغيل البرامج النصية مباشرة على الخادم ، متجاوزًا اتصال HTTP تمامًا. على سبيل المثال ، يمكنك استخدام الأمر wp import WP-CLI لتشغيل المكون الإضافي WordPress Importer مباشرة من خلال واجهة سطر الأوامر.
هام: تبدو أخطاء 504 Gateway Timeout مشابهة لأخطاء 503 Service Unavailable أو 502 Bad Gateway. لكنهم جميعًا مختلفون. إذا كنت تواجه خطأ 504 في Kinsta ، فافتح تذكرة دعم لإصلاح مشكلتك على الفور.
لمراقبة وقت تعطل موقعك بنفسك ، يمكنك استخدام أداة مثل updown.io. سيتحقق من حالة موقع الويب الخاص بك (أو أي عنوان URL) بشكل دوري عن طريق إرسال طلب HTTP إليه. يمكنك ضبط تردد الفحص من 15 ثانية إلى ساعة واحدة. إذا كان موقع الويب الخاص بك لا يستجيب بشكل صحيح ، فسيعلمك برسالة بريد إلكتروني أو رسالة نصية قصيرة.

ستحصل على كمية كبيرة من الائتمانات المجانية مع كل حساب من حسابات updown.io ، ولكن إذا كنت تبحث عن بدائل أرخص ، يمكنك التحقق من WebGazer أو UptimeRobot. ستساعدك هاتان الأداتان على مراقبة وقت تشغيل موقعك كل 5 دقائق مجانًا. هذا لائق بما يكفي لمعظم مالكي مواقع الويب.

ستمنحك مراقبة موقع الويب الخاص بك فكرة عن عدد مرات تعطله. هذا مفيد بشكل خاص إذا كنت تستخدم موفر استضافة مشترك. يعتني معظم مضيفي WordPress المُدارين بهذا الأمر تلقائيًا نيابة عنك. ومن ثم يوصى دائمًا بالذهاب معهم.
للحصول على شرح مفصل ، تحقق من منشور Kinsta حول أهمية استضافة WordPress المُدارة.
هجمات البريد العشوائي أو الروبوتات أو هجمات DDoS
يمكن للمهاجمين الخبثاء إحضار خادم الويب الخاص بك إلى عملية الزحف عن طريق إرسال عدد كبير جدًا و / أو طلبات كثيفة الاستخدام للموارد. إذا كان موقعك يتلقى رسائل غير مرغوب فيها من قبل الروبوتات أو يتعرض لهجوم DDoS ، فيمكن أن يربك خادمك وينتج عنه أخطاء 504 Gateway Timeout للعديد من المستخدمين الحقيقيين.
يمكنك إلقاء نظرة على حركة مرور الخادم والتحليلات لمعرفة ما إذا كان يمكنك اكتشاف أي أنماط غير منتظمة في حركة مرور الموقع. إذا كنت تستخدم Kinsta لاستضافة موقعك ، فيمكنك عرض هذه البيانات بسهولة بالانتقال إلى لوحة معلومات MyKinsta Analytics.

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

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

أخيرًا ، يمكنك استخدام مكون إضافي للأمان في WordPress لتعزيز أمان موقع الويب الخاص بك عن طريق اكتشاف وحظر حركة المرور / عناوين IP المقلقة. يمكنك أن تطلب من مضيفك حظر بعض عناوين IP أيضًا.
هل تعاني من مشاكل التوقف و WordPress؟ Kinsta هو حل الاستضافة المصمم مع وضع الأداء والأمان في الاعتبار! تحقق من خططنا
اعتمادًا على طول الهجوم وحجمه ، قد تكون هذه عملية لا تنتهي أبدًا لإدراج عناوين IP في القائمة السوداء حيث يقوم العديد من المهاجمين بتغيير عناوين IP وعناوين الوكيل الخاصة بهم بعد حظرهم.
ملاحظة: لا تسمح Kinsta لعملائها بتثبيت إضافات أمان WordPress حيث يمكن أن يكون لها تأثير كبير على أداء الموقع ، وخاصة إمكانيات المسح. نظرًا لأن Kinsta يستخدم موازنات التحميل مع Google Cloud Platform ، فلن يعمل حظر عناوين IP دائمًا على النحو المنشود.
يمكنك استخدام حلول الأمان المخصصة مثل Cloudflare أو Sucuri لحماية مواقعك من هجمات DDoS و spambots. لمزيد من المعلومات ، يمكنك الاطلاع على مقالات Kinsta حول كيفية تثبيت Cloudflare على موقع WordPress الخاص بك وكيف ساعدت Sucuri في إيقاف هجوم DDoS في مساراته.
قاعدة بيانات WordPress تالفة
في بعض الأحيان ، يمكن أن يكون الخطأ 504 Gateway Timeout بسبب وجود قاعدة بيانات فاسدة ، خاصة في مواقع WordPress. عادةً ما يكون هذا بسبب جداول أو ملفات قاعدة البيانات التالفة. في بعض الأحيان ، قد يكون سبب ذلك أيضًا مشكلة أمنية خطيرة مثل اختراق موقعك أو قاعدة بياناتك.
يعتمد إصلاح قاعدة بيانات WordPress التالفة على المشكلة. تعمل المكونات الإضافية مثل WP-DBManager على تسهيل تشخيص مشكلات قاعدة البيانات وإصلاحها. أوصيك بقراءة الإرشادات التفصيلية الخاصة بـ Kinsta حول إصلاح مشكلات قاعدة بيانات WordPress للبدء.
تحقق من المكونات الإضافية والسمات الخاصة بموقعك
في معظم الحالات ، لا تتسبب المكونات الإضافية والسمات التابعة لجهات خارجية في أخطاء 504. ولكن هناك احتمال ضئيل في أنها قد تتسبب في انقضاء مهلة الخادم ، عادةً عن طريق ترتيب العديد من الطلبات غير المخزنة في قائمة الانتظار التي تم إنشاؤها بواسطة المكون الإضافي / السمة. نظرًا لأن هذا يربط الكثير من العاملين في PHP على الخادم الخاص بك ، فقد يتسبب في أخطاء 504.
مثال رائع على هذه المشكلة هو WooCommerce ، وهو مكون إضافي مثبت لإضافة وظائف التجارة الإلكترونية إلى مواقع WordPress.
إن أبسط طريقة يمكنك من خلالها استكشاف هذه المشكلة وإصلاحها هي إلغاء تنشيط جميع المكونات الإضافية الخاصة بك. تذكر أنك لن تفقد أي بيانات إذا قمت فقط بإلغاء تنشيط مكون إضافي.
إذا كان بإمكانك الوصول إلى لوحة تحكم المسؤول ، فيمكنك الانتقال إلى شاشة المكونات الإضافية ، وتحديد إلغاء التنشيط من قائمة الإجراءات المجمعة ، وتحديد جميع المكونات الإضافية ، ثم الضغط على زر تطبيق . سيؤدي هذا إلى تعطيل جميع المكونات الإضافية الخاصة بك.

إذا لم تتمكن من الوصول إلى منطقة المسؤول الخاصة بك ، فيمكنك تعطيل المكونات الإضافية عبر SFTP باستخدام الطريقة الموضحة من قبل. ما عليك سوى إعادة تسمية اسم مجلد المكون الإضافي الرئيسي لتعطيل جميع المكونات الإضافية بشكل مجمّع.
بمجرد إلغاء تنشيط جميع المكونات الإضافية ، تحقق مما إذا كان يتم تحميل موقعك بشكل صحيح. إذا كان يعمل ، يجب عليك تنشيط كل مكون إضافي ، واختبار الموقع بعد تمكين كل مكون إضافي.
أخيرًا ، تأكد من تحديث الإضافات والسمات ونواة WordPress الخاصة بك. تأكد أيضًا من أن خادمك يقوم بتشغيل الإصدار الموصى به من PHP.
إذا شعرت أن هذا أمر مربك للغاية ، فيمكنك دائمًا التواصل مع مضيفك للحصول على المساعدة. يستخدم Kinsta Kinsta APM وتقنيات استكشاف الأخطاء وإصلاحها الأخرى لمساعدة العملاء على تضييق نطاق البرنامج المساعد أو الاستعلام أو البرنامج النصي الذي قد يتسبب في حدوث الخطأ.
في أسوأ السيناريوهات ، مثل استعلام غير فعال أو رمز تالف في مكون إضافي / سمة ، يمكنك إحضار مطور WordPress لإصلاح المشكلة.
تحقق من سجلات الأخطاء
يمكن أن يكون عرض سجلات الأخطاء مفيدًا جدًا عند استكشاف أخطاء 504 وإصلاحها على موقع WordPress الخاص بك. يمكن أن يساعدك هذا في تضييق نطاق مشكلة على موقعك بسرعة ، خاصةً إذا كانت ناتجة عن مكون إضافي متطلب على موقعك.
إذا كنت أحد عملاء Kinsta ، فيمكنك بسهولة رؤية الأخطاء في عارض السجل في لوحة معلومات MyKinsta.

إذا لم يكن لدى مضيفك أداة تسجيل ، فيمكنك تمكين وضع تصحيح أخطاء WordPress عن طريق إضافة الكود التالي إلى ملف wp-config.php الخاص بك:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
يعمل ثابت WP_DEBUG على تمكين أو تعطيل وضع تصحيح أخطاء WordPress. يحتوي على ثابتين مصاحبتين اختياريتين يمكنهما توسيع ميزاته. يوجه ثابت WP_DEBUG_LOG
جميع الأخطاء ليتم حفظها في ملف debug.log داخل الدليل /wp-content/
. إذا كنت لا ترى هذا الملف ، فيمكنك دائمًا إنشاء واحد.
يتحكم ثابت WP_DEBUG_DISPLAY
في ظهور سجلات تصحيح الأخطاء على صفحة HTML. سيؤدي ضبط هذا على "خطأ" إلى إخفاء جميع الأخطاء ، ولكن يمكنك مراجعة الأخطاء لاحقًا ، حيث قمت أيضًا بتعريف WP_DEBUG_LOG
على أنه "صحيح".
هام: إذا قمت بتمكين WP_DEBUG في بيئة Kinsta ، فسيقوم بتوجيه جميع الأخطاء إلى ملف debug.log وليس إلى error.log في لوحة معلومات MyKinsta.
يمكنك أيضًا تنزيل ملفات سجل أخطاء WordPress الأولية عبر SFTP. عادةً ، يمكنك العثور على سجلات الأخطاء في الدليل الجذر لخادمك في مجلد باسم "السجلات".

يمكن لمستخدمي Kinsta أيضًا تمكين وضع تصحيح أخطاء WordPress من لوحة معلومات MyKinsta الخاصة بهم. للقيام بذلك ، انتقل إلى مواقع> أدوات> تصحيح أخطاء WordPress وانقر فوق الزر تمكين . سيسمح لك ذلك بمشاهدة أخطاء PHP والإشعارات دون تمكين وضع التصحيح عبر SSH أو SFTP.
أخيرًا ، يمكنك التحقق من ملفات سجل الخادم. اعتمادًا على الخادم الذي تستخدمه لاستضافة موقع WordPress الخاص بك ، يتم العثور عليها بشكل شائع في هذه المواقع:
- اباتشي:
/var/log/apache2/error.log/
- Nginx:
/var/log/nginx/error.log/
يمكنك الرجوع إلى تسجيل الوثائق ذات الصلة لـ Apache أو Nginx لمزيد من المعلومات.
تكوين إعدادات Apache أو Nginx بشكل صحيح
يمكنك تحرير ملفات تهيئة الخادم لزيادة حدود الموارد لتوجيهات معينة. يمكن أن يساعدك هذا في حل الخطأ 504 Gateway Timeout.
لخوادم الويب اباتشي
أولاً ، أضف الكود التالي إلى httpd.conf الخاص بك:
TimeOut 600
يحدد هذا الإعداد المدة التي سينتظرها الخادم لطلبات معينة قبل وضع علامة عليها كمشكلة لانتهاء مهلة الشبكة. قيمته الافتراضية هي 60 ثانية (إصدار Apache 2.4).
يمكنك فقط إضافة هذا التوجيه في ملف httpd.conf الخاص بك ، وليس في ملف .htaccess الخاص بك. نظرًا لأن معظم موفري الاستضافة المشتركة لا يسمحون لك بتعديل ملف httpd.conf ، يمكنك محاولة زيادة قيمة التوجيه LimitRequestBody في ملف htaccess الخاص بك بدلاً من ذلك.
ثم أضف السطر التالي إلى ملف php.ini الخاص بك:
max_execution_time 300
القيمة الافتراضية لتوجيه max_execution_time في PHP هي 30 ثانية. ستسمح زيادته بتشغيل نصوص PHP النصية لموقعك لفترة أطول.
لخوادم الويب Nginx
إذا كنت تقوم بتشغيل مواقع WordPress الخاصة بك على Nginx + FastCGI Process Manager (PHP-FPM) أو تستخدم Nginx كوكيل عكسي لـ Apache ، فيمكنك تعديل إعدادات الخادم للمساعدة في منع أخطاء 504 Gateway Timeout.
504 خطأ في مهلة البوابة على Nginx + FastCGI (PHP-FPM)
أولاً ، يجب عليك تحرير ملف تكوين تجمع PHP-FPM. يمكنك العثور عليه في الموقع /etc/php7.4/fpm/pool.d/www.conf
في خادم Nginx (قد يختلف المسار الدقيق بناءً على إصدار PHP). بالتناوب ، يمكنك تشغيل الأمر التالي في جهازك لتعديل ملف تكوين تجمع PHP-FPM:
sudo nano /etc/php/7.2/fpm/pool.d/www.conf
بعد ذلك ، قم بتعيين التوجيه التالي:
request_terminate_timeout = 300
بعد ذلك ، يجب عليك تحرير ملف php.ini الخاص بك. يمكنك تحديد موقعه على /etc/php.ini
. افتح الملف وقم بإضافة / تغيير القيمة لتوجيه max_execution_time
إلى 300 ثانية.
max_execution_time = 300
أخيرًا ، أضف الكود التالي إلى كتلة موقع ملف nginx.conf :
location ~ .php$ { ... fastcgi_read_timeout 300; }
أعد تحميل Nginx و PHP-FPM لتصبح التغييرات سارية المفعول.
sudo service nginx reload sudo service php7.4-fpm reload
سيختلف الرمز الدقيق لإعادة تحميل PHP-FPM بناءً على إصدار PHP المثبت على خادمك. اختبر موقعك لمعرفة ما إذا كان قد أصلح المشكلة.
504 خطأ في مهلة البوابة على وكيل Nginx
إذا كنت تستخدم Nginx كخادم وكيل عكسي لـ Apache ، فيمكنك جعله أكثر تساهلاً تجاه مهلات الخادم عن طريق إضافة التوجيهات التالية إلى ملف nginx.conf الخاص بك:
proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600;
لا تنس إعادة تحميل Nginx بعد إجراء التغييرات.
sudo service nginx reload
أخطاء HTTP الأخرى مثل 504 Gateway Timeout
كما ذكرنا سابقًا في المقالة ، فإن العديد من أخطاء HTTP 5xx الأخرى تشبه خطأ 504 Gateway Timeout. ذلك لأنهم جميعًا يحدثون على جانب الخادم. تشمل هذه الأخطاء:
- 500 خطأ خادم داخلي
- 501 لم يتم تنفيذ خطأ
- 502 خطأ في بوابة غير صالحة
- 503 خطأ غير متوفر في الخدمة
أخطاء HTTP الأخرى الناتجة عن مشكلات من جانب العميل ، مثل خطأ 404 غير موجود ، تشبه أيضًا الخطأ 504. يمكنك الرجوع إلى دليل Kinsta التفصيلي وقائمة رموز حالة HTTP لمزيد من المعلومات.
للتغريدملخص
يمكن أن يتأثر موقع WordPress الخاص بك بخطأ 504 Gateway Timeout لأسباب متعددة. في هذه المقالة ، تعلمت كيفية تحرّي الخلل وإصلاحه جميعًا. عادةً ما تحدث هذه الأخطاء بسبب مشكلات من جانب الخادم ، وفي هذه الحالة يمكنك الوصول إلى مضيفك وحلها بسرعة.
ومع ذلك ، يجب أن تفهم أيضًا أن هذا الخطأ يمكن أن يكون بسبب المكونات الإضافية أو السمات أو الخدمات أو استعلامات قاعدة البيانات غير الفعالة أو مزيج من اثنين أو أكثر من هذه. إذا كنت تستفيد من موارد الخادم الخاص بك (مثل عمال PHP) ، فمن المستحسن تحسين أداء موقعك.
إذا كنت لا تزال تجد أن موقع الويب الخاص بك قد انتهى ، فربما تحتاج إلى ترقية خطة الاستضافة الخاصة بك أو عدد العاملين في PHP. أوصيك بالنظر في هذا الخيار فقط بعد استنفاد جميع الحلول الأخرى الموضحة في هذه المقالة.
From simple static sites to complex ecommerce and membership sites, Kinsta's scalable hosting plans are designed to accommodate all types of websites. To learn more about our scalable cloud hosting, check out this article!
Did we miss anything? If you're still finding it difficult to fix the 504 Gateway Timeout error on your WordPress site, leave a comment below.