400 Bad Requestとは｜HTTP error 400の原因と直し方・実例

サーバーは、届いたリクエストを「大きさは上限内か」「形式を受け付けるか」「構文として読めるか」「内容は決まりに合うか」の順に見ます。「読めない」が400で、それ以外の段で止まると 413（本文が大きい）・414（URL が長い）・431（ヘッダーが大きい・Node.js）・415（形式）・422（内容）のように別の番号になります。nginx はヘッダーの超過も400で返します。

flowchart TD
    R[リクエストが届く] --> A[大きさが上限を超えた?<br>→ 413 本文 / 414 URL / 431 ヘッダー]
    A -->|上限内| C[形式を受け付けない?<br>→ 415]
    C -->|受け付ける| S[構文として読めない?<br>→ 400 Bad Request]
    S -->|読める| V[内容が決まりに反する?<br>→ 422 または 400]
    V -->|合っている| OK[200 OK]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04 の上で、nginx 1.24.0（Ubuntu）を自分の設定ファイルで 127.0.0.1 のポートに起動し、大きすぎる Cookie・長すぎる URL・壊れたリクエスト行・不正な Content-Length・壊れたパーセントエンコードで400と414を返しました。背後の API は Express 5.3.0（Node.js 22.23.4）と FastAPI 0.162.0（Starlette 1.10.0・pydantic 2.14.1・uvicorn 0.54.0・Python 3.13.18）で作り、nginx から中継しています。応答は curl 8.5.0 の curl -v と、生のバイト列を送るときは nc で確かめ、ブラウザの表示は Chromium 153.0.8010.12（playwright 1.63.0・英語の画面）で確かめました。400・413・414・415・422 の定義は MDN（RFC 9110 を出典とする解説）、nginx の上限は nginx の公式ドキュメント、Express の本文の読み取りは body-parser の公式ドキュメント、FastAPI の既定の動きは公式ドキュメント、検索への影響は Google 検索セントラルで確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

400 Bad Requestとは（意味と、誰が返しているか）

この節では、400の正確な意味と、「誰が400を返したか」を最初に見分ける理由が分かります。

400 Bad Request は、サーバーがクライアントの誤りとみなした理由で、リクエストを処理しなかったことを示すステータスコード（サーバーが返す3桁の結果番号）です。 MDN は次のように説明しています。

400 レスポンスの理由は、通常、リクエスト構文が不正であったり、リクエストメッセージのフレームが不正であったり、リクエストルーティングが不正であったりするものです。

つまり「サーバーが壊れている」のではなく、「送られてきたものの形がおかしい」のが400です。MDN は、400を受け取ったクライアントは、リクエストを変えずに繰り返しても同じエラーで失敗すると想定すべきだ、とも書いています。何度も再読み込みしても直らないのはこのためです。

400は、アプリケーションに届く前の層でも返されます。手元では、nginx（Web サーバー）・Node.js（Express の土台）・Express の本文の読み取り・FastAPI の入力チェック、の4か所がそれぞれ別の文言で400を返しました。直す場所が違うので、最初に「どの層が返したか」を見分けます。

400エラーの原因一覧（見る人・作る人別）

この節では、400になる原因を「見ている人の操作で直るもの」と「サイトや API を作る側で直すもの」に分けて一覧で確認できます。

400エラーが出たときの直し方（見ている人向け）

この節では、Web サイトを見ていて「400 Bad Request」「HTTP ERROR 400」が出たときに、自分でできることが順番に分かります。

順番は「URL → 再読み込み → Cookie → 別の環境」です。 一番多いのは Cookie が大きくなって nginx などの上限を超える場合で、そのサイトの Cookie を消すと直ります。

• 「自分だけ400」か「全員400」かは、別の端末やスマホの回線で同じ URL を開くと分かります。 自分だけなら Cookie か拡張機能、全員なら サイト側です。
• Google のログイン画面で「承認エラー」「invalid_request」「redirect_uri_mismatch」と出るときは、Google の公式ドキュメントによると、リクエストの形式や必須パラメーターの誤り、登録したリダイレクト先との不一致（http と https・大文字小文字・末尾のスラッシュまで一致が要る）が原因です。見ている人の操作では直らないので、アプリの提供元に知らせます。

Cookie が何をしているものかは、関連記事「Cookieとセッションの違いと仕組み｜セッションIDの流れを図解」で扱っています。

Chromeでの400の見え方（HTTP ERROR 400・Bad Request）

この節では、400のときにブラウザに何が表示されるのか、表示から「誰が返したか」をどう読むかが分かります。

画面は、サーバーが本文を返したかどうかで変わります。 手元で3通りの400を返し、Chromium 153 で開いたときの表示です。

• 「HTTP ERROR 400」の画面は、サーバーが本文の無い400を返したときに Chrome が代わりに出すものです。 手元の Chromium は英語の画面でしたが、日本語の Chrome では「このページは動作していません」と表示されます（同じ環境で確かめた401の表示は、関連記事「401と403の違い｜Unauthorized・Forbiddenの原因と直し方」にあります）。
• 画面の下に nginx などのソフトの名前があれば、そのソフトが返した400です。JSON が見えるなら、アプリが返しています。
• Chrome では F12 の「ネットワーク」タブで、該当の行の「ステータス」が 400 かどうか、「ヘッダー」の「Cookie」がどれだけの長さかを見られます。

Cookieが大きすぎる400（Request Header Or Cookie Too Large）

この節では、nginx がヘッダーの大きさで400を返す仕組み、上限が「何バイト」なのかの実測、直し方が分かります。

nginx は、リクエストヘッダー1行が large_client_header_buffers の1つ分（既定 8KB）に収まらないと400を返します。 公式ドキュメントは「リクエスト行は1つのバッファを超えられず、超えると 414。ヘッダーの1フィールドも同様で、超えると 400」と説明しています。Cookie は複数あっても1行の Cookie: ヘッダーにまとめて送られるので、Cookie の合計が上限に当たりやすいのです。

9,000文字の Cookie を送った curl -v の原文です（値は省いています）。

$ curl -v -H "Cookie: session=aaa…（9000文字）" http://127.0.0.1:46001/
> GET / HTTP/1.1
> Host: 127.0.0.1:46001
> User-Agent: curl/8.5.0
> Accept: */*
> Cookie: session=aaa…（9000文字）
>
< HTTP/1.1 400 Bad Request
< Server: nginx/1.24.0 (Ubuntu)
< Content-Type: text/html
< Content-Length: 242
< 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>

error.log には、どのヘッダーが長すぎたかが残りました。

2026/10/29 17:30:58 [info] 2015#2015: *2 client sent too long header line: "Cookie: session=aaa…" while reading client request headers, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "127.0.0.1:46001"

上限は「ヘッダー1行が 8,192 バイト」だった

Cookie の値の長さを1バイトずつ変えて、どこで400になるかを測りました。

「Cookie: 」の名前部分と行末の改行を含めて 8,192 バイト（8KB）ちょうどが境目でした。 ブラウザは Cookie を1行にまとめて送るので、1つ1つは小さくても、合計が 8KB に近づくと400になります。手元の Chromium で 3,000文字の Cookie を3つ置いた（document.cookie.length は 9,019）だけで、トップページが400になりました。

直し方（作る側）

• 上限を広げても、Cookie が増え続ければいずれ当たります。広げるのは「原因を特定したあとの時間稼ぎ」と決めておくと、判断がぶれません。
• nginx を通過しても、後ろの Node.js には既定 16KB の上限があり、手元では 20,000字の Cookie を Node に直接送ると 431 Request Header Fields Too Large が返りました（Express のログには残りません）。uvicorn は同じ 20,000字を受け付けました。

URLが長すぎる400と414（nginxのerror.log原文）

この節では、URL が原因の400と414の違い、URL に使えない文字で400になる例、nginx の error.log に出る文言の一覧が分かります。

URL（リクエスト行）が長すぎるときは400ではなく 414 URI Too Long です。 同じ nginx に、9,000文字のクエリ付き URL を送った結果です。

$ curl -i "http://127.0.0.1:46001/?q=aaa…（9000文字）"
HTTP/1.1 414 Request-URI Too Large
Server: nginx/1.24.0 (Ubuntu)
Content-Type: text/html
Content-Length: 186
Connection: close

# error.log
client sent too long URI while reading client request line, client: 127.0.0.1, server: , request: "GET /?q=aaa…

一方、URL の「文字」がおかしいときは400です。curl は URL に生のスペースがあると送る前に「URL rejected: Malformed input to a URL function」で止めるので、nc で生のバイト列を送って確かめました。

Express に直接送ったときは、壊れた %エンコードを Express 自身が Failed to decode param '%E3%81%82%E' という400で返しました。nginx を前に置いていると、nginx の400が先に出て Express には届きません。アプリのログに該当のリクエストが無い400は、手前の層が返しています。

JSONが壊れている400（Express・FastAPIの原文）

この節では、API に送った JSON の構文が壊れているときに、Express と FastAPI が既定で何を返すのかと、エラー原文から原因を読む方法が分かります。

Express の express.json() は壊れた JSON に400を返し、FastAPI は既定で 422 を返します。 末尾にカンマが余った JSON（{"name":"taro","email":"t@example.com",}）を nginx 経由で送った結果です。

$ curl -v -X POST -H 'Content-Type: application/json' \
    -d '{"name":"taro","email":"t@example.com",}' http://127.0.0.1:46001/api/users
> POST /api/users HTTP/1.1
> Content-Type: application/json
> Content-Length: 40
>
< HTTP/1.1 400 Bad Request
< Server: nginx/1.24.0 (Ubuntu)
< Content-Type: application/problem+json; charset=utf-8
< X-Request-Id: 95ef27fb
<
{"type":"about:blank","title":"リクエストの本文を読めません","status":400,
 "instance":"/api/users","requestId":"95ef27fb",
 "detail":"Expected double-quoted property name in JSON at position 39 (line 1 column 40)",
 "errorType":"entity.parse.failed"}

detail の文言は Node.js の JSON.parse が出すもので、「position 39（40文字目）」が、余ったカンマの直後を指しています。body-parser の公式ドキュメントは、構文の失敗を status 400・type 'entity.parse.failed' と定めています。

FastAPI の既定の応答は、detail の配列に loc（どこか）・msg・type が入ります。

HTTP/1.1 422 Unprocessable Content
{"detail":[{"type":"json_invalid","loc":["body",38],"msg":"JSON decode error","input":{},"ctx":{"error":"Illegal trailing comma before end of object"}}]}

送信側で直すときは、JSON を手で組み立てずに言語の関数（JavaScript なら JSON.stringify、Python なら json.dumps）で作ります。文字列の連結で作った JSON は、値に引用符や改行が入ったときに壊れます。

必須パラメーター不足・型違いの400と422の使い分け

この節では、「JSON としては読めたが内容が足りない・違う」ときに400と422のどちらを返すか、その線引きと実装が分かります。

線は「構文として読めたかどうか」で引きます。 読めなければ400、読めたが必須項目が無い・型が違う・業務の決まりに反するなら 422 Unprocessable Content です。MDN は422を「サーバーがリクエストコンテンツのコンテンツ型を理解し、構文が正しいことを示していますが、コンテンツに格納された指示を処理することができなかった」と説明しています。

FastAPI は既定ではどちらも422にまとめます。手元では、RequestValidationError のハンドラーで「JSON が読めない（json_invalid）ときだけ400」に分けました。

@app.exception_handler(RequestValidationError)
async def validation_handler(request: Request, exc: RequestValidationError):
    errors = exc.errors()
    # JSON として読めない（構文の誤り）→ 400、読めたが内容が決まりに合わない → 422
    parse_failed = any(e["type"] == "json_invalid" for e in errors)
    status = 400 if parse_failed else 422
    return JSONResponse(
        status_code=status,
        media_type="application/problem+json",
        content={
            "type": "about:blank",
            "title": "リクエストの本文を読めません" if parse_failed else "入力に誤りがあります",
            "status": status,
            "errors": [{"loc": e["loc"], "msg": e["msg"], "type": e["type"]} for e in errors],
        },
    )

$ curl -i -X POST -H 'Content-Type: application/json' -d '{"name":"taro","email":"t@example.com",}' http://127.0.0.1:46001/py/users
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
{"type":"about:blank","title":"リクエストの本文を読めません","status":400,"errors":[{"loc":["body",38],"msg":"JSON decode error","type":"json_invalid"}]}

$ curl -i -X POST -H 'Content-Type: application/json' -d '{"name":"taro"}' http://127.0.0.1:46001/py/users
HTTP/1.1 422 Unprocessable Content
{"type":"about:blank","title":"入力に誤りがあります","status":422,"errors":[{"loc":["body","email"],"msg":"Field required","type":"missing"}]}

Express には入力チェックの仕組みが無いので、自分で書きます。手元の API は、必須項目の不足を400にし、どの項目がなぜ誤りかを errors に入れました。

app.post('/api/users', (req, res) => {
  if (!req.is('application/json')) {
    return problem(res, req, 415, 'Content-Type は application/json が必要です', { accept: ['application/json'] });
  }
  const errors = [];
  const { name, email } = req.body || {};
  if (typeof name !== 'string' || name.length === 0) errors.push({ field: 'name', message: 'name は必須です' });
  if (typeof email !== 'string' || !email.includes('@')) errors.push({ field: 'email', message: 'email の形式が正しくありません' });
  if (errors.length) return problem(res, req, 400, '入力に誤りがあります', { errors });
  res.status(201).json({ id: 1, name, email });
});

$ curl -i -X POST -H 'Content-Type: application/json' -d '{"name":"taro"}' http://127.0.0.1:46001/api/users
HTTP/1.1 400 Bad Request
{"type":"about:blank","title":"入力に誤りがあります","status":400,"instance":"/api/users","requestId":"c60fb337","errors":[{"field":"email","message":"email の形式が正しくありません"}]}

$ curl -i "http://127.0.0.1:46001/api/items?page=abc"
HTTP/1.1 400 Bad Request
{"type":"about:blank","title":"page は1以上の整数で指定します","status":400,"instance":"/api/items?page=abc","requestId":"6bf7ee5e","received":"abc"}

• すべての入力の誤りを400にまとめる設計も広く使われています。 Ruby on Rails や Laravel は入力チェックの失敗に422を使い、Express のプロジェクトでは400にまとめることが多いです。大切なのは、プロジェクトの中で揃えて API の仕様書に書くことです。
• クライアントから見ると、400も422も「送り直すときに自分が変える」コードです。本文の errors に「どの項目が・なぜ」を入れておけば、番号の違いで困ることはありません。

Content-Typeの不一致（415と400の違い）

この節では、Content-Type が本文と合わないときに何が起き、415と400のどちらを返すのが適切かが分かります。

「その形式は受け付けない」なら 415 Unsupported Media Type、「受け付ける形式だが中身が読めない」なら400です。 MDN は415を「メッセージのコンテンツが対応していない形式であるため、サーバーがリクエストの受け入れを拒否する」と説明しています。

curl の -d は既定で Content-Type: application/x-www-form-urlencoded を付けます。JSON を送ったつもりでも、サーバーには「フォーム形式」として届きます。

$ curl -v -X POST -d '{"name":"taro","email":"t@example.com"}' http://127.0.0.1:46001/api/users
> Content-Type: application/x-www-form-urlencoded
< HTTP/1.1 415 Unsupported Media Type
{"type":"about:blank","title":"Content-Type は application/json が必要です","status":415,"instance":"/api/users","requestId":"1dc2f758","accept":["application/json"]}

• Express の express.json() は Content-Type が application/json でない本文を読みません（type オプションの既定）。req.body が空のまま先に進むので、「必須項目が無い」という別の400に見えます。先に req.is('application/json') で確かめて415を返すと、送信側が原因に気づけます。
• FastAPI は、本文を JSON として読めなかったとき、Content-Type に関係なく「本文が辞書ではない」という422にまとめました。

400・413・414・415・422・431の使い分け（判断表）

この節では、API を作る人が「クライアントの誤り」に返すコードを迷わず決める順番と、本文の大きさで返る 413 の実物が分かります。

1. 1URL（リクエスト行）が長すぎる → 414nginx は large_client_header_buffers の1つ分（8KB）を超えると414
2. 2ヘッダーが大きすぎる → 400（nginx）または 431（Node.js）Cookie の合計が原因のことが多い
3. 3本文が大きすぎる → 413nginx の client_max_body_size（既定 1m）・express.json の limit（既定 100kb）
4. 4受け付けない形式・文字コード → 415フォーム形式で JSON の API を呼んだ
5. 5構文として読めない → 400壊れた JSON・不正な %エンコード・読めない整数
6. 6読めたが内容が決まりに合わない → 422（または400）必須項目の不足・形式・範囲
7. 7認証・権限・存在・競合 → 401・403・404・409400の仲間ではない

本文が大きすぎると 413（nginx と Express の実物）

$ curl -i -X POST -H 'Content-Type: application/octet-stream' --data-binary @two.bin http://127.0.0.1:46001/upload/   # 2MB、nginx は client_max_body_size 1m
HTTP/1.1 413 Request Entity Too Large
<head><title>413 Request Entity Too Large</title></head>

$ curl -i -X POST -H 'Content-Type: application/json' --data-binary @big.json http://127.0.0.1:46001/api/users    # 150KB、express.json の既定 100kb
HTTP/1.1 413 Payload Too Large
{"type":"about:blank","title":"request entity too large","status":413,…,"errorType":"entity.too.large"}

nginx の公式ドキュメントは、client_max_body_size を超えると 413 を返し、ブラウザはこのエラーを正しく表示できない、と注意しています。アップロードで「400 のような画面」が出るときは、実際には413のことがあります。413の理由句は、RFC 9110 で「Payload Too Large」から「Content Too Large」に変わりました（MDN）。

認証まわり（401・403）の返し分けは前述の401と403の記事で、全部のコードは関連記事「HTTPステータスコード 一覧｜全コードの原因と対処・curl実例つき」で扱っています。

作る人向け：400の本文（Problem Details）とログの残し方

この節では、400の本文に何を書けばクライアントが直せるのか、サーバーのログに何を残せば問い合わせからたどれるのかが分かります。

400の本文は「どの項目が・なぜ・どう直すか」を機械が読める形で返します。 RFC 9457（Problem Details for HTTP APIs）の形に揃えると、クライアントのエラー処理を共通にできます。手元の Express と FastAPI はどちらも application/problem+json で返しています。

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
X-Request-Id: c60fb337

{
  "type": "https://example.com/problems/validation-error",
  "title": "入力に誤りがあります",
  "status": 400,
  "instance": "/api/users",
  "requestId": "c60fb337",
  "errors": [
    { "field": "email", "message": "email の形式が正しくありません" }
  ]
}

• 1構文の失敗と内容の失敗で title を分ける「本文を読めません」と「入力に誤りがあります」。クライアントは直す場所が分かる
• 2項目ごとの errors を配列で返す最初の1件で止めず、全部返す。フォームは一度に直せる
• 3リクエスト ID を応答ヘッダーと本文とログに入れる問い合わせの ID でログを1行に絞れる。手元は X-Request-Id を自分で付けた
• 4内部の情報を本文に出さないスタックトレース・検証の実装の詳細・他のユーザーの存在が分かる文言は書かない
• 5400 は「比率」で監視する件数は利用者の打ち間違いでも増える。全体に対する比率の急増と、手前の層の400を分けて見る

Express：body-parser のエラーをまとめて対応づける

body-parser は、失敗の種類を err.type に入れて投げます。公式ドキュメントのとおり、構文の失敗は400、大きすぎは413、文字コードや圧縮の未対応は415です。手元のエラーハンドラーと、残したログです。

app.use((err, req, res, next) => {
  const map = { 'entity.parse.failed': 400, 'entity.too.large': 413,
                'charset.unsupported': 415, 'encoding.unsupported': 415 };
  const status = map[err.type] || err.status || 500;
  console.log(JSON.stringify({ level: 'warn', requestId: req.id, method: req.method, url: req.originalUrl,
    status, type: err.type, message: err.message,
    contentType: req.get('Content-Type'), length: req.get('Content-Length') }));
  problem(res, req, status, status === 400 ? 'リクエストの本文を読めません' : err.message,
          { detail: err.message, errorType: err.type });
});

{"level":"warn","requestId":"95ef27fb","method":"POST","url":"/api/users","status":400,"type":"entity.parse.failed","message":"Expected double-quoted property name in JSON at position 39 (line 1 column 40)","contentType":"application/json","length":"40"}
{"level":"warn","requestId":"d01417ee","method":"POST","url":"/api/users","status":413,"type":"entity.too.large","message":"request entity too large","contentType":"application/json","length":"150039"}
{"level":"warn","requestId":"104f9c62","method":"POST","url":"/api/users","status":415,"type":"charset.unsupported","message":"unsupported charset \"SHIFT_JIS\"","contentType":"application/json; charset=shift_jis","length":"39"}

ログに Content-Type と Content-Length を残すと、「本文そのもの」を残さなくても原因の大半が分かります。本文を丸ごと残すとパスワードや個人情報が混ざるので、残すなら項目名だけにします。

nginx：400 は access.log と error.log の両方で見る

# access.log（9番目の欄がステータス）
127.0.0.1 - - [29/Oct/2026:17:30:58 +0900] "GET / HTTP/1.1" 400 242 "-" "curl/8.5.0"
127.0.0.1 - - [29/Oct/2026:17:30:58 +0900] "GET /?q=aaa…" 414 186 "-" "-"
127.0.0.1 - - [29/Oct/2026:17:31:08 +0900] "HELLO" 400 166 "-" "-"

# error.log（error_log ... info; のとき）
client sent too long header line: "Cookie: session=aaa…" while reading client request headers
client sent HTTP/1.1 request without "Host" header while reading client request headers

access.log の 400 は「何が来たか」までは分かりません。理由は error.log の client sent … の行にあります。手元では、ヘッダー超過も文法違反も [info] レベルで記録されたので、調べるときだけ error_log /path/error.log info; にして reload します。エラー本文の設計全体は、関連記事「APIエラーレスポンス設計｜RFC 9457準拠のJSON例と実装コード」で扱っています。

よくあるエラー・つまずき（原文つき）

この節では、400まわりで実際に出た文言と、そこから読み取る原因・直し方を一覧で確認できます。

よくある質問

Q. 400 Bad Request とは何ですか？ A. サーバーが「リクエストの形がおかしい（クライアント側の誤り）」と判断して処理しなかったことを示すステータスコードです。構文の誤り・大きすぎるヘッダー・壊れた JSON などが原因で、サーバーの故障ではありません。

Q. 400エラーの直し方は（見ている人）？ A. URL を確かめる、再読み込みする、そのサイトの Cookie を削除する、シークレットウィンドウか別のブラウザで開く、拡張機能を切る、の順に試します。手元では、Cookie を消した直後に同じ URL が200で開きました。それでも出るならサイトの管理者に、日時・URL・操作を添えて知らせます。

Q. スマホ（iPhone・Android）で400が出ます。 A. パソコンと同じで、原因の多くは Cookie です。ブラウザの設定からそのサイトの Cookie（サイトデータ）を削除するか、別のブラウザで開きます。Wi-Fi とモバイル回線を切り替えて変わるなら、回線側の中継が原因のこともあります。

Q. 「Request Header Or Cookie Too Large」とは何ですか？ A. nginx が、Cookie を含むヘッダー1行が上限（既定 8KB）を超えたときに返す400の文言です。手元の実測では、Cookie: と改行を含めて 8,192 バイトが境目でした。見る人は Cookie を消し、作る人は Cookie を小さくするか large_client_header_buffers を広げます。

Q. 400と422はどちらを返すべきですか？ A. 構文として読めなければ400、読めたが内容が決まりに反するなら422です。すべて400にまとめる設計も広く使われているので、プロジェクトで揃えて仕様書に書きます。FastAPI は既定でどちらも422、Express の body-parser は構文の失敗を400にします。

Q. 400と414・413の違いは何ですか？ A. URL（リクエスト行）が長すぎると414、本文が大きすぎると413、ヘッダー1行が長すぎると nginx は400（Node.js は431）です。手元では、同じ 9,000文字を URL に付けると414、Cookie に付けると400になりました。

Q. ローカルでは動くのに本番だけ400になります。 A. 本番にだけある手前の層（nginx・ロードバランサー・CDN）の上限に当たっていることが多いです。curl -v で Server: ヘッダーと本文を見て誰が返したかを確かめ、アプリのログに該当のリクエストが無ければ手前の層の設定を見ます。

Q. 400の本文には何を書けばよいですか？ A. RFC 9457 の Problem Details の形で、title（人向けの短い説明）・status・項目ごとの errors・リクエスト ID を返します。スタックトレースや内部の情報は書きません。

Q. 400はSEO（検索順位）に影響しますか？ A. Google 検索セントラル（2026年3月6日更新）は、429 を除く 4xx はすべて同じように扱い、4xx を返す URL はインデックスに登録せず、登録済みの URL は削除される、と説明しています。公開したいページが400になっていないかは、ログアウトした状態や curl で確かめます。

Q. Google のログインで「400. That's an error. Error: invalid_request」と出ます。 A. Google の公式ドキュメントでは、invalid_request は「リクエストの形式が正しくない・必須パラメーターが無い・対応していない認証方法」、redirect_uri_mismatch は「登録したリダイレクト先と一致しない」が原因です。どちらもログインしようとしたアプリ側の設定の問題なので、提供元に知らせます。

Q. curl で JSON を送ると400になります。 A. -d だけでは Content-Type がフォーム形式になります。-H 'Content-Type: application/json' を付け、JSON はシングルクォートで囲んで中はダブルクォートにします。手元では、この指定を付けるだけで415・400が201になりました。

Q. 400を返すとき、ログに本文を残してよいですか？ A. 本文にはパスワードや個人情報が混ざるので、丸ごとは残しません。手元では、Content-Type・Content-Length・エラーの種類（err.type）・リクエスト ID を残し、これで原因の切り分けができました。

まとめ

• 400 Bad Request は「サーバーがリクエストを読めなかった」。直すのは送った側で、再読み込みしても同じ結果になる。
• 見ている人は、URL の確認→再読み込み→そのサイトの Cookie を削除→別のブラウザ、の順。Cookie を消すと直ることが多い。
• 手元の nginx では、ヘッダー1行が 8,192 バイトを超えると400（Request Header Or Cookie Too Large）、URL が超えると414、本文が超えると413だった。Node.js はヘッダー超過に431を返した。
• JSON の構文が壊れていると Express は400、FastAPI は既定で422。構文の失敗は400、読めたが内容が違えば422、形式を受け付けないなら415、と線を引く。
• 400の本文は Problem Details（どの項目が・なぜ）とリクエスト ID、ログには Content-Type・Content-Length・エラーの種類を残す。「誰が400を返したか」は curl -v の Server ヘッダーとアプリのログの有無で分かる。

次に読むとよい記事です。サーバー側のエラーは関連記事「500エラーとは｜Internal Server Errorの原因と直し方を実例で」と関連記事「504 Gateway Time-outの原因と直し方｜502・503との違いと実例」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• MDN「400 Bad Request」（RFC 9110 15.5.1 を出典とする解説）：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/400
• MDN「413 Content Too Large」：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/413
• MDN「414 URI Too Long」：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/414
• MDN「415 Unsupported Media Type」：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/415
• MDN「422 Unprocessable Content」：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/422
• IETF「RFC 9110 HTTP Semantics」15.5 Client Error 4xx：https://httpwg.org/specs/rfc9110.html#status.400
• IETF「RFC 9457 Problem Details for HTTP APIs」：https://www.rfc-editor.org/rfc/rfc9457
• nginx「Module ngx_http_core_module」large_client_header_buffers・client_max_body_size：https://nginx.org/en/docs/http/ngx_http_core_module.html
• Express「express.json([options])」（5.x API）：https://expressjs.com/en/5x/api/express/
• Express「body-parser」Errors：https://expressjs.com/en/resources/middleware/body-parser.html
• FastAPI「Handling Errors」（RequestValidationError の上書き）：https://fastapi.tiangolo.com/tutorial/handling-errors/
• Google Identity「ウェブサーバー アプリケーションに OAuth 2.0 を使用する」（承認エラー）：https://developers.google.com/identity/protocols/oauth2/web-server?hl=ja
• Google Chrome ヘルプ「Chrome で Cookie を削除、許可、管理する」：https://support.google.com/chrome/answer/95647?hl=ja
• Google 検索セントラル「HTTP ステータスコード、ネットワーク エラー、DNS エラーが Google 検索に与える影響」：https://developers.google.com/search/docs/crawling-indexing/http-network-errors?hl=ja

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。