Cloudflare のレートリミットが WP STAGING REST API をブロックする (HTTP 429)

サイトを Cloudflare 経由で公開していてレートリミットのルールが有効になっている場合、そのルールが WP STAGING REST API にも適用されることがあります。すると Cloudflare はそれらのリクエストに HTTP 429 (Too Many Requests) を返し、REST API に依存する WP STAGING の機能が動かなくなります。解決策は、レートリミットのルールに 1 行の除外条件を追加することです。

なぜ Cloudflare のレートリミットが WP STAGING REST API を壊すのか

Cloudflare のレートリミットのルールは、受信したリクエストそのものを評価します。リクエストを送信したプラグインは判定材料になりません。そのためドメイン全体を対象にしたルールや、/booking のようなアクセスの多いパスを対象にしたルールは、WP STAGING が自身の REST API に送る内部リクエストまでカウントします。

カウンターの上限を超えると、Cloudflare は条件に一致する以降のリクエストをブロックし、HTTP 429 を返します。WP STAGING のリクエストは WordPress まで到達しないため、呼び出し元の機能が失敗するか、応答待ちのまま止まります。

次の条件がすべて当てはまる場合、このサイトは影響を受けます。

  • ゾーンで Cloudflare のレートリミットが有効になっている。
  • レートリミットのルールが WordPress サイト、またはその配下のパス (例: /booking) に一致する。
  • そのルールが WP STAGING REST API を除外していない。

動かなくなる WP STAGING の機能

WP STAGING REST API は次のような複数の機能で使われています。

  • バックグラウンドジョブ
  • Remote Sync
  • Magic Login
  • プラグインの自動更新
  • その他の REST API ベースの機能

これらのリクエストがレートリミットの対象になると HTTP 429 で失敗し、そのリクエストを発生させた機能は処理を完了できません。

WP STAGING REST API を Cloudflare のレートリミットから除外する方法

WP STAGING REST API へのリクエストに一致しなくなるよう、レートリミットのルールを編集します。

手順 1: レートリミットのルールを開く

Cloudflare のダッシュボードでアカウントを選び、次に対象のドメインを選択します。Security を開き、Security rules に進みます。レートリミットのルールはここに一覧表示されます。

手順 2: WordPress サイトを対象にしたルールを編集する

429 応答が発生している WordPress サイト、またはそのパスを対象にしたルールを開きます。

手順 3: ルールの式に除外条件を追加する

ルールの一致条件の式に、次の条件を追加します。

and not http.request.uri.query contains "/wpstg/v1"

/booking を保護するルールの場合、完成した式は次のようになります。

(http.host eq "example.com" and starts_with(http.request.uri.path, "/booking")) and not http.request.uri.query contains "/wpstg/v1"

手順 4: ルールをデプロイする

保存してデプロイします。これにより、次のようなリクエストはレートリミットの対象外になり、サイトの他の部分は保護されたままになります。

?rest_route=/wpstg/v1/check_magic_login

注意: wpstg/v1 は URL のパスではなくクエリ文字列の一部です。WP STAGING は ?rest_route= 形式で REST API を呼び出すため、除外条件には http.request.uri.path ではなく http.request.uri.query を使ってください。

よくある質問

なぜ除外条件に http.request.uri.path ではなく http.request.uri.query を使うのですか

WP STAGING は REST の URL を https://example.com/?rest_route=/wpstg/v1/<endpoint> の形で生成します。つまり名前空間 wpstg/v1 はクエリ文字列に現れます。http.request.uri.path を評価するルールではこれを検出できないため、除外条件は何の効果もないまま見過ごされます。

この除外でサイトの保護は弱くなりますか

除外されるのは、クエリ文字列に /wpstg/v1 を含むリクエストだけです。ドメインへのそれ以外のリクエストは、これまでどおりレートリミットのルールにカウントされます。

/wp-json/wpstg/v1/ でも 429 が出ます。どうすればよいですか

環境によっては、パーマリンク形式で REST API にアクセスする場合があります。その場合はパス用の条件をもう 1 つ追加してください。

and not starts_with(http.request.uri.path, "/wp-json/wpstg/v1/")

429 の原因が Cloudflare 以外という可能性はありますか

あります。WAF、ホスティング側のレートリミット、セキュリティ系プラグインのいずれも HTTP 429 を返すことがあります。Cloudflare で除外条件をデプロイした後もエラーが続く場合は、サーバーとプラグインのログを確認してください。

修正できたことをどう確認しますか

失敗していた機能をもう一度実行します。たとえば Magic Login のリンクを開く、Remote Sync を開始するなどです。その後 Cloudflare の Security Events ログを確認します。/wpstg/v1 を含むリクエストに、レートリミットによるブロックのアクションが表示されなくなっていれば成功です。

関連記事

Updated on 8月 4, 2026

Rene Hermenau

著者: Rene Hermenau

著者について: René Hermenau は WP STAGING の創設者です。WordPress のバックアップ、ステージング、移行、データベース処理、安全なデプロイメントワークフローに取り組んでいます。