400 Bad Request 是通用的用戶端錯誤。伺服器認為要求有某處不對而拒絕處理，例如語法錯誤、訊息框架無效、具欺騙性的要求路由、有問題的 Host 標頭、無效的查詢參數，或無法解析的主體。用戶端不應原封不動地重送同一個要求。
許多伺服器會把原本有更具體狀態碼的問題也回應為 400。例如當標頭超出 nginx 的緩衝區時，它會回應「400 Bad Request: Request Header Or Cookie Too Large」，其實 431 會更精確；許多 API 也會對原本可以使用 422 的驗證錯誤回傳 400。
回應主體通常是找出實際原因的最佳線索。
回應範例
HTTP
HTTP/1.1 400 Bad Request
Date: Fri, 06 Nov 2026 10:15:32 GMT
Server: nginx
Content-Type: text/html
Content-Length: 217
Connection: close
<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx</center>
</body>
</html>SEO 與重新導向檢查
搜尋引擎對 400 的處理方式與其他 4xx 錯誤相同：網址不會被編入索引，而已編入索引的網址一旦開始回傳 400，就會被移除。爬蟲送出的是精簡、標準且不帶 Cookie 的要求，因此只有爬蟲才遇到的 400，通常是網址中的特殊字元或防火牆規則所造成。在重新導向檢查中，重新導向鏈中段出現 400，往往代表某次重新導向產生了格式錯誤的網址，例如字元遭到重複編碼，或查詢字串已損壞。
常見原因與使用情境
- Cookie 過多或過大。請清除該網站的 Cookie，或在 nginx 中調高
large_client_header_buffers。 - 網址格式錯誤，例如未編碼的空格、損壞的百分比編碼，或無效的
Host標頭。 - API 要求中的 JSON 無效，或缺少必要參數。
- 將一般 HTTP 要求送到 HTTPS 連接埠，nginx 會回報為「The plain HTTP request was sent to HTTPS port」。