xmlrpc.php が 500 Internal Server Error を返すときは、XML-RPC の仕組みそのものではなく、その裏で動く PHP がサーバー側で止まっていることがほとんどです。まず curl で再現してエラーログを読み、多い順にプラグインの致命的エラー、PHP の XML 拡張の不足、メモリ不足、.htaccess の書式違いを確かめると、たいていは原因に行き着きます。この記事では、正常なときの応答の確かめ方から、原因ごとの確認方法と直し方、使っていない場合の止め方までを説明します。
xmlrpc.php は何に使われているか
xmlrpc.php は、外部のアプリやサービスが WordPress に投稿・取得などを行うための古くからある窓口です。現在は REST API が主流ですが、次のような用途で今も使われていることがあります。
- 外部のブログ投稿ツールや、古いデスクトップエディターからの投稿
- 他サイトからのピンバック
- 一部のサイト管理サービスや連携プラグイン
どの機能が XML-RPC に依存しているかは、サービスやアプリのバージョンによって変わります（2026年10月現在）。500 エラーで困っているのが「何の連携か」を先に確認しておくと、直した後の動作確認がしやすくなります。逆に、何も使っていないと分かれば、後半で説明するように止めてしまう選択肢もあります。
まず再現して、正常な応答と比べる
ブラウザで xmlrpc.php を開くと、正常なら「XML-RPC server accepts POST requests only.」という一文が表示されます。ここで 500 になるなら、XML-RPC の処理に入る前の段階、つまり WordPress の読み込みやサーバー設定で失敗しています。
次に、実際の XML-RPC リクエストを送って確かめます。認証の要らない system.listMethods を使うと安全に試せます。
# GET でステータスだけを見る
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/xmlrpc.php
# POST で利用できるメソッドの一覧を取得する
curl -s -X POST -H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>' \
https://example.com/xmlrpc.php正常なら <methodResponse> で始まる XML が返り、wp.getPosts などのメソッド名が並びます。ここで押さえておきたいのは、ユーザー名やパスワードの誤りといった「XML-RPC としてのエラー」は、多くの場合 HTTP ステータスは 200 のまま、XML の中に faultCode として返るという点です。HTTP として 500 が返っているなら、認証の問題ではなくサーバー側の障害と考えて調べを進めます。
なお、502 や 504 が返る場合は PHP-FPM やリバースプロキシのタイムアウトなど別系統の問題なので、ステータスの数字は正確に控えておいてください。
エラーログを読む
500 の本当の原因はログにしか残りません。サーバーの PHP エラーログ（コントロールパネルから見られることが多い）か、WordPress のデバッグログを確認します。デバッグログを使う場合は、wp-config.php のバックアップを取ったうえで次を追加し、もう一度 curl を実行します。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );wp-content/debug.log に出た Fatal error の行が手がかりになります。調べ終わったら設定を戻し、debug.log は削除してください。
原因1：プラグインやテーマの致命的エラー
xmlrpc.php は内部で WordPress 全体を読み込むため、有効なプラグインとテーマの functions.php がすべて動きます。そのため、どれか一つが PHP の致命的エラーを起こすと、XML-RPC も 500 になります。XML-RPC のメソッドを追加・変更するプラグイン（xmlrpc_methods フィルターを使うもの）が原因のこともあります。
ログの Fatal error に wp-content/plugins/プラグイン名/ が含まれていれば、そのプラグインを更新するか無効化して再度 curl で確かめます。ほかのページは問題なく XML-RPC だけが 500 になる場合は、XML-RPC のときだけ動く処理に不具合がある可能性が高く、ステージング環境で一つずつプラグインを止めて切り分けるのが確実な進め方です。
原因2：PHP の XML 拡張が入っていない
WordPress の XML-RPC は、受け取った XML を PHP の XML 拡張（xml_parser_create() などの関数）で解析します。PHP を入れ替えたり新しいバージョンに上げたりしたときにこの拡張が入っていないと、ログに「Call to undefined function xml_parser_create()」のようなエラーが出て 500 になります。
# 読み込まれている拡張に xml があるか確認
php -m | grep -i xmlコマンドラインの PHP と Web サーバーの PHP は設定が別のことがあるので、サイトヘルスの「情報」タブにあるサーバーの項目や、ホスティングのコントロールパネルの PHP 設定でも確認してください。VPS で拡張が無い場合は、使っている PHP のバージョンに合った XML 拡張のパッケージ（Debian / Ubuntu なら php8.x-xml のような名前）を入れ、PHP-FPM や Web サーバーを再起動します。共用サーバーではホスティング会社に問い合わせます。
原因3：メモリ不足や処理時間の上限
大きな画像を XML-RPC 経由でアップロードしたときや、多数の投稿を一度に取得したときだけ 500 になる場合は、メモリ不足が疑われます。ログに「Allowed memory size of ... bytes exhausted」とあればこれです。
wp-config.php で WordPress が使うメモリの上限を上げられますが、PHP 側の memory_limit を超えては設定できません。
define( 'WP_MEMORY_LIMIT', '256M' );上限を上げる前に、送っているデータが大きすぎないか、連携ツール側で一度に送る量を減らせないかも確認してください。
原因4：.htaccess の書式違い
セキュリティ対策として、xmlrpc.php へのアクセスを .htaccess で制限している場合は、その書き方を確認します。Order や Deny from は Apache 2.2 の古い書式で、Apache 2.4 で互換モジュール（mod_access_compat）が無効だと、その部分が設定エラーとなり 500 を返します。サーバーのエラーログに「Invalid command 'Order'」のような記録があれば、これが原因です。
Apache 2.4 では次のように書きます。
<Files xmlrpc.php>
Require all denied
</Files>ただし、これは xmlrpc.php を遮断する設定です。XML-RPC を使いたいのにこの記述がある場合は、誰かが過去に入れた対策が残っているということなので、削除するか、使う相手の IP だけを Require ip で許可する形に書き換えます。編集前に .htaccess のバックアップを取ってください。
原因5：大量アクセスによる過負荷
アクセスログに、多数の IP から xmlrpc.php への POST が短時間に集中している記録がある場合は、パスワードの総当たりやピンバックを悪用したアクセスでサーバーが過負荷になっている可能性があります。この場合、500 や 503 が断続的に出ます。XML-RPC を使っていないなら遮断し、使っているならサーバーの WAF や IP 制限で守る方向で考えます。
使っていないなら止める
XML-RPC を使う連携が一つも無いなら、止めてしまうのが手間もリスクも少ない方法です。止める前に、前述のとおり依存しているサービスが無いかを確かめてください。
サーバー側で遮断するのが確実で、Apache 2.4 なら原因4の Require all denied、Nginx なら次のように書きます。
location = /xmlrpc.php {
deny all;
}WordPress 側の設定だけで済ませたい場合、xmlrpc_enabled フィルターに false を返すと、認証が必要なメソッドが使えなくなります。ピンバック関連のメソッドは認証が不要なため、このフィルターでは止まらない点に注意してください。ピンバックも止めたいときは、xmlrpc_methods フィルターで該当メソッドを外します。子テーマの functions.php か mu-plugin に書きます。
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );まとめ
- xmlrpc.php の 500 は、XML-RPC の認証エラーではなく、サーバー側で PHP が止まっているサインです。認証の誤りは通常 200 と faultCode で返ります。
- curl の
system.listMethodsで再現し、エラーログの Fatal error を確認します。 - 原因は多い順に、プラグインやテーマの致命的エラー、XML 拡張の不足、メモリ不足、.htaccess の古い書式、大量アクセスによる過負荷です。
- 使っていないなら、依存している連携が無いことを確かめたうえで、サーバー側で遮断するのが手間の少ない方法です。