WordPressのCloudflare詳細設定｜WAFカスタムルール・レート制限・Cache Rules・Workers

Cloudflare は CDN（コンテンツの配信）だけでなく、WAF（不正なアクセスを止める仕組み）、レート制限、エッジで動くプログラム（Workers）などの機能を持っています。この記事では、Cloudflare を通して配信している WordPress サイトで、ログイン画面の保護、キャッシュの調整、セキュリティヘッダーの追加を行う設定を説明します。プランごとの上限や画面名は、2026年11月時点で Cloudflare の公式ドキュメント（developers.cloudflare.com）で確認したものです。Cloudflare の画面は変更が多いので、名前が違う場合は公式ドキュメントで確認してください。

Cloudflare をまだ設定していない場合や、Cloudflare 経由で訪問者の本当の IP アドレスをサーバーに渡す設定は、「WordPress に Cloudflare を設定する手順」を先に参照してください。

プランごとの主な上限（2026年11月時点）

WAF のカスタムルールでログイン画面などを守る

カスタムルールは、条件に合うリクエストを、サーバーに届く前にブロックしたりチャレンジ（ボットかどうかの確認）を出したりする設定です。

1. Cloudflare のダッシュボードでドメインを選び、「Security rules」（セキュリティルール）のページを開きます。
2. 「Create rule」から「Custom rules」を選びます。
3. 「Rule name」に名前を入れ、「When incoming requests match」で条件を作ります。条件は画面で選ぶほか、「Edit expression」で式を直接書けます。
4. 「Then take action」で動作を選び、「Deploy」で有効にします。

WordPress でよく使う例を3つ挙げます。Free プランでは5個まで作れるので、必要なものから入れます。

例1: wp-login.php を海外から開くときにチャレンジを出す

日本からだけログインするサイトの例です。日本以外からのアクセスには、「Managed Challenge」でボットかどうかを確かめます。

(http.request.uri.path eq "/wp-login.php" and ip.src.country ne "JP")

• 動作: Managed Challenge
• 海外出張先や、海外のサーバーから管理する人がいる場合は、その人も確認画面を通ることになります。日本以外からのログインを止めてしまう場合は「Block」を選びますが、自分が締め出されないよう、先に「Managed Challenge」で様子を見ます。
• 国の判定には ip.src.country を使います（以前の ip.geoip.country は非推奨です）。

例2: xmlrpc.php へのアクセスを止める

(http.request.uri.path eq "/xmlrpc.php")

• 動作: Block
• XML-RPC は、パスワードの総当たりや大量のピンバックに使われることがあります。ただし、Jetpack や一部のスマートフォンアプリ、外部からの投稿ツールは XML-RPC を使うので、使っていないことを確かめてから止めます。WordPress 側で止める方法は「WordPressのXMLRPCを無効化する方法」で説明しています。

例3: アップロード用のフォルダーにある PHP の実行を止める

画像などを置く wp-content/uploads に PHP ファイルが置かれて実行される被害を防ぎます。通常の WordPress では、このフォルダーの PHP を直接開く必要はありません。

(http.request.uri.path contains "/wp-content/uploads/" and http.request.uri.path contains ".php")

• 動作: Block

ルールを入れた後は、セキュリティの分析画面（Security の Analytics や Events）で、どのルールが何件のリクエストに働いたかを確認し、正しいアクセスを止めていないかを見ます。

レート制限でログインの試行回数を抑える

レート制限ルールは、同じ IP アドレスからの短時間の大量アクセスを止める設定です。カスタムルールと同じ「Security rules」の「Create rule」から「Rate limiting rules」を選んで作ります。

Free プランでは1個だけ作れ、条件に使えるのはパスなど一部の項目、数える期間と遮断する時間はどちらも10秒です。リクエストのメソッド（POST だけを数える、など）を条件にするのは上位のプランの機能です。Free プランでの設定例は次のとおりです。

レート制限とカスタムルールを組み合わせた設定は、「WordPressのログイン試行をCloudflareで制限する方法」でも説明しています。

マネージドルールを確認する

Free プランでは「Cloudflare Free Managed Ruleset」が使えます。広く悪用されている脆弱性への攻撃を止めるルールのセットで、Cloudflare 側で更新されます。Pro 以上のプランでは、より多くのルールを含む「Cloudflare Managed Ruleset」と「Cloudflare OWASP Core Ruleset」も使えます。マネージドルールで正しいアクセス（管理画面での保存など）が止められた場合は、セキュリティの分析画面で該当のルールを特定し、そのルールだけを例外にします。

WAF の設定全体の考え方は「WordPressをCloudflare WAFで守る設定」でまとめています。

キャッシュの設定は Page Rules ではなく Cache Rules で行う

Page Rules は、2026年11月時点の公式ドキュメントで非推奨（deprecated）とされています。Cloudflare は既存の Page Rules を新しい機能へ自動で移す予定を案内しており、キャッシュの設定は Cache Rules、セキュリティレベルは Configuration Rules、転送は Redirect Rules（Single Redirects）が受け持ちます。新しく設定する場合は Cache Rules を使います。

Cloudflare が標準でキャッシュするもの

Cloudflare は、標準では画像・CSS・JavaScript などの静的なファイルを拡張子で判断してキャッシュし、HTML はキャッシュしません。そのため、何も設定しなければ、WordPress の管理画面やログイン後のページが他人にキャッシュとして配信されることはありません。

例: アップロードした画像を長くキャッシュする

「Rules」の Cache Rules で、新しいルールを作ります。

(http.request.uri.path contains "/wp-content/uploads/")

• Cache eligibility: Eligible for cache
• Edge TTL: 元のサーバーの指定を上書きして、1か月など長めにする
• Browser TTL: 1週間など

画像を同じファイル名で差し替えると、古い画像がしばらく表示されます。差し替えたときは、Cloudflare の「Caching」の「Configuration」から、そのURLのキャッシュを削除（Purge）します。

HTML もキャッシュしたい場合

Cache Rules で「Eligible for cache」を選ぶと、そのルールに合うものは HTML も含めてキャッシュの対象になります。WordPress の HTML をキャッシュする場合は、管理画面（/wp-admin/）・wp-login.php・ログインしている人・コメントを書いた人・プレビュー、WooCommerce ならカートや購入手続きのページを、キャッシュの対象から外す必要があります。条件を誤ると、ログインした人のページが他の訪問者に表示されるおそれがあるので、自分でルールを組むより、Cloudflare の公式プラグイン「Cloudflare」と組み合わせて使う APO（Automatic Platform Optimization）や、Cloudflare に対応したキャッシュ系プラグインの利用を検討してください。APO を使うには、公式ドキュメントのとおり Cloudflare の WordPress プラグインが必要です。

セキュリティヘッダーを付ける

Transform Rules で付ける（コード不要）

Cloudflare の「Rules」にある Transform Rules の「Response Header Transform Rules」（レスポンスヘッダーの変更）で、サイトのレスポンスにヘッダーを付けられます。操作は「Set static」を選び、ヘッダー名と値を入れます。

Content-Security-Policy は、WordPress のテーマやプラグイン、広告やアクセス解析のタグを止めてしまうことがあるので、いきなり付けず、Content-Security-Policy-Report-Only で影響を確かめてから設定します。サーバー側（.htaccess や Nginx）で付ける方法は「WordPressのセキュリティヘッダー設定方法」で説明しています。

Workers で付ける（条件で分けたい場合）

HTML のときだけ付ける、パスごとに値を変えるなど、条件で分けたい場合は Workers を使えます。現在の Workers は、次の ES モジュール形式で書きます（addEventListener('fetch', …) を使う古い書き方の例が多く出回っていますが、新しく作るならこちらにします）。

export default {
  async fetch(request, env, ctx) {
    // 元のサーバー（Cloudflare のキャッシュを含む）からレスポンスを受け取る
    const response = await fetch(request);

    // HTML 以外はそのまま返す
    const contentType = response.headers.get('content-type') || '';
    if (!contentType.includes('text/html')) {
      return response;
    }

    // ヘッダーを変更できるように、レスポンスを作り直す
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Content-Type-Options', 'nosniff');
    newResponse.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');
    newResponse.headers.set('X-Frame-Options', 'SAMEORIGIN');
    return newResponse;
  },
};

作った Worker は、ドメインのルート（例: example.com/*）に割り当てると、そのURLへのリクエストで動きます。Workers は、ルートに合うリクエストのたびに実行され、画像や CSS へのリクエストも数えられます。Free プランの1日10万リクエストの上限に収まるかを、サイトのアクセス数と照らして確認してください。単にヘッダーを付けるだけなら、Workers のリクエスト数を使わない Transform Rules のほうが向いています。

キャッシュが効いているかを確かめる

Cloudflare を通したレスポンスには cf-cache-status というヘッダーが付きます。curl で確かめられます。

# 画像のキャッシュ状況（2回目以降に HIT になるかを見る）
curl -sI https://example.com/wp-content/uploads/2026/11/sample.jpg | grep -i cf-cache-status

# HTML（標準の設定では DYNAMIC になる）
curl -sI https://example.com/ | grep -i cf-cache-status

このヘッダーは訪問者へのレスポンスに付くもので、WordPress（元のサーバー）へのリクエストには付きません。PHP の中でキャッシュの状況を調べることはできないので、ブラウザーの開発者ツールか curl で確認します。

設定を変えるときの注意

• ルールを追加・変更したら、ログイン、投稿の保存、問い合わせフォームの送信、（あれば）購入手続きを一通り試し、止められていないかを確認します。
• 問題が起きたときにすぐ戻せるよう、ルールの名前に目的を書き、変更した日を記録しておきます。
• 元のサーバーの IP アドレスが知られていると、Cloudflare を通らずに直接アクセスされ、WAF やレート制限が効きません。サーバー側のファイアウォールで、Web のポートへの接続を Cloudflare の IP アドレスからに限ると、この抜け道を防げます。