400 Bad Requestとは
400 Bad Request（フォー・ハンドレッド・バッド・リクエスト）は、要求の書式や内容が不正で、サーバーが処理できないことを示すステータスです。
RFCでは、要求の構文が不正、メッセージの区切り方を解釈できない、転送先を誤認させる指定があるなど、サーバーがクライアント側の問題と認識して処理できない、または処理しない広い条件を表します。
400は「入力値が何でも間違い」という万能コードではありません。認証なら401、権限なら403、資源不在なら404、メディア種類なら415など、より具体的なステータスが適する場合があります。
代表的な原因
不正な区切り、許容外の文字、壊れた対象指定などが該当します。
内容の長さや転送時の区切りが曖昧だと、リクエストスマグリング攻撃にもつながります。
Host、権威情報、転送された情報の組み合わせを確認します。
APIが400を選ぶ場合は、項目別のエラーを安全な本文で返します。
どの層が返したかを調べる
- 要求を最小化するメソッド・URI・必須ヘッダー・最小本文だけで再現します。
- 通信上のメッセージを確認するクライアントログだけでなく、プロキシ通過後のヘッダー・符号化・長さを確認します。
- 中継点ごとのログを照合するCDN、負荷分散装置、Webサーバー、アプリケーションのどこまで届いたかを追います。
- 正常要求との差分を取るContent-Type、文字集合、問い合わせ符号化、Cookie 大きさなどを比較します。
JSON構文と構造定義を分ける
JSON自体が閉じていない、UTF-8として不正、Content-Typeと実体が違うなら要求を読めず400が自然です。構文は正しいが必須項目不足・型不一致なら、API方針により400または422 Unprocessable Contentなどを選びます。
クライアントへは修正可能な項目・制約・関連付けIDトークンを返し、呼び出し履歴追跡情報、SQL、ファイルパス、秘密情報、認証トークンを含めません。詳細は保護されたサーバーログへ残します。
再送前に要求を直す
400は同じメッセージをそのまま再送しても通常は改善しません。時計ずれや一時的なプロキシ変換が原因でない限り、構文・ヘッダー・本文を修正してから送ります。自動再試行は無限ループと負荷増加を招きます。
400はサーバーがクライアントエラーと認識した要求自体の処理拒否です。構文、境界処理、経路制御、アプリケーション側の入力検証を分け、どの中継点が返したかと正常要求との差分から直します。
400の構文・メッセージ境界・経路指定の定義：RFC 9110「400 Bad Request」