WordPressサイトが急に遅くなると、まずサーバーのCPU、メモリ、画像サイズ、プラグインの重さを疑いがちです。もちろんそれらも重要ですが、小規模なサーバーでは、別の理由で「CPUは空いているのにページが返ってこない」状態になることがあります。
代表的な原因の一つが、xmlrpc.phpへの大量アクセスです。特にApacheで同時に処理できるリクエスト数が少ない構成では、XML-RPCへのPOSTが処理枠を埋め、トップページやREST APIまで待たされることがあります。
この記事では、特定のサイトだけに閉じた話ではなく、小規模なWordPressサイトで起こりやすい遅延の見方として、原因の切り分け方と対策を整理します。
遅い原因は「重いページ」だけではない
Webサイトの遅さには、大きく分けて二つの種類があります。一つは、ページそのものが重いケースです。画像が大きい、JavaScriptが多い、データベース問い合わせが重い、といった原因です。
もう一つは、リクエストを処理する入口が詰まっているケースです。ページ自体はそれほど重くなくても、サーバーが同時に処理できる枠を別のアクセスに使われてしまうと、普通の閲覧者のリクエストが順番待ちになります。
小規模サーバーでは、この違いが特に重要です。CPU使用率だけを見ると余裕があるように見えても、ApacheやPHPの同時処理枠が少ないと、数本のリクエストで待ち行列ができます。
XML-RPCとは何か
xmlrpc.phpは、WordPressに昔から用意されている外部連携用の入口です。古い投稿アプリ、Pingback、Trackback、一部の外部サービス連携などで使われてきました。
一方で、現在のWordPress運用では、記事投稿やメディアアップロードにREST APIを使うことも多くなっています。REST APIは/wp-json/や/wp-json/wp/v2/...として提供され、xmlrpc.phpとは別物です。
この違いを理解しておくと、対策の判断がしやすくなります。XML-RPCを閉じても、REST APIを使った投稿運用まで必ず止まるわけではありません。
処理枠が埋まると通常ページも待たされる
たとえば、Apacheの同時処理枠が少ない構成を考えます。外部からxmlrpc.phpへのPOSTが継続的に届くと、その処理に枠が使われます。枠が埋まった状態で普通の閲覧者がトップページを開くと、ページそのものが軽くても、まず空き枠を待つことになります。
実際の調査でも、アクセスログの大半がPOST //xmlrpc.phpで占められている例があります。通常の閲覧に比べてXML-RPCへのPOSTが極端に多い場合は、botやスキャナ、総当たり系のアクセスを疑うべきです。
ここで注意したいのは、アクセス元IPがそのまま攻撃元とは限らないことです。CloudFrontなどのCDNを前段に置いている場合、サーバーのApacheログにはCDNのエッジIPだけが残ることがあります。実IPまで追いたい場合は、X-Forwarded-Forをログに出す、CloudFrontログやWAFログを保存する、といった準備が必要です。
CloudFrontを外せば速くなるとは限らない
CDNを使っているサイトで遅延が起きると、「CDNを外した方が早いのでは」と考えたくなります。しかし、XML-RPCへのPOSTがオリジンへ流れ込んでいる場合、CDNを外すとサーバー本体が直接さらされるだけになることがあります。
問題は、CDNの存在そのものではなく、CDNが防御層として機能していないことです。WAFがない、POSTを広く許可している、公開ページのキャッシュがほとんど効いていない、といった状態では、CDNが単なる通過点になってしまいます。
この場合は、CDNを外すよりも、CDNで止めるべきリクエストを止め、公開ページのキャッシュを効かせ、オリジンへの到達を絞る方が現実的です。
対策は入口から重ねる
XML-RPCを使っていないサイトであれば、まず/xmlrpc.phpと//xmlrpc.phpを403で止めるのが効果的です。CloudFront FunctionやWAFでオリジンに届く前に止め、さらにApacheやNginxなどのWebサーバー側でも同じパスを拒否しておくと、CDNを迂回された場合にも備えられます。
REST APIを使った記事投稿やメディアアップロードを続けたい場合は、/wp-json/を止めないようにします。XML-RPCとREST APIは別の入口なので、対策対象を分けて考えることが大切です。
ただし、Jetpackや古い投稿アプリなど、XML-RPCに依存する機能を使っている場合は影響確認が必要です。すべてのサイトで無条件に閉じるのではなく、「自分の運用でXML-RPCを使っているか」を先に確認します。
確認すべきログと設定
原因を切り分けるときは、次の順番で見ると整理しやすくなります。
- アクセスログで、どのパスへのリクエストが多いか
POST /xmlrpc.phpやPOST //xmlrpc.phpが異常に多くないか- ApacheやPHP-FPMの同時処理数が少なすぎないか
- CDNがPOSTをそのままオリジンへ流していないか
- 公開ページにキャッシュが効いているか
- オリジンがCDNを迂回して直接アクセスされていないか
- 実IPを追えるログ設定になっているか
標準的なApacheのアクセスログには、処理時間が入っていないことがあります。その場合、過去ログだけで「どのリクエストが何秒詰まらせたか」までは断定できません。それでも、アクセスの大半がXML-RPCへのPOSTで、同時処理枠が少なく、通常ページまでタイムアウトしているなら、処理枠の詰まりを強く疑えます。
すぐできる対策と次にやる対策
緊急対応としては、まずXML-RPCを止め、トップページ、REST API、管理画面の動作確認を行います。これで通常ページの応答が戻るなら、原因の大枠はかなり絞れます。
その後は、恒久対策としてCDN/WAFのログを有効化し、実IPを追えるようにします。レート制限、WAFルール、キャッシュポリシー、オリジンへの直接アクセス制限も見直します。小規模サーバーの場合は、ApacheのMaxRequestWorkersやタイムアウト設定も、メモリ量に合わせて調整します。
ただし、同時処理数を増やすだけでは根本対策になりません。攻撃的なリクエストを受け続けたまま処理枠だけ増やすと、メモリ不足や別のボトルネックにつながることがあります。入口で不要なリクエストを落とし、必要なリクエストだけをオリジンに通す設計が重要です。
まとめ
WordPressサイトの遅延は、ページの重さだけでなく、サーバーの処理枠が埋まることでも起きます。特に小規模なApache構成では、XML-RPCへの大量POSTが通常ページやREST APIの応答を巻き込むことがあります。
対策では、まずログでxmlrpc.phpへのアクセス量を確認し、不要であればCDNとWebサーバーの両方でXML-RPCを止めます。そのうえで、REST APIは残し、公開ページのキャッシュ、WAF、実IPを追えるログ、オリジン直撃対策を整えると、同じ種類の遅延に気づきやすくなります。
小規模サイトほど、強いサーバーへ載せ替える前に「入口で何を通しているか」を確認する価値があります。遅さの原因をページ内だけに探さず、アクセスログと処理枠の両方から見ていくことが、安定運用への近道です。
