Cloudflare は、サイトの DNS と CDN を受け持つことで、読者とサイトのサーバーのあいだに立ち、そのドメインへの通信を仲立ちするサービスです。公式の文書では、この立ち位置を「リバースプロキシ」と呼んでいます。無料プランでも、DNS・SSL 証明書・CDN(キャッシュ)・DDoS 攻撃対策などが使えます(2026年10月10日時点)。
ただし、設定を間違えると困ることもあります。メールを受けるレコードをプロキシにするとメールが届かなくなりますし、サーバーが http を https へ転送しているのに SSL のモードに Flexible を選ぶと、サイトが開けなくなります。この記事は、Cloudflare を自分のサイトに使おうか迷っている初心者に向けて、何をするサービスなのか、プロキシ済み(オレンジの雲)と DNS のみ(グレーの雲)の違い、SSL のモード、無料プランでできること、使い始めるときの手順と注意を、公式の文書に沿って説明します。
Cloudflare の文書は随時更新されるので、日付が効く話には「2026年10月10日時点」と、出どころのページの更新日を添えています。
- Cloudflare が何をするサービスか(DNS・プロキシ・CDN・SSL の関係)
- プロキシ済み(オレンジの雲)と DNS のみ(グレーの雲)の違いと、DNS のみにするレコード
- SSL のモードの違いと、Flexible を選ぶとどうなるか
- 無料プランでできること(数には出どころと更新日つき)と、「全部キャッシュされて速くなる」わけではないこと
- 使い始める手順は、ドメインの契約はそのままで、ネームサーバーだけを Cloudflare に向けること。その前にやる3つのこと
Cloudflare とは? DNS・プロキシ・CDN の関係
Cloudflare の公式の文書には、次の趣旨の説明があります。サイトやアプリを速く・安全にするために、Cloudflare は DNS と CDN のサービスを提供していて、そのドメインへの通信をリバースプロキシする、という説明です。
用語を一つずつ補います。
- DNS。 公式は「インターネットの電話帳」と説明しています。
cloudflare.comのようなドメイン名を、数字の IP アドレスに変える仕組みです - リバースプロキシ。 公式の説明では、Web サーバーの前に立つサーバーの網のことです。リクエストをサーバーへ回したり、サーバーの代わりに応えたりします。サイトの安全・速さ・安定のために置かれます
- CDN。 コンテンツ配信ネットワークの略で、世界の各地のサーバーから中身を配る仕組みのことです。キャッシュ(よく見られる中身の写しを、読者の近くに置くこと)もその一つです
- オリジン。 サイトの元のデータを置いているサーバーのことです。この記事では「サーバー」と書きます
公式は、リバースプロキシの利点を4つ挙げています。
- 負荷分散(Load balancing)
- 攻撃からの保護(サーバーの IP アドレスを見せずに済む)
- キャッシュ(近くのサーバーから返す)
- SSL の暗号化(暗号の処理をサーバーの代わりに受け持つ)
つまり Cloudflare は、サイトを置くサーバーの代わりではなく、サーバーの前に立つものです。サイトを置くサーバーを選ぶ話は、レンタルサーバーの比較の記事にあります。
出典: Cloudflare の仕組み(How Cloudflare DNS works。2026年4月20日更新)
ドメインを載せると、Cloudflare が DNS の答えを出す元になる
ふつうのやり方(公式の言い方で「フルセットアップ」)でドメインを Cloudflare に載せると、Cloudflare がそのドメインの権威 DNSになります。権威 DNS とは、そのドメインの DNS の答えを出す元のことです。DNS のレコード(ドメイン名と行き先の対応を書いた1行ずつの記録)は、Cloudflare の画面か API で管理します。
ネームサーバーを Cloudflare に向け、確認が済むと、ドメインの状態が「有効(active)」になります。ネームサーバーとは、そのドメインの DNS の設定を預けている先です。
Cloudflare DNS は権威 DNS のサービスで、どのプランでも使えます(2026年8月14日更新のページ)。
出典: Cloudflare の仕組み(2026年4月20日更新)・Cloudflare DNS(2026年8月14日更新)
「1.1.1.1」は別のもの
「Cloudflare DNS」で調べると、1.1.1.1 の話も出てきます。1.1.1.1 は、パソコンやスマホが名前を引くときに使う公開の DNS リゾルバー(名前を引く側)で、無料です。サイトの DNS を Cloudflare に任せる話とは別のものです。この記事で扱うのは、サイトの側の話です。
出典: 1.1.1.1(DNS Resolver。2026年4月30日更新)
プロキシ済み(オレンジの雲)と DNS のみ(グレーの雲)は何が違う?
Cloudflare の DNS のレコードには、「プロキシの状態」(Proxy status)があります。この設定で、そのレコードの HTTP/HTTPS の通信を Cloudflare の網に通すか、サーバーへ直に行かせるかが決まります。
- プロキシ済み(Proxied)。 画面ではオレンジの雲。Cloudflare が読者とサーバーのあいだに立ち、最適化・キャッシュ・保護をします
- DNS のみ(DNS-only)。 画面ではグレーの雲。Cloudflare はサーバーの本当の IP アドレスを答えるだけで、HTTP/HTTPS の通信は Cloudflare を通りません
雲の色だけで見分けず、「プロキシ済み」「DNS のみ」という名前も一緒に覚えておきます。
| 項目 | プロキシ済み(オレンジの雲) | DNS のみ(グレーの雲) |
|---|---|---|
| HTTP/HTTPS の通信 | Cloudflare の網を通る | Cloudflare を通らず、サーバーへ直に行く |
| DNS で名前を引くと | Cloudflare の IP アドレスが返る | サーバーの本当の IP アドレスが返る |
| 最適化・キャッシュ・保護 | Cloudflare がする | できない |
| HTTP/HTTPS の分析 | Cloudflare が出せる | 出せない(DNS の分析だけ) |
| 向いているもの | Web の通信を受けるレコード | メールや確認用など、Web の通信を受けないレコード |
出典: Proxy status(2026年4月21日更新)
なお、プロキシ済みのレコードの TTL(DNS の答えを覚えておく時間)は Auto で、300 秒に決まっていて、変えられません。
名前を引くと、何が返る?
プロキシ済みの名前を DNS で引くと、サーバーの IP ではなく、Cloudflare のエニーキャストの IP アドレス(近くのデータセンターへ通信を回すための共有の IP)が返ります。DNS のみの名前を引くと、サーバーの本当の IP が返り、誰でもそれを知れます。公式は、これで標的にされる攻撃への守りが一枚減る、と書いています。
macOS や Linux の dig コマンドで、cloudflare.com を引いた例です(2026年10月10日に手元で引いた例。IP アドレスは、引く場所と時刻で変わります)。
$ dig +short A cloudflare.com
104.16.132.229
104.16.133.229
返った IP アドレスは、Cloudflare が公開している IP の範囲 104.16.0.0/13 に入っていました。公開されている範囲の一覧は、Cloudflare の IP アドレス(IPv4)にあります。ここで言えるのは「Cloudflare の IP が返った」までです。cloudflare.com の設定の画面を見たわけではありません。
プロキシにできるのは、A・AAAA・CNAME だけ
プロキシにできるのは、IP アドレスを引くための A・AAAA・CNAME のレコードだけです。MX や TXT などほかの種類は、いつも DNS のみです。しかも、プロキシにできるのは HTTP/HTTPS の通信のためのものです。
A と AAAA は、ドメイン名を IP アドレスにつなぐ記録(AAAA は IPv6 という新しい形式の IP アドレス用)、CNAME は「この名前は、あの名前の別名です」と伝える記録、MX はメールの届け先を決める記録、TXT は文字を書いておく記録です。
公式は、Web の通信を受ける A・AAAA・CNAME はすべてプロキシにすることを勧めています。ドメインの持ち主の確認に使う CNAME などは、プロキシにしません。
同じ名前に A(または AAAA)のレコードが複数あって、1つでもプロキシ済みなら、その名前の A・AAAA は全部プロキシ済みとして扱われます。
出典: Proxy status(2026年4月21日更新)・Proxy status の制限(2026年4月21日更新)
DNS のみにするレコード
公式は、DNS のみを、Web の通信を受けないレコード(メールやほかのサービスの確認用)にだけ勧めています。Web 用のレコードを DNS のみにすると、サーバーの IP が誰にでも見え、Cloudflare は最適化・キャッシュ・保護も、HTTP/HTTPS の分析もできません。
逆に、次のレコードは、プロキシにすると壊れるので DNS のみにします。公式の「Use cases」のページが挙げているものです。
| レコード | DNS のみにする理由 |
|---|---|
| メールの通信を受けるレコード(メールだけに使う A・AAAA。MX はそもそもプロキシできない) | プロキシにすると、相手のメールサーバーが Cloudflare の IP につないでしまい、メールが届かなくなる |
| ドメインの確認用(ほかのサービスが「このドメインの持ち主か」を確かめる CNAME・TXT) | プロキシにすると確認の行き先が合わず、確認に失敗する。確認が終わるまで DNS のみにする |
| ほかのサービス(Wix・Squarespace・Webflow など)でサイトを動かしている名前 | そのサービスがプロキシに対応していなければ、SSL のエラー・リダイレクトのループ・ページが壊れる、が起きうる |
| ほかの CDN・プロキシ(CloudFront・Akamai・Fastly など)へ向く CNAME | 2つのプロキシがぶつかる |
| HTTP 以外(FTP・SSH・RDP・ゲームのサーバーなど)に使う名前 | Cloudflare のプロキシは HTTP と HTTPS しか扱わない |
出典: Proxy status の Use cases(2026年4月23日更新)
気をつけたい:メール用の A レコードがプロキシになっていないか確かめる
画面からドメインを Cloudflare に載せると、プロキシは最初からオンです(公式の注記)。つまり、mail.example.com のようなメール用の A レコードも、そのままだとプロキシ済みになりえます。メールの通信を受けるレコードをプロキシにすると、メールが届かなくなります。
メール用の A・AAAA のレコードは、DNS のみにします。MX はそもそもプロキシにできません。ドメインを載せたら、メール用のレコードが DNS のみになっているかを、画面で確かめます。
プロキシにすると、サーバーから見える相手の IP が変わる
プロキシにすると、サーバーから見た相手の IP は、読者の IP ではなく Cloudflare の IP になります。読者の本当の IP は、CF-Connecting-IP と X-Forwarded-For というヘッダー(通信に添える情報)に入ります。サーバーのアクセスログなどで読者の IP を見ているときは、気にしておきます。
また、ドメインを載せた直後は「保留(pending)」の状態です。持ち主の確認が済むまで(最大24時間ほど)は、プロキシ済みにしたレコードも DNS のみとして働き、DNS を引くとサーバーの IP が返ります。
出典: Proxy status(2026年4月21日更新)・Proxy status の制限(2026年4月21日更新)
SSL のモードは? Flexible を選ぶとどうなる?
Cloudflare を間に入れると、通信の暗号化の道は2本になります。
- 読者 ⇔ Cloudflare
- Cloudflare ⇔ サーバー(オリジン)
公式の「暗号化モード」(SSL/TLS Encryption Mode)の設定は、この2本のつながりの扱いを決めます。1本目の証明書は Cloudflare が用意してくれますが、2本目をどうするかは、モード次第です。
自分で選べるモード
自分で選ぶモード(公式の画面の言い方で Custom SSL/TLS)は、無料プランでは次の4つです。
| モード | 公式の説明の要点 | 公式の勧め |
|---|---|---|
| Off | 読者 ⇔ Cloudflare も、Cloudflare ⇔ サーバーも、暗号化なし。HTTPS のリクエストは HTTP へ転送される | 勧めていない。ブラウザに「保護されていない」と出る |
| Flexible | 読者 ⇔ Cloudflare は HTTPS にできるが、Cloudflare ⇔ サーバーは暗号化されない(すべて HTTP)。サーバーに SSL 証明書が無くても動く | 「部分的に安全」。サーバーに証明書を置けない、またはサーバーが SSL/TLS に対応していないときの選択 |
| Full | 読者のリクエストと同じ方式でサーバーにつなぐ。HTTPS のときも、サーバーの証明書は確かめない | できるなら Full か Full (strict) |
| Full (strict) | Full に加えて、サーバーの証明書を確かめる | できるなら Full (strict)(Enterprise を除く) |
5つ目に Strict (SSL-Only Origin Pull) というモードもありますが、Enterprise のゾーンだけで使えます。
変える場所は、Cloudflare の画面の SSL/TLS の Overview のページです(2026年10月時点の公式の手順では)。
出典: 暗号化モード(Encryption modes。2026年4月16日更新)・Off(2026年7月9日更新)・Flexible(2026年9月1日更新)・Full(2026年7月9日更新)・Full (strict)(2026年7月9日更新)・Strict (SSL-Only Origin Pull)(2026年7月9日更新)
Flexible を選ぶとどうなる? 注意は3点
Flexible は、サーバーに証明書を用意しなくても、読者のブラウザには https で見せられます。手軽に見えますが、公式は次の3点を注意として書いています。3つともそろえて読んでください。
- Cloudflare とサーバーのあいだは、暗号化されません。 読者 ⇔ Cloudflare は HTTPS でも、Cloudflare ⇔ サーバーはすべて HTTP です。だから公式は「部分的に安全」と書いています
- サーバーが http を https へ自動で転送しているなら、Flexible は使ってはいけません。 Cloudflare は HTTP でサーバーにつなぐので、リダイレクトのループになり、サイトが開けなくなります。このときブラウザには
ERR_TOO_MANY_REDIRECTSや「The page isn't redirecting properly」というエラーが出ます。暗号化モードの設定ちがいは、このエラーのよくある原因の一つです - ログインや個人のデータなど、大事な情報を扱うなら、使いません。 公式は Full か Full (strict) を使うよう書いています
公式は、できるなら Full か Full (strict) を強く勧めています。理由は、サーバーへの悪意のある通信を防ぐためです。
なお、Flexible が対応するのは、443番(HTTPS の標準のポート)の HTTPS だけです。ほかのポートの HTTPS は Full として動きます。
出典: Flexible(2026年9月1日更新)・暗号化モード(2026年4月16日更新)・ERR_TOO_MANY_REDIRECTS のトラブルシューティング(2026年9月1日更新)
Full と Full (strict) の違い
Full は、サーバーの証明書をまったく確かめません。期限が切れていても、自己署名(自分で作っただけ)でも、名前が合っていなくても通ります。公式は、Full (strict) でないと、悪意のある人がつながりを乗っ取って、自分の証明書を出すこともありうる、と書いています。サーバーが443番で HTTPS を受けていないと、読者に525エラーが出ることがあります。
Full (strict) は、いちばん安全なモードです。サーバーの証明書は、次の3つを満たす必要があります。満たさないと、読者に526エラーが出ることがあります。
- 期限内であること
- 公的に信頼される認証局か、Cloudflare の Origin CA が発行したものであること
- 名前(CN か SAN)が、つながる先のホスト名と合っていること
出典: Full(2026年7月9日更新)・Full (strict)(2026年7月9日更新)
今の既定は? Automatic SSL/TLS
公式のページには「Automatic SSL/TLS (default)」という見出しがあります。サーバーの証明書や対応を調べて、いちばん安全なモードを選んで当ててくれる機能です。
ただし、公式は同じページに、新しい Automatic の機能を順に広げている途中だとも書いています。まだ移っていないドメインは、画面に Custom SSL/TLS(自分で選ぶ)の選択肢しか出ません(2026年10月10日時点)。自分のドメインがどちらなのかは、画面で確かめます。
Automatic SSL/TLS は、モードを安全でない側へは変えません。たとえば、サーバーの証明書が切れても、Full (strict) から Full には下げません。サーバー側の SSL の設定を正しく保つのは、自分の責任です。
無料の SSL 証明書(Universal SSL)と Always Use HTTPS
読者 ⇔ Cloudflare の証明書は、Universal SSL という仕組みで、無料で自動です。Cloudflare に載せて有効になったドメインには、無料で、ほかと共有しない、公に信頼される SSL 証明書が既定で発行され、更新もされます。Free でも使えます。
- フルセットアップでは、ルートのドメイン(
example.com)と1段目のサブドメイン(www.example.comなど)が対象です。それより深い名前は対象外で、別の方法が要ります - 証明書は、ドメインが Cloudflare で有効になってから発行されます
- 種類は DV(ドメインの持ち主だけを確かめ、組織は確かめない)です
Always Use HTTPS は、読者の http のリクエストを、すべて https へ転送する設定です。Free でも使えます。公式は、転送をサーバー側ですることを勧めていません。ループの原因になるからです。
ここまでの話をまとめると、無料で自動なのは「読者 ⇔ Cloudflare」の証明書です。「Cloudflare ⇔ サーバー」の暗号化は、モードしだいです。
ドメインの取り方や、レンタルサーバー側で SSL を設定する話は、WordPress の始め方の記事にあります。
出典: Universal SSL(2026年8月14日更新)・Always Use HTTPS(2026年8月14日更新)
CDN とキャッシュは、全部を速くしてくれるわけではない
「Cloudflare を通せば、全部キャッシュされて速くなる」と考えたくなりますが、公式の説明はそこまで言っていません。
キャッシュとは、よく見られる中身(画像・動画・Web ページなど)の写しを、サーバーより読者に近い各地のデータセンターに置き、サーバーの負荷を下げて表示を速くする仕組みです。どのプランでも使えます。
ただし、既定の動きは次のとおりです。
- HTML と JSON は、既定ではキャッシュしません。 キャッシュするかどうかは、MIME タイプ(中身の種類)ではなく、拡張子で決まります。robots.txt は既定でキャッシュします
- 既定でキャッシュする拡張子は、CSS・JS・JPG・PNG・GIF・WEBP・SVG・WOFF2・PDF・MP4 など(公式の表から抜粋。表は変わるので、全部は書きません)
- HTML などをキャッシュしたいときは、Cache Rules(キャッシュのルール)で決めます
- サーバーの指示でもキャッシュしません。
Cache-Controlがprivate・no-store・no-cache・max-age=0のとき、Set-Cookieがあるとき、GET 以外のリクエストのとき、です
キャッシュできる1ファイルの大きさは、Free・Pro・Business で512 MBまでです。
キャッシュから返ったかどうかは、応答のヘッダー cf-cache-status で分かります。HIT はキャッシュにあった、MISS はキャッシュできるが無かったので、サーバーから取った、という意味です。
出典: Cloudflare Cache(2026年4月16日更新)・既定のキャッシュの動き(2026年9月14日更新)・キャッシュの応答(2026年9月4日更新)
Cloudflare を通った応答のヘッダー
curl -I は、ページの中身を取らずに、応答のヘッダーだけを見るコマンドです。macOS や Linux で、www.cloudflare.com の応答を見た例です(2026年10月10日に手元で流した例。値は毎回変わります。途中の別の応答の行は省いています)。
$ curl -sI https://www.cloudflare.com/ | grep -i -E "^(HTTP|server|cf-ray|cf-cache-status|content-type)"
HTTP/2 200
content-type: text/html; charset=utf-8
server: cloudflare
cf-ray: a4847a40dbbaf526-NRT
Cloudflare を通った応答には、server: cloudflare と cf-ray が付いていました。cf-ray は、Cloudflare を通ったリクエストごとの識別子です(公式の説明)。
出典: Cloudflare Ray ID(2026年4月20日更新)
無料プランでできること(2026年10月10日時点)
公式の無料プランのページ(日本語)の見出しは「サイトの保護と高速化に必要な基本機能」です。ただし、このページの本文には、機能ごとの数がありません。そこで、数は製品ごとの公式の文書にある「Availability」の表などから引き、行ごとに出どころと更新日を添えます。
| できること | 無料プラン(Free)の内容 | 出どころ(更新日) |
|---|---|---|
| DNS | どのプランでも使える。Free で使えるのは、ネームサーバーを Cloudflare に向けるフルセットアップだけ | DNS(2026年8月14日) |
| SSL 証明書(Universal SSL) | 無料で自動発行・自動更新。ルートのドメインと1段目のサブドメインが対象 | Universal SSL(2026年8月14日) |
| CDN(キャッシュ) | どのプランでも使える。キャッシュできる1ファイルは512 MBまで(Free・Pro・Business) | Cache(2026年4月16日)・既定の動き(2026年9月14日) |
| DDoS 攻撃対策 | 標準の、量で課金しない(unmetered)対策(レイヤー 3〜7)がある | DDoS protection(2026年8月14日) |
| WAF のカスタムルール | 5個まで(Pro 20・Business 100)。正規表現は Free と Pro では使えない | Custom rules(2026年8月25日) |
| Always Use HTTPS | 使える | Always Use HTTPS(2026年8月14日) |
| プロキシを通すアップロード | 1回100 MBまで(Pro 100 MB・Business 200 MB) | 既定の動き(2026年9月14日) |
| ドメインの購入(Cloudflare Registrar) | どのプランでも使える。登録の元(レジストリ)に払う額だけで、上乗せなし。自動更新が既定 | Registrar(2026年4月24日) |
用語を補います。
- DDoS 攻撃。 大量の通信を送りつけて、サイトを使えなくする攻撃のことです
- WAF。 怪しい通信を見つけて止めるための仕組みです。カスタムルールは、自分で決める遮断のルールです
- レジストラ。 ドメインを売っている会社のことです
数の注意です。
- DDoS 攻撃対策は、同じ公式の表の中に、Free と上のプランで内容が違う行もあります。「Free でも有料と全部同じ」とは言えません
- 数は変わります。この表は2026年10月10日時点で、行ごとの更新日は右の列のとおりです
- Pro・Business の月額は、公式の料金のページから確かめられなかったので、書きません
- Pages と Workers の無料の枠は、この記事には書きません。Pages と Workers の違いの記事にまとめています
なぜ無料なの? 気をつけること
公式ブログの説明(2024年9月27日)
Cloudflare の公式ブログ「Reaffirming our commitment to free」(2024年9月27日)によると、無料プランは会社の創業と同時、2010年9月27日に始まりました。公式は「無料プランはなくならない」と書いています。これは2024年の記事なので、今の約束として読むときは、公式の最新の発表を確かめてください。
無料で続けられる理由として、公式は次の3つを挙げています。
- 通信の費用。 Cloudflare の後ろにあるサイトが多いほど、各地のプロバイダー(ISP)は Cloudflare と直接つなぐ利点があります。Cloudflare は多くの ISP と、費用なしで通信をやりとりしています。その「後ろにあるサイトの多さ」を支えているのが、無料の利用者です
- 攻撃の情報。 無料の利用者が多いぶん、いろいろな通信と攻撃が見え、問題に早く気づけます
- 品質の確かめ。 無料の利用者が新しい機能を最初に試すことが多く、すぐに大きな規模で反応が分かります
出典: Reaffirming our commitment to free(Cloudflare ブログ。2024年9月27日公開)
無料の帯域は「量で課金しない」
同じブログは、無料プランの帯域(転送量)は「unmetered」だと書いています。この記事では「量で課金しない」と呼びます。通信は、ネットワークのどこかに空きがあるところで運ぶので、有料の企業向けの通信と性能が同じとは限らない、とも説明しています。ただし、規約で、大きなファイル(動画など)は無料プランの対象外とされています。
規約(2026年9月28日更新)の「Content Delivery Network (Free, Pro, or Business)」には、次の趣旨のことが書かれています。Enterprise 以外は、動画や大きなファイルを CDN で配るには、専用の有料サービス(Developer Platform・Images・Stream など)を使う必要があります。使わずに配ると、CDN の利用を止めたり制限したりすることがあります。動画や大きな画像・音声を配りたいときは、原文を読んでから決めてください。
出典: Reaffirming our commitment to free(2024年9月27日公開)・Service-Specific Terms: Application Services(規約。2026年9月28日更新)
Cloudflare 自身が止まったことがある
Cloudflare を前に立てると、Cloudflare の網で障害が起きたとき、サイトを見ようとした人にエラーが出ることがあります。公式の報告の範囲で、2回分を紹介します。
2025年11月18日の障害。 Cloudflare のブログの日本語版の報告には、次のように書かれています。
2025年11月18日11時20分(UTC)(このブログでは時刻はすべてUTCで記載します)を起点に、Cloudflareのネットワークにおいて、中核となるネットワークトラフィック配信で重大な障害が発生しました。これにより、当社の顧客が運営するサイトにアクセスを試みたユーザーにエラーページ(Cloudflareネットワーク内でエラーが発生したことを示す)が表示されました。
11:20 UTC は、日本時間では20:20です。公式が書いている範囲は、次のとおりです。
- 原因。 サイバー攻撃や悪意のある行為ではない、と公式は書いています。データベースの権限の変更をきっかけに、ボット管理(Bot Management)が使う「フィーチャーファイル」に重複した行が出て、ファイルの大きさが倍になりました。それを読むソフトウェアには大きさの上限があり、倍の大きさがその上限を超えたため、ソフトウェアが止まりました。最初は大規模な DDoS 攻撃を疑った、とも書かれています
- 回復。 中核の通信は14:30 UTC までにほぼ通常どおりに戻り、17:06 UTC に全システムが正常になりました
- 影響。 中核の CDN とセキュリティは HTTP の5xx エラー(サーバー側のエラー)、Turnstile(サイトに置く確認の部品)は読み込めない、ダッシュボードはほぼ動いていたものの、ログイン画面の Turnstile が使えず、ほとんどの人がログインできませんでした
2025年12月5日の障害。 08:47 UTC から Cloudflare の網の一部で大きな障害があり、09:12 UTC に解決しました(影響は約25分)。影響を受けたのは一部の利用者で、その通信は、Cloudflare が配る HTTP の通信全体の約28%にあたります。公式は、攻撃ではなく、業界全体に関わる脆弱性に対応するために、リクエストの本文を読む処理を変えたことがきっかけだと書いています。この報告は公開後に書き直されているので、読むときは公式の最新の文を確かめてください。
今の状態は、公式のCloudflare Statusのページで確かめられます。
出典: 2025年11月18日の Cloudflare の障害(日本語版)・Cloudflare outage on November 18, 2025(英語版)・Cloudflare outage on December 5, 2025
使い始めるには? ドメインの契約はそのまま、ネームサーバーだけ
無料プランでは、ネームサーバーを移すのが前提
Free と Pro のプランで使えるのは、フルセットアップ(Primary setup)だけです。Cloudflare がそのドメインの権威 DNS になる方式です。ネームサーバーを変えずに、サブドメインだけをプロキシする「CNAME セットアップ(Partial)」は、Business と Enterprise のプランだけです。
つまり、無料プランで DNS やプロキシを使うなら、ネームサーバーを Cloudflare に向けます。
ただし、Cloudflare の何を使うにも移す必要がある、という意味ではありません。たとえば、Cloudflare Pages は、サブドメインなら、ネームサーバーを移さずに使えます。くわしくはPages と Workers の違いの記事にあります。また、Cloudflare Registrar(Cloudflare でのドメインの購入)で買ったドメインは、最初から Cloudflare の DNS を使うので、この記事の手順は要りません。
出典: Primary setup (Full)(2026年8月14日更新)・Zone setups(2026年8月25日更新)・CNAME setup (Partial)(2026年8月14日更新)
ドメインの契約は、今の会社のまま
公式の手順では、ネームサーバーを書き換える場所は、いまのレジストラ(ドメインを買った会社)の管理画面です。手順の中に、ドメインを Cloudflare へ移す(移管する)段はありません。つまり、ドメインの契約は今の会社のままで、ネームサーバーだけを Cloudflare に向けます。
レジストラごとの画面の操作は、この記事では確かめていないので書きません。公式の手順には、自分のレジストラがどこか分からないときは、ICANN Lookup を使う、と書かれています。
手順は4段
公式のフルセットアップの手順は、次の4段です(2026年10月時点の公式の手順では。2026年7月29日更新)。
- 画面でドメインを載せる。 Onboard a domain を選び、ルートのドメイン(
example.comのような名前)を入れて、Continue を押し、プランを選びます - DNS のレコードを見直す
- ネームサーバーを変える。 ドメインを買った会社の管理画面で、いまのネームサーバーを消し、Cloudflare が示す2つを入れます
- 反映を確かめる
出典: Set up a primary zone (Full setup)(2026年7月29日更新)
ネームサーバーを変える前の3つ
ここを抜かすと、サイトやメールが止まることがあります。
1. DNS のレコードを、全部見直す。 Cloudflare には、いまの DNS のレコードを自動で読み込む機能(クイックスキャン)がありますが、公式は、これが全部を見つけるとは限らないと書いています。特に、ルートのドメイン、サブドメイン(www など)、メールのレコードを見直します。正しいレコードをそろえずに有効にすると、読者に DNS_PROBE_FINISHED_NXDOMAIN(名前が見つからない)のエラーが出ることがあります。
公式の手順の例では、メールのレコード(mail の A・MX・DMARC・DKIM・SPF の TXT)は、どれも「DNS Only」です。上の「気をつけたい:メール用の A レコードがプロキシになっていないか確かめる」の話を思い出してください。
2. DNSSEC が有効なら、先にレジストラで切る。 DNSSEC は、DNS の答えが書き換えられていないかを確かめる署名の仕組みです。公式は、有効のままネームサーバーを変えると、ドメインにつながらなくなることがある、と書いています。ドメインが Cloudflare で有効になったあとで、Cloudflare から入れ直せます。
3. ネームサーバーの名前を、一字も違えずに写す。 ネームサーバーは2つ割り当てられ、Cloudflare が自動で決めます。選べません。公式は、名前を正確に写さないと、DNS が正しく動かない、と書いています。
変えたあと:反映を待って確かめる
反映は、最大24時間待ちます。有効(Active)になると、Cloudflare からメールが届き、画面の Domains のページで状態が Active になります。コマンドでも確かめられます。公式の手順にある形は、次のとおりです。<ドメイン> に自分のドメインを入れます。
macOS・Linux:
dig ns <ドメイン> @1.1.1.1
Windows:
nslookup -type=ns <ドメイン> 1.1.1.1
反映にかかる「ふつうの時間」は、公式に書かれていないので、この記事では書きません。ドメインが有効になる前は、プロキシ済みにしたレコードも DNS のみとして働きます(「プロキシ済み(オレンジの雲)と DNS のみ(グレーの雲)は何が違う?」の節のとおり)。
出典: Set up a primary zone (Full setup)(2026年7月29日更新)
サイトを置く場所としての Cloudflare:Pages と Workers
ここまでの DNS・プロキシ・CDN・SSL は、いわばサイトの前に立つ Cloudflare の話でした。Cloudflare には、サイトそのものを置くサービスもあります。Pages と Workers です。
Pages は、フルスタックのアプリを作って、Cloudflare の世界中のネットワークにすぐ公開できるサービスで、どのプランでも使えます。Workers は、インフラを設定・保守せずに、新しいアプリを作ったり、既存のものを強くしたりできる、サーバーレスの実行環境です。公式は、新しく始めるなら Workers を勧めています。
上限・料金・どちらを選ぶかは、Cloudflare Pages と Workers の違いの記事にまとめました。HTML のような静的なファイルでできたサイトを作る話は、SSR と SSG の違いの記事にあります。
出典: Cloudflare Pages の文書(2026年8月25日更新)
よくある質問
ネームサーバーを変えるだけで使える? ドメインは移す?
無料プランで DNS やプロキシを使うなら、ネームサーバーを Cloudflare に向けます。ドメインの契約は、いまの会社のままで構いません。公式の手順に、ドメインを移す段はありません。変える前に、DNS のレコードを全部見直す・DNSSEC を切る・ネームサーバーの名前を一字も違えずに写す、の3つを済ませます。くわしくは、上の「使い始めるには?」の節にあります。
プロキシ済み(オレンジの雲)と DNS のみ(グレーの雲)は、どっちにする?
公式は、Web の通信を受ける A・AAAA・CNAME はプロキシ済みを勧めています。メールを受けるレコード・ドメインの確認用・HTTP 以外に使う名前は、DNS のみにします。くわしくは、上の「プロキシ済み(オレンジの雲)と DNS のみ(グレーの雲)は何が違う?」の節にあります。
Cloudflare の SSL 証明書は無料?
読者 ⇔ Cloudflare の証明書(Universal SSL)は、Free でも無料で自動です。ただし、Cloudflare ⇔ サーバーの暗号化は、SSL のモードしだいです。Flexible は、このあいだが暗号化されません。くわしくは、上の「SSL のモードは?」の節にあります。
なぜ Cloudflare の無料プランは無料なの?
公式ブログ(2024年9月27日)は、通信の費用・攻撃の情報・新機能の確かめ、の3つを理由に挙げています。ただし、動画や大きなファイルを無料の CDN で配ることは、規約で認められていません。くわしくは、上の「なぜ無料なの?」の節にあります。
サイトを見ていると出る「人間であることを確認します」は何?
見る側の人に向けた答えです。Cloudflare の確認(Challenges)は、サイトを見ている人が本物の人間で、ボットや自動のプログラムではないかを確かめる仕組みです。Cloudflare を使っているサイトの側の仕組みで、プロキシを通しているサイトで出ることがあります。
ブラウザの中でいくつかの確認をするか、チェックボックスやボタンを押すなどの小さな操作を求めます。公式によると、ほとんどの人は操作なしで自動で通ります。文字や絵を選ばせるパズル(CAPTCHA)は使いません。
何度も出るときに、公式が挙げているのは次の3つです。
- ブラウザを最新の安定版にする
- 広告ブロックやプライバシーの拡張機能を、いったん止める
- IP アドレスの評判が悪いとき(共用の VPN や会社のプロキシでよくあります)は、別のネットワークにつなぐ
確認が出る理由の例として、公式の表には、IP の危険度が高い・IP の過去の評判・ボットに似た通信・サイトの運営者が決めたルール・ブラウザの確認、があります。Internet Explorer では確認が動きません。Chrome・Safari・Firefox などの今のブラウザを使います。
出典: Cloudflare Challenges(2026年4月15日更新)・Challenges のトラブルシューティング(2026年5月5日更新)
まとめ
- Cloudflare は、サイトを置くサーバーの前に立ち、DNS と CDN を受け持って通信を仲立ちする(リバースプロキシ)。無料プランでも、DNS・SSL 証明書・CDN・DDoS 攻撃対策などが使える(2026年10月10日時点)
- プロキシ済み(オレンジの雲)は Web の通信用。メールを受けるレコード・ドメインの確認用・HTTP 以外の名前は DNS のみ。画面から載せるとプロキシは最初からオンなので、メール用の A レコードを確かめる
- Flexible は、Cloudflare とサーバーのあいだが暗号化されない。サーバーが https へ転送しているとループで開けなくなり、ログインや個人のデータがあるなら使わない。公式は Full か Full (strict) を強く勧めている
- 既定では HTML と JSON をキャッシュしない。「全部キャッシュされて速くなる」わけではない
- 無料の帯域は「量で課金しない」で、動画や大きなファイルを無料の CDN で配ることは規約で認められていない
- 使い始めるときは、ドメインの契約はそのまま、ネームサーバーだけを Cloudflare に向ける。変える前に、レコードを全部見直す・DNSSEC を切る・名前を一字も違えずに写す
- サイトを置く場所としては Pages と Workers があり、違いは別の記事にまとめている
参考資料
- Cloudflare の仕組み(How Cloudflare DNS works)
- Cloudflare DNS
- 1.1.1.1(DNS Resolver)
- Cloudflare の無料プラン(日本語)
- Proxy status
- Proxy status の Use cases
- Proxy status の制限
- Cloudflare の IP アドレス(IPv4)
- 暗号化モード(Encryption modes)
- Flexible
- Full
- Full (strict)
- Off
- Strict (SSL-Only Origin Pull)
- ERR_TOO_MANY_REDIRECTS のトラブルシューティング
- Universal SSL
- Always Use HTTPS
- Cloudflare Cache
- 既定のキャッシュの動き
- キャッシュの応答(cf-cache-status)
- DDoS protection
- WAF のカスタムルール
- Cloudflare Registrar
- Reaffirming our commitment to free(Cloudflare ブログ)
- Service-Specific Terms: Application Services(規約)
- 2025年11月18日の Cloudflare の障害(日本語版)
- Cloudflare outage on November 18, 2025(英語版)
- Cloudflare outage on December 5, 2025
- Cloudflare Status
- Cloudflare Ray ID
- Primary setup (Full)
- Zone setups
- CNAME setup (Partial)
- Set up a primary zone (Full setup)
- Cloudflare Challenges
- Challenges のトラブルシューティング
- Cloudflare Pages の文書
※この記事は、公式の資料をもとに AI(Claude)で下書きし、2026年10月10日時点の公式の資料と照らして確かめてから公開しています。誤りに気づいたらお問い合わせからお知らせください。



