خطأ 502 Bad Gateway
ما هو خطأ 502 Bad Gateway، وأسبابه الشائعة في الخادم الأعلى والوكيل، وكيف يتعامل معه Googlebot، وتأثيره في الزحف والفهرسة.
اللغات
دليل واحد في هذه الصفحة
- أداة مباشرة ذات صلةWebsite Down Checker
يعني خطأ 502 Bad Gateway أن وكيلاً أو بوابة أمام موقعك (مثل شبكة توصيل محتوى أو موازن تحميل أو وكيل عكسي) تلقى استجابة غير صالحة من خادم المصدر خلفه. إنها مشكلة في البنية التحتية وليست مشكلة في Search Console. تجمع وثائق Google بين 502 و500 و503 ضمن معاملة واحدة لأخطاء 5xx: يتباطأ الزحف بما يتناسب مع عدد عناوين URL التي تعرض أخطاء، ويُتجاهل محتوى استجابات 5xx، وتُحذف الصفحات من الفهرس إذا استمرت الأخطاء. لا تنشر Google عتبة مدة آمنة محددة أو ضماناً للتعافي التلقائي، لذلك يحمل الارتفاع القصير خطراً عملياً أقل بكثير من الخطأ المتكرر — لكنه ليس خالياً من الخطر رسمياً. شخّص المشكلة حسب الطبقة (شبكة توصيل المحتوى، والوكيل العكسي، والمصدر)، واربط العلامة التجارية أو صفحات الخطأ بالترويسات ومعرّفات التتبع والسجلات بدلاً من الوثوق بصفحة الخطأ وحدها.
الخلاصة — يعني خطأ 502 Bad Gateway أن خادماً كان يطلب صفحتك من خادم آخر وتلقى إجابة سيئة. عادةً يكون الخادم «الأمامي» شبكة توصيل محتوى أو وكيلاً، بينما الخادم «الخلفي» هو موقعك الفعلي (المصدر). المشكلة في الاستضافة أو البنية التحتية — وليست في Google Search Console — وعادةً ما يحمل خطأ 502 قصير الأجل خطراً محدوداً على تحسين محركات البحث عملياً، مع أن Google لا تنشر مدة «آمنة» دقيقة. وتصبح المشكلة أكبر كلما طال استمرارها.
ما هو خطأ 502 Bad Gateway
عندما تحمّل صفحة، لا ينتقل الطلب غالباً مباشرةً إلى موقعك. بل يمر عبر وسيط — مثل شبكة توصيل محتوى CDN (كـ Cloudflare)، أو موازن تحميل، أو وكيل عكسي (مثل Nginx). يمرر ذلك الوسيط الطلب إلى خادمك الفعلي، وينتظر استجابة، ثم ينقلها إلى الزائر.
يظهر خطأ 502 Bad Gateway عندما يطلب الوسيط من خادمك الصفحة ويتلقى شيئاً غير صالح — أو لا يتلقى شيئاً على الإطلاق. وبعبارة بسيطة: لم يتمكن الخادم الأمامي من الحصول على إجابة سليمة من الخادم الخلفي. 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
وهذه هي الدقة المهمة: لا يعني خطأ 502 تلقائياً أن موقعك متوقف. قد يكون خادمك سليماً تماماً ويجيب بشكل جيد عند طلبه مباشرةً — لكن إذا عجز الوكيل الموجود أمامه عن الوصول إليه (بسبب مهلة انتظار، أو إعداد سيئ، أو عطل خاص بشبكة توصيل المحتوى)، فسيظل الزوار يرون خطأ 502.
كيف يختلف عن أخطائه الشبيهة
سترى بعض أخطاء 5xx التي تبدو متشابهة:
- 500 — واجهت شيفرة موقعك نفسها خطأً أثناء بناء الصفحة.
- 502 — تلقى وكيل أمام موقعك إجابة سيئة منه.
- 503 — موقعك غير متاح عمداً (صيانة مخطط لها أو ضغط زائد).
- 504 — انتظر وكيل موقعك، لكن انتهت مهلة الانتظار من دون أي إجابة.
هذه الأخطاء مرتبطة، لكنها تشير إلى أماكن مختلفة ينبغي فحصها.
هل يضر خطأ 502 بتحسين محركات البحث؟
عادةً لا يسبب ضرراً كبيراً — ما دام لا يستمر. يتعامل زاحف Google (Googlebot) مع خطأ 502 بالطريقة نفسها التي يتعامل بها مع أخطاء 5xx الأخرى: يبطئ الزحف بما يتناسب مع عدد عناوين URL التي تعرض أخطاء، ثم يزيده مجدداً بعد أن يبدأ موقعك في الاستجابة برموز 2xx. لا تنشر Google مدة «آمنة» دقيقة، لكن خطأ 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 التي تعيد خطأ خادم — لكنها لا تحدد ذلك بعدد معين من الأيام. وقد ذكر John Mueller من Google بشكل غير رسمي أن «عدة أيام» هي تقريباً المدة التي تبدأ عندها الصفحات بالاختفاء، وأنها تميل إلى العودة بعد تعافي الموقع — لكن تعامل مع ذلك باعتباره قراءة تقريبية لشخص واحد في حادثة محددة، لا قاعدة رسمية.
ماذا تفعل حيال الخطأ
- لا تحاول «إصلاح» الخطأ في Search Console. فـ Search Console لا يفعل سوى الإبلاغ عن خطأ 502 بعد وقوعه. يحدث الإصلاح في شبكة توصيل المحتوى أو الوكيل أو الخادم.
- تحقق مما إذا كانت المشكلة عندك وحدك أم عند الجميع. إذا كان الإنترنت كله يعمل لكن موقعك متوقف، فالمشكلة في إعدادك. وإذا كانت شبكة توصيل محتوى كبيرة تواجه عطلاً، فقد لا يكون الخطأ من جانبك — ولا يوجد ما تصلحه سوى الانتظار.
- راجع صفحة حالة المضيف أو شبكة توصيل المحتوى وسجلات خادمك. هناك توجد الإجابة الحقيقية.
هل تريد تشخيصاً طبقةً بطبقة (شبكة توصيل المحتوى مقابل الوكيل مقابل المصدر)، وما تقوله وثائق Google تحديداً، وما قاله John Mueller أثناء عطل Cloudflare في نوفمبر 2025؟ انتقل إلى علامة التبويب Advanced.
الخلاصة — خطأ 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 = لم تصل إجابة في الوقت المحدد.)
الخلاصة العملية: رمز 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 الخاص بمهلة البوابة.
ملخص الذكاء الاصطناعي
عرض مختصر لنسخة Advanced:
- 502 = فشل في طبقة الوكيل أو البوابة. يعرّفه RFC 9110 §15.6.3 بأنه تلقي بوابة أو وكيل استجابة غير صالحة من خادم وارد — وهذا دليل على فشل عند حد فاصل، وليس إثباتاً للقفزة (شبكة توصيل المحتوى أو الوكيل أو المصدر) التي تسببت فيه. قد يكون المصدر سليماً بينما يرى الزوار خطأ 502.
- أسباب مختلفة، عائلة موثقة واحدة. 500 (حدث خطأ في تطبيق المصدر)، و502 (تلقى الوكيل إجابة سيئة، وفق RFC §15.6.3)، و503 (المصدر غير متاح عمداً)، و504 (لم يتلق الوكيل إجابة في الوقت المحدد، وفق RFC §15.6.5). تجمع وثائق Google بين 500 و502 و503 ضمن معاملة واحدة لأخطاء 5xx — ولا توثق تماثلاً خاصاً بكل حالة خارج قاعدة العائلة تلك.
- استجابة Googlebot: ينخفض معدل الزحف بما يتناسب مع عدد عناوين URL التي تعرض أخطاء، ويُتجاهل محتوى 5xx، وتُحفظ عناوين URL المفهرسة على المدى القصير لكن تُحذف إذا استمرت الأخطاء، ويزداد الزحف مجدداً تدريجياً بعد عودة 2xx — ولا تنشر Google مدة آمنة دقيقة أو جدولاً زمنياً مضموناً للتعافي.
- المدة مهمة، لكن لا توجد عتبة رسمية. تحمل الارتفاعات القصيرة خطراً عملياً أقل بكثير؛ والأخطاء المتكررة هي الخطر الحقيقي. وضع تعليق Mueller غير الرسمي في نوفمبر 2025 خروج الصفحات من الفهرس عند «عدة أيام»، مع تعافٍ سريع نسبياً — تعامل معه كقراءة ممارس لحادثة واحدة، لا اتفاقية مستوى خدمة موثقة.
- شخّص بربط الأدلة عبر الطبقات، لا بالوثوق بالعلامة التجارية وحدها: شبكة توصيل المحتوى (مهلة انتظار أو فشل DNS/SSL أو عطل المزوّد — وتوثق Cloudflare وAWS CloudFront أسباباً مختلفة خاصة بمنصتيهما) → الوكيل العكسي (
proxy_passسيئ، أو استنفاد المجموعة، أو رفض الاتصال) → المصدر (تعطل التطبيق أو PHP-FPM، أو OOM، أو استنفاد قاعدة البيانات، أو حجب WAF لعناوين IP الخاصة بالوكيل أو الزاحف). طابق الترويسات ومعرّفات التتبع والسجلات المؤرخة على جانبي القفزة قبل تحديد الطبقة الفاشلة. - ليس إصلاحاً واحداً يناسب الجميع. لا يفعل GSC سوى الإبلاغ عن خطأ 502 بعد وقوعه ولا يستطيع إصلاحه. ولا يستطيع الزوار إصلاحه أيضاً؛ وعلى مالكي المواقع الذين لا يملكون وصولاً إلى البنية التحتية التصعيد بدلاً من تعديل الإعدادات؛ وينبغي أن تستند التغييرات المدمرة — إضافة WAF إلى قائمة السماح أو تعديل جدار الحماية أو الوكيل — إلى أدلة السجلات والمزوّد، لا أن تكون تخميناً للاستجابة الأولى. وإذا كانت أخطاء 502 تظهر فقط لـ Googlebot أو للطلبات التي تمر عبر شبكة توصيل المحتوى، فاشتبِه في حجب خاص بالروبوتات، لا في عطل شامل.
الوثائق الرسمية
وثائق المصادر الأولية حول كيفية تعامل محركات البحث مع أخطاء 5xx، بما فيها 502.
- كيفية تأثير رموز حالة HTTP في زواحف Google — الوثيقة المرجعية؛ تسرد
502 (bad gateway)إلى جانب 500 و503 وتشرح المعاملة المشتركة لمعدل الزحف والفهرسة. - كيفية التعامل مع توقف الموقع المخطط له — يوضح لماذا يكون 503 (وليس 502 أو 404 أو 200) هو الرمز الصحيح للتوقف المقصود، مع ترويسة
Retry-After. وهو مفيد للتمييز بين 502 و503. - مواصفة robots.txt — التعامل مع أخطاء الخادم — كيف تتعامل Google مع خطأ 5xx في ملف robots.txt نفسه.
المواصفة
- RFC 9110 §15.6.3 — 502 (Bad Gateway) — التعريف على مستوى المواصفة: تلقي بوابة أو وكيل استجابة غير صالحة من خادم وارد وصل إليه أثناء محاولة تنفيذ الطلب. وهي تحدد الحد الذي لوحظ فيه الفشل، لا القفزة التي تسببت فيه.
Bing / Microsoft
- مركز مساعدة Bing Webmaster Tools — تعرض Bing مشكلات الزحف من جانب الخادم (من فئة 5xx)، بما فيها أعطال الاتصال، في تقارير أخطاء الزحف.
الاقتباسات من المصدر
تصريحات مسجلة من Google. يؤدي كل رابط إلى موضع الاقتباس مباشرةً.
Google — كيفية التعامل مع أخطاء 5xx (بما فيها 502)
- “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (ترجمة) «تحث أخطاء الخادم 5xx و429 زواحف Google على إبطاء الزحف مؤقتًا. وبالنسبة إلى Google Search، تُحفظ عناوين URL المفهرسة بالفعل في الفهرس، لكنها تُحذف في النهاية.» — Google Search Central، How HTTP status codes affect Google’s crawlers. الانتقال إلى الاقتباس
- “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.”
(ترجمة) «تخفض Google معدل الزحف للموقع. ويتناسب الانخفاض مع عدد عناوين URL الفردية التي تعيد خطأ خادم. وبالنسبة إلى Google Search، يزيل مسار فهرسة Google من الفهرس عناوين URL التي تستمر في إعادة خطأ خادم.»
— الوثيقة نفسها، صف الجدول الذي يغطي
500و502و503. الانتقال إلى الاقتباس - “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (ترجمة) «بمجرد أن يبدأ الخادم في الاستجابة برمز حالة 2xx، تزيد Google معدل الزحف للموقع تدريجيًا.» — الوثيقة نفسها. الانتقال إلى الاقتباس
John Mueller، Google (Bluesky، 18 نوفمبر 2025 — رداً في سلسلة نقاش حول ارتفاع أخطاء 5xx أثناء عطل Cloudflare)
- “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (ترجمة) «نعم. 5xx = يتباطأ زحف Google، لكنه سيتسارع مجددًا.» عرض المنشور
- “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” (ترجمة) «إذا ظل 5xx لعدة أيام، فقد تبدأ الأشياء في التساقط، لكن حتى عندئذ ستعود سريعًا إلى حد كبير.» نُقلت العبارة عبر مقال Matt G. Southern في Search Engine Journal عن التبادل نفسه؛ أكدها مقابل سلسلة النقاش الأصلية قبل اعتبارها نهائية. قراءة التغطية
قائمة فحص استجابة 502 Bad Gateway
عندما يظهر خطأ 502 — في متصفح أو في أداة مراقبة أو في تقرير خطأ الخادم (5xx) في Search Console — اعمل على هذه القائمة. تعمل علامات الدور [Any] سواء أكان لديك وصول إلى البنية التحتية أم لا؛ أما [Host/CDN/App owner] فتتطلب ذلك.
- [Any] أكد أن الخطأ حقيقي وحديث — أعد طلب عنوان URL الآن؛ فقد يتأخر تقرير خطأ الخادم (5xx) عن عطل قصير انتهى بالفعل.
- [Any] افحص النطاق — هل هو عنوان URL واحد، أم قسم، أم الموقع بأكمله؟ (يزداد تأثير الزحف مع عدد عناوين URL التي تعرض أخطاء.)
- [Any] راجع صفحة حالة مزوّد شبكة توصيل المحتوى أو DNS لمعرفة ما إذا كان هناك عطل شامل للمزوّد قبل لمس إعدادك.
- [Host/CDN/App owner] اختبر الاتصال المباشر بالمصدر مقابل الاتصال عبر شبكة توصيل المحتوى — إذا أجاب المصدر برمز 2xx مباشرةً بينما أعادت الشبكة 502، فالمشكلة عند الحافة أو بينهما.
- [Host/CDN/App owner] تحقق مما إذا كانت أخطاء 502 تصيب الروبوتات أو عناوين IP الخاصة بشبكة توصيل المحتوى فقط بينما المتصفحات سليمة — فهذا يشير إلى حجب محتمل في WAF أو جدار الحماية، لا إلى عطل. أكد ذلك في سجلات جدار الحماية أو WAF قبل إضافة أي شيء إلى قائمة السماح؛ فإضافة القائمة ليست إصلاحاً عاماً ويجب أن تتبع الدليل لا أن تسبقه.
- [Host/CDN/App owner] اقرأ سجلات أخطاء الوكيل (Nginx أو Apache أو HAProxy) بحثاً عن مهلات انتظار الخادم الأعلى أو حالات رفض الاتصال.
- [Host/CDN/App owner] اقرأ سجلات المصدر بحثاً عن تعطل التطبيق أو عمليات إنهاء OOM أو استنفاد اتصالات قاعدة البيانات حول الطوابع الزمنية.
- [Any] تحقق مما يراه Googlebot باستخدام الاختبار المباشر في فحص عنوان URL في GSC.
- [Host/CDN/App owner] طبّق الإصلاح الخاص بالطبقة فقط بعد أن تشير السجلات أو أدلة المزوّد إليه — فتغييرات WAF وجدار الحماية والمهلة وإعداد الوكيل تغييرات في البنية التحتية، وليست تخمينات للاستجابة الأولى.
- [Any] بعد الإصلاح، اترك التعافي يحدث — تعيد استجابات 2xx الزحف تدريجياً؛ ولا تنشر Google جدولاً زمنياً دقيقاً للتعافي. استخدم «التحقق من الإصلاح» فقط لطلب إعادة فحص أسرع، لا بوصفه «إصلاحاً».
- [Host/CDN/App owner] أكد أنك تستخدم 503 (لا 502) لأي توقف مخطط له مستقبلاً.
هل خطأ 502 لدي من شبكة توصيل المحتوى أم الوكيل أم المصدر؟
خطأ 502 هو فشل بين الخوادم، لذلك شخّصه بالسير إلى أسفل المكدس بدلاً من التخمين. ابدأ من الحافة وتحرك إلى الداخل.
السؤال 1. هل يعلن مزوّد شبكة توصيل المحتوى أو DNS لديك عن عطل الآن؟
- نعم → من المرجح أنه عطل شامل لدى المزوّد (حادثة Cloudflare في نوفمبر 2025 مثال نموذجي). عادةً لا يوجد ما تصلحه من جانبك. أكد سلامة المصدر، ثم انتظر التعافي — إذ يزداد معدل زحف Google مجدداً تدريجياً بعد عودة استجابات 2xx، مع عدم نشر جدول زمني دقيق. توقف هنا.
- لا → تابع.
السؤال 2. هل يجيب المصدر برمز 2xx عند طلب مباشر (مع تجاوز شبكة توصيل المحتوى أو الوكيل)؟
- لا — يفشل المصدر أيضاً → المشكلة في طبقة المصدر. افحص في السجلات تعطل التطبيق أو PHP-FPM، أو عمليات إنهاء OOM، أو استنفاد اتصالات قاعدة البيانات، أو عملية نشر سيئة. لاحظ أن هذا قد يظهر أيضاً كخطأ 500 أو 504، بحسب الطريقة التي يراه بها الوكيل. توقف هنا.
- نعم — المصدر سليم مباشرةً، لكن شبكة توصيل المحتوى أو الوكيل يعيد 502 → تابع. المصدر سليم؛ هناك شيء أمامه لا يستطيع الحصول على استجابة نظيفة.
السؤال 3. هل تعمل المتصفحات العادية بينما لا يحصل إلا Googlebot أو عناوين IP الخاصة بشبكة توصيل المحتوى على أخطاء 502؟
- نعم → اشتبه في حجب WAF أو جدار حماية يتعامل مع نطاقات IP الخاصة بالوكيل أو الزاحف كمهاجمين. أكد ذلك أولاً في سجلات جدار الحماية أو WAF، ثم أضف نطاقات IP المشروعة لشبكة توصيل المحتوى ونطاقات عناوين IP الخاصة بالزواحف التي تم التحقق منها إلى قائمة السماح — لا تضفها من دون ذلك التأكيد. توقف هنا.
- لا — يحصل الجميع عبر الوكيل على 502 → تابع.
السؤال 4. ماذا تُظهر سجلات الوكيل العكسي عن الخادم الأعلى؟
- مهلة انتظار / رفض اتصال → يستطيع الوكيل الوصول إلى الواجهة الخلفية لكنه لا يحصل على استجابة سليمة في الوقت المناسب → مشكلة في سعة الواجهة الخلفية أو المهلة (المجموعة مستنفدة أو المهلات ضيقة جداً). ارفع السعة أو المهلات، أو أصلح الواجهة الخلفية البطيئة.
- مضيف أو DNS خاطئ / فشل مصافحة SSL إلى الخادم الأعلى → إعداد الوكيل خاطئ → أصلح كتلة
proxy_passأو upstream، أو إعداد TLS بين الوكيل والواجهة الخلفية.
أياً كانت الطبقة، فإن تنظيف تحسين محركات البحث واحد في الغالب ولا يتطلب تدخلاً مستمراً. بعد أن تعيد عناوين URL الاستجابة برمز 2xx، تستأنف Google الزحف تلقائياً — ولا حاجة إلى إعادة الإرسال.
خرافات وأخطاء 502 التي ينبغي تجنبها
- الخرافة: «خطأ 502 مشكلة في Google أو تحسين محركات البحث أصلحها في Search Console». لا. خطأ 502 فشل في الاستضافة أو البنية التحتية؛ ولا تفعل Search Console سوى الإبلاغ عنه بعد وقوعه. يحدث الإصلاح في شبكة توصيل المحتوى أو الوكيل أو المصدر. ويطلب «التحقق من الإصلاح» من Google إعادة الفحص فحسب — ولا يصلح شيئاً.
- الخرافة: «يعني خطأ 502 دائماً أن خادمي متوقف». لا. “A 502 always means my server is down.” (ترجمة) «يعني خطأ 502 دائماً أن خادمي متوقف.» قد يعيد المصدر رمز
2xxعند طلبه مباشرةً بينما يرى الزوار 502 عبر شبكة توصيل المحتوى — بسبب مهلة انتظار أو إعداد upstream سيئ أو عطل خاص بالشبكة. اختبر الاتصال المباشر بالمصدر قبل افتراض تعطل الخادم. - الخرافة: «502 أقل خطورة من 500 بالنسبة إلى تحسين محركات البحث». لا. تمنح وثائق Google رموز 500 و502 و503 الانخفاض نفسه في معدل الزحف والإزالة النهائية نفسها من الفهرس عند استمرار الأخطاء. ولا يوجد تساهل موثق مع 502.
- الخرافة: «سيؤدي خطأ 502 لمرة واحدة إلى إزالة صفحتي من الفهرس». لا. يتباطأ الزحف ثم يزداد مجدداً. يتطلب انخفاض الصفحات استمرار الخطأ — وتستخدم وثائق Google هذه الكلمة من دون تحديد عدد الأيام بدقة. ووضع تعليق Mueller غير الرسمي في نوفمبر 2025 ذلك عند عدة أيام تقريباً، وأضاف أن الصفحات المحذوفة «تعود بسرعة إلى حد ما» — تعامل مع ذلك كقراءة ممارس لحادثة واحدة، لا عتبة رسمية.
- الخرافة: «يعني 502 و503 الشيء نفسه». لا. 503 هو رمز «الخدمة غير متاحة» المقصود الذي ينبغي استخدامه للصيانة المخطط لها (مع
Retry-After)؛ أما 502 فهو فشل وكيل غير مقصود. ويؤدي الخلط بينهما في المراقبة إلى إخفاء الحوادث الحقيقية خلف فترات الصيانة المتوقعة. - الخرافة: «يصلح مسح ذاكرة التخزين المؤقت للمتصفح خطأ 502 على مستوى الموقع». هذه نصيحة لزائر يستكشف عرضه الخاص. إذا كانت شبكة توصيل المحتوى أو الوكيل أو المصدر يفشل فعلاً، فلن يغير أي إجراء في المتصفح شيئاً لأي شخص آخر.
- النمط المضاد: الضغط تلقائياً على «التحقق من الإصلاح» وتحديث GSC. أثناء ارتفاع عابر (أو عطل في شبكة توصيل المحتوى)، غالباً ما تكون أسرع خطوة صحيحة هي عدم فعل شيء سوى تأكيد التعافي. تتولى Google الزيادة التدريجية تلقائياً.
دليل الحوادث: الموقع يعيد خطأ 502
- أكد النطاق. افحص عنوان URL متأثراً واحداً باستخدام Website Down Checker ثم اختبر عناوين URL متعددة باستخدام Bulk HTTP Status Code Checker. إذا فشل متصفحك وحده، أصلح مشكلة الشبكة المحلية أو DNS قبل تصعيد حادث على مستوى الموقع. وإذا أعادت عناوين URL عامة كثيرة خطأ 502، فتابع.
- سجّل الاستجابة الفاشلة. احفظ الوقت وعنوان URL والحالة وترويسات الاستجابة وأي معرّف طلب من شبكة توصيل المحتوى. إذا كان الخطأ متقطعاً، كرر الطلب بدلاً من اعتبار إعادة محاولة ناجحة واحدة تعافياً.
- حدد البوابة — وتعامل مع العلامة التجارية كإشارة واحدة لا كإثبات. اقرأ الترويسات وصفحة الخطأ ذات العلامة التجارية بحثاً عن بصمة شبكة توصيل المحتوى أو وكيل عكسي أو موازن تحميل، لكن أكد ذلك مقابل صفحة حالة المزوّد وسجلاتك قبل استنتاج القفزة الفاشلة؛ فالصفحات والترويسات ذات العلامة التجارية خاصة بالمزوّد ولا تثبت السبب عالمياً. إذا أبلغ المزوّد عن عطل، فاتبع مسار الحادث لديه؛ وإلا واصل نحو المصدر.
- قارن الحافة بالمصدر. اطلب اسم المضيف العام بالطريقة المعتادة، ثم أرسل اسم المضيف نفسه مباشرةً إلى عنوان IP المعروف للمصدر باستخدام
curl --resolve. إذا نجح المصدر بينما أعادت الحافة 502، فافحص الاتصال من شبكة توصيل المحتوى إلى المصدر وTLS وإعداد الوكيل. وإذا فشل كلاهما، فانتقل إلى سجلات التطبيق والمصدر. - اربط السجلات حسب الطابع الزمني. يشير رفض الاتصال أو فشل TLS إلى حد البوابة أو المصدر؛ وتشير استجابة الخادم الأعلى المشوهة أو المغلقة فجأة إلى خدمة المصدر. أصلح الطبقة الفاشلة، لا Search Console.
- تحقق من التعافي. أعد فحوصات المصدر العام والمباشر معاً عبر عناوين URL ممثلة. إذا استقرت استجابات 2xx، راقب السجلات وSearch Console بينما يستأنف Googlebot الزحف تلقائياً. وإذا تكررت أخطاء 502، فارجع إلى الخطوة 4 باستخدام الطوابع الزمنية الجديدة بدلاً من زيادة المحاولات بلا تفكير.
موجه: صنّف مجموعة من أخطاء 502 حسب الطبقة
الصق ملف CSV يحتوي على عنوان URL والطابع الزمني والحالة وترويسات الاستجابة ونتيجة الحافة العامة ونتيجة المصدر المباشر وأي مقتطف سجل مطابق. أزل الأسرار وملفات تعريف الارتباط وترويسات التفويض وعناوين المصدر الخاصة أولاً.
You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.
For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.
Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.
DATA:
[PASTE SANITIZED CSV HERE]توقع قائمة فرز، لا تقريراً نهائياً للسبب الجذري. تحقق من كل فحص مقترح مقابل الترويسات والسجلات المباشرة.
إعادة إنتاج خطأ 502 العام
شغّل هذا في طرفية macOS أو Linux. يطبع ترويسات الاستجابة من دون تنزيل النص، ولا يتبع عمليات إعادة التوجيه، كي ترى الاستجابة الأولى.
curl -sS -D - -o /dev/null https://www.example.com/affected-pathالمكافئ في PowerShell:
Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheckإذا كان التطبيق يتعامل مع HEAD بطريقة مختلفة، فاستخدم GET عادياً وتخلص من النص:
Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headersمقارنة مسار شبكة توصيل المحتوى بالمصدر المعروف
استبدل 203.0.113.10 بعنوان IP لمصدر تسيطر عليه. يحافظ --resolve على اسم المضيف العام لترويسة HTTP Host واسم TLS أثناء الاتصال بذلك العنوان.
curl -sS -D - -o /dev/null \
--resolve www.example.com:443:203.0.113.10 \
https://www.example.com/affected-pathلا تكشف مصدراً محمياً ولا تضعف جدار الحماية لديه لمجرد إجراء هذا الاختبار. نفّذه من شبكة مصرح لها بالفعل. يضيّق نجاح المصدر المباشر مع خطأ 502 العام نطاق الفشل إلى مسار شبكة توصيل المحتوى أو الوكيل؛ أما الفشل في المسارين فيوجهك إلى المصدر أو التطبيق.
أدوات لتضييق نطاق خطأ 502
- Website Down Checker — أكد إمكانية الوصول إلى عنوان URL من نقطة مراقبة خارجية لدى Cloudflare، والتقط التوقيت وإعادة التوجيه وأدلة DNS محدودة. يجيب عن سؤال «هل يحدث هذا لي وحدي؟» قبل أن تبدأ في تغيير البنية التحتية.
- Bulk HTTP Status Code Checker — اختبر مجموعة ممثلة من عناوين URL، وشاهد مسارات إعادة التوجيه الكاملة ووقت الاستجابة، وصدّر النتائج. استخدمه لفصل فشل مسار واحد عن حادث 502 أوسع.
- لوحة معلومات شبكة توصيل المحتوى أو موازن التحميل لديك — طابق معرّفات الطلبات والطوابع الزمنية من الاستجابة الفاشلة مع سجلات الحافة وحالة المزوّد.
- سجلات تطبيق المصدر والخادم — أكد ما إذا كان الخادم الأعلى قبل الطلب وما إذا كان قد أعاد الاستجابة أو أعاد ضبطها أو أرسلها بشكل مشوه. هذا ما يحول فرضية الطبقة إلى سبب جذري.
لا تستطيع أي أداة تحديد الطبقة الفاشلة من 502 وحده. قارن دليل الحافة العامة بطلب مباشر مصرح به إلى المصدر وبسجلات مؤرخة.
اختبر نفسك: 502 Bad Gateway
خمسة أسئلة سريعة عن ماهية 502 وتأثيره في تحسين محركات البحث. اختر إجابة لكل سؤال، ثم تحقق منها.
موارد تستحق وقتك
كتاباتي ذات الصلة
- دليل شامل لرموز حالة HTTP لتحسين محركات البحث — موضع 502 وبقية عائلة 5xx، وما يشير إليه كل رمز لمحركات البحث.
- دليل المبتدئين إلى تحسين محركات البحث التقني — كيف ترتبط صحة الخادم بالزحف ضمن الصورة الأكبر.
- Robots.txt وتحسين محركات البحث: كل ما تحتاج إلى معرفته — ذو صلة لأن خطأ 5xx في ملف robots.txt يُعامل معاملة خاصة.
من أرجاء المجال
- كيفية تأثير رموز حالة HTTP في زواحف Google (Google Search Central) — المصدر الأساسي: تجميع
502 (bad gateway)مع 500 و503، والصياغة الدقيقة لمعدل الزحف والفهرسة. - كيفية التعامل مع توقف الموقع المخطط له (Google Search Central) — الفرق بين 503 و502 ولماذا يكون 503 رمز التوقف المقصود.
- عطل Cloudflare يسبب ارتفاع أخطاء 5xx: ماذا يعني ذلك لتحسين محركات البحث (Matt G. Southern، Search Engine Journal) — عطل نوفمبر 2025 كدراسة حالة واقعية، مع تعليقات Mueller.
- 502 Bad Gateway: مرجع MDN (MDN Web Docs) — تعريف محايد على مستوى المواصفة لرمز الحالة.
- RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — مواصفة دلالات HTTP الأساسية.
- كيفية إصلاح خطأ 502 Bad Gateway (Kinsta) — جولة شاملة لاستكشاف أخطاء المتصفح وإصلاحات المضيف من منظور صاحب الموقع.
- 502 bad gateway: معناه وكيف يمكن لمطوري الويب إصلاح هذه الأخطاء (Webflow) — نظرة عامة على الأسباب والإصلاحات للمطورين.
سجل التغييرات
تم التحديث في 6 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 6 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 17 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
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.