WordPressを残したままCloudflareで守る：
WAF・Bot対策の始め方

結論：作り直さずに、攻撃を「手前で止める」方法

WordPressをやめる準備がまだできていない、予約や会員の機能があってすぐには移れない。そんなときに、今のサイトを残したまま守りを足す方法が、Cloudflareを手前に置くやり方です。WordPressをCloudflareへ移す4つの方法で「方法① Cloudflareを門番にする」として紹介したものを、この記事では設定の中身まで掘り下げます。

レンタルサーバーにもWAFはありますが、レンタルサーバーのセキュリティだけで大丈夫？で見たとおり、サーバー側の防御だけでは止められない攻撃も多くあります。Cloudflareは、サーバーの外にもう一枚の網を張る役目です。

Cloudflareを前に置くと何が起きるか

ネームサーバーをCloudflareに切り替え、サイトのDNSの記録を「プロキシ済み」（管理画面のオレンジの雲）にすると、通信の流れが次のように変わります。

Cloudflareの公式ドキュメントによると、プロキシできるのはA・AAAA・CNAMEの3種類の記録だけで、MXやTXTは常に「DNSのみ」です。また「DNSのみ」の記録は、問い合わせた人にサーバーの本当のIPアドレスを返します。この点は、あとのつまずきやすい点で大事になります。

できること

WAF（不正な通信を止める）

Cloudflareが用意したルール（マネージドルール）と、自分で書くルール（カスタムルール）の2種類があります。無料プランでも「Free Managed Ruleset」が使え、カスタムルールは5つまで作れます。カスタムルールでは、条件に合った通信を「ブロック」「マネージドチャレンジ（人間か確かめる画面）」「スキップ」などで扱えます。

ログイン画面への回数制限

回数制限のルール（Rate limiting rules）は、Cloudflareの公式ドキュメントでも、ログイン画面を総当たり攻撃から守る使い方が例に挙がっています。無料プランは1ルールで、数える期間と止める時間はどちらも10秒です。短いですが、機械的に大量に試す攻撃を鈍らせる効果は期待できます。

Bot対策

無料プランでは「Bot Fight Mode」が使え、よく知られたボットの特徴に合う通信に、計算の手間がかかる確認を出します。手軽な反面、細かい例外を作れないという弱点があります（後述）。

管理画面へのアクセス制限

カスタムルールで、/wp-adminやwp-login.phpへの接続を、会社のIPアドレスや国で絞れます。さらに強くしたい場合は、Cloudflare Access（Zero Trustの機能）で、管理画面に入る前にCloudflare側のログインを求める方法もあります。Accessは初期状態で「許可した人以外は拒否」になる仕組みです。料金や人数の条件は、契約前に公式で確かめてください。

表示の高速化

画像・CSS・JavaScriptなどは、Cloudflareの拠点にキャッシュされて配られます。HTMLとJSONは初期設定ではキャッシュされないため、ログイン中の管理画面がキャッシュされる心配は、初期設定のままなら小さくて済みます。

WordPress向けの設定例

無料プランのカスタムルール5つと回数制限1つで、当ラボが小さな会社のサイトでまず考える組み合わせです。式はCloudflareの「式エディター」での書き方の例で、使う前にご自分のサイトに合わせて見直してください。

できないこと（WordPress本体の脆弱性は残る）

• 穴そのものはふさがらない：プラグイン・テーマ・本体・PHPの更新は引き続き必要です。
• 正規の通信に見える攻撃は見分けにくい：Patchstackの報告は、権限の確認漏れを突く攻撃は通常のログイン済みの通信と見分けがつかず、従来のWAFでは防ぎにくいとしています。CloudflareもWAFの一つで、例外ではありません。
• サーバーを直接狙われると素通り：元のサーバーのIPアドレスが知られていると、Cloudflareを通らずに攻撃されます（次の節）。
• サーバーの中の問題は見えない：すでに入り込んだ不正なプログラム、同じサーバーの別のサイトからの侵入、漏れたパスワードでのログインには効きません。

Cloudflareは「攻撃される回数を減らす」道具で、「攻撃されても大丈夫にする」道具ではありません。更新を続けられないことが根本の悩みなら、攻撃される場所そのものを減らす方法（静的化やEmDashへの移行）も比べてみてください。

設定の流れ

1. 今のDNSの記録を書き写す
   今のDNSの管理画面で、A・CNAME・MX・TXTなどの記録を全部控えます。メールの設定（MX、SPFのTXT）は特に念入りに。
2. Cloudflareにサイトを追加する
   無料プランを選び、読み込まれた記録が控えと同じか一つずつ確かめます。足りないものは手で足します。
3. プロキシする記録を決める
   サイトの記録（ドメイン名とwww）だけをプロキシ済みにし、メールなどの記録はDNSのみのままにします。
4. SSLのモードを「フル（厳密）」にする
   サーバー側にも有効な証明書があることを確かめてから設定します。
5. ネームサーバーを切り替える
   ドメインを契約している会社の管理画面で、Cloudflareが示すネームサーバーに変えます。切り替え後、サイトの表示・管理画面へのログイン・フォームの送信・メールの送受信を確かめます。
6. 守りの設定を足していく
   マネージドルールを確かめ、上の設定例をチャレンジから始めます。数日ようすを見て、問題がなければ強めます。
7. 元のサーバーへの直接の接続を絞る
   次の節の「元のサーバーを守る」を行います。

ネームサーバーの切り替えでメールを止めないための詳しい注意は、WordPressをCloudflareへ移す4つの方法の「つまずきやすい点」も参考にしてください。

つまずきやすい4つの点

① 元のサーバーのIPアドレスが知られている

Cloudflareの公式ドキュメントは、プロキシ済みの記録でサーバーのIPアドレスを隠すとともに、Cloudflare以外からの通信をサーバー側で止めることをすすめています。また、Cloudflareに移る前のDNSの記録の履歴や、SPFなどのTXTの記録からIPアドレスが漏れることがあるとして、記録の見直しや、移行後にサーバーのIPアドレスを変えることも挙げています。同じサーバーを指すmailやftpの記録がDNSのみのまま残っていないかも確かめましょう。共用のレンタルサーバーでは、Cloudflare以外を止める設定ができるかどうかをサーバー会社に確かめてください。

② SSLのモードを「フレキシブル」にしてしまう

「フレキシブル」は、訪問者とCloudflareの間だけを暗号化し、Cloudflareとサーバーの間は暗号化しないモードです。Cloudflareは「フル」か「フル（厳密）」を強くすすめています。WordPress側の常時HTTPSの設定とかみ合わず、表示がおかしくなる原因にもなりやすいので、最初から「フル（厳密）」を目指しましょう。

③ ログに全員が同じIPアドレスで記録される

Cloudflareを通すと、サーバーのログにはCloudflareのIPアドレスが記録されます。訪問者の本当のIPアドレスはCF-Connecting-IPという項目で届くので、Apacheならmod_remoteipなどで読み取るよう設定します。これをしないと、ログイン回数を制限するプラグインが全員をまとめて締め出したり、逆に誰も止められなかったりします。

④ Bot Fight Modeが必要な通信まで止める

Bot Fight Modeは、スマートフォンのアプリや外部サービスからの通信にも確認を出すことがあり、カスタムルールの「スキップ」などで例外を作れません。アプリからの投稿、決済や予約の外部サービスからの通知、監視サービスなどを使っている場合は、オンにした直後にそれらが動いているかを確かめ、困るなら止めます。

無料プランと有料プランの違い

当ラボの見立てでは、問い合わせ中心の小さな会社のサイトなら、まず無料プランで十分に始められます。Proプランを考えるのは、WordPressの攻撃に合わせたルールをより多く使いたいとき、アプリや外部サービスのためにBot対策の例外が必要なとき、ログイン画面の回数制限を長めにしたいとき、などです。

よくある質問

参照元

• Cloudflare Docs：Proxy status（2026年4月21日更新）
• Cloudflare Docs：WAF Managed Rules（2026年9月8日更新）
• Cloudflare Docs：WAF Custom rules（2026年10月16日更新）
• Cloudflare Docs：Rate limiting rules（2026年8月25日更新）
• Cloudflare Docs：Bot Fight Mode（2026年8月3日更新）
• Cloudflare Docs：Self-hosted public application（Access、2026年4月17日更新）
• Cloudflare Docs：Protect your origin server（2026年10月2日更新）
• Cloudflare Docs：Encryption modes（2026年4月16日更新）
• Cloudflare Docs：Restoring original visitor IPs（2026年4月23日更新）
• Cloudflare Docs：Default cache behavior（2026年9月14日更新）
• Cloudflare Docs：Automatic Platform Optimization（2026年4月16日更新）
• Cloudflare：Network & CDN の料金プラン
• Patchstack：State of WordPress Security in 2026（2026年2月25日更新）
• 最終確認日：2026年11月4日

WordPress乗り換えラボ編集部

運営：株式会社イメージ・ジャパン（1997年創立）。WordPressからの乗り換えと乗り換え後の見守りのほか、Web制作・SEO、AI導入支援、自社AIツール（VCT・Symphy・Mapvoice AI）の開発・運営を手がけています。

あわせて読みたい

WordPressをCloudflareへ移す4つの方法：残す・静的化・作り直す・EmDash

レンタルサーバーのセキュリティだけで大丈夫？サーバー側の防御が防げない攻撃

WordPressのセキュリティ対策：続ける人がやるべきことと、続けられない人の選択肢