خطای ⁦400 Bad Request⁩ چیست و چگونه رفع می‌شود؟

لینکی را از یک ایمیل، یا سایتی را که هر روز از آن استفاده می‌کنید، باز می‌کنید و صفحه‌ای سفید با ⁦"400 Bad Request"⁩ به خط درشت می‌بینید. گاهی سطر دوم چیز بیشتری می‌گوید، مانند ⁦"Request Header Or Cookie Too Large"⁩، و پایین صفحه واژه nginx آمده است. ممکن است کروم به جای آن صفحه خاکستری خودش را نشان دهد: «این صفحه کار نمی‌کند» و ⁦"HTTP ERROR 400"⁩. برنامه‌نویسان همین عدد را از یک API می‌گیرند، معمولاً همراه با یک پیام کوتاه JSON.

همه این‌ها یعنی سرور درخواستی دریافت کرده که حاضر نبوده آن را بپذیرد. در ادامه می‌خوانید این کد یعنی چه، صفحه را چه کسی فرستاده است، علت‌ها و راه‌حل‌ها برای بازدیدکننده چیست، 400 چه فرقی با 401، 403، 404 و 413 دارد و برنامه‌نویسان چه چیزهایی را باید بررسی کنند، همراه با یک نمونه بازسازی‌شده.

خطای ⁦400 Bad Request⁩ یعنی چه؟#

⁦400 Bad Request⁩ یعنی سرور از رسیدگی به درخواست خودداری می‌کند، چون خود درخواست را معیوب می‌داند. استاندارد HTTP، یعنی ⁦RFC 9110⁩، سه نمونه می‌آورد: نحو نادرست درخواست (malformed request syntax)، قاب‌بندی نامعتبر پیام (invalid message framing، یعنی طول یا مرز پیام درست مشخص نشده است) و مسیریابی فریبنده درخواست (deceptive request routing). به زبان ساده، آدرس، هدرها یا داده‌ها قاعده‌هایی را که سرور با آن‌ها کار می‌کند شکسته‌اند.

کدهای خانواده 400 مشکل‌هایی را در سمت درخواست توصیف می‌کنند، اما «خطای کلاینت» همیشه به این معنا نیست که شما کار اشتباهی کرده‌اید: کوکی‌ای که خود سایت گذاشته است می‌تواند درخواست‌های مرورگر شما را بیش از حد بزرگ کند. یک قاعده از همین تعریف بیرون می‌آید. به گفته مرجع MDN، درخواستی که بدون تغییر تکرار شود با همان خطا شکست می‌خورد؛ پس بارگذاری دوباره کمکی نمی‌کند، اما تغییر دادن درخواست کمک می‌کند.

صفحه 400 پیش روی شما را چه کسی فرستاده است؟#

سطر دوم صفحه و نامی که پایین آن آمده است نشان می‌دهند کدام برنامه درخواست را رد کرده و اغلب اینکه چرا.

سطر کروم را با یک سرور آزمایشی کوچک روی رایانه خودمان بررسی کردیم که با 400 و بدنه خالی پاسخ می‌دهد؛ در ⁦Chromium 145⁩ با زبان فارسی دقیقاً همین سطرها و یک دکمه بار کردن مجدد دیده شد. کروم این متن را خودش می‌نویسد، پس چیزی درباره علت نمی‌گوید.

خطای 400 گام‌به‌گام چگونه رخ می‌دهد؟#

هر درخواست سه بخش دارد و سرور آن‌ها را به ترتیب بررسی می‌کند:

1. خط درخواست (request line). متد و آدرس، مانند GET /search?q=shoes. نویسه‌های خاص به شکل یک % و دو رقم شانزده‌شانزدهی (هگزادسیمال) فرستاده می‌شوند که به آن کدگذاری درصدی (percent-encoding) می‌گویند؛ % بدون این دو رقم را نمی‌توان رمزگشایی کرد.
2. هدرها. سطرهایی مانند Host و User-Agent، به‌علاوه Cookie که همه کوکی‌هایی را که مرورگر برای آن سایت نگه می‌دارد با خود می‌برد. سرورها برای هر سطر هدر سقفی می‌گذارند: در nginx به‌طور پیش‌فرض 8 کیلوبایت و در Apache برابر 8,190 بایت.
3. بدنه. داده‌های فرم یا API، اغلب JSON، که برنامه قالب و فیلدهای الزامی آن را بررسی می‌کند.
4. حکم. نخستین بررسی‌ای که شکست بخورد درخواست را با 400 پایان می‌دهد، معمولاً همراه با دلیلی کوتاه.
5. تکرار. چیزی تغییر نکرده است، پس تلاش بعدی همان آدرس، کوکی‌ها و داده را می‌فرستد و همان 400 را می‌گیرد.

تفاوت 400 با 401، 403، 404 و 413 چیست؟#

400 کد کلی است؛ سرورها هرجا کد دقیق‌تری مناسب باشد آن را می‌فرستند. 401 یعنی سرور درخواست را خوانده اما می‌خواهد بداند چه کسی آن را فرستاده است؛ نوشته خطای ⁦401 Unauthorized⁩ چیست و چگونه رفع می‌شود؟ به آن می‌پردازد. آپلودی که بیش از حد بزرگ است معمولاً 413 می‌گیرد (nginx به‌طور پیش‌فرض تا 1 مگابایت بدنه درخواست را می‌پذیرد)، هرچند برخی برنامه‌ها با 400 پاسخ می‌دهند.

چرا خطای ⁦400 Bad Request⁩ می‌گیرم؟#

از سمت بازدیدکننده، این‌ها علت‌های معمول‌اند:

• آدرسی که اشتباه تایپ شده یا خراب است. لینک‌هایی که از ایمیل و برنامه‌های پیام‌رسان کپی می‌شوند بریده می‌شوند یا نویسه‌های اضافه می‌گیرند؛ % بدون دو رقم شانزده‌شانزدهی پس از آن، مانند 50%off، رمزگشایی نمی‌شود.
• کوکی‌های بیش از حد زیاد یا بزرگ برای آن سایت، علتی که پشت ⁦"Request Header Or Cookie Too Large"⁩ است.
• کوکی خراب یا کهنه. پس از آنکه سایتی سامانه ورود خود را تغییر می‌دهد، یک کوکی قدیمی ممکن است مقداری داشته باشد که کد جدید نمی‌تواند آن را بخواند.
• افزونه‌ای که درخواست‌ها را بازنویسی می‌کند، مانند افزونه‌ای که هدرها یا کوکی‌ها را ویرایش می‌کند.
• چیزی در میانه راه، به‌ندرت: نرم‌افزار امنیتی‌ای که ترافیک وب را بازرسی می‌کند، یا پروکسی‌ای که با طرح (scheme) یا پورت نادرست تنظیم شده است.

پیام ⁦"Request Header Or Cookie Too Large"⁩ یعنی چه؟#

یعنی کوکی‌هایی که مرورگر شما برای آن سایت نگه می‌دارد، همراه با بقیه هدرها، دیگر در سقف اندازه سرور جا نمی‌شوند، پس nginx درخواست را با 400 رد می‌کند. مرورگر همه کوکی‌های یک سایت را در یک هدر Cookie و با هر درخواست می‌فرستد و nginx هر سطر هدری را که از یک بافر بزرگ‌تر باشد رد می‌کند؛ این بافر به‌طور پیش‌فرض 8 کیلوبایت است، همان‌طور که مستندات large_client_header_buffers توضیح می‌دهد.

سقف‌های دو طرف با هم جور نیستند. استاندارد کوکی، یعنی ⁦RFC 6265⁩، از مرورگرها می‌خواهد دست‌کم 4,096 بایت برای هر کوکی و دست‌کم 50 کوکی برای هر دامنه نگه دارند، که روی هم بسیار بیشتر از 8 کیلوبایت است. سایتی با کوکی‌های تحلیلی و نشست فراوان می‌تواند پس از چند هفته استفاده عادی از این خط بگذرد و آن وقت خطا فقط همان یک سایت را می‌گیرد، چون فقط کوکی‌های خود آن سایت با درخواست‌هایش فرستاده می‌شوند.

IIS همین را با ⁦"HTTP 400 - Bad Request (Request header too long)"⁩ بیان می‌کند و برخی سرورها کد دقیق‌تر 431 را می‌فرستند. راه‌حل در سمت شما یکی است: کوکی‌های همان سایت را پاک کنید.

به‌عنوان بازدیدکننده، خطای 400 را چگونه رفع کنید؟#

این گام‌ها را به ترتیب پیش بروید؛ سه گام نخست یک دقیقه طول می‌کشند.

1. آدرس را بررسی کنید. آن را دوباره تایپ کنید، یا صفحه اصلی سایت را باز کنید و از آنجا پیش بروید. برای یک لینک طولانی از ایمیل، آن را بدون بخش پس از ? امتحان کنید.
2. فقط کوکی‌های همان سایت را پاک کنید. این کار شما را فقط از همان یک سایت خارج می‌کند و به سایت‌های دیگر دست نمی‌زند.
   • کروم: بیشتر > تنظیمات > حریم خصوصی و امنیت > کوکی‌های طرف سوم > دیدن همه داده‌ها و اجازه‌های سایت، نام سایت را جست‌وجو کنید، حذف را انتخاب و تأیید کنید (گام‌های گوگل).
   • اج: Settings and more > Settings > Privacy, search, and services > Cookies > See all cookies and site data (تنظیمات و موارد بیشتر > تنظیمات > حریم خصوصی، جست‌وجو و سرویس‌ها > کوکی‌ها > دیدن همه کوکی‌ها و داده‌های سایت)، نام سایت را جست‌وجو کنید، پیکان کنار آن را باز کنید و Delete (حذف) را انتخاب کنید.
   • فایرفاکس: در همان سایت روی نماد سپر کنار نوار نشانی کلیک کنید و پاک کردن کوکی‌ها و داده‌های سایت… را انتخاب کنید.
   • سافاری در مک: Safari > Settings > Privacy > Manage Website Data (سافاری > تنظیمات > حریم خصوصی > مدیریت داده‌های وب‌سایت)، سایت را انتخاب کنید و روی Remove (حذف) کلیک کنید.
3. یک پنجره ناشناس را امتحان کنید. در کروم، بیشتر > پنجره ناشناس جدید یا ⁦Ctrl+Shift+N⁩. این پنجره بدون کوکی‌های سایت شروع می‌شود و افزونه‌ها در آن خاموش‌اند، مگر اینکه خودتان اجازه داده باشید. اگر صفحه باز شد، علت یک کوکی یا یک افزونه بوده است.
4. افزونه‌ها را یکی‌یکی خاموش کنید؛ در کروم از مسیر بیشتر > افزونه‌ها > مدیریت افزونه‌ها، و از افزونه‌هایی شروع کنید که محتوا را مسدود می‌کنند یا درخواست‌ها را ویرایش می‌کنند.
5. فایل را کوچک‌تر کنید، اگر خطا هنگام فرستادن یک فایل ظاهر می‌شود.
6. بدون VPN یا پروکسی، یا با اینترنت همراه امتحان کنید. اگر صفحه باز شد، چیزی در شبکه نخست درخواست‌های شما را تغییر می‌دهد.
7. با سایت تماس بگیرید و آدرس، زمان و چیزی را که روی آن کلیک کردید بفرستید. اگر خطا چند روز پس از پاک کردن کوکی‌ها برگشت، سایت بیش از آنچه سرورش می‌پذیرد کوکی می‌گذارد.

پاک کردن کش DNS یا راه‌اندازی دوباره روتر به‌ندرت کمک می‌کند: وقتی سروری با 400 پاسخ می‌دهد، رایانه شما آن را پیدا کرده است.

برنامه‌نویسان وقتی کدشان 400 می‌گیرد چه چیزی را بررسی کنند؟#

در کد، 400 یعنی سرور درخواستی را که برنامه شما ساخته رد کرده است و بدنه پاسخ معمولاً فیلد یا قاعده مربوط را نام می‌برد. پیش از هر تغییری، بدنه را در لاگ ثبت کنید. علت‌های معمول:

• JSON نامعتبر: یک ویرگول اضافه در انتها، نقل‌قول تکی، یا رشته‌ای که دستی به هم چسبانده شده است. از رمزگذار (encoder) زبان خود استفاده کنید، مانند JSON.stringify یا json.dumps.
• هدر Content-Type که با بدنه جور نیست، مثلاً JSON که با نوع فرم فرستاده شده است.
• پارامترهای جاافتاده یا نادرست: فیلد الزامی‌ای که فراموش شده، عددی که به شکل متن فرستاده شده، تاریخی با قالب نادرست.
• رشته‌های پرس‌وجوی دست‌ساز (query string). فاصله، & و % درون مقدارها باید کدگذاری شوند؛ URLSearchParams یا urllib.parse.urlencode این کار را برایتان انجام می‌دهند.
• هدرهایی که سرور نمی‌پذیرد. یک کوکی بزرگ یا یک توکن طولانی می‌تواند از سقف هر هدر بگذرد: 8 کیلوبایت در nginx، LimitRequestFieldSize در Apache و MaxFieldLength در IIS. HTTP/1.1 همچنین برای هدر Host جاافتاده یا تکراری پاسخ 400 را الزامی می‌کند.
• عادت‌های HTTP/1.1 در HTTP/2. HTTP/2 نام هدرها را با حروف کوچک الزامی می‌کند و هدرهای اتصال مانند Connection و Keep-Alive را ممنوع می‌کند؛ سرور چنین درخواستی را بازنشانی (reset) می‌کند یا با 400 پاسخ می‌دهد. این اتفاق وقتی می‌افتد که کد یا یک پروکسی هدرهای HTTP/1.1 را به HTTP/2 منتقل کند.

بازسازی یک 400 برای JSON معیوب#

یک سرور کوچک Node.js را روی رایانه خودمان اجرا کردیم که وقتی بدنه یک سفارش JSON معتبر نیست با 400 پاسخ می‌دهد، سپس با curl -i (گزینه -i سطر وضعیت و هدرها را چاپ می‌کند) یک درخواست فرستادیم که بدنه‌اش یک ویرگول اضافه در انتها دارد:

curl -i http://127.0.0.1:18400/api/orders -H "Content-Type: application/json" -d '{"product": "sku-123", "qty": 2,}'

خروجی (⁦curl 8.22⁩ روی ویندوز 11، ⁦Node.js 24⁩):

HTTP/1.1 400 Bad Request
Content-Type: application/json
Date: Thu, 12 Nov 2026 01:21:06 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

{"error":"invalid JSON","detail":"Expected double-quoted property name in JSON at position 32 (line 1 column 33)"}

در پیام، position 32 همان } درست پس از ویرگول است: JSON هیچ ویرگولی را پیش از آکولاد بسته نمی‌پذیرد. آن را حذف کنید تا بدنه معتبر شود. یک API واقعی پیامش را به شکل دیگری می‌نویسد، اما الگو همین است: سطر وضعیت می‌گوید درخواست نادرست است و بدنه می‌گوید کجا.

پشت پروکسی چه چیزی تغییر می‌کند؟#

اگر پروکسی درست تنظیم شده باشد، هیچ چیزی در درخواست تغییر نمی‌کند. برای آدرس https:// کلاینت با یک درخواست CONNECT از پروکسی می‌خواهد تونلی باز کند و پروکسی بایت‌ها را بی‌آنکه بخواند در دو جهت عبور می‌دهد؛ پس پاسخ 400 که برمی‌گردد حکم خود سایت است. یک اشتباه رایج در تنظیم، طرحی است که با پورت جور نیست: یک درخواست ساده http:// روی پورتی که HTTPS انتظار دارد، پیام ⁦"The plain HTTP request was sent to HTTPS port"⁩ را از nginx می‌گیرد. با پروکسی HTTPS، میزبان، پورت و طرح را دقیقاً همان‌طور که سازنده نقطه اتصال نشان می‌دهد کپی کنید.

اسکرپر با 400 چگونه باید رفتار کند؟#

به‌عنوان باگی در درخواست خودش، نه مسدودسازی. تکرار بدون تغییر همان 400 را برمی‌گرداند و استخر پروکسی مسکونی آدرسی را که سایت می‌بیند تغییر می‌دهد، نه درخواستی را که کد شما می‌فرستد. دست نگه دارید، درخواست و بدنه پاسخ را در لاگ ثبت کنید و چیزی را که نام می‌برد درست کنید.

برخی کدهای دیگر واقعاً ارزش تلاش دوباره دارند، مانند 503 پس از یک مکث؛ کدهای وضعیت HTTP در وب اسکرپینگ آن‌ها را از کدهایی که یعنی توقف جدا می‌کند.

کجا ممکن است با 400 روبه‌رو شوید#

• سایتی که هر روز به آن سر می‌زنید و ناگهان ⁦"Request Header Or Cookie Too Large"⁩ نشان می‌دهد.
• لینک‌های طولانی در ایمیل‌ها، برنامه‌های پیام‌رسان و خبرنامه‌ها که در راه بریده می‌شوند.
• فرم‌های آپلود با سقف اندازه‌ای که صفحه به آن اشاره نمی‌کند.
• دکمه‌های ورود با گوگل در برنامه‌هایی که تنظیماتشان نادرست است، با کد ⁦"Error 400"⁩.
• فراخوانی‌های API از اسکریپت‌ها، Postman و ابزارهای بدون کدنویسی (no-code) پس از تغییر نام یا نوع یک فیلد.

اشتباه‌های رایج#

• پاک کردن همه داده‌های مرور. این کار شما را از همه سایت‌ها خارج می‌کند؛ فقط کوکی‌های سایتی که خطا می‌دهد اهمیت دارند.
• بارگذاری دوباره، بارها و بارها. درخواست تغییر نمی‌کند، پس پاسخ هم تغییر نمی‌کند.
• مقصر دانستن اتصال. 400 یعنی درخواست رسیده است.
• برنامه‌نویسان: تکرار یک 400 در حلقه یا چرخاندن آدرس‌های آی‌پی برای آن، و ثبت کد وضعیت در لاگ بدون بدنه.
• صاحبان سایت: بالا بردن سقف هدرها به جای کم کردن کوکی‌ها. خود استاندارد کوکی به سرورها توصیه می‌کند کوکی‌ها را کم‌شمار و کوچک نگه دارند.

راهنمای انتخاب#

پرسش‌های متداول#

آیا خطای 400 تقصیر من است یا تقصیر سایت؟#

می‌تواند هر دو باشد؛ این کد فقط می‌گوید درخواست معیوب بوده است. غلط تایپی یا افزونه در سمت شماست، کوکی بیش از حد بزرگ را خود سایت گذاشته است و پاسخ 400 از یک API باگی در کد فراخواننده است.

چرا فقط در یک سایت خطای ⁦400 Bad Request⁩ می‌گیرم؟#

چون علت معمولاً در کوکی‌ها یا سقف‌های همان سایت است: هر سایت فقط کوکی‌های خودش را دریافت می‌کند و سقف‌های اندازه خودش را تعیین می‌کند. کوکی‌های همان سایت را پاک کنید؛ اگر پنجره ناشناس هم همان خطا را نشان داد، سایت باید آن را درست کند.

آیا VPN یا پروکسی می‌تواند باعث خطای 400 شود؟#

به‌ندرت. VPN، و پروکسی‌ای که HTTPS را تونل می‌کند، درخواست شما را بدون تغییر عبور می‌دهند، پس 400 از سایت می‌آید. اگر خطا فقط با پروکسی روشن ظاهر می‌شود، طرح و پورت آن را بررسی کنید؛ نرم‌افزار امنیتی‌ای که ترافیک را بازرسی می‌کند هم می‌تواند هدرها را تغییر دهد.

خطای ⁦400 Bad Request⁩ را در آیفون یا گوشی اندروید چگونه رفع کنم؟#

در اندروید، سایت را در کروم باز کنید، در بالا روی نماد اطلاعات صفحه کنار نوار نشانی بزنید، سپس کوکی‌ها و داده‌های سایت را باز کنید و کنار داده‌های ذخیره‌شده روی حذف بزنید. در آیفون، نخست یک زبانه خصوصی سافاری را امتحان کنید؛ اگر کار کرد، مسیر Settings > Apps > Safari > Advanced > Website Data > Remove All Website Data (تنظیمات > برنامه‌ها > سافاری > پیشرفته > داده‌های وب‌سایت > حذف همه داده‌های وب‌سایت) آن را پاک می‌کند، اما شما را از همه سایت‌ها خارج می‌کند.

چرا در Postman خطای ⁦400 Bad Request⁩ می‌گیرم؟#

معمولاً به خاطر بدنه یا نوع آن. وقتی بدنه raw روی JSON تنظیم شده باشد، Postman هدر Content-Type متناسب را اضافه می‌کند، اما هدری که خودتان وارد کرده‌اید بر آن مقدم است. JSON و پارامترهای الزامی را بررسی کنید و سپس بدنه پاسخ را بخوانید.

پیام ⁦"Error 400: redirect_uri_mismatch"⁩ یعنی چه؟#

وقتی ظاهر می‌شود که برنامه‌ای شما را برای ورود به گوگل می‌فرستد: آدرس بازگشتی که برنامه به گوگل داده است با هیچ‌یک از آدرس‌های ثبت‌شده برای آن برنامه جور نیست. فقط توسعه‌دهنده برنامه می‌تواند آن را در تنظیمات Google Cloud خود درست کند.

خلاصه#

خطای ⁦400 Bad Request⁩ یعنی سرور درخواست شما را دریافت کرده و آن را به همان شکلی که بود نپذیرفته است. بازدیدکننده‌ها آدرس را بررسی می‌کنند، کوکی‌های همان یک سایت را پاک می‌کنند، پنجره ناشناس را امتحان می‌کنند و افزونه‌ها را خاموش می‌کنند. برنامه‌نویسان بدنه پاسخ را می‌خوانند، JSON، هدرها یا پارامترها را درست می‌کنند و هرگز یک 400 را بدون تغییر دوباره امتحان نمی‌کنند. اگر برای پایش یا جمع‌آوری داده به پروکسی نیاز دارید، انواع آن را در صفحه پروکسی ما مقایسه کنید.