400 Bad Request とは？原因と解決方法

400 Bad Request エラーとは？

400 Bad Request は HTTP ステータスコードの一つで、サーバーがリクエストを受け取ったものの、リクエスト自体に問題があるように見えるため処理しないことを意味します。HTTP の標準仕様（RFC 9110 の 15.5.1 節）では、不正な構文、無効なメッセージフレーミング、偽装されたリクエストルーティングなど、「クライアントエラーとみなされる何らかの理由により」サーバーがリクエストを処理できない、または処理しない状態と定義されています。

サーバーが壊れたことを意味する 500 エラーとは違い、400 はリクエストの側に原因があると指摘しています。つまり、ブラウザやアプリが送った URL、ヘッダー、Cookie、データのいずれかです。ウェブサイト自体は、他の人にとっては通常どおり動作しています。

訪問者にとってはこれは良い知らせです。たいていはあなたの側で1分ほどで直せるからです。400 エラーの大半は、入力ミスのあるリンクか破損した Cookie が原因です。

400 エラーはどう表示されるか

表示されるメッセージはサーバーソフトウェアによって異なり、追加のテキストが原因を知る最大の手がかりになることがよくあります。

400 Bad Request の原因

• 不正な形式の URL。 余分な % 記号、スペース、エンコードすべきだった文字、途中で切れたリンクや二重に貼り付けられたリンクなどです。

• 破損した、または大きすぎる Cookie。 ログイン、A/B テスト、アクセス解析などで多くの Cookie を設定するサイトでは、Cookie ヘッダーがサーバーの上限を超えることがあります。更新中に破損した Cookie が拒否されることもあります。

• 大きすぎるリクエストヘッダー。 Cookie 以外にも、長い認証トークンや、拡張機能・プロキシが追加するヘッダーが積み重なります。

• API に送られた無効なデータ。 必須フィールドの欠落、不正な形式の JSON、誤った Content-Type ヘッダーなどです。

• HTTPS ポートに送られた HTTP。 ロードバランサーやリバースプロキシの背後でよく起こります。

• 大きすぎるファイル。 多くのサーバーは 413 Content Too Large を返しますが、アプリやフレームワークによっては代わりに 400 を返します。

解決策1：URL を確認する

アドレスバーをよく見てください。注意すべき問題は次のとおりです。

• 後ろに16進数の2文字が続かない %（%20 は問題なし、%2 や %zz は不正）。

• スペース、{ }、|、\ などの特殊な文字。特にメール、PDF、チャットアプリからコピーしたリンクに注意してください。

• 二重に貼り付けられたリンク（https://example.com/https://example.com/...）や、途中で切れたリンク。

• トラッキングパラメーター付きの非常に長い URL。? 以降をすべて削除して、もう一度試してください。

他のサイトのリンクからアクセスした場合は、代わりにそのサイトのトップページを開き、そこから目的のページに移動してください。

解決策2：そのサイトだけの Cookie を削除する

以前に利用したことのあるサイトでの 400 エラーは、ほとんどがこれで直ります。特に、Cookie やヘッダーが「too large」や「too long」と表示されるメッセージに有効です。すべてのサイトの Cookie を消す必要はなく、そのサイトの分だけで十分です。

• Chrome / Edge： アドレスバーの左端のアイコンをクリック → Cookie とサイトデータ（または サイトの設定）→ そのサイトのデータを削除して再読み込みします。

• Firefox： 鍵アイコンをクリック → Cookie とサイトデータを消去…

• Safari（Mac）： Safari → 設定 → プライバシー → Web サイトデータを管理… → サイトを検索 → 削除。

• iPhone： 設定 → アプリ → Safari → 詳細 → Web サイトデータ → サイトを左にスワイプして削除します。

解決策3：シークレットモードで試し、キャッシュを削除する

シークレット / プライベート ウィンドウでページを開いてください（Chrome と Edge は Ctrl + Shift + N、Firefox は Ctrl + Shift + P、Safari は Cmd + Shift + N）。プライベートウィンドウは Cookie も拡張機能もない状態で始まるため、そこでページが表示されるなら、解決策2または解決策4で恒久的に直せます。

シークレットモードでも失敗する場合は、ブラウザのキャッシュを削除し（Ctrl + Shift + Delete → キャッシュされた画像とファイル）、最後の手段として DNS キャッシュをフラッシュ します。DNS が 400 の原因になることはまれですが、サイトがサーバーを移転した後は、古いアドレスのせいでリクエストを拒否するサーバーにつながってしまうことがあります。

解決策4：拡張機能を無効にし、ファイルサイズを確認する

プライバシーツール、ヘッダー編集ツール、クーポン検索ツール、一部の広告ブロッカーなど、リクエストを書き換える拡張機能は、サーバーが拒否するような形でヘッダーを追加・変更することがあります。すべて無効にして再読み込みし、1つずつ有効に戻して原因を見つけてください。

アップロード時にエラーが出る場合は、より小さなファイルで試してください。画像を圧縮するか、大きなファイルを分割します。これにより、413 ではなく 400 として報告されている場合でも、サーバーがサイズを理由に拒否しているかどうかがわかります。

サイト管理者向け：400 エラーの原因を見つける

ユーザーからサイトで 400 エラーが出ると報告があった場合は、ユーザーが見ている正確なメッセージとサーバーログから調べ始めましょう。nginx と Apache は理由を info レベルで記録するため、見当たらない場合は一時的にエラーログのレベルを上げてください。アクセスログでは、どの URL が 400 を返しているかがわかります。DNS Robot の HTTP ヘッダーチェック ツールでは、ステータスコード、サーバーソフトウェア、ページが送るすべての Set-Cookie ヘッダーを確認でき、増え続ける Cookie を見つけるのに役立ちます。

# どのリクエストが 400 を返しているか？（nginx の combined ログ形式）
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# nginx が記録した理由（error_log ... info; の設定が必要）
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

「Request Header Or Cookie Too Large」

nginx はリクエストヘッダーを large_client_header_buffers で設定されたバッファに読み込みます。デフォルトは 8 KB のバッファが4つ です。1行のヘッダー（通常は Cookie ヘッダー）が1つのバッファに収まらないと、この 400 が発生します。Apache で同等の上限は LimitRequestFieldSize で、デフォルトは 8,190 バイトです。

正しい解決策は 送るデータを減らす ことです。不要になった Cookie を削除し、セッション Cookie を小さく保ち、Cookie の有効範囲を実際に使うパスやサブドメインに限定してください。大きなシングルサインオンのトークンなどで、どうしても大きなヘッダーが必要な場合は、上限を引き上げます。

# nginx（http または server ブロック）
large_client_header_buffers 4 16k;

# Apache での同等の設定（httpd.conf / vhost）
# LimitRequestFieldSize 16380

「The plain HTTP request was sent to HTTPS port」

nginx は、TLS を想定しているポート（通常は 443）に何かが平文の HTTP を送ると、この 400 を返します。よくある原因は、ロードバランサーやプロキシが http:// の通信をポート 443 に転送している、http://example.com:443 のようなリンクがある、あるいは古い ssl on; 設定のせいで本来 TLS を想定すべきでないポートが TLS を待ち受けている、といったものです。

各 listen 行が、実際に届く通信と一致しているか確認してください。HTTPS には listen 443 ssl;、平文の HTTP には listen 80; を使い、80 から 443 へリダイレクトします。また、前段のプロキシが 443 には HTTPS で（80 には HTTP で）通信していることも確認しましょう。

API から返される 400 エラー

API は、バリデーションに失敗したリクエストに 400 を返します。API を呼び出している場合は、レスポンスボディを読んでください。ほとんどの API は、どのフィールドが間違っているかを説明しています。そのうえで、有効な JSON を送っているか、正しい Content-Type: application/json ヘッダーを付けているか、必須パラメーターがすべてそろっているかを確認します。

API を開発している場合は、問題を明示したボディを返しましょう（例：{"error": "email is required"}）。また、形式は正しいが意味的に無効なリクエストには 422 Unprocessable Content を使い、400 はまったく解析できないリクエスト用に残しておくことも検討してください。

400 と 401・403・404・413・429・431 の違い

関連するエラーのガイド：403 Forbidden、401 Unauthorized、429 Too Many Requests。失敗せずにリダイレクトがループする場合は ERR_TOO_MANY_REDIRECTS を参照してください。リダイレクトチェッカー では、リダイレクトの各ステップを確認できます。