HTTP 504

خطأ HTTP 504 Gateway Timeout: ماذا يعني وكيف تصلحه

الخطأ 504 يعني أن الـ proxy انتظر ولم يحصل على شيء فاستسلم. والسؤال الحقيقي دائمًا: ما الذي جعل الخادم الخلفي بهذا البطء؟

ماذا يعني خطأ HTTP 504 فعليًا

خطأ HTTP 504 Gateway Timeout يعني أن بوابة أو وكيلًا — nginx أو موزّع حمل أو CDN — مرّر الطلب إلى خادم خلفي ولم يستلم استجابة ضمن مهلته المضبوطة. ومثل 502، صفحة 504 يولّدها الوسيط لا تطبيقك. لكن على عكس 502، لم يعد شيء مكسورًا — لم يعد أي شيء في الوقت المحدّد أصلًا.

وثمة دقيقة مهمة: قد يكون الخادم الخلفي ما زال يعالج الطلب بعد أن استسلم الـ proxy. يرى المستخدم 504، وينهي التطبيق العمل بعدها بثوانٍ، وقد تكون الآثار الجانبية — دفعة مالية، بريد، كتابة في قاعدة البيانات — حدثت رغم ذلك. لهذا تستحق أخطاء 504 على النقاط غير المتكرّرة الأثر حذرًا إضافيًا، ولهذا يكون الإصلاح عادة تسريع العمل أو جعله غير متزامن، لا مجرّد رفع المهلة.

الأسباب الجذرية الشائعة لخطأ 504

عمل خلفي بطيء فعلًا

استعلام قاعدة بيانات بطيء، أو فهرس مفقود، أو نمط استعلامات N+1، أو نداء طويل لواجهة خارجية يدفع زمن الاستجابة فوق حد الـ proxy. الوكيل يتصرّف بشكل صحيح؛ التطبيق هو الطرف البطيء.

مهلة الـ proxy أقصر من العمل المشروع

بعض النقاط تستغرق وقتًا طويلًا بطبيعتها — تقارير، تصدير، رفع ملفات كبيرة — لكن مهلة قراءة الـ proxy (مثل proxy_read_timeout في nginx وافتراضيها 60 ثانية) أو مهلة الخمول في موزّع الحمل أقصر منها. وهذا التعارض يحوّل ميزة سليمة إلى 504.

تشبّع العمال — طلبات تنتظر ولا تُلتقط

كل عمال التطبيق أو خيوطه مشغولون (غالبًا محتجزون بنداءات خارجية بطيئة)، فتجلس الطلبات الجديدة في طابور حتى تنقضي مهلة الـ proxy. النقطة ليست بطيئة بذاتها — الخدمة فقط لا تملك يدًا فارغة.

مشاكل شبكية بين الـ proxy والخادم الخلفي

فقدان حزم، أو شبكة overlay مضطربة، أو تغييرات في مجموعات الأمان، أو DNS يشير إلى عنوان غير قابل للوصول — كلها تجعل محاولات اتصال الـ proxy تعلّق حتى المهلة. أقل شيوعًا من بطء التطبيقات، لكنه ينتج الأعراض نفسها.

كيف تحقّق في خطأ 504 وتصلحه

حدّد أي قفزة تجاوزت مهلتها، وقِس كم يستغرق الخادم الخلفي فعلًا، ثم قرّر هل تسرّع العمل أم تنقله خارج مسار الطلب أم تعدّل سلسلة المهلات عمدًا.

  1. 1

    حدّد أي طبقة تجاوزت مهلتها

    يمر الطلب غالبًا عبر CDN ثم موزّع حمل ثم nginx ثم التطبيق. ولكل قفزة مهلتها، وهوية صفحة 504 وترويساتها تكشف من استسلم أولًا. ومعرفة الطبقة تخبرك أي قيمة مهلة وأي سجل تقرأ.

  2. 2

    قِس زمن استجابة الخادم الخلفي الحقيقي

    استخدم سجلات الوصول (مثل $upstream_response_time في nginx) أو بيانات مراقبة الأداء أو التتبّع لمعرفة كم تستغرق النقطة المتأثرة فعلًا. إن كانت تقترب من المهلة باستمرار فقد وجدت المشكلة؛ وإن كانت سريعة عادة فابحث عن التشبّع أو الشبكة.

  3. 3

    اعثر على الاعتماد البطيء

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

  4. 4

    افحص تشبّع العمال والمجمّعات

    راجع استخدام مجمّعات العمال أو الخيوط، وعمق طابور الطلبات، وانتظار مجمّع اتصالات قاعدة البيانات. إذا كانت الطوابير عميقة فالإصلاح هو تحرير العمال (مهلات على النداءات الخارجية)، أو زيادة السعة، أو تخفيف الحمل — لا لمس النقطة التي صادف أن مهلتها انقضت.

  5. 5

    راجع سلسلة المهلات

    اسرد كل مهلة على المسار — مهلة أصل الـ CDN، ومهلة خمول الموزّع، وproxy_read_timeout، ومهلة عامل التطبيق — واجعلها مقصودة: كل طبقة خارجية أطول قليلًا من الداخلية، حتى تنتج الأعطال أخطاء واضحة في الطبقة الصحيحة بدل سباقات غامضة.

  6. 6

    اربط الخطأ بالنشر والمرور

    أخطاء 504 التي تبدأ بعد نشر تشير إلى استعلام بطيء جديد أو فهرس أُزيل؛ والتي تتبع ذروات المرور تشير إلى السعة. أما العمل الطويل بطبيعته فانقله خارج مسار الطلب بطابور مهام وأعد 202 مع نقطة حالة بدل حجز الاتصال.

كيف تمنع أخطاء 504

  • راقب مئينات زمن الاستجابة (p95/p99) لكل نقطة ونبّه عند اقترابها من مهلة الـ proxy — فالخطأ 504 ليس إلا زمن استجابة تجاوز الخط.
  • ضع مهلات صريحة على كل نداء خارجي حتى لا يحتجز اعتماد بطيء واحد العمال ويجوّع الخدمة كلها.
  • انقل الأعمال الطويلة — التقارير والتصدير والعمليات الكبيرة — إلى مهام خلفية بدل إبقاء اتصالات HTTP مفتوحة.
  • تابع سجلات الاستعلامات البطيئة في قاعدة البيانات وأضف الفهارس قبل أن يدفع نموّ البيانات استعلامًا فوق المهلة.
  • وثّق سلسلة المهلات كاملة وراجعها عند إضافة أي طبقة جديدة (CDN أو mesh أو بوابة) حتى تبقى القيم متّسقة.

كيف يساعدك AllStak مع أخطاء 504

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

وتكشف مقاييس البنية التحتية جانب التشبّع — المعالج والذاكرة والحمل على خوادم التطبيق وقاعدة البيانات — بينما تحتفظ السجلات المركزية بأسطر الاستعلامات البطيئة ورسائل مهلة الـ proxy من الدقائق نفسها. ومع علامات النشر على الخط الزمني ذاته، يستغرق التمييز بين «استعلام بطيء جديد» و«مرور تجاوز السعة» دقائق بدل اجتماعات.

أسئلة شائعة عن HTTP 504

ما الفرق بين 504 و502؟

كلاهما يولّده الـ proxy، لكن 502 يعني أن الخادم الخلفي استجاب بشكل سيئ — رفض الاتصال أو أغلقه مبكرًا أو أرسل ردًا مشوّهًا — بينما 504 يعني أنه لم يستجب أصلًا ضمن المهلة. الأول يشير إلى تطبيق ميت أو منهار؛ والثاني إلى تطبيق بطيء أو متعذّر الوصول.

هل يستمر تنفيذ الطلب بعد 504؟

غالبًا نعم. الـ proxy ملّ الانتظار، لكن الخادم الخلفي يواصل المعالجة عادة ما لم يكتشف الاتصال المغلق ويتوقّف. أي أن الكتابات أو المدفوعات أو الرسائل قد تكتمل رغم أن العميل رأى خطأ — لذا صمّم النقاط غير المتكرّرة الأثر بمفاتيح idempotency حتى تكون إعادة المحاولة آمنة.

هل أرفع مهلة الـ proxy وحسب؟

فقط عندما يكون العمل طويلًا بحق وقرّرت قبوله على مسار الطلب. رفع المهلات لإخفاء استعلامات بطيئة يستبدل خطأً واضحًا باتصالات محتجزة وطوابير أعمق وانهيارات متسلسلة أسوأ تحت الضغط. قِس أولًا؛ فالإصلاح الصحيح غالبًا عمل أسرع أو مهمة خلفية.

لماذا تنقضي مهلة عميلي قبل ظهور أي 504؟

لأن مهلة العميل نفسه أقصر من مهلة الـ proxy. فيستسلم المتصفح أو SDK أو تطبيق الجوال ويبلّغ عن خطأ شبكة بينما الـ proxy لا يزال ينتظر — فلا تُظهر سجلات الخادم شيئًا غريبًا. اجعل مهلات العميل أطول قليلًا من أبطأ قفزة، أو قصّر الميزانية على جهة الخادم.

استكشف المزيد

القدرات

حسب إطار العمل

قارن

شاهد زمن الاستجابة قبل أن يصبح 504

يتتبّع AllStak أزمنة استجابة نقاطك من الخارج والداخل، فيظهر الاستعلام البطيء خلف مهلتك القادمة على رسم بياني قبل أن يظهر كانقطاع.

ابدأ مجاناً عرض الأسعار