CDNは利用者に近い配信拠点からコンテンツを届け、元のサーバーへの負荷を減らす仕組みです。導入しただけで全ページがキャッシュされるとは限りません。公開画像やCSSから始め、会員ページ・フォーム・決済の除外と更新の反映を確認します。
CDNは「利用者とオリジンの間に置く分散配信・制御レイヤー」
CDNの価値は、すべてのデータを最寄りのサーバーへ複製することではありません。どのリクエストを同じ応答として扱うか、何秒まで古くてよいか、オリジンへ誰を通すかをルール化し、利用者に近い拠点で処理できる通信を増やすことです。
CDNとは？意味と構成要素をわかりやすく整理
CDN（Content Delivery Network、コンテンツ配信ネットワーク）とは、利用者と本来の配信元であるオリジンサーバーの間でHTTPリクエストを受け、分散した拠点からコンテンツを配信・中継する基盤です。公開ドメインのDNSをCDNへ向けると、利用者のリクエストは遅延や経路、障害、容量などを考慮して処理拠点へ送られます。
CDNの中心的な機能は共有キャッシュですが、それだけではありません。製品や契約によって、TLS終端、HTTP/2・HTTP/3、圧縮、画像変換、WAF、DDoS対策、bot管理、レート制限、エッジコード、ログ、署名URLなどを提供します。したがって、「CDN＝キャッシュサーバー」ではなく、「キャッシュを含む分散リバースプロキシ基盤」と考えると理解しやすくなります。
オリジンサーバー
正規のコンテンツやアプリケーション応答を作る上流です。Webサーバー、ロードバランサー、オブジェクトストレージ、APIなどが該当します。
エッジ・POP
利用者からの通信を受ける分散拠点です。保存済み応答の配信、TLS、圧縮、ルール、セキュリティ処理などを行います。
キャッシュ
以前のHTTP応答を保存し、条件を満たす次回リクエストへ再利用する仕組みです。ブラウザキャッシュとCDNの共有キャッシュは別物です。
リバースプロキシ
利用者の前面でリクエストを受け、上流へ転送する役割です。CDNのedgeもリバースプロキシとして動きますが、単一拠点のproxyがCDNとは限りません。
CDN・キャッシュ・DNS・ロードバランサーの違い
| 用語 | 主な役割 | CDNとの関係 |
|---|---|---|
| CDN | 分散した拠点でコンテンツを配信・中継し、経路・キャッシュ・セキュリティを制御 | 利用者とオリジンの間に置く配信レイヤー |
| キャッシュ | 保存した応答や計算結果を再利用 | CDNの主要機能の一つ。ブラウザー、application、databaseにも存在 |
| DNS | ドメイン名を接続先へ解決 | 利用者をCDNへ向ける入口。DNS自体はWeb本文を配信しない |
| ロードバランサー | 複数backendへリクエストを振り分ける | 多くはオリジン側のアプリケーションを分散。CDNのedge配信とは層が異なる |
| Webホスティング | Webサーバー、ストレージ、実行環境を提供 | CDNのオリジンになり得る。CDN導入後も保守・backup・capacityは必要 |
| WAF | 不正なHTTP通信を検知・遮断 | CDNに統合される場合があるが、ルール設計と誤検知対応は別途必要 |
CDNの仕組み：リクエストからcache hit・missまで
CDNの仕組みは、リクエストの入口、キャッシュキーの作成、保存済み応答の鮮度判定、オリジン取得、応答の保存という順に追うと理解できます。以下は一般化した流れであり、regional キャッシュやtiered キャッシュなどの中間層は製品によって異なります。
DNS・経路制御でCDNのedgeへ到達
利用者がURLへアクセスすると、公開ホスト名のDNS設定やCDN事業者の経路制御により、リクエストを処理するPOPへ到達します。HTTPSでは利用者とedgeの間でTLS接続が確立されます。
リクエストからcache keyを作る
CDNはhost、パスを基本に、設定したクエリ string、ヘッダー、Cookie、methodなどを組み合わせてキャッシュキーを作ります。同じkeyは「同じ応答として扱う」という意味です。
保存済み応答が新鮮ならHIT
同じkeyの応答が保存され、TTL内などの条件を満たしていればedgeから返します。オリジンへの往復がなくなるため、遅延と上流負荷を減らせます。
なければMISS、期限切れなら再検証
保存済み応答がなければ上位キャッシュまたはオリジンへ取得します。期限切れでもETagやLast-Modifiedを使って再検証し、304 Not Modifiedなら保存済みbodyを再利用できます。
条件を満たす応答を保存し、利用者へ返す
オリジンから届いた状態、ヘッダー、bodyを利用者へ転送し、cacheabilityとTTLの条件を満たす場合は次回のために保存します。Set-Cookie、Authorization、状態 code、object sizeなどの扱いは実装と設定を確認します。
具体例：1,000件のうち850件がHITした場合
次の数字は仕組みを理解するための説明例です。実際のダッシュボードでは、キャッシュ対象だけを分母にするか、BYPASSやREVALIDATEDをどう数えるか、多段キャッシュをどこで測るかが製品ごとに異なります。
850 HIT ÷ 1,000 eligible requests = 85%キャッシュ対象1,000件のうち850件が有効なedge キャッシュから返った例です。hit率だけでなく、HIT時とMISS時の応答時間も分けて見ます。
1 − (150 origin requests ÷ 1,000 viewer requests) = 85%850件ではオリジンへ届かなかったと仮定した単純計算です。tiered キャッシュ、リクエスト collapsing、subrequestがあると、非HIT数とオリジン要求数は一致しません。
cache key・TTL・Cache-ControlがCDN設計の中心
CDNの成否を決めるのは拠点数よりも、何を同じ応答として扱うかを決めるキャッシュキーと、いつまで再利用してよいかを決めるTTLです。ここを曖昧にすると、同じ利用者向けの応答が細かく分かれてHIT率が落ちるか、異なる利用者の応答が混ざるかのどちらかが起こります。
cache keyには「応答を本当に変える値」だけを含める
- 基本：host、パス、必要なクエリ stringを基準にする
- 含める候補：language、currency、tenant、画像formatなど、オリジンの応答を変える値
- 避けたい候補：一意のセッション ID、追跡用クエリ、膨大な種類のUser-Agentなど、不要な細分化を生む値
- 認証後ページ：Authorizationやセッション Cookieを無視して共有しない。原則BYPASSとし、共有する場合は厳密に分離する
主要なCache-Controlディレクティブ
| 指示 | 主な意味 | 実務上の注意 |
|---|---|---|
max-age | 応答を新鮮とみなす秒数 | ブラウザーと共有キャッシュの双方に影響。共有キャッシュだけ別にしたい場合はs-maxage等を検討 |
s-maxage | 共有キャッシュ向けの鮮度時間 | CDNではmax-ageより優先される。事業者の実装と上書きルールを確認 |
public | 共有キャッシュで保存可能と明示 | 認証付き応答を共有する場合は、内容が本当に全員共通か厳密に確認 |
private | 共有キャッシュでは保存しない | ブラウザーなど私的キャッシュでの保存は許容し得る。機密情報はno-storeも検討 |
no-cache | 再利用前に再検証を要求 | 保存禁止ではない。ETagやLast-Modifiedと組み合わせると304でbodyを再利用できる |
no-store | 保存を禁止 | 個人情報、決済、機密性の高い応答で検討。CDNルールが上書きしないか確認 |
must-revalidate | staleな応答を無断で再利用しない | オリジン障害時に古い応答を返したくない重要情報に使うが、可用性とのトレードオフ |
stale-while-revalidate | 再検証中に一定時間stale応答を返す | 応答待ちを減らせるが、製品の実装差と重要情報の陳腐化を評価 |
stale-if-error | オリジン error時に一定時間stale応答を許容 | 障害時の閲覧継続に使えるが、価格・在庫・法令情報では慎重に設定 |
immutable | 鮮度期間中は内容が変わらないと示す | 内容ハッシュ付きCSS・JS・画像など、URLがversionごとに変わる資産と組み合わせる |
RFC上の意味とCDN製品の既定動作は分けて確認します。CDN側のCache Rules、minimum TTL、状態 code TTLなどがオリジンのヘッダーを上書きする場合があります。
用途別のヘッダー例
# 内容ハッシュ付き静的ファイル
Cache-Control: public, max-age=31536000, immutable
# 公開HTML：browserは5分、共有CDNは1時間
Cache-Control: public, max-age=300, s-maxage=3600
ETag: "page-v42"
# 個人情報を含む認証後ページ
Cache-Control: private, no-store例は出発点です。更新要件、事業者のルール、ブラウザキャッシュ、再検証、stale許容を含めてテストしてください。
CDN-Cache-ControlとCache-Statusも押さえる
RFC 9213では、一般のCache-Controlとは別にCDNなど特定の共有キャッシュへ指示を出す考え方と、CDN-Cache-Controlヘッダーが定義されています。ブラウザーのTTLとCDNのTTLを分けたいときに有用ですが、利用するCDNが対応しているか、独自ヘッダーとの優先順位を確認します。
RFC 9211のCache-Statusは、キャッシュがリクエストをどう扱ったかを標準化された形式で示すヘッダーです。すべてのCDNが常時付与するわけではないため、実際にはAge、Via、CF-Cache-Status、X-Cacheなど製品固有のヘッダーやログも併用します。
CDNを導入する5つのメリット
CDNのメリットは「サーバーが近くなる」だけではありません。キャッシュヒットでオリジン処理を省くこと、接続や圧縮をedgeで最適化すること、急増した通信を分散することが組み合わさって効果が生まれます。
表示・ダウンロードを高速化しやすい
利用者に近いedgeから応答し、オリジンへの往復を省くことで、画像、CSS、JavaScript、公開HTML、動画などの待ち時間を短縮できます。
originのCPU・帯域・接続数を減らせる
同じ応答をedgeで再利用すれば、Webサーバー、ストレージ、API、データベースへ届く要求と転送量を減らせます。
アクセス急増を吸収しやすい
ニュース掲載、キャンペーン、動画公開、ソフトウェア配布などで同じコンテンツへアクセスが集中した際、分散拠点で処理できます。
一部の公開コンテンツを障害時も返せる
stale配信を許容した公開GETでは、オリジンが一時的に応答できないときに保存済み内容を返せる場合があります。完全な障害対策ではありません。
攻撃をoriginの前で制御しやすい
WAF、DDoS対策、bot管理、レート制限、TLS終端をedgeで適用し、オリジンの公開範囲を狭められます。
効果はHITする通信に偏る
cold キャッシュ、個人別API、POST、書き込み、認証、database処理はオリジンへ依存します。CDN導入後も上流の性能・冗長化・監視は必要です。
CDNのデメリット・導入時の注意点
CDNは便利ですが、通信経路と状態を一層増やします。導入前より速くなっても、更新・障害・セキュリティの切り分けが難しくなるため、メリットだけで判断しないことが大切です。
古い情報が残る
TTL、ブラウザー キャッシュ、edge キャッシュ、regional キャッシュが重なり、更新後も古いHTMLや画像が表示されることがあります。versioned URL、再検証、対象を絞った削除を設計します。
個人情報が混ざる危険
セッション、tenant、Authorization、Cookieを無視した共有キャッシュは重大な情報漏えいにつながります。認証後ページは原則bypassし、別ユーザーでの試験を必須にします。
MISS時は経路が増える
利用者→CDN→オリジンとなるため、キャッシュできない通信ではedge処理や接続の分だけ遅くなる場合があります。動的APIは実測で判断します。
費用が読みにくい
転送量、リクエスト、function、WAF、ログ、削除、専用IPなど課金軸が増えます。攻撃やhotlink、cache-busting クエリでも費用が増える可能性があります。
障害点・設定点が増える
CDN自身の障害、DNS、証明書、WAF誤遮断、設定反映、global 削除などが追加されます。bypass・切り戻しと権限管理が必要です。
製品ごとの用語差が大きい
HIT、MISS、BYPASS、DYNAMIC、EXPIRED、STALE、UPDATINGなどの定義が異なります。ダッシュボードの分母とログ仕様を公式文書で確認します。
CDNに向くコンテンツ・共有キャッシュしない通信
拡張子だけで判断せず、同じキャッシュキーの利用者へ同じ応答を返してよいか、何秒古くてもよいか、認証・個人情報に依存するかで分類します。
CDNとSEOの関係：順位を直接上げる機能ではない
CDNを使うだけで検索順位が上がるわけではありません。速度と可用性が改善すれば、ユーザー体験やクロールの安定へ間接的に寄与する可能性はありますが、コンテンツ品質、検索意図への適合、index可否、canonical、HTTP 状態、内部リンク、レンダリングが正しいことが前提です。
Google Search Centralは、CDNをオリジンと利用者の間に置く中継として説明し、CDN利用自体を問題としていません。一方で、cold キャッシュではGooglebotの最初の取得がオリジンへ到達することがあり、クロール急増時にはオリジン容量にも注意が必要です。HTTP cachingを適切に使えば、再取得の効率化や配信負荷の低減につながります。
CDN導入・移行時のSEOチェック
- 状態：通常ページは200、移転は適切な301・308、存在しないURLは404・410を返す
- robots：robots.txt、noindex、X-Robots-TagをCDNルールやerror pageで誤って変更しない
- canonical：CDN用ホスト名ではなく公開する正規URLを示し、Host ヘッダーとredirectを確認する
- crawler遮断：WAF・bot対策・rate limitがGooglebotや主要crawlerを誤遮断しない
- error キャッシュ：一時的な5xxや403を長時間キャッシュしない。復旧後に古いerrorが残らないか確認する
- rendering：CSS、JavaScript、画像、fontが403・CORS・署名期限切れにならず、モバイルでも読み込める
- 速度：HITだけでなくcold キャッシュ、HTML、LCP画像、第三者script、オリジン応答も測定する
CDNのセキュリティ：WAFだけでなくorigin保護とcache境界を見る
CDNは攻撃通信をオリジンの前で受けられるため有力な防御層ですが、導入しただけで安全になるわけではありません。CDNを迂回してオリジンへ直接アクセスできれば、WAFやrate limitを回避される可能性があります。
利用者→edge、edge→originをHTTPSにする
viewer側だけでなくオリジン側もTLSで保護し、証明書名、SNI、Host ヘッダー、redirect、TLS versionを確認します。
origin直アクセスを制限する
OAC、署名付きリクエスト、mTLS、認証済みcustom ヘッダー、firewall allowlist、private networkなど、対応方式でCDN以外の経路を閉じます。
private contentは署名と期限を設計する
署名URL・Cookie、権限失効、キャッシュキー、Range リクエスト、download再開を合わせて確認し、URL漏えい時の影響を限定します。
cache poisoning・deceptionを試験する
keyに入らないヘッダーやパス解釈差を悪用して有害な応答を共有させたり、認証ページを静的ファイルのように見せて保存させたりする攻撃を想定します。
DDoS対策として期待できること・できないこと
CDNは大規模ネットワークで通信を吸収し、既知の攻撃をedgeで遮断し、HITする静的要求をオリジンへ送らないことで耐性を高められます。しかし、認証APIや検索などオリジンで高コスト処理を行うL7攻撃、cache-busting、正規ユーザーに似たbot、攻撃時の従量課金は別途対策が必要です。
CDNを安全に導入する7ステップ
最初から全URLをキャッシュせず、観測しやすい静的ファイルから段階的に広げます。変更前後でURL、body、ヘッダー、状態、遅延、オリジン リクエスト、費用を比較し、異常時にbypassまたは切り戻しできる状態を作ります。
1. URLとデータを分類する
static asset、public HTML、public API、authenticated、upload、admin、errorへ分け、method、クエリ、ヘッダー、Cookie、個人情報、更新頻度、最大size、Rangeの有無を記録します。
2. 成功指標と許容範囲を決める
p95 遅延、オリジン リクエスト・bytes、error率、費用、何秒古くてよいか、障害時にstaleを返すかを決めます。「HIT率だけ」を目標にしません。
3. 検証用ホストでDNS・TLS・origin接続を確認する
viewer TLSとオリジン TLS、Host、SNI、IPv4・IPv6、CNAME、CAA、redirect、証明書更新を確認します。本番切替前に同じURL・ヘッダーで比較します。
4. URL群ごとにcache policyを定義する
cacheability、キャッシュキー、TTL、stale、error キャッシュ、compression、forwardするヘッダー・Cookie・クエリを明記します。最初はhash付きassetから始めます。
5. security boundaryを試験する
別ユーザー、別tenant、別language、別currencyでbodyが混ざらないこと、logout後にprivate contentが残らないこと、オリジン直アクセスが制限されることを確認します。
6. release・purge・rollbackを準備する
static assetはcontent hash付きURLを基本にし、HTMLから新versionへ切り替えます。緊急削除の対象、完了確認、rate limit、費用、削除後のMISS集中を想定します。
7. 小さく公開し、edgeとoriginを同時に監視する
一部host・パス・通信量から開始し、リクエスト、bytes、キャッシュ状態、遅延、4xx・5xx、TLS、WAF、オリジン load、費用を同じ時間軸で確認します。
変更前に、通常記事・検索・ログイン・フォーム・カートの代表URLを用意します。公開コンテンツは初回と2回目の応答を比較し、個別ページは異なるテスト利用者で内容が混ざらないことを確かめます。全削除はオリジンへのアクセスが急増するため、まず対象URLだけの削除で更新確認を行ってください。
導入後の確認方法：curl・ヘッダー・ログで見る
ブラウザの体感だけでは、ブラウザー キャッシュ、CDN キャッシュ、オリジン処理のどこが効いているか判断できません。同じURLを複数回取得し、応答 ヘッダーとCDN・オリジンログを照合します。
まずはresponse headerを確認する
# headerのみ確認
curl -I https://example.com/assets/app.a1b2.css
# cache-bustingせず、同じURLを数回確認
curl -sS -D - -o /dev/null https://example.com/article/
# 特定headerやstatusを抽出
curl -sS -D - -o /dev/null https://example.com/ \
| grep -Ei '^(HTTP/|age:|cache-control:|etag:|vary:|cache-status:|cf-cache-status:|x-cache:)'見るべき指標
| 指標 | 何が分かるか | 注意点 |
|---|---|---|
| キャッシュ状態 | HIT、MISS、BYPASS、EXPIRED、STALE、REVALIDATEDなど | 名称・分母・多段キャッシュの扱いは製品ごとに異なる |
Age | 共有キャッシュに保存されてからの概算秒数 | 再検証、削除、eviction、階層移動でreset・欠落する場合がある |
| オリジン リクエスト | 実際に上流へ到達した要求数 | edgeの非HIT数と一致しない場合がある |
| オリジン bytes | 上流からCDNへ転送した量 | 大容量object、Range、圧縮、多段キャッシュを考慮 |
| p50・p95・p99 遅延 | 平均では見えない遅い利用者・MISSを把握 | HIT・MISS、地域、パス、状態別に分ける |
| 4xx・5xx | WAF誤遮断、オリジン error、証明書・DNS問題 | error 応答がキャッシュされていないか確認 |
| 費用 | transfer、リクエスト、function、WAF、ログなどの増減 | bot、hotlink、攻撃、cache-bustingを分けて見る |
よくあるトラブルと確認順
更新したのに古い
ブラウザー キャッシュ → edgeのAge・状態 → TTL・s-maxage → 削除対象 → 上位キャッシュ → オリジン bodyの順に確認します。
HIT率が上がらない
キャッシュ対象、Set-Cookie、Authorization、クエリのばらつき、Vary、minimum TTL、object eviction、通信量量を確認します。
別ユーザーの内容が出る
直ちにキャッシュをbypass・削除し、キャッシュキー、Cookie、Authorization、tenant、Vary、URL正規化を調査します。重大事故として扱います。
CDN経由だけ502・SSL error
オリジン証明書名、SNI、Host ヘッダー、TLS version、firewall、オリジン timeout、DNS解決、IPv6を確認します。
CDNサービスを選ぶときの比較ポイント
「拠点数が多い」「無料で使える」だけでは選べません。自社の利用地域、コンテンツ、認証、運用体制を基準に、次の項目を比較します。
配信地域と実測latency
利用者の多い国・地域で、HITとMISS、HTMLと大容量ファイルを測定します。公称拠点数だけで決めません。
cache ruleの表現力
パス、状態、ヘッダー、Cookie、クエリ、TTL、stale、削除、tiered キャッシュを要件どおり設定できるか確認します。
origin保護・private配信
OAC相当、mTLS、private network、署名URL・Cookie、鍵管理、権限失効を確認します。
WAF・DDoS・bot対策
標準範囲、追加料金、ルール上限、managed rule、rate limit、ログ、緊急対応窓口を確認します。
ログ・分析・エクスポート
キャッシュ状態、オリジン 遅延、リクエスト ID、WAF、地域、費用を外部基盤へ送れるか、保持期間と遅延を見ます。
料金とサポート
転送、リクエスト、削除、function、ログ、WAF、専用機能、最低契約、攻撃時課金、サポート時間を同じ想定通信量で比較します。
| サービス・項目 | 確認した仕様 | 導入時の判断 |
|---|---|---|
| Cloudflareの初期設定 | HTMLとJSONは標準ではキャッシュ対象ではない。追加ルールの設定が必要。 | WordPress記事のHTMLも保存したい場合は、ログイン・カート等の除外を先に設計する。 |
| CloudFrontのMinimum TTL | 0より大きい場合、オリジンのno-cache・no-store・privateより最低TTLが優先される。 | 個別情報を返す経路にはキャッシュ無効の設定を選び、実応答を確認する。 |
| 削除とブラウザー保存 | CDN側の削除は、利用者のブラウザー内にあるコピーの削除とは別。 | 画像・CSS等はファイルURLの更新、HTMLは短い鮮度・再検証も組み合わせる。 |
CDNに関するよくある質問
CDNとキャッシュは同じものですか？
同じではありません。キャッシュは応答を保存・再利用する仕組みで、CDNは利用者とオリジンの間に置く分散配信基盤です。CDNはキャッシュのほか、TLS、WAF、経路制御、動的通信の中継も担えます。
CDNを導入すると必ずWebサイトが速くなりますか？
必ずではありません。HITではオリジン往復を省けますが、cold キャッシュ、動的処理、細分化しすぎたkey、重いedge処理では改善が小さい場合があります。導入前後を同じ条件で実測します。
動的コンテンツやAPIにもCDNは使えますか？
使えます。共有可能なGET応答だけを短時間キャッシュする方法と、キャッシュせずにCDNを経由させ、TLS、WAF、rate limitを適用する方法があります。認証・個人情報を含む応答は原則共有しません。
Cache-Controlのno-cacheは保存禁止という意味ですか？
保存禁止ではありません。no-cacheは保存した応答を再利用する前に再検証する指示です。保存自体を禁止する指示はno-storeです。CDN側ルールによる上書きも確認します。
WordPressサイトにもCDNは必要ですか？
必須ではありません。海外閲覧、大容量画像、アクセス急増、オリジン負荷が課題なら有効です。小規模な国内サイトでは、画像圧縮、不要plugin削減、サーバー・database改善を先に行う方が効果的な場合もあります。
CDNを使うとSEO順位が上がりますか？
直接の順位保証はありません。速度・可用性の改善がユーザー体験やcrawl安定へ寄与する場合はありますが、content品質、index設定、canonical、状態、renderingが前提です。
CDNはDDoS攻撃を完全に防げますか？
完全には防げません。CDNは防御層になりますが、WAF、rate limit、オリジン非公開化、applicationの高コスト処理対策、攻撃時課金の監視、緊急対応を組み合わせます。
キャッシュヒット率は何％なら良いですか？
一律の基準はありません。静的資産では高くしやすい一方、更新頻度の高いHTMLや個人別APIでは低くても正常です。オリジン offload、遅延、error、正確性、費用と合わせて判断します。
更新したのに古いページが表示されるのはなぜですか？
ブラウザーまたはCDNの保存済み応答がまだfreshだからです。静的資産は内容ハッシュ付きURL、HTMLは短いTTL・再検証、緊急更新は対象を絞った削除を使い分けます。
まとめ：CDNはcache key・鮮度・origin保護まで設計する
CDNは、利用者とオリジンの間に分散したedgeを置き、キャッシュ可能な応答を再利用し、キャッシュしない通信も中継する配信基盤です。HITではオリジン往復を省けますが、MISS、再検証、動的要求、書き込みは上流へ到達します。
安全に導入するには、コンテンツ別にcacheability、キャッシュキー、TTL、versioning・削除、stale、認証境界を決め、edgeとオリジンのリクエスト、bytes、遅延、状態、費用を同じ時間軸で監視してください。個人情報の共有、古い重要情報、オリジン bypass、削除後の負荷集中を防げて初めて、CDNは持続的な高速化になります。
- 最初に：URLとデータを公開・共有可能・個人別へ分類する
- 設定で：応答を変える値だけをキャッシュキーへ含め、TTLと更新方法を決める
- 安全性で：オリジン直アクセス、認証後ページ、キャッシュ poisoning・deceptionを試験する
- 運用で：HIT率だけでなくオリジン offload、p95 遅延、error、費用を追う
事実確認に用いた一次資料・公式資料 / HTTPの標準仕様と、各CDN製品の実装例を分けて確認しています。製品固有の既定値や状態名を、CDN全体の普遍的仕様として扱わないでください。 / IETF・RFC / RFC 9111：HTTP Caching / RFC 5861：stale-while-revalidate / stale-if-error / RFC 9211：The Cache-Status HTTP Response Header Field / RFC 9213：Targeted HTTP Cache Control / CDN-Cache-Control / AWS CloudFront公式資料 / How CloudFront delivers content / Understand the cache key / Restrict access to an AWS origin / Use Amazon CloudFront Origin Shield / Cloudflare公式資料 / Origin Cache Control / Revalidation / stale-while-revalidate / Cloudflare cache responses / CDN-Cache-Control / Avoid web cache poisoning / Cache Deception Armor / Google Search Central公式資料 / Crawling December：CDNs and crawling / Crawling December：HTTP caching / 2026年9月16日に再確認した公式資料 / HTMLの初期設定、Minimum TTL、キャッシュ削除の範囲を確認しました。料金比較や利用地域別の実測は含みません。 公式文書の照合であり、製品の契約・復元・決済や障害復旧を実機検証した記録ではありません。 / Cloudflare：標準キャッシュ動作 / AWS：CloudFrontのキャッシュ設定 / Cloudflare：削除方法 /
