2026年10月5日

WordPressの「405 Method Not Allowed」を解決する方法｜応答ヘッダーで返した相手を特定し、原因の多い順に対処する

エラー・白い画面

WordPress で「405 Method Not Allowed」が出たときは、最初に「誰が 405 を返したのか」を応答ヘッダーで確かめるのが近道です。WordPress 本体は、存在しない REST API のルートやメソッドに対して 405 ではなく 404 を返すため、405 の多くは Web サーバー・WAF・CDN・静的ホスティングなど、WordPress より手前の層で発生しています。この記事では、症状の読み方と、原因の可能性が高い順の確認・対処方法を説明します。

405 Method Not Allowed とは

HTTP のリクエストには、ページを取得する GET、フォームを送信する POST、REST API でよく使う PUT・PATCH・DELETE などの「メソッド」があります。405 は「その URL は存在するが、このメソッドは受け付けない」という意味の応答です。HTTP の仕様（RFC 9110）では、405 を返すときは Allow ヘッダーで受け付けるメソッドを示すことになっています。

WordPress で 405 が表に出るのは、主に次のような場面です。

お問い合わせフォームやコメントを送信したとき
ブロックエディターで保存・更新したとき（エディターは REST API を使います）
外部のアプリや自作のスクリプトから REST API や xmlrpc.php を呼んだとき
管理画面で特定の操作をしたとき（admin-ajax.php への POST）

なお、アップロードするファイルが大きすぎる場合は 405 ではなく 413（Request Entity Too Large）が返ります。post_max_size や upload_max_filesize は 405 とは別の問題です。

手順1：誰が 405 を返したのかを特定する

ブラウザの開発者ツールの「ネットワーク」タブを開き、エラーになった操作をもう一度行います。405 になったリクエストを選び、次の点を確認してください。

リクエストの URL とメソッド：POST がどこに送られているか
**応答ヘッダーの Server**：nginx、Apache、cloudflare、AmazonS3 など、応答した相手の手がかりになります
**応答ヘッダーの Allow**：受け付けるメソッドの一覧（例：GET, HEAD）
応答本文：WordPress の REST API なら JSON（{"code": ...}）で返ります。nginx の場合は「405 Not Allowed」という短い HTML、WAF の場合はサーバー会社独自のエラーページになることが多いです

コマンドで再現する場合は curl を使います。

# POST で送った場合の応答ヘッダーを確認
curl -i -X POST https://example.com/wp-json/ -d "test=1"

# DELETE を送った場合（REST API クライアントの検証用）
curl -i -X DELETE https://example.com/wp-json/wp/v2/posts/1

サーバーにログインできる場合は、アクセスログで 405 の行を探します。どの URL・メソッド・クライアントで発生しているかが分かります。

# nginx の例（ログの場所は環境に合わせて変更）
grep '" 405 ' /var/log/nginx/access.log | tail -n 20

アクセスログに 405 が記録されていなければ、サーバーより手前の CDN や WAF が返していると判断できます。

手順2：原因の多い順に確認する

1. 静的なファイルやキャッシュに POST している

nginx は、静的なファイル（.html や画像など）への POST を 405 で拒否します。WordPress では次のような状況で起こります。

ページキャッシュ系のプラグインが生成した HTML を、nginx の設定で直接返している
フォームの送信先（action 属性）が、PHP を通らない URL を指している
Simply Static などで静的サイトに書き出し、静的ホスティングにそのまま置いている

静的ホスティング（オブジェクトストレージや静的サイト向けのサービス）は、一般に POST を処理できません。この場合、フォームは外部のフォームサービスに送るか、WordPress を残したサーバーの URL に送る設計に変える必要があります。

nginx の場合は、WordPress 向けの基本の設定で try_files が PHP に処理を回しているかを確認します。

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;  # 環境のソケットに合わせる
}

fastcgi-php.conf のファイル名や PHP-FPM のソケットの場所はディストリビューションや PHP のバージョンで異なります。設定を変えたら sudo nginx -t で文法を確認してから sudo systemctl reload nginx で反映します。

2. Web サーバーの設定でメソッドを制限している

セキュリティ対策として、受け付けるメソッドを GET・POST などに絞る設定が入っていることがあります。REST API の更新処理（PUT・PATCH・DELETE）がこれに引っかかると 405 になります。

# nginx の設定から、メソッドを制限している記述を探す
sudo grep -rnE 'limit_except|request_method' /etc/nginx/

# Apache の設定と .htaccess から探す
sudo grep -rnE 'LimitExcept|<Limit |REQUEST_METHOD' /etc/apache2/ /var/www/

if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; } のような記述が見つかったら、REST API を使う URL（/wp-json/）を除外するか、制限そのものが本当に必要かを見直します。設定ファイルを編集する前にはコピーを取っておいてください。

3. WAF やセキュリティ機能がリクエストを拒否している

レンタルサーバーの WAF、ModSecurity、セキュリティ系プラグイン、CDN のファイアウォールなどが、送信内容を攻撃と判断して止めることがあります。多くは 403 を返しますが、製品や設定によっては 405 になることもあります。特定の文言を含むフォーム送信や記事の保存だけが失敗する場合は、この可能性が高いです。

確認するには、サーバーの管理画面で WAF のログを見て、該当の時刻に検知の記録があるかを調べます。WAF を一時的に無効にして再現しなくなれば原因と判断できますが、無効のまま運用せず、誤検知した規則だけを除外する設定に切り替えてください。

4. ホスティング会社が xmlrpc.php や特定のメソッドを止めている

ホスティング会社によっては、不正アクセス対策として xmlrpc.php へのアクセスを止めていたり、PUT・DELETE を受け付けなかったりします。外部のアプリから xmlrpc.php を使っている場合は、REST API とアプリケーションパスワードを使う方式への移行を検討します。

PUT や DELETE が通らない環境でも、WordPress の REST API は POST に X-HTTP-Method-Override ヘッダー（または _method パラメーター）を付けたリクエストを、指定したメソッドとして扱います。ブロックエディターも内部でこの仕組みを使えるようになっています。

# DELETE の代わりに POST + メソッド上書きで送る例（認証情報はダミー）
curl -i -X POST https://example.com/wp-json/wp/v2/posts/1 \
  -H "X-HTTP-Method-Override: DELETE" \
  -u "username:your-application-password"

5. プラグインやテーマが独自の REST ルートを間違って登録している

自作やプラグインの REST API で、register_rest_route() の methods に指定したメソッドと、呼び出し側のメソッドが一致していないと、WordPress は rest_no_route を返します。このときのステータスは 404 ですが、手前のプロキシが書き換えている場合もあるため、応答本文の JSON の code を確認してください。プラグインが原因かを確かめるには、ステージング環境でプラグインを一つずつ停止して再現を試します。

修正後の確認

開発者ツールで同じ操作を行い、ステータスが 200 系（REST API の作成なら 201）になるか
アクセスログに 405 が出なくなったか
フォームの場合、送信内容が実際に届いているか（メールや管理画面の記録）

設定ファイルの変更は、可能ならステージング環境で試してから本番に反映してください。Web サーバーの設定やパッケージの構成は（2026年10月現在）ディストリビューションごとに差があるため、コマンドは例として自分の環境に合わせて読み替えてください。

まとめ

405 は「URL はあるが、そのメソッドは受け付けない」という応答で、WordPress 本体より手前の層が返していることが多い
開発者ツールや curl で Server・Allow ヘッダーと応答本文を見て、返した相手を特定する
多い原因は、静的ファイル・キャッシュへの POST、Web サーバーのメソッド制限、WAF の誤検知、ホスティングの制限
PUT・DELETE が通らない環境では X-HTTP-Method-Override を使う方法がある
ファイルサイズの問題は 413 であり、405 とは別に扱う