2026年5月17日

CloudflareのDDoS対策の設定方法：既定の防御・カスタムルール・オリジン保護（WordPress向け）

ネットワーク・接続

Cloudflare は、レイヤー3・4（ネットワーク層）とレイヤー7（HTTP）の DDoS 対策を、無料プランを含むすべてのプランで、量の上限なしで提供しています。攻撃の検知と緩和は自動で行われるので、「DDoS 対策を有効にする」ための特別なスイッチはありません。

ただし、この防御が働くのは Cloudflare を経由したアクセスだけです。DNS の設定が不十分だったり、サーバー（オリジン）の IP アドレスが知られていて直接攻撃されたりすると効果がありません。また、WordPress のログイン画面への総当たりのような「少量でもしつこいアクセス」は、DDoS の自動防御では止まらないことがあります。この記事では、WordPress サイトを例に、Cloudflare で行う設定と、オリジン側で行う設定を順に説明します。

ダッシュボードの画面名は、2026年10月時点の Cloudflare の新しいセキュリティダッシュボードの英語表記で書いています。Cloudflare は画面の構成を変えることがあるので、見つからない場合は公式ドキュメント（developers.cloudflare.com）で現在の場所を確認してください。

ステップ1: サイトを Cloudflare に追加し、DNS をプロキシにする

Cloudflare のダッシュボードでドメインを追加し、表示されたネームサーバーに、ドメインを登録している会社の管理画面でネームサーバーを変更します。
「DNS」→「Records」で、Web サイトの A / AAAA / CNAME レコードの「Proxy status」が「Proxied」（オレンジの雲）になっていることを確認します。

「DNS only」（灰色の雲）のレコードは Cloudflare を経由しないので、DDoS 対策も WAF も働きません。また、DNS only のレコードはオリジンの IP アドレスをそのまま公開してしまいます。次の点も確認します。

mail などのサブドメインが、Web サーバーと同じ IP アドレスを DNS only で指していないか
SPF などの TXT レコードに、Web サーバーの IP アドレスが書かれていないか
メールを Web サーバーと同じサーバーから送っていないか（メールのヘッダーや不達通知から IP アドレスが分かります）

Cloudflare は、導入前の DNS の記録が外部に残っていることを理由に、導入後にオリジンの IP アドレスを変えることを勧めています。すでに IP アドレスを狙われている場合は、サーバー会社に IP アドレスの変更ができるか相談してください。

あわせて、「SSL/TLS」の暗号化モードを「Full (strict)」にし、オリジンにも有効な証明書を置いておくと、Cloudflare とオリジンの間も検証つきの HTTPS になります。

ステップ2: HTTP DDoS 対策の感度を確認する

HTTP の DDoS 対策は、Cloudflare が管理するルールセット（HTTP DDoS attack protection）として既定で動いています。通常は既定のままで構いませんが、正当なアクセスが止められる場合や、逆にもっと早く止めたい場合は、上書き（override）を作って感度と動作を変えられます。

「Security」→「Security rules」を開き、「DDoS protection」タブを選びます。
「HTTP DDoS attack protection」の「Create override」を選びます。
「Override name」に名前を付け、「Ruleset action」と「Ruleset sensitivity」を選んで「Save」を押します。

選べる値は次のとおりです（2026年10月時点の公式ドキュメントによる）。

項目	選択肢
Ruleset sensitivity	High（既定）、Medium、Low、Essentially Off
Ruleset action	Block、Managed Challenge、Interactive Challenge（Log は Enterprise の Advanced DDoS Protection のみ）

感度は High が最も敏感です。感度を下げると誤検知は減りますが、攻撃を止めるまでのしきい値も上がります。Advanced DDoS Protection を契約していないプランで作れる上書きは1つだけで、すべてのリクエストに適用されます。

ステップ3: ログイン画面と XML-RPC にカスタムルールを付ける

WordPress では、/wp-login.php と /xmlrpc.php への総当たりがよく起きます。これらへのアクセスにチャレンジ（ブラウザの確認）をかけると、ボットによる大量のアクセスがオリジンに届きにくくなります。カスタムルール（以前の「Firewall Rules」に代わる機能）で設定します。

「Security」→「Security rules」で「Create rule」→「Custom rules」を選びます。
「Rule name」に名前を付けます。
「When incoming requests match」で「Edit expression」を開き、下の式を入れます（項目を選んで作っても同じです）。
「Then take action」で「Managed Challenge」を選び、「Deploy」を押します。

手順3で入れる式です。

(http.request.uri.path eq "/wp-login.php") or (http.request.uri.path eq "/xmlrpc.php")

XML-RPC を使っていない（Jetpack や外部アプリからの投稿をしていない）なら、/xmlrpc.php は「Block」にしても構いません。使っている場合は、チャレンジをかけるとアプリが接続できなくなるので、このルールから外してください。

管理者の IP アドレスが固定なら、その IP アドレスを除外する条件を足すと、自分がチャレンジを受けずに済みます。

((http.request.uri.path eq "/wp-login.php") or (http.request.uri.path eq "/xmlrpc.php")) and not ip.src in {203.0.113.10}

203.0.113.10 は例なので、自分の IP アドレスに置き換えます。公式ドキュメントでは、いきなり「Block」にせず「Managed Challenge」で始め、「Security」→「Analytics」の「Events」で引っかかったリクエストを確かめてから「Block」に変える進め方を勧めています。作れるカスタムルールの数は、Free が5個、Pro が20個、Business が100個です（2026年10月時点）。

ステップ4: レート制限ルールでログインの試行回数を抑える

同じ IP アドレスから短時間に何度もアクセスされる場合は、レート制限ルールで止めます。「Security」→「Security rules」で「Create rule」→「Rate limiting rules」を選び、次のように設定します。

条件: URI Path が /wp-login.php と等しい
数える単位: IP アドレス
しきい値: 例として 10 秒間に 10 リクエスト
動作: Block（「Duration」は遮断を続ける時間）

Free プランのレート制限ルールは1個までで、条件に使える項目は Path と Verified Bot、数える単位は IP のみ、期間と遮断時間はどちらも 10 秒に固定されています（2026年10月時点）。ログイン画面の表示とログインの送信でそれぞれリクエストが発生するので、しきい値を低くしすぎると正しくログインする人まで止まります。設定後に自分でログインして確かめてください。

ステップ5: 攻撃を受けているときは Under Attack mode を使う

レイヤー7の攻撃でサイトが重くなっているときは、「Under Attack mode」を一時的にオンにします。ドメインの「Overview」ページにある「Quick Actions」の「Under Attack Mode」をオンにすると、訪問者全員にブラウザの確認画面が表示され、通過した人だけがサイトを見られます。

最後の手段として使い、攻撃が収まったらオフに戻します。常時オンにするものではありません。
JavaScript が動かない環境の訪問者や、外部サービスからのアクセス（API、フィード、決済の通知など）が通らなくなることがあります。
管理画面だけにかけたい場合は、「Rules」→「Configuration Rules」でパスを条件にしたルールを作り、「I'm Under Attack」をオンにする方法もあります。

ボットのアクセスが多いだけなら、「Security」→「Settings」で「Bot traffic」に絞り込み、「Bot fight mode」をオンにする方法もあります（Free プランで使えます）。ただし Bot fight mode はカスタムルールで除外できず、API やアプリからのアクセスにチャレンジをかけることがあるので、外部連携を使っているサイトでは動作を確かめてから使ってください。

ステップ6: オリジンサーバーを直接攻撃されないようにする

オリジンの IP アドレスが知られていると、攻撃者は Cloudflare を通らずに直接サーバーへアクセスできます。VPS や専用サーバーなら、Web のポート（80・443）を Cloudflare の IP アドレスからだけ受け付けるように、ファイアウォールを設定します。Cloudflare の IP アドレス範囲は https://www.cloudflare.com/ips/ で公開されています。

Ubuntu の ufw を使う場合の例です。SSH のポートを先に許可しておかないと、自分も接続できなくなるので注意してください。

# SSH を先に許可しておく（ポートを変えている場合は合わせる）
sudo ufw allow OpenSSH

# Cloudflare の IP 範囲からだけ 80/443 を許可する
for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443
done

# 誰からでも 80/443 を許可していた規則があれば削除する（例）
sudo ufw delete allow 'Apache Full'

sudo ufw status numbered

Cloudflare の IP アドレス範囲は変わることがあるので、定期的に一覧を確認します。レンタルサーバーでは自分でファイアウォールを設定できないことが多いので、サーバー会社が用意している WAF や IP 制限の機能を使います。

より強く守りたい場合は、Cloudflare からの接続であることを証明書で確かめる Authenticated Origin Pulls（暗号化モードが Full か Full (strict) のときに使えます）や、オリジンを公開 IP アドレスなしで Cloudflare につなぐ Cloudflare Tunnel（cloudflared をサーバーに入れて使います）もあります。

ステップ7: オリジンで訪問者の本当の IP アドレスを記録する

Cloudflare を経由すると、サーバーのログや WordPress から見える接続元は Cloudflare の IP アドレスになります。このままだと、ログの調査やセキュリティプラグインの IP 制限が正しく働きません。Apache なら mod_remoteip で、Cloudflare が付ける CF-Connecting-IP ヘッダーから本当の IP アドレスを復元します。

sudo a2enmod remoteip

/etc/apache2/conf-available/remoteip.conf を作り、次のように書きます。RemoteIPTrustedProxy には、Cloudflare の IP 範囲を1行に1つずつ、すべて並べます。

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
# 以下、https://www.cloudflare.com/ips/ の範囲をすべて並べる

アクセスログに本当の IP アドレスを残すには、/etc/apache2/apache2.conf の LogFormat の %h を %a に変えます。

sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

RemoteIPTrustedProxy に Cloudflare 以外の範囲を入れると、ヘッダーを偽装した接続元の IP アドレスを信じてしまうので、公式の一覧だけを使ってください。

注意点

Cloudflare の DDoS 対策は、キャッシュしない動的なページ（WordPress のログイン、検索、カートなど）への負荷までは減らしません。重い処理への大量アクセスは、ステップ3・4のルールで絞ります。
ルールを足したら、管理画面へのログイン、投稿、問い合わせフォーム、決済や外部連携がこれまでどおり動くかを確認します。止まった場合は、「Security」→「Analytics」の「Events」で、どのルールが止めたかを確かめます。
プランごとの機能や上限は変わることがあります。設定前に公式ドキュメントで現在の内容を確認してください。

まとめ

Cloudflare の DDoS 対策は全プランで自動的に働く。まず Web サイトの DNS レコードが「Proxied」になっているか、オリジンの IP アドレスが漏れていないかを確認する。
HTTP DDoS の感度と動作は「Security rules」の「DDoS protection」タブで上書きできるが、通常は既定のままでよい。
WordPress では /wp-login.php と /xmlrpc.php にカスタムルールとレート制限をかける。
攻撃を受けているときだけ Under Attack mode を使う。
オリジンは Cloudflare の IP アドレスからだけ受け付け、mod_remoteip で本当の接続元を記録する。