HTTPQUERY
日本語

400 Bad Request

使い方

400 Bad Request エラーが届いた場合、失敗についてより詳しく知るためにメッセージボディを調べる責任はクライアントにあります。サーバーは、クライアントが問題を是正できるだけの十分な詳細を返します。400 Bad Request レスポンスの一般的な原因には次のようなものがあります。

これらのエラーが発生した場合、クライアントは URL を再確認する、ブラウザのクッキーを消去する、再送信の前に過大なファイルを圧縮する、といった対応を試みます。

注意

400 エラーはクライアントエラー(リクエストの形式が不正)であるのに対し、500 エラーはサーバーの障害(有効なリクエストの処理中にサーバーが壊れた)です。400 は一時的なものではありません。同じリクエストを再試行しても同じエラーになります。クライアントは再試行の前にリクエストを修正しなければなりません。不正な形式のヘッダーを注入するブラウザ拡張機能やアドウェアは、予期しない 400 エラーのよくある原因です。拡張機能を無効化すると問題の切り分けに役立ちます。

SEO への影響

Google のような検索エンジンは、400 ステータスを返す URL をインデックスしません。以前にインデックスされていた URL がこのステータスコードを返すようになると、検索結果から削除されます。このコードを返すページはクロールバジェットを消費しません。

例

クライアントがパスに波かっこ文字を含むリソースを要求します。これらは URL において有効ではないため、サーバーは 400 Bad Request で応答します。

リクエスト

GET /index{15}.html HTTP/1.1
Host: example.com

レスポンス

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 131

<html>
  <head>
    <title>Malformed URL</title>
  </head>
  <body>
    <p>Invalid characters in HTTP request</p>
  </body>
</html>

対処方法

400 Bad Request は、クライアント側の書式の問題によりサーバーがリクエストを拒否したことを意味します。

URL にエンコードの誤りがないか確認します。波かっこ、空白、非 ASCII 文字などの特殊文字にはパーセントエンコーディングが必要です。リクエストパスとクエリ文字列の全体を調べます。不正なバイト列を検出するため、URL をバリデーターにかけます。

リクエストヘッダーを検証します。不正な形式の Host ヘッダー、過大な Cookie ヘッダー、必須ヘッダーの欠落がこのエラーを引き起こします。ヘッダーを API 仕様と照合します。リクエストとともに送信された生のヘッダーを調べるには、ブラウザの DevTools(Network タブ)または curl -v を使います。

リクエストボディに構文エラーがないか調べます。無効な JSON、壊れたフォームエンコーディング、Content-Type ヘッダーと実際のボディ形式の不一致は拒否の原因になります。送信前にリンターで JSON ペイロードを検証します。

ブラウザのキャッシュとクッキーを消去します。破損した、または期限切れのクッキーは不正な形式のリクエストヘッダーを生みます。サーバーのバッファ上限を超える大きなクッキー値は頻出のきっかけです。保存されたデータを消去して再試行します。

Content-Length を実際のボディサイズと照合します。宣言されたバイト数と送信されたバイト数が一致しないと、bad request レスポンスになります。

サーバー側のサイズ制限を確認します。nginx は、large_client_header_buffers(デフォルト:8 KB のバッファ4つ)で設定されたバッファを超える過大なヘッダーを 400 で拒否します。nginx.conf で値を増やします。

large_client_header_buffers 4 16k;

Apache は LimitRequestFieldSize(デフォルト 8190 バイト)と LimitRequestLine を適用します。サーバー設定または仮想ホストでこれらを引き上げます。

LimitRequestFieldSize 16384
LimitRequestLine 16384

正確な原因を特定するためにデバッグログを有効化します。nginx は info レベルで拒否の理由をログに記録します。error_log を info に設定し、/var/log/nginx/error.log を確認します。Apache は LogLevel info で、問題となったヘッダー名をエラーログに記録します。

リバースプロキシのヘッダー転送を調べます。nginx や Apache がリバースプロキシとして動作している場合、Host、X-Forwarded-For、X-Real-IP の各ヘッダーが誤って設定されていると、バックエンドがリクエストを拒否します。proxy_set_header ディレクティブが有効な値を渡していることを確認します。

コードリファレンス

.NET

HttpStatusCode.BadRequest

Rust

http::StatusCode::BAD_REQUEST

Rails

:bad_request

Go

http.StatusBadRequest

Symfony

Response::HTTP_BAD_REQUEST

Python3.5+

http.HTTPStatus.BAD_REQUEST

Java

java.net.HttpURLConnection.HTTP_BAD_REQUEST

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_BAD_REQUEST

Angular

@angular/common/http/HttpStatusCode.BadRequest