WordPressサイトを開いたとき、「400 Bad Request」や「Request Header Or Cookie Too Large」と表示されることがあります。公開ページは開くのに管理画面だけ400になる、特定ブラウザだけ開けない、記事保存や外部連携だけ失敗するなど、症状はさまざまです。
400は、サーバーが要求を正しく処理できない、または処理しないと判断した状態です。CookieやHTTPヘッダーが大きすぎる場合もありますが、URL、フォーム、REST APIの内容、CDN・WAF、プラグインなど別の原因でも起こります。
最初から全Cookie削除、キャッシュ全消去、WAF停止、.htaccess編集をまとめて行わないでください。400の発行元と発生範囲を記録してから、一つずつ切り分ける方が安全です。
この記事では、自分のブラウザだけの問題か、WordPress・CDN・サーバーまで共通する問題かを確認し、原因に合った復旧方法を選ぶ順番を解説します。
先に結論：400エラーは7段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | 画面・完全なURL・時刻・直前操作を保存する | 同時刻のログと照合する |
| 2 | サイト全体か特定URL・操作だけかを分ける | 要求のどこが壊れたか絞る |
| 3 | プライベートウィンドウで一度確認する | Cookieや拡張機能の影響を推定する |
| 4 | 別端末・別回線で一度比較する | 利用環境だけかサイト共通かを分ける |
| 5 | HTTP 400、応答本文、識別IDを確認する | CDN・Webサーバー・アプリの発行元を調べる |
| 6 | 同時刻のアクセス・エラーログを見る | 推測ではなく理由を確認する |
| 7 | 原因候補を一つだけ直して再確認する | 効果を判定し、二次障害を防ぐ |
プライベートウィンドウで開けても、「キャッシュが原因」とは限りません。通常ウィンドウとの違いにはCookie、ログイン状態、拡張機能などが含まれるため、次に対象サイトのデータだけを確認します。
400 Bad Requestとは？
RFC 9110の400 Bad Requestは、サーバーがクライアント側の誤りと認識した理由により、要求を処理できない、または処理しない状態です。例として、壊れた要求構文、不正なメッセージの区切り、誤解を招くルーティングが挙げられています。
ここでいう「クライアント」は、読者本人だけを指すとは限りません。ブラウザ、WordPressのJavaScript、プラグイン、外部連携ツール、CDNやプロキシを通った要求が、最終的に不正な形だと判断される場合があります。
そのため、400が出たからといって「WordPress本体が壊れた」「Cookieを消せば必ず直る」とは断定できません。エラーが出たURL、操作、ブラウザ、ログイン状態、応答本文を比較して、どの要求だけ失敗するかを確認します。
400・401・403・413の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 400 Bad Request | 要求の構文・内容・ヘッダーなどを処理できない | URL、Cookie、ヘッダー、送信内容、サーバーログ |
| 401 Unauthorized | 対象に必要な有効な認証情報がない | 認証方式、WWW-Authenticate、資格情報 |
| 403 Forbidden | 要求は理解されたが処理を拒否された | 権限、WAF、IP・アクセス制限 |
| 413 Content Too Large | 送信した内容がサーバーの上限を超えた | ファイル・本文サイズ、送信上限 |
認証を求める401なら、WordPressの401 Unauthorizedを直す確認順へ進みます。許可されていない403なら、WordPressの403 Forbiddenを安全に直す手順が対象です。
画像アップロード時に本文サイズの上限が疑われる場合は、WordPressで画像をアップロードできないときの確認順も参考にしてください。番号が違う場合は、400の対処をそのまま当てはめません。
最初の10分で行う安全な初動
1．エラー画面と操作を記録する
エラー画面全体、完全なURL、発生時刻とタイムゾーン、直前の操作を保存します。ページ閲覧、ログイン、記事保存、フォーム送信、画像アップロード、REST API、外部ツールの同期のどれで起きたかが重要です。
応答を確認できる場合は、HTTPステータスが本当に400か、エラー本文、Server、CDNの識別IDも記録します。「Bad Request」「Request Header Or Cookie Too Large」など、表示された文言を省略せず残してください。
2．発生範囲を一度ずつ比較する
トップページ、別の記事、管理画面、問題のURLを一度ずつ確認します。サイト全体ではなく長いURLだけ失敗する、閲覧はできるが保存だけ失敗する、といった差が原因の手がかりになります。
次に、同じURLをプライベートウィンドウと別端末で一度ずつ比較します。通常ウィンドウだけ400なら、対象サイトのCookieやブラウザ拡張が候補です。すべての端末で同時に出るなら、CDN、Webサーバー、WordPress側を優先します。
3．送信操作を連打しない
記事保存、フォーム、注文、API更新など、状態を変える操作は連打しません。400なら通常は要求が適用されていないと考えられますが、複数の中継層やアプリ処理がある環境では、画面だけで処理結果を断定せず、保存先や送信履歴を確認します。
症状から原因候補を絞る
| 症状 | 優先する原因候補 | 次の確認 |
|---|---|---|
| 特定ブラウザの通常画面だけ400 | サイトCookie、拡張機能、保存済み認証状態 | プライベート画面、対象サイトのデータ |
| ログイン中だけ400 | 大きいCookie、セッション、セキュリティ機能 | CookieヘッダーとWebサーバーログ |
| 長いURL・検索URLだけ400 | 不正なURL文字、エンコード、要求行 | 元URL、リンク生成元、アクセスログ |
| 記事保存・フォームだけ400 | 送信形式、必須項目、JSON、Content-Type | ブラウザNetworkとアプリログ |
| 外部ツールの同期だけ400 | API構文、パラメータ、認証形式 | 送信先ドメイン、API応答本文 |
| 全端末・全URLで同時に400 | CDN・WAF・プロキシ・Webサーバー | 障害情報、識別ID、エラーログ |
| 更新後から特定機能だけ400 | プラグイン、テーマ、独自コード | 直前変更と同時刻のログ |
400を返した場所と要求内容を特定する
ブラウザの開発者ツールを使える場合は、Networkで失敗した要求を一つ選び、Request URL、Method、Status、Response、Content-Typeを確認します。CookieやAuthorizationなどの秘密情報は、画面共有や公開フォーラムへそのまま載せません。
CDNの識別IDやブランド表示がある場合も、CDNが400を生成したのか、配信元の400を中継したのかをログで確認します。Cloudflareの400公式資料では、不正なURLエンコードや矛盾したメッセージの区切りなど、要求自体の問題が例示されています。
Webサーバー、CDN・WAF、WordPress、PHPのログを同じ時刻で照合します。「header too large」「invalid request」「malformed JSON」など具体的な理由があれば、その原因だけを直します。ログが見られない共有サーバーでは、時刻、URL、エラー本文を添えてサポートへ確認します。
原因別の安全な直し方
1．対象サイトのCookieやログイン状態
プライベートウィンドウでは開き、通常ウィンドウだけ400になる場合は、まず対象ドメインのCookieとサイトデータを確認します。削除するとログアウトし、カート、下書きフォーム、表示設定などが消える場合があるため、必要な内容を保存してから対象サイト分だけ削除します。
すべてのブラウザ履歴や保存パスワードを消す必要はありません。削除後は一度だけログインし直し、同じ操作を確認します。直らない場合はCookieを繰り返し消さず、次のログ確認へ進みます。
2．Cookie・HTTPヘッダーが大きすぎる
Nginx公式のlarge_client_header_buffers資料では、一つの要求ヘッダーが一つのバッファへ収まらない場合、400を返すと説明されています。長いCookieもヘッダーに含まれるため、ログイン中や特定利用者だけで発生する原因になり得ます。
ただし、最初からバッファを大幅に増やすのは避けます。異常にCookieを増やしているプラグイン、重複したセッション、不要なヘッダーを先に特定します。共有サーバーでは自分で設定を変えず、対象ヘッダーと上限をホストへ確認してください。
3．URLの文字・長さ・エンコード
メールやチャットからコピーしたURLに、全角記号、余分な引用符、改行、重複した?や&が入っていないか確認します。元のページからリンクを開き直し、手入力でURLを修正し続けるより、リンクを生成した場所を直します。
パーマリンク設定を保存し直す操作は、すべての400に効く万能策ではありません。通常の記事URLまで404になるなど、パーマリンク固有の症状がある場合だけ、WordPressの404エラーを直す確認順に沿って扱います。
4．フォーム・REST API・JSONの送信内容
記事保存や外部連携だけ400なら、要求本文のJSON、必須項目、データ型、Content-Type、URLパラメータを確認します。APIの応答本文に不足項目や不正な値が示されていれば、表示された項目だけを直します。
記事保存時に「返答が正しいJSONレスポンスではありません」と出る場合は、WordPressのJSONレスポンスエラーを直す手順でREST API、WAF、パーマリンクを切り分けてください。ログへ送信本文を残す場合は、個人情報や認証情報を伏せます。
5．CDN・WAF・リバースプロキシ
CDN・WAFのイベントで、400の時刻、URL、ルール、要求サイズ、識別IDを確認します。セキュリティ上不正な要求を拒否している場合があるため、CDNやWAFを全面停止せず、誤検知と確認できた条件だけを調整します。
要求の区切りが矛盾するなど、攻撃へ悪用され得る形を400で拒否する場合もあります。見た目を直すために不正な要求を許可せず、送信元の実装または中継設定を修正します。
6．プラグイン・テーマ・独自コード
更新直後から特定機能だけ失敗し、ログが対象を示している場合は、その変更だけをテスト環境で切り戻します。全プラグイン停止は、フォーム、キャッシュ、セキュリティ、決済へ影響するため最初の操作にしません。
本番外で再現する方法はWordPressのテスト環境を作る手順、不要プラグインの整理はWordPressプラグインを安全に減らす方法を参考にしてください。
やってはいけない対処
- 原因を確認せず、全ブラウザデータと保存パスワードを削除する
- Cookie削除、キャッシュ全消去、WAF停止を同時に行う
- CDN・WAF・セキュリティプラグインを無効のまま放置する
- ログを見ずに要求ヘッダーの上限を大幅に増やす
- すべての400でパーマリンクを保存し直す
- 無関係な
.htaccess、データベース、PHP設定を編集する - プラグインやテーマのフォルダを一括削除する
- Cookie、Authorization、APIキーを含むログを公開する
- フォーム保存やAPI更新を連打する
- 400ページを正常な200応答へ置き換える
変更前に、元の設定値と戻し方を記録します。設定ファイルやプラグインを触る場合は、WordPressのバックアップを安全に取る手順で復元手段を確認してください。
復旧後に確認すること
- 問題のURLとトップページがHTTP 200で開く
- ログイン中・未ログインの両方で表示できる
- 記事保存、フォーム、画像、外部連携を一度ずつ確認する
- Cookie削除後に必要なログイン状態と設定を戻した
- CDN・WAFの防御を有効な状態へ戻した
- サーバーログで同じ400が再発していない
- スマートフォンとPCで重要ページを確認した
- 一時停止した自動処理を重複なく再開した
公開記事が継続して400を返す場合は、検索にも影響します。GoogleのHTTPステータス公式資料では、429以外の4xxを返すURLの内容は検索に利用されず、既存URLも時間とともにインデックスから外れると説明されています。復旧後は主要URLが200を返すことを確認します。
サーバー会社へ伝える情報
- 400が出た完全なURL
- 発生時刻とタイムゾーン
- 表示されたエラー本文とスクリーンショット
- 公開画面、管理画面、保存、APIのどこで出るか
- 通常画面とプライベート画面の結果
- 別端末・別回線での結果
- Server、CDN識別IDなどの応答情報
- 直前の更新、設定変更、外部連携
- 実施済みの確認と結果
「400を直してください」だけでなく、「7月21日14時10分、ログイン中の管理画面だけ400。プライベート画面の公開ページは正常。表示はRequest Header Or Cookie Too Large」のように伝えると、確認対象を絞りやすくなります。
よくある質問
Cookieを削除すれば必ず直りますか？
いいえ。特定ブラウザやログイン中だけ400になる場合は有効なことがありますが、URL、API、CDN、サーバーが原因なら直りません。プライベートウィンドウとの比較後、対象サイト分だけを扱います。
ブラウザキャッシュの削除で直りますか？
400は要求側の問題を示すため、表示用ファイルのキャッシュ削除だけでは直らない場合が多くあります。Cookie、URL、要求ヘッダー、送信内容を分けて確認してください。
自分だけ400が出るのはなぜですか？
そのブラウザに保存されたCookie、ログイン状態、拡張機能、ネットワーク経路が関係する可能性があります。別ブラウザで開けたことだけで原因を断定せず、通常画面とプライベート画面の差を確認します。
400と「正しいJSONレスポンスではありません」は同じですか？
同じとは限りません。保存要求が400を返し、その結果としてJSONエラーが表示される場合はありますが、JSONエラーには403、500、HTML応答など別の原因もあります。Networkのステータスと応答本文を確認します。
サーバーの上限を増やすべきですか？
ログでヘッダー上限が原因と確認でき、正当な要求が必要量を超えている場合に検討します。異常に大きいCookieや重複ヘッダーを残したまま上限だけを増やさないでください。
まとめ
WordPressの400 Bad Requestは、サーバーが要求を正しく処理できない、または処理しない状態です。Cookieだけに決めつけず、URL、操作、ブラウザ、端末、応答本文、同時刻のログを比較します。
安全な復旧の基本は、発生範囲を分け、対象サイトのデータや原因となった要求だけを一つずつ直すことです。ログを確認できない場合は、画面、時刻、URL、比較結果をそろえてサーバー会社や制作者へ相談してください。