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

午前3時、スマホが激しく振動しました。眠い目をこすって見ると、サーバー監視アラートの嵐。慌ててPCを開くと、CPU使用率は100%に張り付き、サイトは完全にダウンしていました。ログを確認すると、数十個のIPアドレスがAPIに対して毎秒数百回のリクエストを送り続けていました。いわゆる「CC攻撃」です。
正直、その夜は絶望的でした。手動でIPをブロックしても、すぐに新しいIPが現れるイタチごっこ。2時間ほど格闘した末、Cloudflareに防御機能があったことを思い出しました。ダッシュボードを開くと、「Rate Limiting(レート制限)」という機能がありました。
「これ絶対有料だよな……」と躊躇しつつクリックしてみると、なんと無料版でも使えるではありませんか! IPごとに「1分間に20リクエストまで」というルールを設定した瞬間、攻撃トラフィックはピタリと止まりました。魔法のようでした。
その経験から学んだのは、**「CC攻撃の防御は難しくない、重要なのは事前にレート制限を設定しておくこと」**です。この記事では、Cloudflareのレート制限機能の使い方、無料版での活用法、シーン別の推奨しきい値、そして陥りやすい罠について解説します。
CC攻撃とは? なぜレート制限が有効なのか
まず、CC攻撃(Challenge Collapsar)について簡単に説明します。要するに、大量の「正常に見える」アクセスを行い、サーバーのリソースを枯渇させる攻撃です。
通常のDDoS攻撃とは何が違うのでしょう? 従来のDDoSは大量のジャンクデータを送りつけるため特徴が顕著で、Cloudflareの自動防御で防げます。しかし、CC攻撃は通常のHTTPリクエストを装うため、区別がつきにくいのです。
例えば、普通のユーザーは1分間に数ページ、5〜10リクエスト程度しか送りません。しかしCC攻撃では、単一IPから30秒で1000回以上のリクエストが飛んできます。
レート制限は、まさにこの「頻度」に着目します。IPアドレス(またはセッション、APIキー)ごとのリクエスト頻度を監視し、設定したしきい値を超えたら、「キャプチャ認証(人間かどうかの確認)」を出したり、一時的にブロックしたりします。
「正常なユーザーまで巻き込まないか?」と心配になるかもしれません。例えばAPIでデータを連打するような場合です。そのための「適切なしきい値設定」については、後ほど詳しく解説します。
無料版でもOK!機能完全ガイド
これは声を大にして言いたいのですが、2022年10月から、Cloudflareはレート制限機能を全プランに無料開放しました。
以前は「100万リクエストあたり5ドル」という従量課金制でした。これが導入のハードルになっていたのですが、今は違います。無料版(Freeプラン)でも1つのレート制限ルールを作成できます。ProやBusinessプランなら、さらに多くのルールを作れます。
「たった1つ?」と思うかもしれませんが、個人サイトや中小規模のサービスなら、最も攻撃されやすい「ログイン画面」や「重要なAPI」を守るだけで十分効果があります。
まずは無料版で、最も重要なエンドポイントを保護することから始めましょう。
しきい値はどう設定する? シーン別推奨設定
「Requests per period(期間あたりのリクエスト数)」の入力欄を前にして、「10にするべきか、100にするべきか」と悩む必要はありません。以下に推奨値をまとめました。これらはあくまで参考値なので、実際のログを見て調整してください。
ログイン/登録画面(最優先防御対象)
ここはブルートフォース攻撃(総当たり攻撃)の標的になりやすい場所です。
推奨設定(Free版向けシンプル構成):
- 20リクエスト / 60秒 → Block(またはManaged Challenge) 10分間
根拠:普通のユーザーが、パスワードを間違え直したとしても、1分間に20回もログインボタンを押すことはありません。一方で攻撃スクリプトは秒速で試行してくるので、この設定で十分に防げます。
APIエンドポイント
APIの種類によって異なります。
一般的なデータ取得API:
- 30リクエスト / 10秒 → Managed Challenge
- 秒間3リクエスト程度。フロントエンドからの連打にも耐えられます。
重い処理を伴うAPI(画像処理、検索など):
- 10リクエスト / 60秒 → Block
- サーバー負荷が高い処理は厳しめに制限します。
一般的なWebページ(スクレイピング対策)
推奨設定:
- 100リクエスト / 30秒 → Managed Challenge
Webページは、HTMLだけでなくCSS、JS、画像などのリクエストも発生するため、しきい値は高めに設定します。30秒で100回なら、人間が普通にブラウジングしていても引っかかりませんが、高速なスクレイパーは検知できます。
⚠️注意: トップページ(ルートパス)に厳しい制限をかけないでください! Googlebotなどの検索エンジンのクローラーがブロックされ、SEO順位が下がる原因になります。
5分で完了!設定チュートリアル
では、実際に設定してみましょう。
手順1:設定画面へ移動
Cloudflareダッシュボードにログインし、対象ドメインを選択。
Security → WAF → Rate limiting rules へ進みます。「Create rule」ボタンをクリック。
手順2:ルール作成
例として、ログイン画面(/api/login)を保護する設定を作ります。
- Rule name:
Login-Protectionなど分かりやすい名前を。 - Expression(マッチ条件):
- Field:
URI Path - Operator:
equals - Value:
/api/login - ※API全体を守るなら
contains/api/にします。
- Field:
- Rate limiting parameters(制限パラメータ):
- Characteristics:
IP Address(IPごとにカウント) - Period:
60 seconds(1分間) - Requests:
20(20回まで許可)
- Characteristics:
- Action(アクション):
- Action:
Managed Challenge(推奨) - Duration:
10 minutes(10分間制限)
- Action:
Managed Challenge を選ぶと、疑わしい場合にのみ「各種検証画面」が表示され、明らかなBotはブロックされます。Block を選ぶと即座に403エラーを返しますが、誤検知のリスクがあるため、最初はChallengeがおすすめです。
- Deploy をクリックして完了!
これで、1分間に同じIPから20回以上ログイン試行があると、自動的に10分間制限されるようになります。
陥りやすい罠と高度なテクニック
罠1:SEOクローラーをブロックしてしまう
前述の通り、サイト全体(/)に対して厳しいレート制限をかけると、Googlebotもブロックしてしまいます。
対策:
- 制限は「ログイン画面」「検索API」など、負荷が高く攻撃されやすいパスに限定する。
- どうしても全体にかける場合は、
Known Bots(既知の良質なボット)を除外する条件を加える(ただしこれは有料版の機能です)。
罠2:攻撃者がCloudflareを回避する
攻撃者があなたのサーバーの「真のIPアドレス(源IP)」を知っている場合、Cloudflareを経由せずに直接攻撃してきます。
対策:
- サーバーのファイアウォール(iptablesやAWS Security Group)で、CloudflareのIP帯域からのアクセスのみを許可し、それ以外をすべて遮断してください。これが最強の対策です。CloudflareのIPリストは公式サイトで公開されています。
テクニック:分散型攻撃への対応
IPアドレスをコロコロ変えてくる攻撃には、IPベースの制限が効きにくい場合があります。
対策:
- Cookie/Sessionベースの制限: ログイン済みユーザーなら、Characteristicsを
IPではなくHeader(Cookie) に設定することで、IPが変わってもセッション単位で追跡してBANできます。
まとめ
レート制限の導入は、**「転ばぬ先の杖」**です。攻撃を受けてから慌てて設定するのではなく、平和な今のうちに、まずは「ログイン画面」だけでも保護設定を入れておきましょう。無料版の1ルールで十分守れます。
Cloudflareレート制限設定フロー
CC攻撃を防ぐためのレート制限ルールの設定手順
⏱️ Estimated time: 5 min
- 1
Step1: 管理画面へアクセス
CloudflareダッシュボードのSecurity > WAF > Rate limiting rulesへ移動し、「Create rule」をクリック。 - 2
Step2: 保護対象の指定
Expressionセクションで、URI Path equals /login のように攻撃されやすいパスを指定。 - 3
Step3: しきい値の設定
Requests per periodを設定。ログイン画面なら60秒間に20回程度が目安。 - 4
Step4: アクションの選択
しきい値を超えた時の動作を選択。最初は誤検知を防ぐため「Managed Challenge」を選び、期間を10分(600秒)などに設定。 - 5
Step5: デプロイとテスト
ルールを保存。ブラウザやcurlコマンドで連打して、設定通りにブロック/チャレンジが表示されるかテストする。
FAQ
無料版でいくつのルールを作れますか?
SEOに悪影響はありますか?
誤って普通のユーザーをブロックしてしまいませんか?
4 min read · 公開日: 2025年12月1日 · 更新日: 2026年1月22日
関連記事
Next.js ファイルアップロード完全ガイド:S3/Qiniu Cloud 署名付き URL 直接アップロード実践

Next.js ファイルアップロード完全ガイド:S3/Qiniu Cloud 署名付き URL 直接アップロード実践
Next.js Eコマース実践:カートと Stripe 決済の完全実装ガイド

Next.js Eコマース実践:カートと Stripe 決済の完全実装ガイド
Next.js ユニットテスト実践:Jest + React Testing Library 完全設定ガイド


コメント
GitHubアカウントでログインしてコメントできます