これまでの3回では、なぜ切り替えるのか、どうやってドメインのDNS解決をCloudflareに向けるのか、そしてプラグインのレイヤーでどの設定を確認すべきかについてお話ししてきました。今回はまとめの回です。キャッシュが本当に有効になっているかどうかをどう確認するか、何かおかしいと感じたときにどの方向から調べればよいか、そして今回の調整を終えての実際の感想についてお伝えします。
キャッシュが本当にヒットしているかをどう判断するか
判断方法は難しくありません。ブラウザに標準で備わっている開発者ツールを使えば、重要な情報を確認できます。
1. プライベートモードを開く：シークレットウィンドウでブログにアクセスします。管理者としてログインした状態だとキャッシュが回避されてしまい、実際の訪問者の体験とは異なるものを見ることになるためです。
2. 開発者ツールを開く：F12キーを押すか、ページ上で右クリックして「検証」を選び、Network（ネットワーク）タブに切り替えます。
3. ページを強制リロードする：Ctrl+F5、Macの場合はCmd+Shift+Rを押します。
4. 最初のリクエストを探す：通常リストの先頭にあり、タイプが document になっているもので、これがドメイン本体へのHTMLリクエストです。これをクリックします。
5. レスポンスヘッダーを確認する：Headersタブに切り替え、Response Headersの欄を見ます。
レスポンスヘッダーの中で、重点的に確認すべきフィールドは2つです。
| ヘッダー | 表示内容 | 説明 |
|---|---|---|
| cf-cache-status | HIT | キャッシュにヒットしている。ページはCloudflareのエッジノードから直接返されており、実サーバーへのオリジンリクエストは発生していない |
| cf-cache-status | MISS / DYNAMIC | ちょうどキャッシュが切れたタイミング、または初回アクセス。1〜2回リロードすると通常HITに変わる |
| x-wp-cf-super-cache | cache | Super Page Cacheプラグインがページを引き受けており、Cloudflareでのページレベルのキャッシュを制御している |
何度リロードしてもcf-cache-statusがDYNAMICまたはBYPASSのままであれば、まずSuper Page Cacheプラグインの管理ページで「Purge All Cache」を一度実行し、古いキャッシュをクリアした上で、シークレットウィンドウで再度テストしてみてください。
ヘッダーに元のサーバーの情報が表示される場合の対処法
これは切り替えの初期に最もよく遭遇する状況です。ヘッダーに表示されているのがCloudflareではなく、オリジンサーバー自体の識別情報（サーバーヘッダーにローカルのサーバーソフトウェア名が表示されている、あるいはローカルキャッシュがヒットした際のマークが出ているなど）である場合、今回のリクエストが実際にはまだCloudflareを経由していない、あるいはCloudflareがオリジンのヘッダーをそのまま転送しているだけで、自分自身ではキャッシュに関与していないということを意味します。このような場合は、通常以下の3つの原因のいずれかに該当します。
原因1：プロキシのステータスがオンになっていない
これが最もよくある原因です。ドメインのDNS解決自体はCloudflareを使っていても、あるレコードの「プロキシステータス」が灰色の「DNSのみ」になっていて、オレンジ色の「プロキシ済み」になっていない場合、トラフィックはオリジンサーバーに直接届いてしまい、Cloudflareは一切介入しません。
確認方法：Cloudflareのダッシュボードにログインし、ドメインのDNSレコードページに入り、メインドメインとwwwに対応するAレコードの右側にあるプロキシステータスのアイコンを確認します。灰色になっていれば、編集をクリックしてオレンジ色の「プロキシ済み」に切り替え、保存します。
原因2：ドメインのDNS解決がまだ世界規模で反映されていない
ネームサーバーを変更したばかりの場合、世界規模でのDNSキャッシュの更新には時間がかかり、通常十数分から数時間程度です。完全に反映される前は、自分の端末がアクセスしているのは古い解決結果のままである可能性があります。
確認方法：Cloudflareのダッシュボードのトップページに戻り、ドメインのステータスが緑色の「アクティブ」になっているかを確認します。まだ「保留中」であれば、もう少し待ちます。
原因3：ローカルの端末やブラウザのキャッシュが古いまま残っている
サーバー側の切り替えが完全に終わっていても、自分のパソコンやブラウザが以前のリクエスト結果を覚えてしまっていて、表示されるヘッダーが実際のオンラインの状態と一致していないことがあります。
確認方法：別のネットワーク環境でテストしてみます。例えば、自宅のWi-Fiではなくスマートフォンのモバイルデータ通信に切り替えて、同様にシークレットモードでブログにアクセスする、あるいはサードパーティ製のオンラインHTTPヘッダー検査ツールで一度確認してみます。これらの環境で確認したサーバーの識別情報がすでにCloudflareに変わっていれば、オンライン上では実際にはすでに切り替えが成功していて、自分が今いるネットワークや端末側のローカルキャッシュがまだ更新されていないだけだということになります。しばらくすれば自然に解消します。
今回の調整を終えての実際の感想
このブログは更新頻度の高くない個人ブログで、これまでの方針——Cloudflareが外部CDNとサイト全体のHTMLキャッシュを担い、LiteSpeed Cacheはローカルツールの役割に戻り、QUIC.cloudは余裕のある画像最適化の額度だけを残す——に沿って切り替えを完了させた結果、全体的な効果は期待通りでした。静的リソースとページの読み込み速度は遅くなっておらず、セキュリティ防御の面では明確な追加収穫があり、さらにPage Optimizationの額度が尽きることによる機能の中断を心配する必要もなくなりました。
決定から検証までの4回を通して、核心となる考え方は実は一つです。外部CDNとキャッシュのレイヤーの仕事は完全にCloudflareに任せ、元々QUIC.cloudのクラウド額度に依存していた機能は実際の残額度に応じて個別に対応する——額度がないものはオフにし、余裕があるものは残して使い続け、その間をCloudflare無料版に元々欠けているHTMLキャッシュ能力を補う軽量なプラグインで橋渡しする、というものです。更新頻度の高くない個人ブログの多くにとって、これはお金をかける必要もなく、長期的な手動メンテナンスも必要としない方法だと言えます。
系列文章：ブログキャッシュをCloudflareへ移行
