
前回は、なぜこのブログのキャッシュをCloudflareに切り替えることにしたのか、そして最終的に決めた役割分担——Cloudflareが外部CDNとセキュリティ防御を担い、LiteSpeed Cacheはローカルツールの役割に戻る——についてお話ししました。今回はいよいよ実際の作業です。大きく2段階に分かれます。まずドメインのDNS解決をCloudflareに向け(これによってCloudflareがトラフィックを引き受けてキャッシュとプロキシができるようになります)、その後WordPressの管理画面に戻ってLiteSpeed側の設定を切り替えます。ここで一点補足しておくと、変更するのはDNS解決とキャッシュのレイヤーだけで、オリジンサーバー、WordPress本体、データベースはそのまま動かしません。
作業前に順序をはっきりさせておく
この順序を逆にしてはいけません。ドメインのDNS解決がまだCloudflareを向いていない、Cloudflare側でドメインのステータスが「アクティブ」になっていない段階で、先にLiteSpeedプラグインでCloudflare APIを有効にしてトークンを入力してしまうと、プラグインはまだ有効になっていないドメインへ接続を試みることになり、高い確率で接続に失敗し、現在正常に動いている管理画面に支障をきたす可能性もあります。
正しい順序は、まずCloudflare側でドメインを完全に引き受けさせ、ステータスが緑色になったことを確認してから、WordPressの管理画面に戻って作業を始めるという流れです。
ステップ1:Cloudflareでドメインを引き受けさせる
この作業はCloudflareの公式サイト上で完了するもので、WordPressの管理画面とは関係ありません。
1. サイトを追加する:Cloudflareのダッシュボードにログインし、「サイトを追加」をクリックして、ドメインを入力し、無料プランを選びます。
2. DNSレコードを確認する:Cloudflareが既存の解決レコードを自動でスキャンします。通常はデフォルトのままで問題なく、確認できたら次に進みます。
3. ネームサーバーを変更する:Cloudflareから新しい2つのネームサーバーのアドレスが提示されます。ドメインを購入した管理会社(さくらインターネット、お名前.com、GoDaddyなど)の管理画面にログインし、元のネームサーバーをCloudflareが提示したものに置き換えます。
4. 反映を待つ:世界規模での反映には通常十数分から数時間かかりますが、この間サイトが停止することはなく、通常通りアクセスできます。
反映されたかどうかの判断基準は単純です。Cloudflareのダッシュボードのトップページに戻り、ドメインのステータスが「保留中(Pending)」から緑色の「アクティブ(Active)」に変わっているかを確認します。緑色になってから次のステップに進みます。
ステップ2:QUIC.cloudとのクラウド連携を解除する
CDNを切り替える前に、まず期限切れになったQUIC.cloudとのクラウド連携を解除しておき、新旧の設定が衝突しないようにします。
WordPressの管理画面でLiteSpeed Cacheのダッシュボードページに入り、「接続を解除」をクリックして、サイトとQUIC.cloudのクラウドとの連携を解除します。このステップはクラウドサービスとの連携を解除するだけで、ローカルのキャッシュ機能には影響しません。
ステップ3:QUIC.cloud CDNをオフにし、Cloudflare APIをオンにする
これが今回の切り替えで最も核心となるステップで、LiteSpeed CacheのCDN設定ページで行います。このページは通常いくつかのタブに分かれていて、1つ目がQUIC.cloud、2つ目がCloudflareです。
| タブ | 項目 | 設定 |
|---|---|---|
| [1] QUIC.cloud | QUIC.cloud CDN | オフ |
| [2] Cloudflare | Cloudflare API | オン |
| [2] Cloudflare | Cloudflareアカウントのメールアドレスを入力 | |
| [2] Cloudflare | APIトークン | 生成したトークンを入力 |
| [2] Cloudflare | Clear Cloudflare cache | オン |
ここで一点、混同しやすい部分があるので個別に説明しておきます。
APIトークンについて:Cloudflareのダッシュボードの右上にあるプロフィールから「APIトークン」を見つけ、作成をクリックして、「ゾーンDNSの編集」テンプレートを選びます(あるいはカスタムトークンで、ゾーン→キャッシュのパージ→編集の権限を付与する形でも構いません)。対象のドメインを選んでから生成します。このトークンが、LiteSpeedに入力するものと同じものです。
このステップが終わると、QUIC.cloudのCDNスイッチとCloudflareのCDNの役割が同時に有効になることはありません——前者はオフ、後者はオンという状態になり、前回触れた原則に沿ったものです。CDNノードによる高速化のレイヤーは、どちらか一方にしか任せられません。
設定の保存に成功すると、LiteSpeedの管理画面の上部に通常Cloudflareのアイコンが表示され、両者が接続されたことがわかります。以後、WordPress内で「すべてのキャッシュをクリア」をクリックすると、ローカルキャッシュとCloudflareのエッジノードのキャッシュが一緒にクリアされます。
このステップが終われば、キャッシュはCloudflareに渡っている
以上の設定が完了すると、ブログにアクセスするトラフィックの経路は次のようになります。訪問者 → Cloudflareのノード → (キャッシュにヒットしなければ)実サーバーへのオリジンリクエスト。ただしこの時点ではCloudflareはデフォルトで静的リソースしかキャッシュせず、HTMLページ自体はキャッシュされていません。この部分の最適化は追加のプラグインで補う必要があり、それが次回扱う内容です。
同時に、LiteSpeed Cacheプラグインの中で元々QUIC.cloudのクラウド額度に依存していた機能(クリティカルCSSの生成など)は、額度不足のために、ページのスタイルが一時的に欠けたりレイアウトが崩れたりする可能性があります。この部分の具体的な調整——どのスイッチをオフにすべきか、どれを残しておいてよいか——は次回、一項目ずつ確認していきます。
系列文章:ブログキャッシュをCloudflareへ移行
