خطأ 502 Bad Gateway

ما هو خطأ 502 Bad Gateway، وأسبابه الشائعة في الخادم الأعلى والوكيل، وكيف يتعامل معه Googlebot، وتأثيره في الزحف والفهرسة.

نُشر أول مرة: 28 يونيو 2026 · آخر تحديث: 6 أغسطس 2026 · Advanced
اللغات
دليل واحد في هذه الصفحة

يعني خطأ 502 Bad Gateway أن وكيلاً أو بوابة أمام موقعك (مثل شبكة توصيل محتوى أو موازن تحميل أو وكيل عكسي) تلقى استجابة غير صالحة من خادم المصدر خلفه. إنها مشكلة في البنية التحتية وليست مشكلة في Search Console. تجمع وثائق Google بين 502 و500 و503 ضمن معاملة واحدة لأخطاء 5xx: يتباطأ الزحف بما يتناسب مع عدد عناوين URL التي تعرض أخطاء، ويُتجاهل محتوى استجابات 5xx، وتُحذف الصفحات من الفهرس إذا استمرت الأخطاء. لا تنشر Google عتبة مدة آمنة محددة أو ضماناً للتعافي التلقائي، لذلك يحمل الارتفاع القصير خطراً عملياً أقل بكثير من الخطأ المتكرر — لكنه ليس خالياً من الخطر رسمياً. شخّص المشكلة حسب الطبقة (شبكة توصيل المحتوى، والوكيل العكسي، والمصدر)، واربط العلامة التجارية أو صفحات الخطأ بالترويسات ومعرّفات التتبع والسجلات بدلاً من الوثوق بصفحة الخطأ وحدها.

الخلاصة — خطأ 502 هو فشل في طبقة الوكيل أو البوابة: يعرّفه RFC 9110 §15.6.3 بأنه تلقي بوابة أو وكيل استجابة غير صالحة من خادم وارد. وهو يختلف عن 500 (حدث خطأ في تطبيق المصدر) وعن 503 (المصدر غير متاح عمداً). تجمع وثائق Google بين 500 و502 و503 ضمن معاملة واحدة لأخطاء 5xx — ينخفض معدل الزحف بما يتناسب مع عدد عناوين URL التي تعرض أخطاء، ويتم تجاهل محتوى 5xx، وتُحذف الصفحات من الفهرس عند استمرار الأخطاء. وتحدث الاستعادة تدريجياً بعد عودة 2xx، مع أن Google لا تنشر جدولاً زمنياً ثابتاً. المدة مهمة، لكن لا توجد عتبة رسمية: تحمل الارتفاعات القصيرة خطراً عملياً أقل بكثير، بينما الأخطاء المتكررة هي التي تعرض الصفحات لخطر حقيقي — وقد وضعت ملاحظات Mueller في نوفمبر 2025 ذلك بشكل غير رسمي عند «عدة أيام»، لا بوصفه اتفاقية مستوى خدمة موثقة. شخّص المشكلة حسب الطبقة — شبكة توصيل المحتوى، أو الوكيل العكسي، أو المصدر — واربط الأدلة عبر القفزات بدلاً من الوثوق بصفحة خطأ تحمل علامة تجارية وحدها.

ما الذي يشير إليه خطأ 502 فعلياً

يعرّف RFC 9110 §15.6.3 خطأ 502 تحديداً بأنه تلقي بوابة أو وكيل استجابة غير صالحة من خادم وارد وصل إليه أثناء محاولة تنفيذ الطلب. هذا الحد في المواصفة مهم — فهو يحدد المكان الذي لاحظت فيه البوابة الفشل، وليس بالضرورة القفزة التي تسببت فيه. حالة 502 دليل على فشل عند حد فاصل، وليست دليلاً على تعطل تطبيق المصدر. هذا التمييز الواحد هو ما تطمسه معظم مقالات المنافسين التي تسرد «13 طريقة لإصلاحه»، ولذلك يأتي التشخيص أدناه على طبقات وليس في قائمة مسطحة. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

قارن بين رموز 5xx التي يسهل الخلط بينها:

  • 500 Internal Server Error — حدث الخطأ في تطبيق المصدر نفسه (خلل في الشيفرة، أو استثناء غير معالج، أو استنفاد الموارد). لقد أجاب المصدر، وكانت إجابته «لقد تعطلت».
  • 502 Bad Gateway — تلقى الوكيل إجابة مشوهة أو غير صالحة من الخادم الأعلى (RFC 9110 §15.6.3).
  • 503 Service Unavailable — المصدر غير متاح عمداً؛ وهذا هو رمز «عد لاحقاً» المقصود والمقبول من Google، ويُستخدم للصيانة المخطط لها، ويفضل مع ترويسة Retry-After.
  • 504 Gateway Timeout — انتظر الوكيل الخادم الأعلى لكنه لم يتلقَّ أي شيء قبل انتهاء مهلة الانتظار (RFC 9110 §15.6.5). (502 = إجابة سيئة؛ 504 = لم تصل إجابة في الوقت المحدد.)
Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

الخلاصة العملية: رمز 503 هو ما تختاره عمداً؛ أما رمز 502 فهو ما يحدث لك عندما تفشل البنية التحتية.

كيف يتعامل Googlebot مع خطأ 502

إليك الجزء الذي يستحق ربطه بوثائق Google الفعلية بدلاً من عبارة «قد يضر بالترتيب» المبهمة التي ستقرأها في أماكن أخرى. تسرد وثيقة Google عن أخطاء HTTP والشبكة الرمز 502 (bad gateway) ضمن رموز 5xx، وتمنح جميع رموز 5xx المعاملة نفسها:

  • ينخفض معدل الزحف بشكل متناسب. تقلل Google معدل الزحف للموقع، ويتناسب الانخفاض مع عدد عناوين URL الفردية التي تعيد خطأ خادم. عدد قليل من أخطاء 502 تأثيره محدود؛ أما خطأ 502 على مستوى الموقع كله فهو رسالة واضحة «أبطئ».
  • يُتجاهل محتوى 5xx. كل ما تتلقاه Google من عنوان URL يعيد 5xx يتم تجاهله — ولن تُفهرس صفحة خطأ 502 على أنها محتواك.
  • الحفاظ على الفهرسة مؤقت. تبقى عناوين URL المفهرسة سابقاً في الفهرس في البداية، لكن مسار فهرسة Google يحذف عناوين URL التي تعيد خطأ خادم باستمرار.
  • الاستعادة تلقائية وتدريجية. بعد أن يبدأ الخادم في الاستجابة مجدداً برموز 2xx، تزيد Google معدل الزحف تدريجياً. لا حاجة إلى إعادة إرسال أو طلب إعادة نظر أو استعراضات «التحقق من الإصلاح» للتعافي العادي — فهذا الزر يطلب من Google إعادة الفحص أبكر فحسب.

أهم خلاصة منفردة: تتعامل Google مع 502 بالطريقة نفسها التي تتعامل بها مع 500 و503. ليس أقل خطورة لمجرد أنه ينشأ في طبقة الوكيل أو شبكة توصيل المحتوى بدلاً من تطبيق المصدر. ولا يوجد تساهل موثق مع 502. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers

المدة هي القصة كلها

يتوقف كون خطأ 502 ضاراً فعلاً على مدة استمراره — لكن Google لا تنشر مدة آمنة ثابتة أو عتبة ثابتة للخروج من الفهرس، لذا اعتبر ما يلي سياقاً عملياً لا اتفاقية مستوى خدمة:

  • ارتفاع قصير (من دقائق إلى بضع ساعات) → ينخفض معدل الزحف بحسب عدد عناوين URL التي تعرض أخطاء، ولذلك يكون لارتفاع قصير محدود النطاق تأثير عملي محدود، ولا يستحق عادةً ملاحقته في Search Console. لا تعفي وثائق Google الأخطاء القصيرة رسمياً — إنها مسألة درجة، وليست حداً فاصلاً صارماً.
  • خطأ يتكرر أو يظل قائماً → هذه هي الفترة التي تنطبق عليها عبارة Google «تعيد خطأ خادم باستمرار»، وقد تبدأ الصفحات في الاختفاء من الفهرس. لا تحدد Google «الاستمرار» بعدد معين من الأيام. ووضع تعليق Mueller العلني (أدناه) ذلك بشكل غير رسمي عند عدة أيام تقريباً، مع تعافٍ سريع نسبياً بعد سلامة الموقع — لكن هذه قراءة ممارس لحادثة محددة، وليست قاعدة موثقة يمكن الاعتماد عليها لكل موقع أو شبكة توصيل محتوى.

ينطبق هذا بصورة تقريبية على عطل Cloudflare في نوفمبر 2025، عندما أظهرت موجة من المواقع أخطاء 5xx من دون أن يكون السبب خطأً منها. وكان رد Mueller العلني على Bluesky أن زحف 5xx يتباطأ لكنه «يزداد مجدداً» — راجع علامة تبويب Quotes للاطلاع على الصياغة الدقيقة وتحفظات الإسناد، بما في ذلك تعليق منفصل عن «عدة أيام» نُقل عبر ملخص من طرف ثالث ولم يُتحقق منه مقابل سلسلة النقاش الأصلية. ويُعد العطل القصير الذي يؤكده المزوّد أقرب إلى أفضل حالة: فهو ظاهر، وينتهي عادةً من تلقاء نفسه، وبعد أن يؤكد المزوّد التعافي وتعود استجابات 2xx الخاصة بك، تكون الاستجابة المعقولة عادةً هي تأجيل تغييرات البنية التحتية بدلاً من إجرائها بشكل تفاعلي.

تشخيص خطأ 502 حسب الطبقة

بما أن خطأ 502 هو فشل في الاتصال بين الخوادم، فإن أسرع طريقة للعثور عليه هي النزول عبر المكدس — شبكة توصيل المحتوى، ثم الوكيل العكسي، ثم المصدر — بدلاً من المرور بقائمة فحص مسطحة. (تحتوي علامة تبويب Decision Trees على جولة إرشادية بذلك.)

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

طبقة شبكة توصيل المحتوى / الحافة

  • مهلة انتظار من الخادم الأعلى: عجزت عقدة الحافة عن الحصول على استجابة من المصدر في الوقت المحدد.
  • تعجز الحافة عن الوصول إلى المصدر إطلاقاً — فشل في تحليل DNS، أو فشل في مصافحة SSL/TLS، أو حجب جدار حماية المصدر أو نظام الأمان لنطاقات IP الخاصة بشبكة توصيل المحتوى.
  • تختلف الأسباب الموثقة حسب المزوّد: تصف وثائق Cloudflare الخاصة باستكشاف الأخطاء سيناريوهات اتصال بالمصدر ومهلات انتظار خاصة بشبكة الحافة لديها، بينما توثق AWS CloudFront مجموعة خاصة بها من أسباب TLS وDNS والمنفذ ووظيفة المصدر — راجع وثائق شبكة توصيل المحتوى التي تستخدمها بدلاً من افتراض أن قائمة أسباب مزوّد واحد تنطبق على آخر.
  • عطل المزوّد نفسه (Cloudflare أو Fastly أو AWS وما إلى ذلك) — حدث 502 واسع النطاق عبر مواقع غير مرتبطة لا علاقة له بصحة خادمك؛ تحقق من ذلك في صفحة حالة المزوّد، لا من العلامة التجارية الظاهرة على صفحة الخطأ وحدها.

طبقة الوكيل العكسي / موازن التحميل (Nginx، Apache mod_proxy، HAProxy)

  • انتهت مهلة الواجهة الخلفية أو رُفض الاتصال.
  • إعداد proxy_pass أو كتلة upstream مُعدّة بشكل خاطئ وتشير إلى المكان الخطأ.
  • استنفاد مجموعة الواجهات الخلفية — كل عامل upstream مشغول.
  • عدم تطابق SSL/TLS بين الوكيل والواجهة الخلفية.

طبقة خادم المصدر

  • تعطل تطبيق أو PHP-FPM أو إعادة تشغيله، أو إنهاء بسبب نفاد الذاكرة (تجاوز حد الذاكرة).
  • استنفاد اتصالات قاعدة البيانات.
  • نشر أو إعادة تشغيل يسبب عدم إتاحة قصير المدى.
  • حجب WAF أو إضافة أمان لعناوين IP المشروعة الخاصة بالوكيل أو الزاحف، والتعامل معها كأنها مهاجمون — وهذه هي الحالة المراوغة، لأن المتصفحات العادية تعمل جيداً بينما يتلقى الوكيل (أو Googlebot) هذه الأخطاء.

يجدر إبراز النمط الأخير: إذا كانت الأخطاء تظهر فقط لـ Googlebot أو فقط للطلبات التي تمر عبر شبكة توصيل المحتوى، بينما لا تظهر في المتصفحات العادية، فأنت أمام حجب خاص بالروبوتات أو استجابة متغيرة، لا عطل حقيقي. اختبر الاتصال المباشر بالمصدر مقابل الاتصال عبر شبكة توصيل المحتوى، وتحقق مما يراه Googlebot فعلياً باستخدام الاختبار المباشر لفحص عنوان URL في Search Console بدلاً من افتراض استمرار التأثير بسبب تقرير خطأ خادم (5xx) قديم.

إصلاح أخطاء البوابة ومنعها

الإصلاحات خاصة بالطبقة، ويختلف الشخص المسؤول عنها حسب الدور:

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

للوقاية، تنجح الأمور المملة: مراقبة وقت التشغيل مع التنبيهات، ومراقبة سجلات أخطاء الخادم والوكيل، ومتابعة حالة المضيف وإتجاه أخطاء الخادم (5xx) في إحصاءات الزحف في Search Console، وربط الارتفاعات بصفحات حالة مزوّدي شبكة توصيل المحتوى وDNS حتى تميز «مشكلتي» من «عطلهم» خلال ثوانٍ.

الرموز ذات الصلة التي ينبغي إبقاؤها واضحة تقع بجوار هذا التجمع مباشرةً: المصدر 500، و503 المقصود، و504 الخاص بمهلة البوابة.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.