第7章までで、Cloudflareの主要なサービスをひととおり見てきました。ここからの第8章は実践編です。これまで学んだ知識を、実際に手を動かして形にしていきます。
最初のテーマはWordPressです。すでにレンタルサーバーやVPSで動いているWordPressサイトを、Cloudflareの後ろに移す――これは、Cloudflareを使い始める最も一般的なきっかけであり、効果もはっきり出る作業です。表示が速くなり、攻撃が減り、証明書の更新から解放されます。
ただし、順番を間違えるとサイトが表示されなくなったり、メールが届かなくなったりします。このページでは、つまずきやすい箇所を含めて、最初から最後まで通しで説明します。
このページで分かること
- WordPressサイトをCloudflareに接続する全体の流れ
- ネームサーバーを変更する前に必ず確認すること
- SSL/TLSモードの選び方（Flexibleを選んではいけない理由）
- WordPressで何をキャッシュし、何をキャッシュしてはいけないか
- 接続後に最低限やっておきたい設定
作業を始める前に
この手順は、次の状態を前提にしています。
- 独自ドメインでWordPressが動いている（レンタルサーバー、VPS、クラウドいずれでも構いません）
- ドメインのネームサーバーを自分で変更できる（レジストラの管理画面にログインできる）
- サイトが
https://で表示できている（まだHTTPSでない場合も進められますが、あとの手順が少し増えます）
そして、作業前に必ず控えておくものが3つあります。
- 現在のDNSレコード一式：レジストラまたはサーバー会社の管理画面から、A・AAAA・CNAME・MX・TXTレコードをすべてメモまたはスクリーンショットで保存します
- サーバーのIPアドレス：WordPressが動いているサーバーのIPアドレス
- 現在のネームサーバー：元に戻したくなったときのために
特に1つめが重要です。この作業でトラブルになる原因の大半は、レコードの写し漏れです。
手順1：Cloudflareにドメインを追加する
Cloudflareのアカウントを作成し、ダッシュボードからドメインを追加します。
入力するのはアペックスドメイン（example.com）です。www.example.com のようなサブドメインではありません。www は、あとでレコードとして扱います。
続いてプランを選びます。個人サイトであればFreeプランで十分です。プランごとの違いはCloudflareの料金プラン入門で解説しています。あとから変更できるので、迷ったらFreeで始めてください。
手順2：DNSレコードを確認する
ドメインを追加すると、Cloudflareが現在のDNSレコードを自動でスキャンし、一覧を表示します。
ここで「スキャンされたから大丈夫」と考えないでください。このスキャンは網羅的ではありません。公式ドキュメントでも、手作業での確認が求められています。控えておいたレコード一覧と、1行ずつ突き合わせてください。
特に見落としやすいのが次の3つです。
wwwのレコード：これが無いとwww.example.comでアクセスできなくなります- MXレコード：メールの配送先です。抜けるとメールが届かなくなります
- TXTレコード：SPF・DKIM・DMARC（メールの認証）、各種サービスの所有権確認に使われています。抜けるとメールが迷惑メール扱いされたり、外部サービスの連携が切れたりします
プロキシ状態（オレンジ雲）の設定
各レコードには、プロキシを通すかどうかの設定があります。
| レコード | プロキシ状態 | 理由 |
|---|---|---|
example.com（A） |
プロキシ済み（オレンジ雲） | サイト本体。ここを守りたい |
www（A または CNAME） |
プロキシ済み（オレンジ雲） | 同上 |
| MXレコード | プロキシ不可 | そもそもプロキシできません |
mail・ftp などのAレコード |
DNSのみ（グレー雲） | メール送受信やFTPが通らなくなります |
ここが第5章までで学んだ内容と直結します。オレンジ雲にした瞬間、そのホスト名へのアクセスはCloudflareを経由し、サーバーのIPアドレスが隠れます。逆に、グレー雲のレコードはIPアドレスがそのまま公開されたままです。
mail.example.com をグレー雲にする必要があるのに、そのレコードがサイト本体と同じIPアドレスを指している場合、そこからサーバーのIPが割れます。この点は避けられない現実として理解しておいてください（対策としては、メールを別ホストに分けるのが確実です）。
手順3：ネームサーバーを変更する
Cloudflareが割り当てた2つのネームサーバー（xxx.ns.cloudflare.com の形式）を、ドメインを取得したレジストラの管理画面で設定します。
変更前に必ずDNSSECを無効化する
現在のDNS事業者でDNSSEC（DNSの改ざん防止機能）が有効になっている場合、先に無効化してください。有効なままネームサーバーを切り替えると、署名の検証が失敗し、ドメイン全体が解決できなくなります。「サイトが真っ白」ではなく「そんなドメインは存在しない」という、最も重い障害です。
無効化してから、DNSの世界に浸透するまで少し待ってからネームサーバーを変更するのが安全です。
反映を待つ
ネームサーバーの変更が世界中に伝わるまでには時間がかかります。数分で終わることもあれば、24時間ほどかかることもあります。Cloudflareのダッシュボードで、ステータスが「Active」になれば完了です。
この待ち時間の間もサイトは表示され続けます。古いネームサーバーを見ている人は今までどおりサーバーに直接、新しいネームサーバーを見ている人はCloudflare経由でアクセスするだけです。
手順4：SSL/TLSモードを正しく設定する
接続直後に必ず確認すべき、最も重要な設定です。
SSL/TLSのページで説明したとおり、Cloudflareには暗号化モードが複数あります。WordPressで問題になるのは次の点です。
- Flexible：訪問者からCloudflareまではHTTPS、CloudflareからサーバーまではHTTP（暗号化なし）。WordPress側が「HTTPSでアクセスしてください」とリダイレクトすると、Cloudflareは再びHTTPでサーバーに送るため、無限のリダイレクトループになります。「リダイレクトが多すぎます」というエラーの典型的な原因がこれです
- Full：サーバーまでもHTTPS。ただし証明書の中身は検証しません
- Full (strict)：サーバーまでHTTPS。かつサーバーの証明書が有効か（期限内か、信頼できる認証局のものか、ホスト名が一致するか）まで検証します
選ぶべきは Full (strict) です。 公式ドキュメントでも「可能な限りFull (strict)を選ぶこと」と明記されています。
サーバー側に有効な証明書が無い場合は、Cloudflareが無料で発行するOrigin CA証明書（最長15年）をサーバーに入れれば、Full (strict) が使えます。この証明書はCloudflare経由のアクセスでのみ有効なものなので、ブラウザから直接見ると警告が出ますが、それで問題ありません。
あわせて有効にする設定
- Always Use HTTPS：HTTPでのアクセスを自動でHTTPSに転送します。WordPress側のリダイレクト設定より手前で処理されるため、サーバーの負荷も減ります
- WordPress側の設定：管理画面の「一般設定」で、WordPressアドレスとサイトアドレスが
https://で始まっているか確認します
手順5：キャッシュを設定する
ここまでで接続は完了していますが、この時点でCloudflareがキャッシュしているのは画像・CSS・JavaScriptなどの静的ファイルだけです。HTML（記事ページそのもの）は毎回サーバーに取りに行っています。
WordPressを本当に速くするには、HTMLもキャッシュする必要があります。ただし、これには注意が必要です。
キャッシュしてはいけない場所
/wp-admin/以下：管理画面。他人にキャッシュが配られたら大惨事です/wp-login.php：ログイン画面- ログイン中の閲覧：WordPressはログイン中のユーザーに
wordpress_logged_in_で始まるCookieを発行します。このCookieがある要求はキャッシュから返してはいけません - カート・購入手続き：WooCommerceなどのECを動かしている場合、
/cart/・/checkout/・/my-account/は必ず除外します - 問い合わせフォームの送信結果：POSTリクエストはそもそもキャッシュされません
方法1：Cache Rulesで自分で設定する
Cache Rulesは、条件を指定してキャッシュの挙動を決める仕組みです。ルール数の上限は Free 10・Pro 25・Business 50・Enterprise 300 です。
最低限、次の2本を作れば形になります。
- 除外ルール（先に評価されるよう上に置く）：URLパスが
/wp-admin/で始まる、または/wp-login.phpである、またはCookieにwordpress_logged_in_を含む → キャッシュしない - キャッシュルール：それ以外のすべて → キャッシュ対象にする（Edge TTLを数時間〜1日程度に設定）
この方法の弱点は、記事を更新してもキャッシュが自動では消えないことです。更新のたびにダッシュボードからキャッシュをパージするか、後述のプラグインを併用します。
方法2：APO（Automatic Platform Optimization）を使う
APOは、WordPress向けにこの設定を一括で肩代わりしてくれる機能です。Workersを使ってHTMLをエッジでキャッシュし、記事を更新すると自動でキャッシュを消してくれます。ログイン中のユーザーには自動的にキャッシュを迂回します。
利用には公式のWordPressプラグイン「Cloudflare」を入れ、APIトークンでサイトと連携させます。料金はFreeプランでは月5ドル、Pro以上のプランには追加費用なしで含まれます。
どちらを選ぶかの目安です。
| Cache Rules | APO | |
|---|---|---|
| 費用 | 無料 | Free プランは月5ドル／Pro以上は無料 |
| 設定の手間 | 自分でルールを組む | プラグインを入れて有効化するだけ |
| 更新時のキャッシュ削除 | 手動またはプラグイン併用 | 自動 |
| 細かい制御 | 自由度が高い | 決められた挙動 |
WordPressしか運用していないなら、まずAPOを試すのが手っ取り早い選択です。細かく制御したい、あるいはWordPress以外のページも同居しているなら、Cache Rulesで自分で組むほうが見通しがよくなります。
手順6：最低限のセキュリティ設定
接続しただけでDDoS Protectionは全プランで自動的に効いています。そのうえで、WordPressなら次を追加しておくと効果が大きいです。
/wp-login.phpにRate Limitingをかける：Rate Limitingで「1分間に5回まで」といった制限をかけると、パスワードの総当たり攻撃がほぼ止まります。Freeプランでも1本作れます/wp-admin/を国やIPで絞る：WAFのカスタムルールで、自分がアクセスする国以外からの管理画面アクセスをブロックできます- Bot Fight Modeを有効にする：ボット対策の基本機能です。無料で使えます
/xmlrpc.phpをブロックする：使っていなければ、WAFのカスタムルールでブロックして構いません。攻撃の入口として有名です
さらに強く守りたい場合は、管理画面の前にCloudflare Accessを置いて、Googleアカウントなどでの認証を必須にする方法があります。この手順は次々ページで扱います。
初心者が注意するポイント
- 移行はアクセスの少ない時間帯に：ネームサーバーの切り替えは巻き戻しに時間がかかります。深夜や休日に作業してください
- MXレコードを最優先で確認する：サイトが表示されない不具合はすぐ気づきますが、メールが届かない不具合は数日気づかないことがあります。切り替え後、自分宛にテストメールを送って確認してください
- キャッシュを有効にしたら必ずログアウトして確認する：ログインしたままだと、キャッシュが効いているのか、ログイン中だから素通りしているのか分かりません。プライベートウィンドウで確認します
- 「更新したのに反映されない」はキャッシュを疑う：Cloudflare・WordPressのキャッシュプラグイン・ブラウザの3段階があります。まずCloudflareのキャッシュをパージし、それでも直らなければプラグイン側を見ます
- 開発時は「開発モード」を使う：ダッシュボードのDevelopment Modeを有効にすると、3時間だけキャッシュを完全に迂回します。テーマやCSSを触るときに便利です
- キャッシュプラグインの二重掛けに注意：WordPress側のキャッシュプラグインとCloudflareのキャッシュが両方効くと、原因の切り分けが難しくなります。どちらか一方に寄せるのが無難です
関連サービス
- Cloudflareのプロキシとは？：オレンジ雲とグレー雲の意味
- SSL/TLSとは？：Full (strict) を理解するための基礎
- CDNとは？：キャッシュ設定の背景にある仕組み
- Rate Limitingとは？：ログイン画面の総当たり対策
- WAFとは？：管理画面のアクセス制限
- Cloudflare Accessとは？：管理画面の前に認証を置く
まとめ
- 作業前に、現在のDNSレコード一式・サーバーIP・現在のネームサーバーを必ず控える
- Cloudflareの自動スキャンは網羅的ではない。
www・MX・TXTを1行ずつ突き合わせる - サイト本体はオレンジ雲、メールやFTPのホストはグレー雲にする
- ネームサーバー変更の前に、必ずDNSSECを無効化する
- SSL/TLSモードは Full (strict)。Flexibleはリダイレクトループの原因になる
- HTMLのキャッシュは Cache Rules で自分で組むか、APO（Freeプランは月5ドル、Pro以上は無料）に任せる
/wp-admin/・/wp-login.php・ログイン中のCookieがある要求は必ずキャッシュから除外する- 切り替え後は、ログアウト状態での表示確認とメールの到達確認を必ず行う
WordPressの接続は、この本で学んできたDNS・プロキシ・SSL/TLS・キャッシュ・WAFのすべてが一度に登場する題材です。逆に言えば、ここまで読んできた方なら、各設定が「なぜそうするのか」まで分かった状態で作業できるはずです。
次のページでは、サーバーを公開せずにサービスを外へ出す方法――Cloudflare Tunnelを使った実践に進みます。
次に読む
※本記事の情報は 2026年8月時点のものです。