先に要点
- Cloudflareは、DNS、CDN、WAF、DDoS対策、Zero Trustなどを提供するネットワーク・セキュリティ系サービスです。
- DNSは「ドメインをどこへ向けるか」、CDNは「配信を速く・軽くする」、WAFは「Web攻撃を入口で止める」役割です。
- Cloudflareを入れれば全部安全になるわけではなく、プロキシ有効 / DNS only、キャッシュ、SSL/TLS、オリジン保護を分けて考える必要があります。
Cloudflareは、Webサイト運用でかなりよく名前が出るサービスです。
ドメイン設定、CDN、高速化、DDoS対策、WAF、SSL/TLS、キャッシュ、リダイレクト、Zero Trust。
できることが多いので、初心者ほど 結局Cloudflareって何をするもの？ となりやすいです。
ざっくり言うと、CloudflareはWebサイトやWebアプリの前段に立ち、名前解決、配信、セキュリティ、通信の制御を助けるサービス群です。
ただし、DNSだけ使う場合と、CDNやWAFまで使う場合では意味がかなり違います。
この記事では、2026年4月21日時点のCloudflare公式ドキュメントを確認しながら、DNS、CDN、WAFをどう使い分けるかを整理します。
CDNの基本から見たい場合は CDNとは？何が速くなるのか、どこまで必要なのかを解説、DNS移行の感覚は ドメイン移管とサーバー移転の違いとは？DNS・ネームサーバー・メール設定の注意点を整理 もつながります。
Cloudflareとは何か
Cloudflareは、WebサイトやAPIの前に入って、アクセスを中継したり、キャッシュしたり、攻撃を止めたりするサービスです。
代表的には次のような機能があります。
ただし、最初から全部を使う必要はありません。
小規模サイトや小さなWebアプリなら、まずはDNS管理、CDN、WAFの3つを分けて理解するだけでもかなり整理できます。
DNS・CDN・WAFの違い
Cloudflareで混乱しやすいのは、DNS、CDN、WAFが同じ画面や同じドメイン設定の中で出てくることです。
でも役割は別です。
| 機能 | 役割 | 見るポイント |
|---|---|---|
| DNS | ドメイン名をサーバーやサービスへ向ける | Aレコード、CNAME、MX、TXT、ネームサーバー |
| CDN | 利用者に近い場所から静的ファイルなどを配信する | キャッシュ対象、更新反映、オリジン負荷 |
| WAF | Webアプリへの怪しいHTTPリクエストを検査・遮断する | ルール、誤検知、攻撃遮断、ログ確認 |
DNSは「住所録」、CDNは「配達拠点」、WAFは「入口の検査」と考えると入りやすいです。
同じCloudflare上にありますが、目的は違います。
DNSだけ使う場合
CloudflareはDNS管理だけでも使えます。
この場合、CloudflareはドメインのDNSレコードを管理しますが、Webアクセス自体をCloudflareが中継しない設定もできます。
たとえば、次のような使い方です。
- AレコードでWebサーバーのIPアドレスへ向ける
- CNAMEで外部サービスへ向ける
- MXレコードでメールサーバーを指定する
- TXTレコードでSPF、DKIM、DMARC、認証用レコードを入れる
- サブドメインごとに向き先を分ける
この段階では、Cloudflareは主にDNS管理の役です。
CDNやWAFを使っているとは限りません。
注意したいのは、ネームサーバーをCloudflareへ切り替えると、DNS管理先そのものが変わることです。
WebのAレコードだけでなく、メール、サブドメイン、認証用TXTレコードまで移し忘れると、サイト以外の機能が止まることがあります。
プロキシ有効とDNS onlyの違い
CloudflareのDNS画面では、レコードごとにプロキシを有効にするか、DNS onlyにするかを選ぶ場面があります。
Cloudflareの画面では、プロキシ有効がオレンジ色の雲、DNS onlyがグレーの雲として表現されることがあります。
違いはかなり重要です。
| 設定 | 何が起きるか | 使える機能 |
|---|---|---|
| DNS only | DNSが実際の向き先を返す | DNS管理のみ。CDNやWAFは基本的に通らない |
| Proxied | CloudflareのIPを返し、HTTP/HTTPS通信がCloudflareを通る | CDN、WAF、DDoS対策、SSL/TLS、キャッシュなどを使いやすい |
Cloudflare公式ドキュメントでも、proxied recordではTLSがCloudflareのグローバルネットワークで終端されること、第三者サービスのIP検証などではDNS onlyが必要になる場合があることが説明されています。
つまり、CloudflareのDNSに入れただけでCDNやWAFが必ず効くわけではありません。
メール用のMX、外部SaaSの検証用CNAME、特殊なプロトコルのサブドメインなどは、DNS onlyにする場面もあります。
一方で、WebサイトやWebアプリのHTTP/HTTPSをCloudflareで守りたいなら、プロキシ有効にする必要があります。
CDNとして使う場合
CloudflareをCDNとして使うと、画像、CSS、JavaScript、公開HTMLなどをCloudflareのエッジから配信できます。
CloudflareのCDN関連ドキュメントでも、キャッシュ可能なコンテンツを利用者に近い場所から返すことで、遅延やオリジン負荷を減らす考え方が説明されています。
CDNが向いているのは、次のような場面です。
- 画像が多いサイト
- CSSやJavaScriptを配信する公開サイト
- アクセスが全国・海外からある
- オリジンサーバーの負荷を下げたい
- 静的ページや公開コンテンツを速くしたい
ただし、CDNは万能ではありません。
ログイン後の個人情報ページ、管理画面、在庫、決済、権限情報のように、利用者ごとに違う内容をキャッシュすると事故になります。
キャッシュは速くする技術ですが、古い内容を残す技術でもあります。
Cloudflareを入れたあとに 更新したのに反映されない 一部ユーザーだけ古い画面が見える という問題が起きたら、まずキャッシュを疑います。
WAFとして使う場合
WAFは Web Application Firewall の略で、WebアプリへのHTTPリクエストを検査し、怪しいアクセスを遮断する仕組みです。
Cloudflare WAFの公式ドキュメントでは、WebやAPIへのリクエストをルールセットにもとづいて検査し、望ましくないトラフィックをフィルタするものとして説明されています。
WAFが見やすい攻撃や挙動には、次のようなものがあります。
- SQLインジェクションらしいリクエスト
- XSSらしいリクエスト
- 管理画面への不審なアクセス
- 既知の脆弱性を狙うリクエスト
- 特定パスへの大量アクセス
- 不審なUser-Agent
- 国やIPレンジによる制限
- APIへの過剰な呼び出し
WAFは、アプリの脆弱性を直さなくてよい魔法ではありません。
根本対策はアプリ側の修正、認証、入力検証、権限設計です。
WAFはその前段で、既知攻撃や明らかに怪しいアクセスを減らす防御層として使います。
DNS・CDN・WAFの使い分け
小規模サイトやWebアプリなら、次のように考えると分かりやすいです。
| やりたいこと | 使う機能 | 注意点 |
|---|---|---|
| ドメインをサーバーへ向けたい | DNS | メールや認証用TXTの移し忘れに注意 |
| 画像や静的ファイルを速くしたい | CDN | キャッシュ対象と更新反映を決める |
| 攻撃っぽいHTTPアクセスを減らしたい | WAF | 誤検知とログ確認をセットで見る |
| DDoSの影響を軽くしたい | プロキシ + DDoS対策 | オリジンIPが直接叩かれない設計も必要 |
| HTTPSを使いたい | SSL/TLS | Cloudflareとオリジン間の暗号化も見る |
重要なのは、目的を分けることです。
Cloudflareを入れる ではなく、DNS管理を移す、CDNで静的ファイルを配る、WAFで管理画面を守る、DDoS対策を前段に置く のように分けて考えます。
SSL/TLSで失敗しやすい点
Cloudflareを入れると、ブラウザとCloudflareの間、Cloudflareとオリジンサーバーの間という2つの通信経路を考える必要があります。
よくある失敗は、Cloudflare側でHTTPSになったので、オリジンサーバー側の証明書を軽く見てしまうことです。
Cloudflare公式のSSL/TLSモードでは、Full (strict) はオリジン証明書をより厳しく検証するモードとして説明されています。
実務では、できるだけ次を目指します。
- ブラウザからCloudflareまでHTTPS
- CloudflareからオリジンまでHTTPS
- オリジン証明書も有効
- HTTPからHTTPSへのリダイレクトを整理
- アプリ側のURL生成やCookie設定も確認
Cloudflareを入れたらHTTPSが全部解決、ではありません。
特にログイン、決済、管理画面があるサイトでは、Cloudflareとオリジン間の通信もきちんと見ます。
小規模サイトでのおすすめ導入順
小規模サイトや小さなWebアプリなら、次の順番が現実的です。
1. DNSを棚卸し
Web、メール、サブドメイン、TXTレコードを確認してからネームサーバーを切り替えます。
2. Webだけプロキシ
まずはHTTP/HTTPSのサブドメインだけプロキシ有効にし、メール系はDNS onlyにします。
3. キャッシュを控えめに
画像、CSS、JavaScriptなど安全な静的ファイルからキャッシュします。
4. WAFを観察しながら
いきなり強く止めすぎず、ログを見ながらルールを調整します。
Cloudflareは強いサービスですが、最初から全部ONにすると原因切り分けが難しくなります。
DNS、プロキシ、キャッシュ、WAFを1つずつ確認しながら入れる方が安全です。
よくある失敗
失敗例1：DNSを移したらメールが止まる
Cloudflareへネームサーバーを切り替えると、DNS管理先が変わります。
MX、SPF、DKIM、DMARCなどのメール関連レコードを移し忘れると、メール送受信や認証に影響します。
失敗例2：プロキシ有効とDNS onlyを混同する
CloudflareのDNSにレコードがあるだけでは、CDNやWAFが効いているとは限りません。
WebをCloudflare経由にしたいなら、対象レコードがプロキシ有効になっているか確認します。
失敗例3：ログイン後のページをキャッシュする
公開ページならCDNキャッシュが効きやすいですが、ログイン後の個別ページを不用意にキャッシュすると危険です。
ユーザーごとに違う情報、権限、在庫、決済、管理画面は慎重に扱います。
失敗例4：WAFを強くしすぎて正規ユーザーを止める
WAFは攻撃を止める一方で、誤検知もあります。
問い合わせフォーム、管理画面、API、外部サービスのWebhookが止まっていないか、ログを見ながら調整します。
失敗例5：オリジンIPが直接アクセス可能なまま
Cloudflareをプロキシとして使っても、オリジンサーバーのIPが直接アクセス可能なら、Cloudflareを迂回されることがあります。
本気で守るなら、オリジン側でCloudflareからの通信だけ許可する、管理経路を分ける、Cloudflare Tunnelを検討するなどの対策も見ます。
導入前チェックリスト
Cloudflareを入れる前に、次を確認します。
- 現在のDNSレコードを全部控えた
- Web、メール、サブドメイン、認証用TXTを分けて確認した
- どのレコードをプロキシ有効にするか決めた
- メール系レコードはDNS onlyにする判断をした
- オリジンサーバーのHTTPS証明書を確認した
- キャッシュしてよいパスと、してはいけないパスを分けた
- 管理画面やログイン後ページのキャッシュを避けた
- WAFのログを確認する担当を決めた
- 誤検知時の解除手順を決めた
- オリジンIPへ直接アクセスできるか確認した
このあたりを見ずに とりあえずCloudflareをON にすると、速くなる前に原因不明のトラブルが増えることがあります。
まとめ
Cloudflareは、DNS、CDN、WAF、DDoS対策、SSL/TLSなどをまとめて扱える強力なサービスです。
ただし、DNS、CDN、WAFは役割が違います。
DNSはドメインの向き先を管理するもの。
CDNは静的ファイルなどを速く・軽く配信するもの。
WAFはWebアプリへの怪しいリクエストを入口で止めるものです。
Cloudflareを使うときは、まず DNSだけ使うのか HTTP/HTTPSをプロキシするのか 何をキャッシュするのか WAFで何を止めるのか を分けて考えます。
小規模サイトでも効果は大きいですが、メールレコード、キャッシュ、SSL/TLS、オリジン保護を確認しながら段階的に入れるのが安全です。
参考
- Cloudflare Docs: Cloudflare Web Application Firewall (WAF)
- Cloudflare Docs: Content Delivery Network (CDN) Reference Architecture
- Cloudflare Docs: Get started with Cache
- Cloudflare Docs: DNS proxy status use cases
- Cloudflare Docs: Full (strict) SSL/TLS encryption mode
- Cloudflare Docs: DDoS Protection