Cloudflareのキャッシュが反映されない原因と対策

ページを更新したのに、古い画像や文章が表示されたまま。Cloudflareを使っていると、こうした場面で「どのキャッシュが残っているのか」が分からず、対応に時間がかかることがあります。急いで全キャッシュを削除する前に、Cloudflare、ブラウザ、配信元サーバーのどこで古いデータが返っているかを切り分けましょう。会員サイトやECサイトでは、表示の古さだけでなく、個人情報を含む画面の誤キャッシュにも注意が必要です。

キャッシュが反映されない主な原因

更新後もCloudflareのキャッシュが残っている

Cloudflareは、一度取得した画像やCSS、JavaScriptなどをエッジに保存し、次のアクセスへ配信します。配信速度を上げられる一方、保存期間が残っていれば、配信元を更新しても古いファイルが表示されることがあります。

まず確認したいのが、レスポンスヘッダーの「CF-Cache-Status」です。「HIT」ならCloudflareのキャッシュから配信されています。「MISS」「BYPASS」「DYNAMIC」などの場合は判断が変わるため、画面だけで決めつけず、対象URLのヘッダーを確認することが近道です。

削除したURLと実際のキャッシュキーが違う

キャッシュを削除したつもりでも、ホスト名やクエリ文字列、端末別の条件が異なると、別のキャッシュとして残ることがあります。たとえば、パラメーター付きURLだけが古い、wwwの有無で表示が違う、といったケースです。

いきなり「Purge Everything」を使うのではなく、問題が起きているURLと条件を特定し、対象を絞って削除します。削除後は再度アクセスし、CF-Cache-Statusと表示内容を確認しましょう。削除操作が完了していても、想定したURLを見ていなければ解決したようには見えません。

ブラウザやCMS側のキャッシュが残っている

古い表示の原因がCloudflareとは限りません。ブラウザ、WordPressのキャッシュプラグイン、サーバーキャッシュ、画像変換サービスなど、配信経路には複数の保存場所があります。

シークレットウィンドウや別端末で確認し、必要に応じてCloudflareを通さない配信元の応答とも比較します。更新時刻やファイル名を変えたテストデータを使うと、どの層で古いデータが返っているかを追いやすくなります。

会員情報の誤キャッシュを防ぐ

ログイン後のページは原則として分けて考える

マイページ、購入履歴、カート、決済、管理画面などは、利用者ごとに内容が変わります。こうしたページを共通のキャッシュとして保存すると、別の利用者へ同じ応答を返してしまうおそれがあります。

静的な商品画像と、ログイン後に生成されるHTMLやAPIレスポンスを同じルールで扱わないことが大切です。個人情報やセッションに関わるURLは、キャッシュ対象から明示的に外す設計を基本にします。

Cookieだけに頼らずURLと応答ヘッダーも確認する

認証Cookieがある通信を除外する方法は有効ですが、Cookie名の変更や新しいサブドメインの追加で、条件から漏れることがあります。アプリ側の仕様を知らないまま除外条件を作ると、ログインページだけ外し、遷移先をキャッシュしてしまうかもしれません。

URLパス、Cookie、リクエストヘッダー、オリジンが返すCache-Controlと、CloudflareのCache Rulesを照合します。「private」や「no-store」を返しているから大丈夫と決めつけず、その設定をCloudflare側がどのように扱う構成なのかまで確認しましょう。

公開前に複数アカウントで表示を確かめる

誤キャッシュは、管理者アカウント一つで確認しただけでは見つけにくいトラブルです。権限や属性の異なるテストアカウントを用意し、ログイン前後、ログアウト後、別ブラウザで同じURLを確認します。

本番の個人情報を使わず、検証環境やテストデータで行うのが安全です。もし個人情報の誤表示が疑われる場合は、キャッシュ削除だけで終わらせず、対象範囲の調査、ログ保全、関係部署への連絡を進めます。

事故を防ぐキャッシュ設計と運用

URLごとにキャッシュ可否を一覧化する

キャッシュ設計は、「全部使う」「全部使わない」の二択ではありません。画像や配布ファイルは長め、更新頻度の高いページは短め、会員向けページは除外するなど、コンテンツの性質に合わせて分けます。

URL、担当部署、更新頻度、個人情報の有無、キャッシュ時間、削除方法を一覧にしておくと、変更時の判断が速くなります。新しい機能を公開するときも、キャッシュ可否を確認項目へ入れておきましょう。

変更・削除・切り戻しの手順を決める

Cache Rulesを変更すると、想定より広い範囲へ影響することがあります。対象条件、変更前の設定、確認URL、作業者、承認者を記録し、問題が出た場合に戻せるようにします。

サイト更新時のキャッシュ削除も、担当者の勘に頼らない仕組みが必要です。CMSの公開処理と連動するのか、手動でURLを指定するのか、緊急時だけ全削除を使うのか。日常の更新フローに合わせて決めます。

アプリとインフラを一緒に見られる支援先を選ぶ

キャッシュ事故は、Cloudflareの設定だけでなく、CMS、認証、API、配信元サーバーの応答が重なって起こります。外部へ運用を依頼するなら、管理画面の設定代行だけでなく、ヘッダーやログを見て原因を切り分けられるか確認したいところです。

障害時の連絡先、キャッシュ削除の権限、変更後の確認範囲まで決めておけば、復旧を急ぐ場面でも迷いにくくなります。Cloudflare運用全体の課題は、Cloudflareの運用課題と対策方法でも整理しています。