HTTP 400 Bad Request

HTTP 400 の意味

HTTP 400 Bad Request は、サーバーがリクエストを読み取り、実質的な処理を行う前に無効として拒否したことを意味します。これはクライアントエラーの受け皿的存在です: 不正な形式の構文、無効なパラメータ、破損したクッキーやヘッダーなど、サーバーが処理を拒否するあらゆるケースが含まれます。

401 や 403 とは異なり、400 は権限について何も語りません — リクエストは到着した時点ですでに壊れていました。API では、どのフィールドがバリデーションに失敗したかを正確に説明する JSON ボディが添付されることがよくあります。

400 エラーのよくある原因

• リクエストボディ内の不正な形式の JSON や XML（末尾のカンマ、誤った引用符、切り詰められたペイロード）です。
• クエリパラメータの欠落や無効な値、またはサーバー側のバリデーションに失敗した値です。
• 破損または肥大化したクッキー — 大規模サイトで特定のユーザーにのみ持続的な 400 が発生する典型的な原因です。
• 誤った Content-Type ヘッダーにより、サーバーがボディを間違った形式として解析しています。
• URL エンコードのミス: クエリ文字列内のエスケープされていないスペース、引用符、非 ASCII 文字です。

ユーザーとしての対処法

• ページを再読み込みしてください。400 が続く場合は、そのサイトのクッキーをクリアしてください — 破損したクッキーが最も一般的な原因です。
• コピー＆ペーストで文字が壊れていないか、URL にタイプミスがないか確認してください。
• 拡張機能がリクエストを書き換えていないか確認するため、シークレットウィンドウで試してください。

開発者としての対処法

• 送信前に JSON ペイロードを検証し、サーバーが受信した正確なリクエストボディをログに記録してください。
• どのフィールドが無効かを示すレスポンスボディを返してください — 何も示さない 400 は誰のデバッグ時間も無駄にします。
• ヘッダーやクッキーサイズに関するサーバーの制限を確認してください（nginx の large_client_header_buffers など）。
• API が両者を区別する場合、形式は正しいが意味的に無効な入力には 422 を使用してください。

レスポンス例

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error":"validation_failed","field":"email","message":"not a valid address"}

よくある質問