Cloudflareの始め方｜失敗しない初期設定手順

こんにちは。Osukeラーニング、運営者の「osuke」です。

Cloudflareを使ってみたいけれど、「ネームサーバーを変えてサイトが止まらないか」「独自ドメインのメールまで届かなくならないか」と不安ではありませんか。アカウント作成そのものは難しくありませんが、既存のDNSレコードを確認せずに切り替えると、Webサイトやメールへ影響が出る可能性があります。

そこで今回は、Cloudflareの始め方を、準備、サイト追加、DNS確認、ネームサーバー変更、SSL確認の順に整理しました。osuke本人の利用体験としては書かず、2026年8月19日時点のCloudflare公式情報と、Xで公開されている利用者の設定・失敗事例を照合して解説します。Cloudflareの全体像を先に知りたい方は、Cloudflareとは何かを初心者向けに解説した記事も参考にしてください。

記事のポイント

• Cloudflareを始める前に控える情報
• サイト追加からActiveになるまでの流れ
• DNS・SSL・メールで失敗しやすい点
• 403や接続エラーが出たときの切り分け方

Cloudflareの始め方とサイト追加の手順

Cloudflareの一般的なFreeプランでは、ドメインをCloudflareへ追加し、DNSレコードを確認してから、ドメイン管理会社側のネームサーバーを変更します。ボタンを急いで押すより、現在の設定を控え、各工程の完了条件を一つずつ確認するほうが安全です。

始める前にドメインとDNSを準備する

最初に必要なのは、取得済みの独自ドメイン、ドメイン管理会社へログインする情報、現在使っているDNSレコードの一覧です。CloudflareはWebサーバーそのものを自動で引っ越すサービスではありません。今のサイトを置いたサーバーはそのままに、ドメインから接続先を案内するDNSをCloudflareへ移す、と考えると作業を理解しやすくなります。

現在のDNS管理画面で、A、AAAA、CNAME、MX、TXTの各レコードをエクスポートするか、少なくとも画面を保存してください。Webサイトの接続先だけでなく、www、メール、サブドメイン、Google Search Consoleなどの所有権確認、SPF・DKIM・DMARCも対象です。Cloudflareの自動スキャンは便利ですが、公式のFull setup手順でも、すべての既存レコードを必ず見つけるとは限らないため確認が必要とされています。

もう一つ見落としやすいのがDNSSECです。レジストラ側でDNSSECを有効にしたまま一般的なFull setupへ切り替えると、名前解決が失敗し、SERVFAILやPendingの原因になる場合があります。公式手順はネームサーバー変更前にレジストラ側のDNSSECを無効化し、CloudflareがActiveになった後でCloudflare側から再度有効にする流れを案内しています。

Xでは、ネームサーバー委任を1年以上先延ばしにしていたという公開投稿もありました。操作が難しいというより、止めたくないサイトのDNSを変える心理的な壁が大きいことが分かります。そこで作業開始日は、アクセスや問い合わせが少ない時間帯を選び、現在値、変更値、戻す値を1枚にまとめてから進めましょう。

変更前に必ず控えるもの

• 現在のネームサーバー2件以上
• A・AAAA・CNAMEと各接続先
• MX・SPF・DKIM・DMARCなどのメール設定
• DNSSECの有効・無効と戻し方
• ホスティング会社とドメイン会社の連絡先

アカウント作成と2FAを設定する

準備ができたらCloudflareの公式サイトでアカウントを作成します。普段確認できるメールアドレスを使い、他サービスで使い回していない長いパスワードを設定してください。登録メールが届かない場合は、迷惑メールフォルダ、入力したアドレス、受信拒否設定を確認します。個人サイトでも、DNSを管理するアカウントを奪われるとサイトとメールの両方に影響するため、通常のSNS以上に慎重な管理が必要です。

ログイン後は、ドメイン追加より先に二要素認証（2FA）を有効にします。認証アプリやセキュリティキーを使い、復旧コードはパスワードと別の安全な場所へ保存します。Cloudflareもアカウント保護のため2FAを推奨しています。複数人で運用する場合は、1つのログイン情報を共有せず、必要なメンバーを追加して権限を分けるほうが安全です。

AIコーディングからCloudflareを操作する場合も、Global API Keyを貼り付けるのは避けましょう。Xでは、ドメインごとにAPIトークンを分け、通常は読み取り専用にし、DNS削除やネームサーバー変更へ人の承認を入れる運用例が公開されています。公開投稿はその人の運用方針ですが、必要最小限の権限に絞るという考え方は、設定ミスや漏えい時の影響を小さくするうえで有効です。

最初のサイト追加にAPIキーは必要ありません。まずブラウザの管理画面で1ドメインを登録し、どの設定がサイト表示へ影響するか理解します。自動化は同じ操作を何度も行う段階になってから、Zone DNS Editなど必要な権限だけを持つAPI Tokenを作れば十分です。アカウント作成日、2FAの方式、復旧コードの保管場所だけは運用メモへ残しておきましょう。

アカウント作成直後の3項目

1. 登録メールアドレスを確認する
2. 2FAを有効にして復旧コードを保存する
3. API Tokenは必要になるまで作らない

サイトを追加して無料プランを選ぶ

Cloudflareの管理画面で「Onboard a domain」またはドメイン追加に相当する項目を選び、example.comのようなルートドメインを入力します。https://、ページのパス、wwwは付けません。Cloudflareは入力したドメインをゾーンとして登録し、既存の公開DNSからレコード候補を検索します。登録済みのドメインでなければ追加できないため、未取得なら先にレジストラで取得します。

個人の学習サイトや小規模サイトで、まずDNS、CDN、基本的な保護を試すならFreeプランから始められます。FreeやProで一般的なのはPrimary setup、つまりCloudflareを権威DNSとして使う構成です。既存の権威DNSを維持したまま一部のサブドメインだけをCloudflareへ向けたい構成は、同じ手順にならない場合があります。Cloudflare公式のDNS setupの種類では、Partial setupはBusinessまたはEnterprise向けと案内されています。

Xでも、既存DNSを維持したままサブドメインをWorkersへ割り当てたかったものの、ネームサーバー変更の要件を見て断念した公開例がありました。これはCloudflareが難しいというより、希望するDNS構成と利用できるプランが合っていなかった例です。「高速化したい」「Workersへ独自ドメインを付けたい」「DNS管理を移したい」のどれが目的かを先に1文で決めると、不要な移行を避けられます。

サイトを追加しただけでは、まだ世界中の訪問者がCloudflare経由になるわけではありません。Cloudflare側へゾーンが作られ、候補のDNSレコードが表示された段階です。この時点なら、現在のネームサーバーはまだ変わっていないため、落ち着いて差分を確認できます。複数ドメインを持っていても、最初は影響が小さい1ドメインだけで手順を覚えるのがおすすめです。

プラン選択前に決めること

• Cloudflareへ権威DNSを移せるか
• 対象はルートドメイン全体か一部のサブドメインか
• 既存サイトを保護するのかWorkersへ公開するのか
• 有料機能が本当に初日から必要か

自動検出されたDNSレコードを確認する

サイト追加後に表示されるDNSレコードは、変更前の一覧と1行ずつ照合します。最低限、ルートドメインのA・AAAA・CNAME、www、使用中のサブドメイン、MX、TXTを確認してください。Webサイトの接続先が1文字違うだけでも表示できず、MXや認証用TXTが抜けると独自ドメインメールの受信や送信認証へ影響します。自動検出されたから正しい、と考えないことが最も重要です。

Web用のA、AAAA、CNAMEには、オレンジ色の雲で示されるProxiedと、灰色の雲で示されるDNS onlyがあります。ProxiedはHTTP/S通信をCloudflareが中継し、キャッシュやDDoS保護などを利用できる状態です。DNS onlyは接続先だけを回答し、通信自体はCloudflareを経由しません。第三者サービスの所有権確認用CNAMEや、Cloudflareが対応しない通信まで何でもProxiedにするのは避けます。

メール関連は特に注意してください。Cloudflare公式のメールレコード設定では、メールサーバーを示すA・AAAAはDNS onlyにし、MXはそのホスト名を参照する例が示されています。SPF、DKIM、DMARCのTXTも、メール提供会社が案内する値と一致させます。普段メールを受け取れていても、切り替え後のテスト送受信までは完了と考えないほうが安全です。

比較作業は、画面を眺めるだけでなく表にすると抜けを見つけやすくなります。レコード種別、名前、変更前の値、Cloudflareの値、Proxy状態、用途の6列を作りましょう。値が不明な行は推測で削除せず、ホスティング会社やメール提供会社の資料で確認します。不要かもしれない古いレコードは、サイトが安定してから別の変更として整理すれば十分です。

ネームサーバーを変更して有効化する

DNSレコードを確認したら、Cloudflareがそのゾーンへ割り当てた2つのネームサーバー名をコピーします。ドメインを取得したレジストラの管理画面へ移動し、現在の権威ネームサーバーをCloudflare指定の2件へ置き換えます。別ドメインで以前使った値を流用せず、今回のゾーンのOverviewに表示された値をそのままコピーしてください。

Cloudflare公式は、スペルミスをPending Nameserver Updateの一般的な原因として挙げています。cloudflare.comの一部を手入力すると間違えやすいため、2件ともコピー＆ペーストし、前後の空白が入っていないか見ます。DNSSECを使っていた場合は、先ほどの手順どおりレジストラ側で一度無効化したことも確認します。登録を保存したら、Cloudflare側で確認処理を進めます。

ここで元のネームサーバーを記録したメモを消してはいけません。表示不良が起きたときは、Cloudflare側のDNS修正で直るのか、レジストラ側を戻す必要があるのかを判断する材料になります。ただし、問題が起きるたびに何度もネームサーバーを往復させると、キャッシュされた情報が混在し、切り分けがさらに難しくなります。まずCloudflareのステータスとDNSレコードを確認しましょう。

Xでは、サイト移行とドメイン設定を別日に分けたという公開例も確認できました。複数の変更を同時に行うより、公開先で仮URLや提供URLの表示を確認し、その後にDNSを切り替えるほうが、エラーの発生場所を絞りやすくなります。初回は「公開先の確認」「DNS切り替え」「SSL・メール確認」を別工程にしてください。

ネームサーバー変更の順番

1. Cloudflare指定の2件をコピーする
2. DNSSECの状態を確認する
3. レジストラで古い値を置き換える
4. 保存後はCloudflareのActive表示を待つ
5. 安定後にCloudflare側でDNSSECを再設定する

Cloudflareの始め方で失敗しない確認方法

ネームサーバーを保存しても、作業はまだ終わりではありません。Active、Web表示、HTTPS、メール、サブドメインまで確認して初めて移行完了です。ここからは、待つべき状態と設定ミスを直すべき状態を分け、問題が出たときの確認順を整理します。

Activeになるまでの反映時間を知る

ネームサーバー変更は、保存ボタンを押した瞬間にすべての通信環境へ同時反映されるわけではありません。Cloudflare公式は、レジストラの更新に最大24時間待つよう案内しています。CloudflareのDomains画面で対象ドメインがActiveになり、登録メールにも有効化の通知が届けば、Cloudflare側が新しい委任を確認できた目安です。

待機中は、パソコンのWi-Fiだけでなく、スマートフォンのキャリア回線からもトップページを開きます。Xには、ネームサーバー反映後にローカル環境からだけ自サイトへ接続できず、キャリア回線では開けたという公開事例があります。投稿だけでは原因を断定できませんが、回線や端末ごとのDNSキャッシュ差を見分けるには有効な確認方法です。

CloudflareがPendingのまま24時間を超える場合は、待ち続ける前に、レジストラで指定した2件がCloudflareのOverviewと完全一致するか、古いネームサーバーが混在していないか、DNSSECが残っていないかを見ます。公式のPending Nameserver Updateの確認手順でも、そのゾーンへ実際に割り当てられた値をコピーすることが強調されています。

サイトが一部の環境で古い表示になるだけなら、むやみにレコードを変更せず、確認時刻、回線、端末、表示結果を記録します。トップページが開くか、wwwが開くか、管理画面へ入れるかを同じ順番で確認すると、症状の違いが見えます。反映を待つ時間と、設定を直す時間を混同しないことが、余計な変更を増やさないコツです。

Active待ちの確認表

• 0〜24時間：管理画面とメールを確認しつつ待つ
• 別回線：Wi-Fiとキャリア回線の両方で表示確認
• 24時間超：ネームサーバー、旧値の混在、DNSSECを再確認
• 記録：時刻・端末・回線・URL・エラー文を残す

SSLを確認してFull strictを選ぶ

ドメインがActiveになったら、https://でトップページと主要ページを開き、ブラウザに証明書警告が出ないか確認します。CloudflareのUniversal SSLは、追加して有効化されたドメインへ無料の公開証明書を発行します。一般的なFull setupでは、ドメイン有効化から証明書の用意に15分〜24時間かかる場合があるため、Active直後にHTTPSだけ失敗しても、まずEdge Certificatesの状態を見ます。

Universal SSLは、訪問者とCloudflareの間で使われるエッジ証明書です。Cloudflareから元のWebサーバーまでの通信を安全にするには、元サーバー側にも有効な証明書が必要です。元サーバーがHTTPSに対応し、証明書の期限、発行元、ホスト名が正しいなら、公式が推奨するFull (strict)を選べます。元サーバーの条件を満たさないまま設定すると、526エラーになる可能性があります。

反対に、Flexibleを安易に使うと、訪問者からCloudflareまではHTTPSでも、Cloudflareから元サーバーまでは暗号化されません。元サーバー側のHTTP→HTTPS転送と組み合わさり、リダイレクトループが起きることもあります。暗号化モードは「エラーが消えるもの」を選ぶのではなく、元サーバーの証明書状態に合わせて選択してください。迷ったらホスティング会社のSSL案内を先に確認します。

確認するURLはトップページだけでは足りません。wwwあり・なし、ログイン画面、問い合わせフォーム、画像が多いページを開きます。画像だけHTTPのURLを読み込むMixed Content、ログイン後に戻されるCookieの問題、フォーム送信後の転送も確認します。Universal SSLの発行待ちと、元サーバーの証明書エラーを分けるだけで、焦って設定を変える回数を減らせます。

SSL確認の判断基準

• Edge証明書がActiveか
• 元サーバーが443番ポートでHTTPSへ応答するか
• 証明書が期限内で対象ホスト名と一致するか
• 条件を満たすならFull (strict)を選ぶ
• 526とリダイレクトループを同じ原因と考えない

メールとサブドメインを確認する

Webサイトが表示できても、メールとサブドメインが動かなければ移行は完了ではありません。独自ドメインメールを使っている場合は、外部の別メールアドレスから1通送り、受信できるか確認します。次に独自ドメイン側から返信し、迷惑メールフォルダへ入らないか、エラーメールが返らないかを見ます。MXだけでなく、送信認証のSPF・DKIM・DMARCも変更前と一致しているか確認してください。

メールサーバーを指すホスト名がProxiedになっていると、メール通信が正しく届かない場合があります。Cloudflareは通常のSMTPを既定ではプロキシしません。公式のメール障害の確認手順では、MX自体はDNS onlyであり、その参照先ホスト名もDNS onlyへ設定するよう説明されています。メール提供会社が指定した正確な値を優先しましょう。

サブドメインも一覧で確認します。www、blog、shop、api、管理用ホスト、外部サービスの認証用CNAMEなど、普段トップページから見えないものが対象です。開発環境やステージング環境へ公開制限をかけている場合は、Cloudflare経由の通信がその制限に引っかからないかも確認します。使っていないように見えるTXTやCNAMEを初日に整理しないほうが無難です。

確認結果は「正常」「未確認」「異常」の3つで記録します。たとえばWebは正常、受信は正常、送信は迷惑メール、apiは未確認という状態なら、全面的な成功や失敗と決めつけず、送信認証とサブドメインを個別に直せます。1回のチェックで全部を覚えようとせず、変更前に作ったDNS表へ結果列を追加すると、次回の設定変更にも使える運用資料になります。

切り替え後の動作テスト

• 外部アドレス→独自ドメインの受信
• 独自ドメイン→外部アドレスの送信
• www、blog、shop、apiなど全サブドメイン
• Search Consoleなど外部サービスの所有権確認
• 問い合わせフォームの送信と通知メール

403や接続エラーを切り分ける

Cloudflare導入後にエラーが出たら、まず画面のエラーコードとCloudflareのRay ID、発生時刻、対象URLを保存します。サイトが全く名前解決できないならDNSやネームサーバー、Cloudflareのエラーページが出るならプロキシから元サーバーまで、WordPress独自の403ならプラグインやホスト側WAFも候補です。「Cloudflareを入れた直後だからCloudflareが原因」と即断せず、通信のどこまで到達しているかを見ます。

Xでは、Cloudflare利用サイトが403になり、投稿者がレンタルサーバー側のセキュリティによるCloudflare IP遮断の可能性を挙げ、ネームサーバーを戻して一旦解決した事例が公開されています。この投稿だけで原因を一般化はできませんが、Cloudflare側設定だけを探しても直らず、オリジンサーバーのWAF、アクセス制限、ログを確認すべき症状があることを示しています。

切り分けでは、Proxyを一時的にDNS onlyへ変える検証が役立つ場合があります。ただし、その間は元サーバーのIPが直接応答し、Cloudflareの保護やキャッシュを通らなくなるため、目的と時間を決めて行います。DNS onlyで開き、Proxiedで403になるなら、Cloudflareからオリジンへの経路、ホスト側の許可設定、CloudflareのWAFルールを重点的に確認できます。

公開直後の防御も忘れないでください。Xには、ドメイン設定後すぐ攻撃を観測し、CloudflareのWAFを設定したという公開投稿があります。Cloudflareの保護は助けになりますが、WordPress本体・テーマ・プラグイン更新、管理画面の強い認証、バックアップまで自動で代行するわけではありません。接続確認とセキュリティ確認を同じ完了チェックへ入れましょう。

エラー別の最初の確認先

• NXDOMAIN・SERVFAIL：DNSレコード、ネームサーバー、DNSSEC
• Pending：割り当てNSとの一致、旧NS混在、24時間経過
• 526：元サーバーの証明書とFull (strict)条件
• 403：Cloudflare WAF、ホスト側WAF、アクセス制限、ログ
• 特定回線だけ失敗：端末・ルーター・回線ごとのDNSキャッシュ

Cloudflareの初期設定を安全に終える

Cloudflareの始め方は、アカウントを作る、ドメインを追加する、DNSを確認する、ネームサーバーを変える、Active後に動作確認するという5段階です。難しいコマンドを覚える必要はありませんが、DNSスキャンを信用しきらず、変更前後の値を比較する丁寧さが必要です。特にDNSSEC、メール、サブドメイン、元サーバーのSSLは、トップページだけ見ていると見落とします。

X上の公開投稿を横断すると、利用者が困っていた点は共通しています。ネームサーバー変更を先延ばしにする、反映待ちと設定ミスを区別できない、特定回線だけ接続できない、403をどのサービスで調べるか迷う、といった問題です。一方で、公開作業とドメイン設定を分け、現在のDNSを控え、複数回線で確認すれば、原因を追いやすくなります。個々の投稿はCloudflare全体の仕様ではないため、判断の土台は公式情報に置きましょう。

初日にすべての高速化・セキュリティ機能を有効にする必要もありません。まずActive、Web表示、HTTPS、メール、サブドメインの5項目を正常にします。その状態をスクリーンショットと表で残した後に、キャッシュ、WAF、Bot対策などを1項目ずつ追加します。変更ごとに確認すれば、不具合が出ても直前の設定へ戻せます。

今日の一歩は、まだネームサーバーを変えなくて構いません。ドメイン会社へログインできるか確認し、現在のDNS一覧を保存し、メールとサブドメインの用途を書き足してください。これが揃えば、Cloudflareの画面へドメインを追加した後も差分を判断できます。次の記事では、A・CNAME・MX・TXTとProxy状態をさらに具体的に扱う予定です。

初期設定の完了条件

1. Cloudflareのドメイン状態がActive
2. 主要ページがHTTPSで表示
3. 独自ドメインメールを送受信
4. 使用中のサブドメインが応答
5. 2FA・バックアップ・更新を確認