Cloudflare レート制限設定ガイド：5 分で CC 攻撃を防御、無料版でも使える

午前 3 時。サーバー監視アラートで目が覚め、CPU 使用率が 100% に達し、サイトが完全にダウン。ログを見ると、数十 IP が API を狂ったように叩き、毎秒数百リクエスト——CC 攻撃でした。

慌てて IP を手動ブロックしても、すぐ新しい IP が現れ、追いきれません。2 時間も消耗した末、Cloudflare に防御機能があるはずだと思い出しました。ダッシュボードを開くと Rate Limiting があり、無料版でも使えます。1 ルールで「1 IP あたり 1 分 20 リクエスト、超過時 10 分ブロック」を設定。5 分で完了し、攻撃トラフィックはすべて遮断されました。

CC 攻撃の防御はそれほど難しくありません。重要なのは、事前にレート制限ルールを入れておくことです。本記事では Cloudflare のレート制限機能について、無料版の使い方、しきい値の目安、シーン別設定、よくある落とし穴まで解説します。

CC 攻撃とは？レート制限で防げる理由

まず CC 攻撃（Challenge Collapsar）とは何か。正常ユーザーに見える大量アクセスで、サーバーリソースを枯渇させる攻撃です。

「DDoS と同じでは？」と思うかもしれません。従来の DDoS は大量のジャンクパケットを送るため特徴が明確で、Cloudflare の自動 DDoS 防御でほぼ防げます。CC 攻撃は正常な HTTP リクエストを送るため、従来の DDoS 防御では見抜きにくいのです。

例えば、正常ユーザーは 1 分に数ページ、5〜10 リクエスト程度。CC 攻撃では単一 IP が 30 秒で 1000 回以上送ることもあります。攻撃者は多数のマシンやプロキシ IP を使い、トラフィックが分散して防ぎにくくなります。

レート制限は、この「頻度の異常」に着目した仕組みです。各 IP（またはセッション、API キーなど）のリクエスト頻度を監視し、しきい値を超えたら CAPTCHA で人間確認を求めたり、一定時間ブロックしたりします。

以前受けた攻撃では、攻撃 IP は秒あたり 200〜300 リクエスト、しきい値は 1 分 20 回。攻撃トラフィックは 1〜2 秒で制限に引っかかり、以降は遮断。正常ユーザーは制限に触れないため、体験への影響はありません。

参考データ：Alibaba Cloud WAF のベストプラクティスでは、典型例として 1 台のボットが 30 秒で 1000 回以上リクエストし、正常ユーザーは通常 1 分に 10 回以下とされています。

この差ははっきりしています。

「正常ユーザーが素早く操作した場合は？」——API でデータを連打するケースもあります。だからこそしきい値設定が重要で、後述のシーン別推奨値を参考にしてください。

無料版でも使える！Cloudflare レート制限機能の全体像

ここは強調したいポイントです。多くの人（以前の私も）がレート制限を有料機能だと思いがち。2022 年 10 月から、Cloudflare はレート制限を Free、Pro、Business すべてのプランで無料提供しています。

以前は 100 万リクエストあたり 5 ドルの従量課金。トラフィックの多いサイトではコストが無視できませんでした。私もそのため導入を先延ばしにしていました。

今は公式ブログでも明言されており、レート制限ルールはすべてのプランに含まれ、追加料金はかかりません。無料版ユーザーは 1 本のレート制限ルールを作成できます。Pro と Business ユーザーはさらに多く作成できます。

「1 本だけで足りる？」——中小規模サイトなら十分です。重要なのは、その 1 本を最も攻撃されやすい場所に使うこと。通常はログイン、登録、コア API です。

私の小規模プロジェクトもすべてログイン API だけを保護する 1 ルールで、約 1 年問題なく運用しています。小規模なスキャン攻撃も遮断されています。

業務が複雑で複数エンドポイントを守る必要があるなら、Pro または Business へのアップグレードを検討してください。Pro は月 20 ドルで 10 ルール、Business は月 200 ドルで 15 ルール。個人サイトや中小企業なら、無料版の 1 ルールで大半の問題は解決します。

補足：無料版はレート制限ルールが 1 本だけですが、Cloudflare の基本 DDoS 防御はすべてのプランに含まれ、トラフィック制限もありません。明らかな DDoS 攻撃は自動で遮断されます。レート制限は、より巧妙な CC 攻撃や API 乱用向けです。

無料版 vs 有料版の主な違い：

• ルール数：Free 1 本、Pro 10 本、Business 15 本
• 高度な特徴：有料版は Bot Score、JA3 フィンガープリントなど複雑なマッチ条件が使える
• 応答時間：有料版は高トラフィック時の応答が速い

レート制限を初めて使うなら、まず無料版で最重要 API を 1 本保護し、効果を見てからアップグレードを検討するのがおすすめです。

しきい値はどう設定する？シーン別の推奨値

初回設定時、「Requests per period」に 10 を入れるか 100 を入れるか、迷った経験があります。Cloudflare 公式ドキュメントや各社のベストプラクティス、実際のテストを踏まえた推奨値をまとめました。参考値であり、自サイトのトラフィック特性に合わせて調整してください。

ログイン/登録 API（最も攻撃されやすい）

ログイン API はブルートフォースやクレデンシャルスタッフィングの標的になりやすい。正常ユーザーのアクセス頻度は低い一方、攻撃時は大量トラフィックが集中します。

推奨設定（3 段階）：

Cloudflare 公式推奨の 3 層ルール：

• 第 1 層：4 回/分 → JavaScript チャレンジ
• 第 2 層：10 回/10 分 → CAPTCHA
• 第 3 層：20 回/時間 → 1 日ブロック

無料版は 1 ルールだけなので簡略化が必要。私の設定は：

• 1 層構成：20 回/60 秒 → 10 分ブロック

しきい値の根拠：ログを見ると、正常ユーザーがパスワードを間違えても 1 分に 5 回を超えることはほぼありません。攻撃スクリプトは 1 分に数百〜数千回試行します。20 回/分なら大半の攻撃を防ぎつつ、誤検知も避けられます。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

セキュリティ要件が高い場合：

• 厳格モード：10 回/60 秒 → 1 時間ブロック

API（業務特性に応じて調整）

API の種類によってアクセス頻度は大きく異なります。

一般クエリ API：

• 推奨：30 回/10 秒 → JavaScript チャレンジ

秒 3 リクエスト程度。多くのフロントエンドアプリに十分で、ユーザーが素早く更新してもすぐブロックされません。

計算集約型 API（画像処理、データ分析など）：

• 推奨：10 回/60 秒 → レート制限

サーバー負荷が高いため低めに。1 分 10 回なら通常利用には十分、悪意ある大量呼び出しは防げます。

公開 API（外部向けサービス）：

• 推奨：課金モデルとリソース許容量に応じて設定

無料 API なら 100 回/時間、有料 API ならプラン別に設定。Google Cloud Armor の参考例では、API に 2000 回/20 分、超過時 20% 流量制限という段階的アプローチも紹介されています。

一般 Web ページ（スクレイピング対策）

一般ページは API より頻度は低いですが、悪意あるスクレイピング対策が必要です。

推奨設定：

• 通常ページ：100 回/30 秒 → JavaScript チャレンジ
• 特殊ページ（検索、ダウンロード）：50 回/60 秒 → CAPTCHA

一般ページのしきい値を高めにする理由：正常閲覧では複数リンクを素早く開き、CSS、JS、画像で 1 ページあたり十数リクエストが発生します。30 秒 100 回なら通常閲覧では触れませんが、クローラーの 30 秒 100 回は速すぎて検知できます。

特に注意：トップページに厳しい制限をかけないこと。以前、トップページに厳格なレート制限を入れたら Google と Bing のクローラーまでブロックし、SEO 順位が下がりました。すぐにルールを削除して回復しました。

実例参考

Alibaba Cloud WAF のベストプラクティスでは、中小サイト向けの予防設定として：

• 単一 IP が 30 秒で 1000 回超 → 10 時間ブロック

比較的緩い設定で、最終防衛線として使えます。迷ったらこれを起点に、ログを見ながら調整してください。

もう 1 つのコツ：ルール作成後、最初は「Block」ではなく「Managed Challenge」を使う。しきい値がやや低くても、真人ユーザーは CAPTCHA を通過できます。一定期間運用して誤検知がなければ「Block」に切り替えましょう。

5 分設定チュートリアル（手順どおり）

理論はここまで。実際の設定手順です。5 分で完了します。

ステップ 1：Rate Limiting ルール画面へ

Cloudflare ダッシュボードにログインし、対象ドメインを選択。

Security → WAF → Rate limiting rules

未設定なら「Create rule」ボタンが表示されます。無料版は「0/1 rules」と表示され、あと 1 本作成できます。

ステップ 2：基本情報

「Create rule」をクリックし、基本情報を入力。

Rule name（ルール名）：

「Login-Rate-Limit」「API-Protection」など、後から識別しやすい名前に。

ステップ 3：マッチ条件（Expression）

どのリクエストをこのルールで監視するかを指定します。

ログイン API を保護する例：

Field: URI Path
Operator: equals
Value: /api/login

/api/login へのアクセスのみ監視します。

API 全体を保護する例：

Field: URI Path
Operator: contains
Value: /api/

/api/ で始まるすべてのパスを監視します。

追加条件も可能。監視スクリプトの User-Agent を除外する例：

Field: User Agent
Operator: does not equal
Value: MyMonitorBot

ステップ 4：レート制限パラメータ（核心）

いつ制限を発動するかを決める最重要セクションです。

Characteristics（カウント特徴）：

リクエストを何で識別・カウントするか。主な選択肢：

• IP Address：訪問者 IP でカウント（推奨、CC 対策の定番）
• Session：Cookie のセッション ID でカウント（ログイン済みユーザー向け）
• Headers：HTTP ヘッダーでカウント（API Key など、API 保護向け）

ログイン API 保護なら IP Address で十分です。

Period（時間窓）：

10 秒、30 秒、60 秒などから選択。私は 60 秒（1 分）が一般的です。短すぎると誤検知、長すぎると防御効果が下がります。

Requests per period（リクエストしきい値）：

時間窓内に許可するリクエスト数。ログインなら 20、API なら 30 が目安。

Duration（ブロック期間）：

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

制限発動後のブロック時間。1 分〜24 時間。私は 10 分 をよく使います。

ログイン保護の完全例：

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

意味：同一 IP が 60 秒間にログイン API へ 20 回超アクセスしたら、10 分間ブロック。

ステップ 5：レスポンスアクション（Action）

しきい値超過時の処理を選択します。

Managed Challenge（托管チャレンジ） — 推奨：

Cloudflare が人間とボットを自動判定。真人ユーザーは検証ページを見るか、そのまま通過。ボットはブロック。誤検知時の影響が最小。

Block（直接ブロック）：

403 を返して拒否。防御力は高いが、誤検知時は対応が手間。ルール確認後に検討。

Legacy CAPTCHA（従来型 CAPTCHA）：

CAPTCHA 入力を要求。体験はやや劣るが、真人とボットの区別には有効。

JS Challenge（JavaScript チャレンジ）：

JavaScript をクライアントで実行させ、実ブラウザか検証。クローラーに有効、正常ユーザーにはほぼ無感知。

最初は Managed Challenge を使い、問題なければ Block に切り替えるのがおすすめです。

ステップ 6：保存と有効化

画面下部の「Deploy」をクリック。即時反映、待ち時間なし。

ステップ 7：動作確認

設定後、簡単にテストできます。

for i in {1..30}; do curl https://yourdomain.com/api/login; done

正しく設定されていれば、最初 20 回は正常、21 回目以降は 429 またはチャレンジ画面が返ります。

Cloudflare ダッシュボードの Security → Events でブロックログも確認できます。

完全設定例

ログイン API /api/auth/login を保護する例：

基本情報：

• Rule name: Login-Rate-Limit

マッチ条件：

• URI Path equals /api/auth/login

レート制限パラメータ：

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

レスポンスアクション：

• Action: Managed Challenge

Deploy をクリックすれば完了。本当に 5 分で終わります。

高度なテクニックとよくある落とし穴

レート制限は設定自体は簡単ですが、運用にはいくつか落とし穴があります。

落とし穴 1：SEO クローラーの誤検知

前述しましたが、再強調します。

トップページや全サイトに厳しいレート制限をかけないでください。

以前、全サイト 30 秒 50 回超でブロックする 1 ルールを入れたら、1 週間で Google Search Console のクロールエラーが急増。Googlebot は CSS、JS、画像を同時取得するため、制限に引っかかりやすい。

ログインと API のみ保護し、一般ページは制限しない構成に変えて解決しました。

推奨：

• ログイン、登録、API など敏感なエンドポイント：厳格に
• 一般コンテンツページ：緩く、または制限なし
• トップページ：可能な限り制限しない

コンテンツスクレイピング対策が必要なら Bot Management（有料）で善意クローラー（Google など）と悪意クローラーを区別できます。

落とし穴 2：攻撃者がレート制限を迂回

レート制限を設定しても CC 攻撃を受けた例：攻撃者が Cloudflare を迂回し、サーバーの実 IP に直接アクセス。

なぜ起きるか：

Cloudflare はリバースプロキシ。サーバーの前に立って防御しますが、実 IP が漏れると、プロキシを飛ばして源サーバーへ攻撃可能です。

対策：

1. サーバーファイアウォールで Cloudflare IP のみ許可

Cloudflare 公式の IP リスト（IPv4/IPv6）で、80/443 へのアクセスを Cloudflare IP のみに制限。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

Linux サーバーでの例：

# Cloudflare IP のみ許可
for i in `curl https://www.cloudflare.com/ips-v4`; do
  ufw allow from $i to any port 443 proto tcp
  ufw allow from $i to any port 80 proto tcp
done

2. 実 IP の定期変更

実 IP が漏れたら変更を検討。DNS で実 IP を直接公開しないこと。

3. Authenticated Origin Pulls の利用

Cloudflare 証明書を要求し、リクエストが Cloudflare 経由であることを保証する高度な方式。

落とし穴 3：監視と調整の忘れ

ルール設定は一度きりではありません。定期的な見直しが必要です。

設定後放置した例：

• しきい値が低すぎて正常ユーザーを誤検知、サポートも原因不明
• トラフィック増加でしきい値が合わなくなった
• 攻撃パターンが変わり、防御効果が低下

推奨：

月 1 回程度 Security Analytics を確認：

• ブロック数
• 正常ユーザーの誤検知
• 429 エラー率の異常

429 が少なければしきい値を下げて防御強化、多ければしきい値を上げるかルールを調整。

テクニック 1：分散型攻撃への対応

最近の CC 攻撃は大量のプロキシ IP を使い、各 IP の頻度が低く、単純な IP 制限では防ぎにくい。

対処法：

1. Session/Cookie カウント（IP ではなく）

セッション機構があるサイトでは Session ID でカウント。IP を変えても Session ID が同じならブロック可能。Characteristics で Cookie を選び、Session Cookie 名を指定。

2. User-Agent フィルタの併用

攻撃スクリプトの User-Agent は「Python」「curl」など異常なことが多い。マッチ条件に User-Agent フィルタを追加。

3. Bot Management（有料）

Cloudflare が各リクエストに 1〜100 のスコアを付与。Bot Score < 30 のリクエストだけにレート制限を適用可能。Business または Enterprise プランが必要。

テクニック 2：段階的レスポンス戦略（有料版）

有料版なら 3 層防御を試せます：

第 1 層（緩）：

• しきい値：高め（例：30 回/分）
• アクション：JS Challenge（ほぼ無感知）

第 2 層（中）：

• しきい値：中程度（例：50 回/10 分）
• アクション：Managed Challenge

第 3 層（厳）：

• しきい値：低め（例：100 回/時間）
• アクション：Block 24 時間

真人ユーザーに猶予を与えつつ、執拗な攻撃者には厳しく対応できます。

テクニック 3：地域別防御

中国向けビジネスなら、海外トラフィックを厳しく制限する選択肢も。

Expression に地理条件を追加：

(ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")

非中国 IP のみ厳格制限。国内ユーザーは影響なし。VPN 利用者も海外扱いになる点に注意。Block より Challenge を推奨。

最後に

核心はシンプルです。レート制限の設定は難しくない。重要なのは、攻撃を受ける前に済ませておくこと。

アラートで目が覚める夜、慌てて調べるより、5 分で 1 ルール入れておく方がずっと楽です。

行動の提案：

1. 今すぐ 1 ルールを設定。攻撃を受けたことがなくても、備えておく価値があります。
2. ログイン API から始める。無料版 1 ルールなら、ログインまたは登録 API に使うのが最優先。
3. 設定後にテスト。curl やブラウザで連続アクセスし、Security Events でログを確認。
4. 定期的に見直す。月 1 回 Security Analytics をチェックし、しきい値を調整。

最後に再確認：サーバーファイアウォールで Cloudflare IP のみ許可すること。攻撃者が Cloudflare を迂回して源サーバーを直接叩けば、いくらルールを増やしても意味がありません。

設定中に問題があれば、Cloudflare 公式ドキュメントやコミュニティフォーラムを参照してください。多くの問題は既知で、解決策が見つかります。

本記事が CC 攻撃からサイトを守る助けになれば幸いです。