全削除と選択削除
全削除は1回の呼び出しでゾーンのキャッシュをすべて空にするので、多数のファイルが変わったデプロイの後に向いています。選択削除は指定した URL・ホスト名・タグ・プレフィックスだけを消し、残りのキャッシュを温かいまま保つので、ファイル1つの差し替えに向いています。
最終更新:
Cloudflare にはキャッシュを無効化する方法が5つあります。2025年4月3日以降、5つすべてが無料プランを含むすべてのプランで使えます。それ以前は3つが Enterprise 専用だったため、古い記事には今でも逆のことが書かれています。
5つの方法の比較
| 方法 | 消える範囲 | 向いている場面 | プラン |
|---|---|---|---|
| 全削除 | ゾーンのキャッシュ全体 | 多数のファイルに触れたデプロイ、または何が変わったか不明なとき | すべて |
| URL 指定 | 指定した URL だけ | 差し替えたばかりのファイル1つ | すべて |
| ホスト名指定 | そのホスト名から配信される全部 | 作り直したサブドメイン、たとえば img.example.com | すべて |
| プレフィックス指定 | あるパス以下の全部 | セクション全体、たとえば example.com/blog/ | すべて |
| タグ指定 | Cache-Tag ヘッダーが付いた全部 | パスではなく業務上のまとまりでグループ化した内容 | すべて |
全削除を使う場面
全削除は API 呼び出し1回で済み、ファイル一覧も要らず、取りこぼしもありません。そこが利点で、これは本物の利点です。静的サイトを作り直してすべてのファイル名のハッシュが変わったあとに、変更点を数え上げるのは無駄な作業です。
代償は、そのゾーンのキャッシュヒット率がゼロに落ちることです。パージ後の訪問はキャッシュが埋まり直すまですべてオリジンに届きます。小さなサイトなら誤差ですが、それなりのトラフィックがあるサイトでは自分で作り出したオリジンの負荷スパイクになります。オリジンが1台のささやかなサーバーなら、そのスパイクがまさに落とす原因です。
選択削除を使う場面
選択削除は残りのキャッシュを温かいまま保ちます。スタイルシートを1枚変えただけで、サイト中の商品写真をオリジンから取り直す理由はありません。
その代わり、正確さが要ります。URL 指定のパージは、クエリ文字列やプロトコルまで含めて完全に一致するURLだけに効きます。次の3つは別々のキャッシュエントリです。
https://example.com/style.csshttps://example.com/style.css?v=2https://www.example.com/style.css
1つ目を消しても残りの2つには何も起きません。「パージが効かない」という結論に至る理由は、圧倒的にこれです。効いてはいるのです、誰も要求しない URL に対して。
ホスト名・プレフィックス・タグ
「1つの正確な URL」と「ゾーン全体」のあいだには3つの中間があり、長らく Enterprise 契約が必要だったせいで使われていません。
- ホスト名は3つのなかで最も大雑把で、準備は不要です。
cdn.example.com以下を作り直したなら、呼び出し1回で済みます。 - プレフィックスは URL のパスに効くので、
example.com/blog/はショップに触れずに記事だけを消せます。 - タグは最も強力で、唯一準備が要ります。オリジンが
Cache-Tagレスポンスヘッダーを返す必要があります。それさえ済めば、いくつの URL にまたがっていようと「商品 4471 に関するすべて」を消せます。
5秒で決める
- どのファイルが変わったか正確にわかっていて、100件未満か。URL 指定で。
- サブドメインやセクションがまるごと変わったか。ホスト名かプレフィックス指定で。
- オリジンがすでに
Cache-Tagを返しているか。タグ指定で。 - どれでもない、または迷っていてサイトが小さいなら。全削除で。
FlarePurge の扱い
FlarePurge は全削除と、URL 指定・ホスト名指定の選択削除に対応しています。この3つで実際のパージの大半をまかなえます。URL を貼り付ければアプリが自動でバッチに分けるので、90件のリストは意識しないまま3回の API 呼び出しになります。
一括パージもできます。お気に入りのゾーンをまとめて、あるいはアカウント内の全ゾーンを1回の確認で。Cloudflare の制限に当たらないよう同時実行数を抑えてあります。その制限はこちらにまとめてあります。