WordPressで「414 Request-URI Too Long」が出る原因と対処法（Apache・Nginx）

「414 Request-URI Too Long」（Nginxでは「414 Request-URI Too Large」）は、ブラウザが送ったURLが長すぎて、Webサーバーが受け付けなかったことを示すエラーです。URLの長さだけが問題なので、PHPのアップロード上限やメモリ上限を変えても直りません。

この記事では、WordPressで414が出る主な原因と見つけ方、URLを短くする対処、どうしても必要な場合にApacheとNginxの上限を変える方法を説明します。

414 と似たエラーの違い

414 の原因は「URLの長さ」です。upload_max_filesize・post_max_size・LimitRequestBody・WP_MEMORY_LIMIT は、いずれもURLの長さとは関係がないため、414の対処にはなりません。

Webサーバーの上限（初期値）

Apacheの LimitRequestLine は、メソッド・URL・HTTPバージョンからなるリクエスト行の長さの上限です。Nginxでは、リクエスト行が large_client_header_buffers のバッファー1つの大きさを超えると414を返します。どちらも公式ドキュメントの記載です（2026年11月時点）。

日本語などのマルチバイト文字はURLの中で %E3%81%82 のように1文字が9文字分になるため、日本語を多く含む検索語やパラメーターは想像以上に長くなります。

WordPressで414が起きる主な原因

1. 投稿一覧の一括操作で大量の投稿を選んだ

管理画面の投稿一覧（edit.php）のフォームはGETで送信されます。「表示オプション」で1ページの表示件数を大きくし、すべてを選んで一括操作（ゴミ箱へ移動・編集など）を実行すると、選んだ投稿のIDがすべて post[]=123&post[]=124… の形でURLに入り、上限を超えることがあります。

対処は次のどちらかです。

• 「表示オプション」の表示件数を減らし、数回に分けて一括操作する
• WP-CLIが使えるサーバーでは、コマンドで処理する

# 例：下書きの投稿をまとめてゴミ箱に移す（--force を付けなければゴミ箱へ移動）
wp post delete $(wp post list --post_type=post --post_status=draft --format=ids)

2. リダイレクトのたびにパラメーターが付け足されている

ログイン画面の redirect_to のように、リダイレクト先のURLをパラメーターとして渡す仕組みで設定が食い違うと、リダイレクトのたびにURLが入れ子になって伸び、最後に414になることがあります。次のコマンドでリダイレクトの流れを確認できます。

curl -sIL --max-redirs 10 "https://example.com/wp-admin/" | grep -iE '^(HTTP|location)'

location: の値が回を追うごとに長くなっていれば、このパターンです。「設定」→「一般」の「WordPressアドレス (URL)」と「サイトアドレス (URL)」の http/https や www の有無、.htaccess やサーバー側のリダイレクト設定、ログイン画面を変更するプラグインの設定が食い違っていないかを確認します。

3. プラグインやテーマが大量のデータをGETで送っている

絞り込み条件の多い検索フォームや、JavaScriptがデータをURLのパラメーターに詰めて送る処理では、選択肢や入力が多いとURLが長くなります。特定の画面や操作のときだけ414になる場合は、このパターンを疑います。

• 該当のプラグインを一時的に停止して再現するか確かめ、再現しなければ作者に報告します。
• 自作のコードであれば、送り方をPOSTに変えます（フォームは method="post"、JavaScriptの fetch() は method: 'POST' にして本文で送る）。データの量に上限がなくなるわけではありませんが、URLの長さの制限は受けなくなります。

原因のリクエストを見つける

1. ブラウザの開発者ツールの「ネットワーク」タブを開いた状態で、414になる操作をもう一度行います。ステータスが414の行を選ぶと、送ろうとしたURLを確認できます。
2. サーバーにログインできる場合は、アクセスログから414を探します。

# Apache（Debian / Ubuntu の例）
sudo grep '" 414 ' /var/log/apache2/access.log | tail -n 20

# Nginx
sudo grep '" 414 ' /var/log/nginx/access.log | tail -n 20

ログの場所はディストリビューションや設定で変わります（RHEL系のApacheは /var/log/httpd/）。共用サーバーでは、コントロールパネルのアクセスログ表示を使います。

どうしても長いURLが必要な場合：上限を引き上げる

Apacheの公式ドキュメントは、LimitRequestLine について「通常は初期値から変えるべきではない」としています。上限を上げると、極端に長いリクエストによる負荷を受けやすくなります。まずは上の原因を直し、それでも必要な場合だけ、必要な分だけ引き上げます。

Apache

LimitRequestLine はサーバー設定かバーチャルホストに書きます。.htaccess に書くとエラーになります。

<VirtualHost *:443>
    ServerName example.com
    LimitRequestLine 16384
    # …既存の設定…
</VirtualHost>

名前ベースのバーチャルホストでは、同じIPアドレスとポートの組み合わせで最初に定義された（既定の）バーチャルホストの値が使われる、と公式ドキュメントに注意書きがあります。複数のサイトを1台で動かしている場合は、既定のバーチャルホストにも同じ値を書きます。

# 構文を確認してから反映する（Debian / Ubuntu）
sudo apachectl configtest
sudo systemctl reload apache2

RHEL系ではサービス名が httpd です（sudo systemctl reload httpd）。

Nginx

http {
    # 1つのバッファーを16KBにする（リクエスト行の上限も16KBになる）
    large_client_header_buffers 4 16k;
}

server ブロックに書くこともできますが、その場合は既定のサーバーの値が使われることがある、と公式ドキュメントに書かれています。迷ったら http ブロックに書きます。

sudo nginx -t
sudo systemctl reload nginx

前段にCDNやロードバランサーがある場合

CloudflareなどのCDN、ロードバランサー、WAFを通している場合は、それぞれにURLの長さの上限があります。Webサーバーの上限を上げても、前段で414になることがあります。エラーページのデザインやレスポンスヘッダーを見て、どこが414を返しているかを確かめます。

共用サーバーでは、これらの値を利用者が変えられないことがほとんどです。その場合は、上の原因（送り方）を直します。

直ったかを確かめる

設定を変えた場合は、長いURLを作って送ってみると、上限が効いているかを確認できます。

# 約9,000文字のパラメーターを付けて送り、ステータスコードだけを表示する
curl -s -o /dev/null -w '%{http_code}\n' "https://example.com/?q=$(head -c 9000 /dev/zero | tr '\0' 'a')"

初期値のままなら414、上限を16KBに上げていれば414以外（通常は200）が返ります（Apache 2.4とNginxの公式Dockerイメージで、この結果になることを確かめています）。最後に、414が出ていた元の操作をもう一度行い、エラーが出ないことを確認します。

まとめ

• 414は「URLが長すぎる」エラーで、PHPのアップロード上限やメモリ上限とは関係がありません。
• WordPressでは、投稿一覧で大量に選んだ一括操作、パラメーターが増えていくリダイレクト、GETで大量のデータを送るプラグインが主な原因です。
• まず開発者ツールやアクセスログで原因のリクエストを見つけ、件数を減らす・POSTに変える・リダイレクト設定を直す、といった方法でURLを短くします。
• 上限を上げる場合は、Apacheは LimitRequestLine（サーバー設定・バーチャルホスト）、Nginxは large_client_header_buffers を、必要な分だけ引き上げます。

• Nginxのclient_max_body_sizeで413エラーを直す（WordPressのアップロード上限）
• Apacheの設定ファイルを構文チェックする方法（apache2ctl -t・httpd -t）