Cloudflareとは？CDN・DNSの仕組みと独自ドメインでの始め方

Cloudflare（クラウドフレア）とは、独自ドメインのDNSを管理し、Webサイトへの通信をCloudflareのネットワーク経由にすることで、表示高速化やDDoS対策、HTTPS化などを提供するサービスです。レンタルサーバーそのものでも、ドメインの所有権そのものでもありません。一般的な導入では、ドメイン取得事業者に登録されているネームサーバーをCloudflare指定のものへ変更し、Cloudflareを権威DNS兼リバースプロキシとして利用します。

この記事では、2026年9月30日時点のCloudflare公式情報を基に、CDN・DNSの仕組み、無料プランで使える範囲、独自ドメイン取得後の設定手順、WordPress運用時の注意点、接続できない場合の確認方法まで解説します。ドメイン自体の基礎は、LUFTMEDIAのドメインとは？URL・DNSとの関係と取得後に行う設定も参照してください。

CloudflareはCDN・DNS・レンタルサーバーのどこを担当するのか？

Cloudflareを理解するには、「ドメイン」「DNS」「Cloudflare」「オリジンサーバー」を分けて考える必要があります。ドメインはWebサイトの名前、DNSはその名前に対応する接続先を案内する仕組み、オリジンサーバーはWordPressやHTML、画像などの元データを保存する場所です。

一般的なフルセットアップでCloudflareを導入すると、Cloudflareが対象ドメインの権威DNSになります。閲覧者がドメインへアクセスしたとき、CloudflareのDNSが問い合わせに答え、プロキシ対象のA・AAAA・CNAMEレコードではオリジンサーバーのIPアドレスではなくCloudflareのAnycast IPアドレスを返します。その後のHTTPまたはHTTPS通信は、閲覧者からCloudflare、Cloudflareからオリジンサーバーという2段階で進みます。この仕組みはCloudflare公式のHow Cloudflare DNS worksで説明されています。

Cloudflareは中継地点でコンテンツをキャッシュし、利用者に近い拠点から配信できます。また、オリジンへ到達する前に不正な通信を検査し、DDoS対策やWAFなどを適用できます。ただし、Cloudflareへ登録しただけでWordPressのデータが移転するわけではありません。サーバー契約、WordPress本体、データベース、バックアップは従来のホスティング環境に残ります。

Cloudflareが提供する「1.1.1.1」は端末利用者向けのパブリックDNSリゾルバーであり、自分のドメインをCloudflare DNSで管理する機能とは別です。パソコンのDNS設定を1.1.1.1へ変更しても、自分のドメインの権威DNSは切り替わりません。DNSの役割を先に整理したい場合は、LUFTMEDIAのDNSとは？ドメインとIPアドレスを結ぶ仕組みも参考になります。

Cloudflareを「サーバーの移転先」ではなく、「DNSとWeb通信の中継・保護レイヤー」と捉えると設定項目を整理しやすくなります。

CloudflareのCDNはアクセス時にどのようにキャッシュを返すのか？

CDNは、オリジンサーバーのコンテンツを複数の拠点へ一時保存し、閲覧者に近い場所から返す仕組みです。初回アクセスやキャッシュ期限切れではCloudflareがオリジンからファイルを取得し、条件を満たすレスポンスをキャッシュします。以後のアクセスでキャッシュが利用できれば、オリジンへの転送を減らし、応答時間とサーバー負荷を抑えられます。

2026年9月30日時点のCloudflare公式のデフォルトキャッシュ仕様では、キャッシュ対象はMIMEタイプではなく主にファイル拡張子で判定されます。画像、CSS、JavaScript、PDF、フォントなどの静的ファイルは標準対象に含まれますが、HTMLとJSONは標準ではキャッシュされません。したがって、WordPressへCloudflareを導入しただけで記事ページ全体が常にキャッシュされるわけではありません。

オリジンが返すHTTPヘッダーも結果を左右します。たとえば「Cache-Control: private」「no-store」「no-cache」「max-age=0」がある場合、通常はキャッシュされません。Set-Cookieを含む応答やGET以外のリクエストも標準動作ではキャッシュ対象外です。ログイン中の管理画面、カート、会員ページを一律にキャッシュすると、利用者ごとの内容が混ざる原因になるため、動的ページには明確な除外条件が必要です。

ブラウザの開発者ツールで対象ファイルを開き、レスポンスヘッダーの「CF-Cache-Status」を確認すると状態を判断できます。「HIT」はキャッシュから配信、「MISS」はその拠点のキャッシュになくオリジンから取得、「DYNAMIC」は標準ではキャッシュ対象外、「BYPASS」はCookieやキャッシュ制御などにより回避された状態の目安です。最初のアクセスがMISSで次がHITになることは正常です。

HTMLもキャッシュしたい場合は、Cloudflareダッシュボードで対象ドメインを選び、「Caching」または「Cache」→「Cache Rules」から条件を作成します。ただし、画面名と利用可能な条件は2026年9月30日時点のプランおよびアカウントUIによって表示差があります。WordPressでは少なくとも「/wp-admin/」「/wp-login.php」、プレビュー、検索結果、Cookie付きログイン状態を除外してから、小さな範囲で動作を確認します。

導入直後はHTMLの全面キャッシュを急がず、画像・CSS・JavaScriptのCF-Cache-Statusから効果を確認してください。

Cloudflare無料プランでは何が使えて何が有料になるのか？

2026年9月30日時点のCloudflare公式料金ページでは、Freeプランは月額0ドルで、DNS、CDN、従量制限を設けないDDoS保護、Universal SSL Certificate、Free Managed Rulesetなどが掲載されています。個人サイト、検証環境、趣味のプロジェクトなどで、基本的なDNS・CDN・HTTPS・防御機能を試せる構成です。Free、Pro、BusinessではDNSクエリ自体に課金しないことも公式DNS FAQに示されています。

無料プランだから通信経路が別物になるわけではありません。プロキシを有効にしたWeb用レコードではCloudflareを経由し、キャッシュやセキュリティ設定が適用されます。一方、画像最適化の一部、高度なWAF機能、追加のパフォーマンス機能、契約上の稼働保証や優先サポートなどは有料プランまたは有料アドオンの対象です。必要な機能を決めずに上位プランへ変更するのではなく、公式比較表の各行を運用要件と照合します。

無料で利用できることと、すべての利用量・機能が無条件に同一であることは別です。製品ごとにリクエスト数、ルール数、アップロードサイズ、保持期間などの制限が設定される場合があります。たとえば2026年9月30日時点の公式キャッシュ仕様では、Free・Pro・Businessのキャッシュ可能なファイルサイズ上限は512MBです。動画配信や大容量ファイル配布では、個別製品の料金・制限ページも確認する必要があります。

Cloudflare Registrarで新規取得または移管する場合はドメイン登録料が別途発生し、無料プランにドメイン取得費用が含まれるわけではありません。すでに他社で取得したドメインは、その登録事業者に置いたままCloudflareのネームサーバーを指定できます。取得先を検討する場合は、LUFTMEDIAのドメイン取得サービスの比較記事で、初年度だけでなく更新料金や移管条件も確認してください。

無料プランは基本機能の導入に向きますが、利用前に「必要なルール数・ファイルサイズ・サポート水準」を公式比較表で照合しましょう。

独自ドメイン取得後にCloudflareへサイトを追加する手順は？

事前に、ドメイン登録事業者の管理画面へログインできること、オリジンサーバーのIPアドレスまたは指定先ホスト名、現在利用中のDNSレコード一覧を確認します。メールを使っている場合はMX、SPF用TXT、DKIM、DMARCも控えます。Cloudflareの自動スキャンは便利ですが、公式手順でもすべての既存レコードを発見できるとは限らないため、現在のDNS画面の記録またはエクスポートを残します。

1. Cloudflareダッシュボードへログインし、アカウントのホーム画面で「Add a domain」を選びます。
2. 「www」を付けず、例として「example.com」のようなゾーン頂点のドメインを入力します。
3. DNSレコードの追加方法を選択して「Continue」へ進み、利用するプランを選びます。
4. 取り込まれたDNSレコードを「DNS」→「Records」で照合します。
5. Webサイト用のA・AAAAまたはCNAME、www用レコード、メール用のMX・TXTなど、不足するレコードを追加します。
6. 表示された2個のCloudflareネームサーバーを控え、登録事業者側の変更へ進みます。

これは2026年9月30日時点のCloudflare公式オンボーディング手順に沿った流れです。UIの日本語化状況やアカウントによって「Add a domain」「Add site」などの表示差があり得ますが、入力対象はサブドメインではなく通常は登録済みのルートドメインです。

Aレコードの「Content」にはホスティング事業者から指定されたIPv4アドレス、AAAAには実際に到達可能なIPv6アドレスを設定します。wwwをルートドメインへ向ける構成ならCNAMEで「www」から「example.com」を指定できます。推測したIPアドレスや、Cloudflareが応答したIPアドレスをオリジンとして入力してはいけません。

メール用MXレコードや、メールサーバー名に使うA・CNAMEレコードは通常「DNS only」にします。Cloudflareの通常のオレンジ色プロキシは主にHTTP/HTTPS向けであり、MX自体はプロキシ対象ではありません。レコード移行漏れはWeb表示だけでなくメール受信にも影響するため、ネームサーバー変更前の照合が重要です。

ネームサーバー変更へ進む前に、旧DNSとCloudflareのレコードを1行ずつ突き合わせ、特にMX・TXT・wwwを確認してください。

ドメイン管理会社でネームサーバーをCloudflareへ切り替えるには？

Cloudflareへドメインを追加すると、そのゾーン専用の標準ネームサーバーが通常2個割り当てられます。形式は「名前.ns.cloudflare.com」です。この値を、ドメインを購入した登録事業者の管理画面へ設定します。Webサーバー会社のDNSレコード画面ではなく、ドメインの委任先を変更する「ネームサーバー設定」「DNSサーバー変更」「Nameservers」などの画面を開きます。

一般的な順路は「ドメイン一覧」→対象ドメイン→「ネームサーバー設定」→「他社ネームサーバーを使用」または「カスタムネームサーバー」→Cloudflare指定の2個を入力→確認→確定です。実際の画面名、本人認証、反映案内は2026年9月30日時点でも登録事業者ごとに異なります。末尾のピリオドを要求する事業者と自動補完する事業者があるため、入力例に従います。

既存ドメインでDNSSECが有効な場合は注意が必要です。Cloudflare公式手順では、フルセットアップのネームサーバー変更前に登録事業者側のDNSSECを無効化するよう案内しています。旧DNSのDSレコードが残ったまま委任先だけを変えると、検証に失敗してドメインへ到達できなくなる可能性があります。Cloudflare側が「Active」になった後、「DNS」→「Settings」または「DNSSEC」で再度有効化し、表示されたDS情報を登録事業者へ登録します。

切り替え後はCloudflareの対象ドメインの「Overview」で状態を確認します。「Pending Nameserver Update」の間は認証待ちで、「Active」になればCloudflareが指定ネームサーバーを確認できた状態です。必要に応じて「Re-check now」を使います。待機中に同じ値を何度も変更すると切り分けにくくなるため、変更日時と旧・新ネームサーバーを記録します。

登録事業者をCloudflareへ移管する操作と、ネームサーバーをCloudflareへ向ける操作は別です。後者だけなら、ドメインの契約・更新・支払いは元の登録事業者に残り、DNSレコードの管理場所がCloudflareへ移ります。Cloudflare公式DNS FAQも、ホスティング事業者や登録事業者を変更せず、登録事業者側で権威ネームサーバーだけを指定できると説明しています。

切り替え前にDNSSECの状態と旧DNSレコードを保存し、CloudflareがActiveになるまでドメイン契約を移管したと誤解しないようにしましょう。

DNSレコードのProxiedとDNS onlyはどう使い分けるのか？

Cloudflareの「DNS」→「Records」では、プロキシ可能なA・AAAA・CNAMEレコードに「Proxy status」が表示されます。「Proxied」はオレンジ色の雲、「DNS only」は灰色の雲として示されるのが一般的です。画面デザインや表記は2026年9月30日時点のUI更新で変わる可能性があります。

Proxiedでは、DNS問い合わせにCloudflareのAnycast IPアドレスが返り、HTTP/HTTPS通信がCloudflareを通ります。CDNキャッシュ、DDoS対策、WAF、リダイレクトなどを利用したい公開Webサイトのホスト名に向きます。DNS onlyでは、DNSがオリジンのIPアドレスまたはCNAMEの接続先を返し、通信はCloudflareのHTTPプロキシを経由しません。Cloudflare DNSは利用できますが、そのホスト名のWeb通信にCDNやWAFは適用されません。

Webサイトの「@」と「www」は、オリジンがCloudflare経由の通信に対応していればProxiedが基本候補です。一方、メール配送先のMX、SPF・DKIM・DMARC用TXT、ドメイン所有確認用TXTはDNS情報として公開します。FTP、SSH、独自ポートの管理サービス、メールサーバー名など、Cloudflareの通常のHTTPプロキシを通さない接続先はDNS onlyを検討します。

外部SaaSや別のCDNがCNAME先として指定されている場合は、その事業者がCloudflareのプロキシ利用を認めているか確認します。Cloudflare公式のDNS record typesでも、別CDNに関連するCNAMEをプロキシすると接続エラーになる場合があると案内されています。所有確認や証明書検証で「CNAMEをそのまま返す」ことが条件なら、検証中はDNS onlyが必要なケースもあります。

プロキシを有効にすると、外部からDNSを引いた際にオリジンIPを直接確認しにくくなりますが、過去のDNS記録、メール用ホスト名、別サブドメインなどからIPが判明することはあります。オリジンサーバー側でもCloudflareの送信元IPだけを許可する構成や、認証付きオリジンプルなどを検討し、オレンジ色の雲だけをアクセス制御の代わりにしないことが大切です。

オレンジ色の雲はWeb公開用、灰色の雲はCloudflareを経由させない用途という基準から、ホスト名ごとに判断してください。

SSL/TLSをFull (strict)にしてWordPressをHTTPS化するには？

Cloudflare経由のHTTPSには、「閲覧者とCloudflare」と「Cloudflareとオリジンサーバー」という2本の接続があります。Cloudflareのエッジ証明書だけが有効でも、後半の接続が暗号化・検証されていなければ、エンドツーエンドの適切な構成にはなりません。

まずレンタルサーバー側で対象ドメインのSSL証明書を有効にします。公的に信頼された証明書、またはCloudflare Origin CA証明書を利用でき、対象ホスト名と一致し、有効期限内で、オリジンが443番ポートのHTTPS接続を受けられることを確認します。そのうえでCloudflareダッシュボードの対象ドメインから「SSL/TLS」→「Overview」を開き、暗号化モードを「Full (strict)」にします。

2026年9月30日時点のCloudflare公式Full (strict)資料では、オリジン証明書が有効期限内で、信頼された認証局またはCloudflare Origin CAから発行され、要求するホスト名と一致することが条件です。条件を満たさないと526エラーが発生し得ます。「Flexible」はCloudflareからオリジンまでHTTPになるため、オリジン側でHTTPからHTTPSへ転送しているWordPressではリダイレクトループの原因にもなります。

WordPressでは「設定」→「一般」の「WordPress アドレス（URL）」と「サイトアドレス（URL）」をHTTPSへ統一します。管理画面へ入れない状態で安易に変更せず、サーバー側SSL、Cloudflareのモード、HTTPSでの直接応答を先に確認します。テーマや本文にhttp://の画像URLが残るとMixed Contentが発生するため、ブラウザの開発者ツールに表示される対象URLを修正します。HTTPSの基礎とサーバー別の考え方は、LUFTMEDIAのSSLとは？HTTPSの仕組みと証明書を設定する方法も参照してください。

「SSL/TLS」→「Edge Certificates」の「Always Use HTTPS」を有効にすればHTTPからHTTPSへの転送を設定できます。ただし、WordPress、レンタルサーバー、Cloudflareの複数箇所に異なる転送ルールがあるとループや過剰な転送が起きます。正規URLをwwwあり・なしのどちらにするか決め、転送元と転送先を表にしてから1つずつ有効化します。

先にオリジンの証明書と443番ポートを確認し、その後Full (strict)へ切り替える順序なら526エラーを切り分けやすくなります。

Cloudflare切り替え後に表示されない場合はどこを確認するのか？

障害時は、DNS、Cloudflareプロキシ、オリジンサーバー、SSL/TLS、WordPressの順に分けて確認します。最初にCloudflareの「Overview」がActiveか、「DNS」→「Records」にルートドメインとwwwのレコードがあるかを見ます。NXDOMAINならレコード不足や委任先の誤り、Cloudflareのエラー画面が出るならプロキシからオリジンまでの問題、WordPress独自のエラーならアプリケーション側の可能性が高まります。

WindowsとmacOSでネームサーバーを確認する

Windows 10・11では「スタート」から「コマンド プロンプト」または「PowerShell」を開き、nslookup -type=NS example.comを実行します。macOSでは「Finder」→「アプリケーション」→「ユーティリティ」→「ターミナル」を開き、dig example.com NSを実行します。回答がCloudflareから割り当てられた2個のネームサーバーと一致するか確認します。ブラウザ操作自体にOS差はほぼありませんが、コマンドと出力形式は異なります。

外部から手軽に確認する場合は、LUFTMEDIAのnslookupオンライン無料ツールで「NS」を指定できます。端末のキャッシュだけで判断せず、複数のDNSサーバーから得た回答とCloudflare画面の値を比較します。

症状ごとの分岐

• NXDOMAIN：CloudflareのA・AAAA・CNAME不足、ドメイン名の入力誤り、ネームサーバー委任を確認します。
• 521：オリジン停止、接続拒否、ファイアウォールがCloudflareの接続を拒否していないか確認します。
• 522：オリジンまでの接続タイムアウトを疑い、サーバー負荷、経路、Cloudflare IP範囲の遮断を調べます。
• 525：Cloudflareとオリジン間のTLSハンドシェイク失敗を確認します。
• 526：Full (strict)で検証できない証明書、期限切れ、ホスト名不一致を確認します。
• リダイレクトが繰り返される：FlexibleとオリジンのHTTPS転送の組み合わせ、www・非wwwの相互転送を確認します。
• 古い画像やCSSが出る：「Caching」→「Configuration」のパージ機能を必要なURLに限定して使い、CF-Cache-Statusも確認します。
• Webは見えるがメールが届かない：MX、メールサーバー名、SPF・DKIM・DMARCの移行漏れとProxy statusを確認します。

切り分けのため一時的にWeb用レコードをDNS onlyへ変え、オリジンへ直接到達できるか調べる方法もあります。ただし、オリジンIPが公開され、Cloudflareの保護とキャッシュが外れるため、確認後は状態を戻します。変更前後の値、実施時刻、エラーコードを記録し、複数の設定を同時に変えないことが復旧への近道です。

参照した公式情報

• Cloudflare Docs：How Cloudflare DNS works
• Cloudflare Docs：Onboard a domain
• Cloudflare Docs：Nameservers
• Cloudflare Docs：Default Cache Behavior
• Cloudflare Docs：Full (strict)
• Cloudflare：Plans & Pricing

エラーコードとNS・DNSレコード・SSLモードを記録し、DNSからオリジンへ順番に一要素ずつ検証してください。