400 Bad Request: لماذا ترفض الخوادم الطلبات وكيف تصلح ذلك
400 Bad Request يعني أن الخادم رفض معالجة طلب يراه مشوهًا، كرابط معطوب أو ترويسات غير صالحة أو كوكي كبير جدًا.
400 Bad Request هو رفض الخادم معالجة طلب لأن فيه ما يبدو معطوبًا: رابط مشوه أو ترويسات غير صالحة أو كوكي كبير جدًا أو جسم لا يستطيع التطبيق تحليله. وبمصطلحات HTTP هو خطأ من العميل، لكن السبب في موقع الويب كثيرًا ما يكون روابط الموقع نفسه أو الكوكيز أو إعداداته.
التعريف
يصف RFC 9110، القسم 15.5.1 الرمز 400 بأنه عجز الخادم عن معالجة الطلب أو عدم رغبته في ذلك «بسبب ما يُعدّ خطأً من العميل»، مثل صياغة الطلب المشوهة أو تأطير الرسالة غير الصالح أو توجيه الطلب المخادع. وهو رمز 4xx العام: عندما لا يناسب رمز أكثر تحديدًا، ترسل الخوادم 400.
الأسباب الشائعة
- ترويسات أو كوكيز كبيرة جدًا. يرد Nginx بـ «400 Bad Request: Request Header Or Cookie Too Large» عندما تتجاوز الترويسات
large_client_header_buffers؛ ويرفض Apache حقول الترويسات الأطول منLimitRequestFieldSize(8190 بايت افتراضيًا). - روابط مشوهة: ترميز نسبة مئوية مكسور مثل
%شاردة أو%zz، أو مسافات خام أو محارف تحكم، وغالبًا من روابط نُسخت من رسائل البريد أو ملفات PDF. - إرسال HTTP عادي إلى منفذ HTTPS: يرد Nginx بـ «400 The plain HTTP request was sent to HTTPS port».
- مشاكل ترويسة Host، كأن يرفض Django أسماء مضيفين غير موجودة في
ALLOWED_HOSTS. - مدخلات API غير صالحة: JSON مشوه أو معاملات مطلوبة ناقصة.
- قواعد أمنية في WAF أو إضافة ترد على الطلبات المشبوهة بـ 400.
التأثير على السيو
تقول وثائق Google إن جميع أخطاء 4xx عدا 429 تُعامل بالطريقة نفسها: يخبر Googlebot مرحلة الفهرسة بأن المحتوى غير موجود، وتُزال الروابط المفهرسة، ويُتجاهل أي محتوى في الرد. وتظهر هذه الروابط في Search Console تحت «Blocked due to other 4xx issue». لذلك فإن 400 على صفحة حقيقية ضار مثل 404 وأصعب في الملاحظة، لأن الصفحة قد تعمل جيدًا في متصفحك أنت.
وهذا هو الفخ الكلاسيكي: قد يصيب 400 ناجم عن ترويسة أو كوكي الزواحف بينما ترى أنت صفحة عادية، أو العكس. اختبر دائمًا من عميل نظيف لا من متصفحك المسجَّل الدخول فيه.
كيف تصلح 400
لأصحاب المواقع
- افحص الرابط بحثًا عن أخطاء إملائية أو علامات
%أو مسافات شاردة، وأصلح الرابط الذي أنتجه. - إذا كنت وحدك ترى الخطأ، فامسح كوكيز الموقع؛ فالكوكي المتضخم هو السبب الأكثر شيوعًا في المتصفحات.
- راجع سجلات CDN أو إضافة الأمان بحثًا عن طلبات محظورة وقت حدوث الخطأ.
للمطورين
ارفع حدود الترويسات فقط إذا كانت الطلبات المشروعة تحتاج ذلك، وأبقِ الكوكيز خفيفة:
# Nginx (في كتلة http أو server)
large_client_header_buffers 4 16k;
# Apache
LimitRequestFieldSize 16380
في واجهات API أعد 400 مع رسالة واضحة، واستخدم 422 عندما تكون الصياغة سليمة لكن القيم تفشل في التحقق. ولا تعد 400 لروابط الصفحات العادية التي تحمل معاملات استعلام غير معروفة؛ تجاهل المعاملات أو وجّه وسم canonical إلى الرابط النظيف.
كيف تتحقق
ألصق الروابط المتأثرة في أداة فحص حالة HTTP التي تطلبها من خوادمنا دون كوكيز متصفحك، وافحص الرد كاملًا بـ أداة فحص ترويسات HTTP. وهذا رد Nginx نموذجي:
HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: text/html
Content-Length: 248
Connection: close
<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
... الأسئلة الشائعة
لماذا يظهر لي 400 Bad Request في موقع واحد فقط؟
غالبًا بسبب كوكي تالف أو كبير جدًا لذلك الموقع. امسح كوكيز ذلك الموقع وأعد التحميل؛ فإذا اختفى الخطأ فعلى الموقع أن يُبقي كوكيزه أصغر.
هل يضر خطأ 400 بالسيو؟
نعم، إذا أصاب صفحات حقيقية. تعامل Google الرمز 400 مثل رموز 4xx الأخرى: لا يُفهرس الرابط، وإن كان مفهرسًا فيُزال.
ما الفرق بين 400 و422؟
الرمز 400 يعني أن الطلب نفسه مشوه، مثل JSON مكسور. والرمز 422 يعني أن الطلب سليم الصياغة لكن البيانات تفشل في التحقق، كعنوان بريد إلكتروني غير صالح.