CloudflareでDNSを管理するには、ドメインをCloudflareに追加し、既存のDNSレコードを漏れなく移し、レジストラでネームサーバーをCloudflareの指定に変更します。WordPressサイトでは、そのあとにSSL/TLSの暗号化モード、プロキシの対象、訪問者IPの扱いを整えると、リダイレクトループやログイン制限の誤作動を避けられます。この記事では、移行前の準備から有効化の確認、WordPress側の調整までを順に説明します。
移行前に準備すること
ネームサーバーの切り替えは、ドメインのすべてのレコード（Web、メール、各種の所有確認）に影響します。作業前に次の3つを済ませておきます。
現在のDNSレコードを書き出す今使っているDNSサービスでゾーンファイルをエクスポートできれば保存します。できない場合は、管理画面のレコード一覧をすべて記録します。特に見落としやすいのは、MX、SPF・DKIM・DMARCのTXT、Google Search Console などの所有確認用TXT、メール配信サービスや外部サービス用のCNAMEです。
DNSSECを確認するレジストラでDNSSECを有効にしている（DSレコードが登録されている）状態でネームサーバーだけをCloudflareに変えると、署名が合わずに名前解決が失敗します。移行前にレジストラ側でDSレコードを削除し、その変更が反映されるのを待ってから切り替えます。DNSSECはCloudflareでの有効化後に改めて設定できます。
# DSレコードが登録されているか確認（何か返る場合はDNSSECが有効）
dig example.com DS +shortTTLを短くしておく旧DNSで重要なレコードのTTLを前日までに短くしておくと、移行直後の修正が早く反映されます。
手順1：Cloudflareにドメインを追加する
Cloudflareのダッシュボードでドメインを追加し、プランを選びます。DNS管理と基本的なプロキシ機能は無料プランでも利用できます（2026年10月現在）。プランごとの機能の範囲は変わることがあるため、公式の説明で確認してください。
追加すると、Cloudflareが既存のDNSレコードを自動で読み取って一覧にします。この自動取り込みは、よく使われる名前を問い合わせて推測する仕組みのため、取りこぼしが起こりえます。準備で書き出した一覧と1件ずつ照合し、足りないレコードを追加します。ゾーンファイルを書き出せた場合は、BIND形式のファイルをインポートする機能を使うと漏れを減らせます。
手順2：プロキシ状態を決める
Cloudflareの各レコードには、プロキシ状態の切り替え（オレンジの雲＝プロキシ済み、グレーの雲＝DNSのみ）があります。
- プロキシ済み：訪問者には Cloudflare のIPアドレスが返り、通信は Cloudflare を経由します。キャッシュやWAFなどの機能が働き、オリジンサーバーのIPは表に出にくくなります。
- DNSのみ：通常のDNSと同じく、登録したIPがそのまま返ります。
プロキシが扱うのはHTTP/HTTPSの通信（決められたポート）です。次のレコードはDNSのみにしておきます。
- メールサーバーのホスト名（MXが指す
mail.example.comなど） - SSH、FTP、データベースなど、Web以外で接続するホスト名
- 外部サービスから「DNSのみにしてください」と指示されている所有確認用のCNAME
最初はWebサイトのホスト名（ルートと www）だけをプロキシ済みにし、ほかはDNSのみで始めると、問題が起きたときに切り分けやすくなります。
手順3：レジストラでネームサーバーを変更する
Cloudflareが割り当てた2つのネームサーバー名をダッシュボードで確認し、レジストラの管理画面でドメインのネームサーバーをその2つに置き換えます。旧ネームサーバーを残したまま追加すると、問い合わせ先によって応答が変わるため、すべて置き換えてください。
変更後、Cloudflareがネームサーバーの切り替えを確認すると、ドメインの状態が有効（Active）になります。反映にかかる時間はTLDやレジストラにより異なり、数分から長いと1〜2日ほどかかることがあります。
# 親ゾーンに登録されたネームサーバーを確認
dig example.com NS +short
# Cloudflare のネームサーバーに直接問い合わせ、移したレコードが返るか確認
dig @xxxx.ns.cloudflare.com example.com MX +short
dig @xxxx.ns.cloudflare.com example.com TXT +short切り替え後もしばらくは、旧ネームサーバーをキャッシュしているリゾルバーから問い合わせが届きます。旧DNSサービスのレコードは数日間削除せず、内容も変えずに残しておきます。
手順4：SSL/TLSの暗号化モードを設定する
WordPressでもっとも多いトラブルが、プロキシを有効にした直後の「リダイレクトが繰り返されました」（ERR_TOO_MANY_REDIRECTS）です。原因の多くは、SSL/TLSの暗号化モードとサーバー側のHTTPSリダイレクトの組み合わせです。
- フレキシブル：訪問者とCloudflareの間はHTTPS、Cloudflareとオリジンの間はHTTPです。オリジンが「HTTPならHTTPSへリダイレクト」していると、Cloudflareは毎回HTTPで取りに行くためループします。通信の一部が暗号化されない点でも推奨しにくい設定です。
- フル：オリジンともHTTPSで通信しますが、証明書の検証はしません。
- フル（厳密）：オリジンともHTTPSで通信し、証明書が有効かも検証します。
オリジンに有効な証明書（Let's Encrypt や Cloudflare の Origin CA 証明書など）を入れ、フル（厳密）にするのが基本です。新しく追加したドメインでは、Cloudflareが自動でモードを選ぶ設定になっていることがあるため、現在のモードを確認しておきます。モードの名称や既定値は変わることがあります。
手順5：WordPress側を調整する
訪問者の本当のIPを記録させるプロキシを経由すると、サーバーに届く接続元IPはCloudflareのものになります。このままでは、アクセスログやログイン試行回数の制限、セキュリティプラグインがCloudflareのIPを訪問者として扱い、誤って全員を遮断することがあります。Webサーバー側で、Cloudflareから届いた通信に限って CF-Connecting-IP ヘッダーの値を接続元として扱うよう設定します。
# nginx の例（ngx_http_realip_module）
# set_real_ip_from には Cloudflare が公開している IP 範囲をすべて列挙する
set_real_ip_from 173.245.48.0/20; # 一部のみ例示。最新の一覧は Cloudflare の公式ページで確認
real_ip_header CF-Connecting-IP;Apache では mod_remoteip で同様の設定ができます。set_real_ip_from を指定せずにヘッダーを信用すると、誰でもヘッダーを偽装してIPを詐称できるため、Cloudflareの範囲に限定することが重要です。Cloudflare のIP範囲は更新されることがあるので、定期的に見直します。
キャッシュの対象を確認するCloudflareは既定では画像やCSSなど拡張子で判定した静的ファイルをキャッシュし、HTMLはキャッシュしません。HTMLもキャッシュする設定を追加する場合は、/wp-admin/、ログインページ、wordpress_logged_in_ で始まるクッキーを持つリクエスト、カートや会員ページを除外します。除外を忘れると、ほかの人のログイン後の画面がキャッシュから表示される事故につながります。
公式プラグインは必要に応じてCloudflare社の公式プラグイン「Cloudflare」を入れると、記事更新時のキャッシュ削除などをWordPressから操作できます。必須ではないので、キャッシュの運用方針に合わせて判断してください。
有効化後の確認
# プロキシ済みのホスト名は Cloudflare の IP が返る
dig example.com A +short
# Cloudflare 経由の応答か（server: cloudflare や cf-ray ヘッダーが付く）
curl -sI https://example.com/ | grep -i -E "server|cf-ray|cf-cache-status"加えて、テストメールを送受信してMXの移行に漏れがないか、管理画面にログインして操作できるか、フォームの送信が通るかを確認します。問題がなければ、Cloudflare側でDNSSECを有効にし、表示されたDSレコードをレジストラに登録します。
まとめ
- 移行前に既存レコードを書き出し、DNSSECのDSを外し、TTLを短くしておきます。
- 自動取り込みの結果は書き出した一覧と照合し、MX・TXT・外部サービス用のCNAMEの漏れを防ぎます。
- プロキシはWebのホスト名だけに使い、メールやSSHのホスト名はDNSのみにします。
- SSL/TLSはオリジンに有効な証明書を入れてフル（厳密）にし、フレキシブルによるリダイレクトループを避けます。
- WordPressでは訪問者IPの復元とキャッシュの除外設定を行い、有効化後にメールとログインを確認します。