504 مهلة البوابة

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

ماذا يعني 504 فعلياً

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

تعيد البوابة 504 Gateway Timeout عندما تنتظر استجابة المصدر ولا تتلقاها في الوقت المحدد. قد يكون المصدر يعالج استعلام قاعدة بيانات ببطء، أو ينتظر API تابعاً لجهة خارجية، أو مثقلاً ببساطة؛ لكن من وجهة نظر البوابة انتهت الساعة. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

الكلمة الأساسية هي مهلة. لم يكن هناك بالضرورة شيء «مكسور»؛ بل لم تصل الاستجابة بالسرعة الكافية.

كيف يختلف عن أشقائه 5xx

يخلط الناس بينها باستمرار:

• 502 Bad Gateway — حصلت البوابة على استجابة من المصدر، لكنها كانت غير صالحة أو مشوهة.
• 503 Service Unavailable — قال الخادم صراحةً «أنا غير متاح الآن» (غالباً عن قصد، مثل نافذة صيانة).
• 504 Gateway Timeout — لم تحصل البوابة على استجابة في الوقت المناسب من المصدر. وهذا ادعاء أضيق من «لم يعد شيء»؛ فقد يظل المصدر يعمل، لكنه لم يرد داخل نافذة الانتظار.

لذلك فإن 504 عَرَض أداء تقريباً دائماً: هناك شيء في الأعلى أبطأ مما ينبغي.

هل يضر 504 بـSEO؟

ليس مباشرةً، وهو ليس عقوبة. لا تقيم Google محتواك؛ بل لا تستطيع حرفياً جلب الصفحة. لكن هناك تكلفة غير مباشرة حقيقية:

• إذا واصل Googlebot مواجهة استجابات بطيئة ومهلات، يتراجع ويزحف إلى موقعك أقل حتى لا يزيد الحمل سوءاً.
• تعاد محاولة 504 واحدة أثناء ارتفاع المرور وغالباً تُتجاهل.
• أخطرها 504 التي تستمر أياماً؛ فهي قد تؤدي إلى إسقاط الصفحات من الفهرس لأن Google لا تستطيع جلبها بثبات. Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

ماذا تفعل حيال ذلك

• أعد التحميل مرة أو مرتين؛ فقد يكون 504 المنفرد عارضاً.
• افحص خادمك وسجلات الأخطاء لمعرفة ما الذي كان بطيئاً (استعلام قاعدة بيانات، API خارجي، أو عملية تطبيق مثقلة).
• لا ترفع قيمة المهلة فقط وتعتبر الأمر منتهياً؛ فهذا يخفي الاستجابة البطيئة بدلاً من إصلاحها (المزيد في علامة التبويب Advanced).
• أبق خادمك سريعاً: التخزين المؤقت، والاستعلامات الأسرع، والسعة الكافية هي الوقاية الحقيقية.

هل تريد النسخة التقنية الكاملة — من أين ينشأ 504 في سلسلة الطلب، وكيف يعمل خفض Googlebot للزحف، ولماذا يجب مراقبة TTFB؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — 504 هو بوابة/وكيل يخبرك بأن الخادم المصدر لم يرد داخل نافذة المهلة — مهلة تختلف عن 502 (استجابة سيئة) أو 503 (عدم توفر صريح). إنها مشكلة إتاحة وليست عقوبة. تقع المهلات في الفئة نفسها مع 429/500/503: يتراجع Googlebot عندما يراها، وتخاطر 504 المستمرة بإزالة الفهرسة. الإصلاح الدائم هو زمن استجابة الخادم (TTFB)، لا قيمة مهلة أطول؛ فرفع المهلة يخفي المصدر البطيء عادةً وقد يزيد الوضع سوءاً تحت الحمل.

أين ينشأ 504 في سلسلة الطلب

قد يبدو مسار الطلب الحديث هكذا: المتصفح → CDN/edge → موازن الحمل → الوكيل العكسي (مثل Nginx) → خادم التطبيق (PHP-FPM أو Node وغيرهما) → قاعدة البيانات / واجهات API الخارجية. ينشئ 504 المكوّن الذي كان ينتظر المكوّن الذي خلفه عند انتهاء مهلته. وهذا أول سؤال تشخيصي: Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• انتهاء مهلة CDN/edge أثناء انتظار المصدر → أصلح أداء المصدر، أو ارفع مهلة المصدر في CDN بحذر.
• انتهاء مهلة موازن الحمل أثناء انتظار خادم التطبيق → افحص صحة خادم التطبيق والتوسع التلقائي.
• انتهاء مهلة الوكيل العكسي أثناء انتظار عملية التطبيق → افحص proxy_read_timeout / fastcgi_read_timeout في Nginx والاستعلام أو العملية البطيئة التي تقف خلفها فعلياً.

يهم تحديد الطبقة الصحيحة، لأن «إصلاح المهلة عند الحافة» و«إصلاح استعلام قاعدة البيانات البطيء في المصدر» مهمتان مختلفتان تماماً.

ما الذي يسبب أخطاء المهلة

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

• استعلامات قاعدة بيانات أو استدعاءات API مصدر بطيئة. قد يدفع استعلام واحد بلا فهرس أو تبعية خارجية بطيئة زمن الاستجابة فوق المهلة.
• حمل زائد على الخادم/التطبيق واستنفاد الموارد. تحت الحمل المتزامن الكافي تصطف الطلبات، وتمتلئ عمليات العمال، وتتوقف الاستجابات عن الوصول في الوقت.
• قيم مهلة مضبوطة خطأً عبر Nginx أو Apache أو موازن الحمل أو CDN — غالباً لا تتطابق بين الطبقات فتستسلم واحدة قبل الأخرى.
• ارتفاعات مرور أو فيضانات روبوتات أو DDoS تطغى مؤقتاً على السعة.

غالباً ما تكون المهلة متقطعة وتعتمد على الحمل

هذا ما يجعلها مزعجة. بخلاف الانقطاع الصريح، يظهر 504 كثيراً تحت الحمل؛ فقد يعرض فحص توفر يرسل طلباً في فترة هادئة نتيجة خضراء 100% بينما يجمع Googlebot، أثناء دفعات زحف أثقل، مهلات بهدوء. وقد ترى ذلك في فحص عنوان URL في Google Search Console كحالة Hostload exceeded بدلاً من خطأ ثابت واضح. إذا قالت مراقبتك إن كل شيء سليم بينما تخالفها إحصاءات الزحف، فـ504 المعتمد على الحمل مشتبه رئيسي.

كيف يتعامل Googlebot (وBingbot) مع المهلات

Google لا تتعامل مع 504 على أنه حكم على جودة المحتوى؛ إنها إشارة إتاحة، والاستجابة هي خفض تلقائي للسرعة. وتقول وثائق الزحف صراحةً: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (ترجمة) «يخفض Googlebot الزحف إذا اكتشف أن خوادمك تواجه مشكلة في الرد على طلبات الزحف». ويقول دليل ميزانية الزحف للمواقع الكبيرة: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (ترجمة) «إذا تباطأ الموقع أو أعاد أخطاء خادم، ينخفض الحد وتزحف Google أقل». Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

يأتي أحدث تأطير مرتبط مباشرة بالاستجابات البطيئة والمهلات من شرح Inside Googlebot الذي نشرته Google في مارس 2026، حيث نُقل عن Gary Illyes قوله: “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (ترجمة) «تتراجع زواحفنا تلقائيًا لتجنب إثقال بنيتك التحتية، فينخفض تواتر الزحف». (نقلته تغطية Search Engine Land؛ تحقق من التسجيل أو النص الأصلي قبل نسب الاقتباس حرفيًا.) هذا التعثر هو ما تظهره 504 للمستخدم.

هناك دقة مهمة: لا ترى Google دائماً «504» حرفياً كما يراه متصفحك. إذا حدثت المهلة قبل حصول Googlebot على أي سطر حالة، تُسجل كـمهلة/خطأ شبكة في إحصاءات الزحف لا كـ5XX نظيف. أما إذا انتهت مهلة وكيل وسيط أو CDN وأنشأ استجابة 504 خاصة به، فيتلقى Googlebot خطأ خادم 5XX معيارياً. وفي الحالتين الأثر واحد: خفض معدل الزحف، ثم إزالة من الفهرس إذا استمرت المشكلة.

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

حلقة التغذية الراجعة: خفض ثم تعافٍ

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

المدة هي ما يحول العارض إلى مشكلة فهرسة

تُعاد محاولة 504 القصيرة العرضية — بضع حالات أثناء ارتفاع ثم تعافٍ سريع — وتتحملها Google إلى حد كبير. ما يهدد إزالة الفهرسة هو نمط مستمر من المهلات عبر نافذة طويلة. تصف آلية «عد لاحقاً» الموثقة لدى Google، حيث تعيد عمداً 503 أو 429 أثناء الحمل الزائد، أفقاً يقارب يومين قبل بدء إسقاط العناوين، لكن هذا الرقم موثق بالاسم لـ503/429 لا لـ504. وتقول إرشادات 5xx الأوسع إن معدل الزحف ينخفض بالتناسب مع عدد العناوين التي تعيد الخطأ ويتعافى تدريجياً بعد سلامة الاستجابات، من دون تحديد أفق ثابت لـ504. تمديد رقم اليومين إلى 504 استنتاج معقول لا حقيقة موثقة؛ تعامل معه هكذا: 504 القصيرة قابلة للتحمل، والنمط المستمر أياماً هو النطاق الذي يستحق القلق، لا تاريخ تشغيل مضمون.

لماذا يهم هذا أكثر في المواقع الكبيرة ومواقع التجارة الإلكترونية

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

زمن استجابة الخادم وTTFB رافعة وقائية قوية — لأسباب مصدرية

هذه نقطة تفوت معظم مقالات 504: انتظار ظهور الأخطاء ثم البحث في السجلات رد فعل. أما مراقبة زمن استجابة الخادم باستمرار لرؤية الانحراف قبل تحوله إلى مهلة فهي عمل استباقي. خادم بطيء لكنه لا ينتهي بعد اليوم قد يصبح خادماً يولد 504 غداً تحت حمل أعلى قليلاً أو تبعية أبطأ قليلاً. ومراقبة TTFB (time to first byte) كإشارة إنذار مبكر مستمرة — لا كقياس بعد الحادث فقط — هي طريقة التقاط الانحراف.

الملاحظة: تراقب TTFB البطء من جهة المصدر. ولن تلتقط CDN ينتهي من الانتظار رغم سلامة المصدر، أو موازن حمل مضبوطاً ليستسلم مبكراً، أو مشكلة في المسار الشبكي بين القفزات؛ في هذه الحالات حدد القفزة المصدرة أولاً. TTFB إصلاح حقيقي ودائم للحالة الشائعة التي يكون فيها المصدر بطيئاً فعلاً، لكنه ليس علاجاً عاماً. بعد تأكيد أن المصدر هو عنق الزجاجة، حسّن بالتخزين المؤقت (الصفحة والكائن وحافة CDN)، واستعلامات قاعدة بيانات أسرع وفهرسة صحيحة، وتوسع تلقائي للحمل، وضبط معقول لمهل مصدر CDN. أما 504 فليست حلاً عاماً.

لماذا يكون «مجرد رفع المهلة» غريزة خاطئة

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

عندما يكون التوقف مخططاً أو تتعمد تخفيف الحمل، فالأداة الصحيحة ليست ترك الصفحات تعيد 504، بل إعادة 503 (مع ترويسة Retry-After) حتى ترسل لمحركات البحث «عد لاحقاً» نظيفة ومقصودة بدلاً من مهلة فوضوية.

تشخيص 504 عملياً

حدد القفزة المصدرة قبل تخمين السبب؛ فهذا الفرق بين إصلاح المشكلة الحقيقية وإصلاح العارض:

• أعد إنتاجه وحدد أي قفزة أجابت. حمّل الصفحة في متصفح، واضربها عبر curl وراقب time_starttransfer لـTTFB، ومررها عبر زاحف مثل Ahrefs Site Audit أو Screaming Frog لمعرفة هل العطل على مستوى الموقع أم معزول. إن أمكن، اختبر المصدر مباشرةً (بتجاوز CDN/الوكيل) لترى هل يكمل المصدر نفسه.
• اقرأ السجلات. تخبرك سجلات الخادم والوكيل أي طبقة انتهت مهلتها، ويفضل أن تخبرك بما كان بطيئاً — الاستعلام أو المصدر المتعطل أو مجموعة العمال المستنفدة. اربط التوقيت ومعرف الطلب عبر الطبقات بدلاً من الافتراض.
• افحص Search Console. تعرض إحصاءات الزحف ارتفاعات رموز الاستجابة ومتوسط زمن الاستجابة؛ كما يوضح تقرير فهرسة الصفحات وفحص عنوان URL هل تواجه Google مهلات (بما فيها «Hostload exceeded»).

المصالحة بين الأدوات مهمة: قد يصف 504 في المتصفح، و5xx في Ahrefs Site Audit، ومهلة في GSC المصدر البطيء نفسه من وجهات نظر مختلفة. لا تفترض أن ثلاث أدوات تعني ثلاث مشكلات.

الرموز ذات الصلة

ينتمي 504 إلى عائلة صغيرة. 500 خطأ خادم عام بلا رمز أكثر تحديداً؛ و502 استجابة مصدر سيئة أو مشوهة؛ و503 «غير متاح» صريح وغالباً مقصود. معرفة الرمز الذي تعيده فعلياً — وإعادة الرمز الصحيح عمداً أثناء التوقف المخطط — نصف المعركة.

ملخص الذكاء الاصطناعي

خلاصة مركزة من النسخة المتقدمة:

• 504 = مهلة، لا استجابة مكسورة. انتظرت بوابة/وكيل (CDN أو موازن حمل أو وكيل عكسي) الخادم المصدر ولم تحصل على استجابة في الوقت المناسب، لا بالضرورة «لا استجابة مطلقاً». وهو مميز عن 502 (استجابة سيئة) و503 (عدم توفر صريح). لا يثبت الرمز وحده أي قفزة أو سبب؛ حدد القفزة المصدرة قبل الإصلاح.
• ليس عقوبة. إنها مشكلة إتاحة؛ لا تستطيع Google جلب الصفحة، لذلك فإن خسارة الترتيب/الفهرسة نتيجة لاحقة لا عقاب.
• المهلات تطلق خفض الزحف. تشرح Google أن Googlebot يخفض زحفه عند ملاحظة صعوبة الخادم في الاستجابة، ويصف Gary Illyes الخوادم المتعثرة بأنها تجعل الجلب يتراجع تلقائياً فتقل وتيرة الزحف.
• المدة مهمة، لكن رقم اليومين ليس رقماً موثقاً من Google لـ504. ذلك الأفق موثق لـ503/429 المعادين عمداً أثناء الحمل الزائد. أما إرشادات 5xx الأوسع فتقول إن معدل الزحف ينخفض بالتناسب ويتعافى تدريجياً، دون جدول ثابت لـ504؛ تعاد محاولة 504 المنفردة وتتحملها Google، لكن النمط المستمر الطويل يهدد إزالة الفهرسة.
• الحلقة تصحح نفسها. بعد عودة الاستجابات، يعود معدل الزحف تلقائياً ولا تحتاج إلى زر خفض يدوي.
• غالباً متقطع/معتمد على الحمل — قد لا يظهر في فحوص التوفر الهادئة، وقد يظهر كـ«Hostload exceeded» في فحص عنوان URL.
• زمن استجابة الخادم (TTFB) رافعة وقائية قوية لأسباب المصدر إذا راقبته كإنذار مبكر، لكنه ليس عاماً؛ فقد ينشأ 504 في CDN أو موازن الحمل أو الوكيل، لذا حدد القفزة أولاً. رفع المهلة ليس إصلاحاً، بل يخفي المصدر البطيء وقد يزيد الحمل.
• عند التوقف المخطط، أعد 503 مع Retry-After، لا 504.

الوثائق الرسمية

وثائق المصدر الأول عن المهلات وأخطاء الخادم واستجابة الزواحف.

التعريف

• MDN — 504 Gateway Timeout — التعريف المعتمد والفرق عن 502.

Google

• استكشاف أخطاء الزحف وإصلاحها — كيف يخفض Googlebot الزحف عند مشكلة الخادم ومتى تعيد 503/429 للحمل الزائد.
• تحسين ميزانية الزحف — كيف تقلل الاستجابات البطيئة وأخطاء الخادم حد الزحف.
• تقرير إحصاءات الزحف — فئتا «خطأ الخادم (5XX)» و«مهلة الصفحة»، وكيف يبطئ Googlebot لتجنب الحمل الزائد.

محرك Bing — Microsoft

• أدوات مشرفي المواقع لدى Bing — تنبيهات أخطاء الزحف — كيف تميز Bing أخطاء الخادم والمهلات كفئتين منفصلتين من أخطاء الزحف.

اقتباسات من المصدر

تصريحات مسجلة، وكل رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

MDN — التعريف

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (ترجمة) «يشير رمز استجابة خطأ الخادم 504 إلى أن الخادم، حين يعمل بوابة أو وكيلاً، لم يتلق استجابة في الوقت المناسب من الخادم المصدر لإكمال الطلب. ويشبه ذلك 502 Bad Gateway، لكن الوكيل أو البوابة في حالة 504 لم يتلق أي استجابة HTTP من المصدر خلال الوقت المحدد.» Jump to quote

Google — الزحف والمهلات

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (ترجمة) «يخفض Googlebot الزحف إذا اكتشف أن خوادمك تواجه صعوبة في الاستجابة لطلبات الزحف.» — مركز بحث Google، استكشاف أخطاء الزحف. انتقل إلى الاقتباس
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (ترجمة) «إذا تباطأ الموقع أو استجاب بأخطاء الخادم، ينخفض الحد وتزحف Google أقل.» — مركز بحث Google، تحسين ميزانية الزحف. انتقل إلى الاقتباس

Gary Illyes، Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (ترجمة) «عندما يعجز خادمك عن تقديم البايتات، ستتراجع زواحفنا تلقائيًا لتجنب إثقال بنيتك التحتية، ما سيخفض تواتر الزحف.» Jump to quote

John Mueller، Google (نقلته Search Engine Journal عن Reddit، أغسطس 2025)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (ترجمة) «لا أتوقع أن يستجيب معدل الزحف بهذه السرعة إلا عند إعادة 429 أو 500 أو 503 أو مهلات.» Jump to quote تعيد مجلة محرك البحث نشر رد Mueller في Reddit وسياقه المحيط.

قائمة فحص زمن استجابة الخادم / TTFB

الهدف إبقاء الاستجابات سريعة بما يكفي كي لا تعمل 504 أبداً، والتقاط الانحراف قبل ذلك. اعمل من الأعلى إلى الأسفل:

• حدد خط أساس TTFB باستخدام curl -w "%{time_starttransfer}" (أو مراقب اصطناعي)، وسجل ما يبدو «طبيعياً» لكل قالب.
• راقب TTFB باستمرار، لا بعد الحادث فقط؛ أطلق تنبيهاً عند الانحراف التصاعدي لا عند الفشل الصريح وحده.
• اختبر الحمل عند التزامن الواقعي والذروة؛ عادةً تعتمد 504 على الحمل، لذلك لن يكشفها فحص في فترة هادئة.
• حلل أبطأ عمل مصدر — استعلامات قاعدة بيانات بلا فهرس، واستعلامات N+1، واستدعاءات API خارجية حاجزة هي المشتبهات المعتادة.
• استخدم التخزين المؤقت بقوة — تخزين الصفحة والكائن وحافة CDN — حتى لا تلمس معظم الطلبات المسار البطيء.
• أكد اتساق قيم المهلة عبر الطبقات (CDN وموازن الحمل وNginx proxy_read_timeout / fastcgi_read_timeout والتطبيق) حتى لا تستسلم طبقة قبل أخرى.
• أكد التوسع التلقائي وهامش السعة لارتفاعات المرور والزحف.
• راجع إحصاءات زحف GSC لارتفاعات المهلة و5XX وزيادة متوسط زمن الاستجابة.
• افحص سجلات الخادم والوكيل لتحديد أي طبقة انتهت مهلتها وعلى ماذا.
• تحقق من أن مراقبة التوفر تغطي حمل الذروة لا فحوص خارج ساعات العمل فقط.
• استخدم 503 + Retry-After للتوقف المخطط بدلاً من ترك الصفحات تعيد 504.

خرافات وأخطاء 504 التي ينبغي تجنبها

هذه أكثر الفخاخ تكراراً؛ وبعضها خرافات واسعة الانتشار تستحق التصحيح:

• «504 عقوبة من Google». لا. إنها مشكلة إتاحة/قابلية زحف لا إجراء خوارزمي. لا تقيم Google محتواك؛ لا تستطيع جلب الصفحة. أي خسارة ترتيب نتيجة لاحقة لعدم الإتاحة وليست عقاباً.
• «أي 504 سيزيل صفحتي فوراً من الفهرس». لا. تعاد محاولة 504 القصيرة العرضية وتتحملها Google؛ الذي يهدد الفهرسة هو تكرار 504 المستمر بكثرة عبر نافذة طويلة.
• «504 و503 متشابهان، فاستخدمهما بالتبادل». لا. قد يكون 503 إشارة مقصودة ومضبوطة، وتدعم Google 503 للتوقف المخطط؛ أما 504 فمهلة غالباً غير مخطط لها وعَرَض مصدر بطيء. أثناء التوقف المخطط أعد 503 مع Retry-After ولا تدع الصفحات تعيد 504.
• «Googlebot عدواني أكثر من اللازم». غالباً العكس. الخادم الذي يعيد 504 بثبات تحت معدل زحف Googlebot سيتدهور أيضاً للمستخدمين الحقيقيين تحت حمل مماثل. تكشف المهلة مشكلة سعة/أداء حقيقية (توجد حالات Hostload exceeded، لكنها الاستثناء).
• «إصلاحها يعني رفع قيمة المهلة». يخفي رفع proxy_read_timeout المصدر البطيء بدلاً من إصلاحه، والمهلة الأطول تحت الحمل تشغل عمليات العمال مدة أطول وقد تزيد الحمل. أصلح الاستجابة البطيئة ولا تمدد الصبر عليها.
• «مراقبة التوفر تقول إننا خضراء، إذن لا مشكلة 504». تعتمد 504 كثيراً على الحمل؛ فقد يفوتها فحص في فترة هادئة بينما يجمعها Googlebot أثناء دفعات زحف أثقل. ثق بإحصاءات الزحف والسجلات أكثر من فحوص خارج ساعات العمل.

أي طبقة تنتهي مهلتها؟

موجه: صنّف مجموعة من حوادث 504

ألصق صفوفاً منقحة تتضمن عنوان URL والتوقيت ورؤوس الاستجابة وTTFB أو الزمن الكلي ونتيجة الحافة العامة ونتيجة المصدر المباشر وتتبع التطبيق وتوقيت قاعدة البيانات وإشارات الموارد. لا تلصق بيانات الاعتماد أو ملفات تعريف الارتباط أو العناوين الخاصة أو بيانات المستخدم.

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

عامل النتيجة كقائمة فرضيات. أكدها في قياسات البوابة والتطبيق وقاعدة البيانات والبنية التحتية.

قياس الحالة وزمن الوصول إلى البايت الأول

شغّل هذا في Shell على macOS/Linux. فهو يبلغ عن رمز الاستجابة النهائي وTTFB لطلب واحد دون طباعة الجسم.

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

كرره بضع مرات لترى هل المهلة ثابتة أم تعتمد على الحمل:

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

المكافئ في PowerShell:

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

يقيس إصدار PowerShell زمن الطلب الكلي لا TTFB. استخدم أمر Shell أو قياسات تطبيقك عندما تحتاج فصل البايت الأول.

أدوات إعادة إنتاج المهلة وتحديد نطاقها

• أداة التحقق من توقف الموقع — اختبر قابلية الوصول من نقطة خارجية والتقط توقيت الاستجابة وإعادة التوجيه وأدلة DNS محدودة، لإثبات هل يمكن إعادة الحادث علناً.
• أداة فحص رموز حالة HTTP بالجملة — افحص مجموعة ممثلة من المسارات وقارن زمن الاستجابة وصدّر المجموعة الفاشلة، لتمييز نقطة نهاية بطيئة من مشكلة مصدر على مستوى الموقع.
• سجلات CDN/موازن الحمل — حدد البوابة التي أصدرت 504 واربط معرف طلبها ومهلتها بمحاولة المصدر.
• تتبع التطبيق وسجلات الاستعلامات البطيئة لقاعدة البيانات — أظهر أين قضى الطلب وقته بعد وصوله إلى المصدر.
• مراقبة البنية التحتية — قارن نافذة الحادث بوحدة المعالجة والذاكرة ومجموعة العمال والاتصالات وتشبع التبعيات، بدلاً من التخمين من رمز الحالة.

TTFB حسب المسار والمئين

المقياس: زمن الوصول إلى البايت الأول لمسارات ممثلة، مقسماً حسب مئينات مفيدة لا المتوسط وحده.

ما الذي يخبرك به: ارتفاع زمن الذيل إنذار مبكر بأن الطلبات تقترب من مهلة البوابة حتى قبل أن تبدأ في إعادة 504.

طريقة جلبه: استخدم مراقبة المستخدم الحقيقي/الخادم أو سجلات البوابة؛ واستخدم سكربت curl في علامة Scripts للفحوص الموضعية لا بديلاً عن قياسات الإنتاج.

المعيار / النطاق الواقعي: أنشئ خط أساس لكل مسار وطريق بنية تحتية. التنبيه المهم هو تغير مستمر عن ذلك الخط أو اقتراب من مهلة البوابة المضبوطة فعلياً، لا رقم SEO عالمياً.

الوتيرة: راقب باستمرار، وراجع اتجاهات مستوى المسار أسبوعياً وأثناء كل حادث 504.

معدل استجابة 504

المقياس: الطلبات التي تعيد 504 مقسومة على جميع الطلبات، مقسمة حسب المسار والبوابة والمصدر وفئة الزاحف/وكيل المستخدم حيثما توفرت.

ما الذي يخبرك به: هل المهلات معزولة، أو مركزة في مسار، أو واسعة بما يكفي للتأثير في الزحف والمستخدمين.

طريقة جلبه: اجمع سجلات CDN أو موازن الحمل أو وصول الخادم حسب رمز الحالة وأبعاد الطلب.

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

الوتيرة: أطلق التنبيه باستمرار؛ وراجع يومياً أثناء التعافي وفي تقرير الاعتمادية الأسبوعي المعتاد.

اكتمال المصدر مقابل مهلة البوابة

المقياس: توزيع أزمنة اكتمال المصدر مقارنة بالمهلة المضبوطة لكل قفزة.

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

طريقة جلبه: صِل حقول توقيت البوابة بتتبعات التطبيق باستخدام معرف الطلب أو التتبع.

المعيار / النطاق الواقعي: أبقِ الاكتمال الطبيعي داخل الحد المضبوط بهامش مريح للتباين المتوقع. عرّف الهامش من توزيعات الإنتاج المرصودة؛ لا تخترع نسبة عامة.

الوتيرة: راجع بعد تغييرات الإعداد أو التبعيات، وكلما ارتفع زمن الذيل أو معدل 504.

اختبر نفسك: 504 Gateway Timeout

خمسة أسئلة سريعة عن معنى 504 وتأثيره في الزحف. اختر إجابة لكل سؤال ثم تحقق منها.

موارد تستحق وقتك

كتاباتي ذات الصلة

• دليل المبتدئ إلى SEO التقني — موضع صحة الخادم وقابلية الزحف في الصورة الأكبر.
• التعرف إلى الزواحف الجديدة على الويب: روبوتات الذكاء الاصطناعي تقترب من روبوتات محركات البحث — من يضرب خادمك فعلياً، ولماذا يهم الحمل.

كلماتي ومحاضراتي

• How Search Works (SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب، بما في ذلك كيفية تنظيم استجابات الخادم لمعدل الزحف. (ينطبق التحفظ الدائم: “This is my understanding of systems… not going to be 100% complete or accurate.”)

من أوساط الصناعة

• MDN — 504 Gateway Timeout — التعريف المرجعي والفرق عن 502.
• Google — استكشاف أخطاء الزحف وإصلاحها — كيف تخفض Googlebot الزحف عند مشكلة الخادم.
• Google — إدارة ميزانية الزحف للمواقع الكبيرة — كيف تخفض الاستجابات البطيئة حد الزحف.
• Google تشرح كيف يعمل الزحف في 2026 (Search Engine Land) — اقتباس Illyes الذي يربط تعثر الخادم بانخفاض وتيرة الزحف.
• هبوط زحف Googlebot؟ Mueller يشير إلى أخطاء الخادم (Search Engine Journal) — جمع Mueller للمهلات مع 429/500/503 كأخطاء تخفض معدل الزحف بسرعة.
• كيفية إصلاح خطأ 504 Gateway Timeout (Kinsta) — شرح تقني جيد من جهة المضيف لسلسلة الطلب وتشخيص السجلات.

فيديوهات

• Google Search Central (YouTube) — سلسلة How Google Search Works وشروحات Martin Splitt للزحف، المفيدة لرؤية تفاعل استجابات الخادم ومعدل الزحف. القناة

سجل التغييرات