Cache-Control の no-cache と no-store の違い：保存させないのは no-store
no-cache は「キャッシュしない」ではありません。RFC 9111 をもとに no-cache、no-store、max-age=0、Pragma の違いを整理し、CDN やブラウザーによって挙動が異なる点も確認します。
開発者ツールでは、Cache-Control: no-cache の付いた応答もキャッシュの項目として表示されることがあります。HTTP キャッシュの仕様 RFC 9111 では、no-cache はそれ自体では保存を禁止しません。保存できるかどうかは別の規則で決まり（3 節）、no-cache は保存された応答を再利用する前にオリジンサーバーでの検証を求めます。保存を止めるのは no-store です。
no-cache：再利用のたびに検証する
引数なしの no-cache が付いた応答は、オリジンでの検証に成功するまで別のリクエストに再利用できません（5.2.2.4 節）。応答全体を検証するとき、キャッシュは保存した ETag を If-None-Match で送ります（4.3.1 節）。応答がまだ有効なら、サーバーは本文のない 304 Not Modified を返すことができます（RFC 9110 の 15.4.5 節）。
max-age=0 も応答をすぐに stale にします。ただしキャッシュがオリジンと切断されているときや、クライアントが max-stale で許可したときは、stale な応答を返せます（4.2.4 節）。no-cache は、stale な応答を返すよう設定されたキャッシュでも、検証なしの再利用を止めます。
no-store：保存しないよう指示する
no-store は、その時点のリクエストと応答のどの部分も保存しないという意味で、private キャッシュにも shared キャッシュにも適用されます（5.2.2.5 節）。no-cache と一緒に来た場合も通常は保存されません。ただし must-understand を実装したキャッシュがそのステータスコードのキャッシュ規則を理解していれば、no-store を無視することが推奨されています（5.2.2.3 節）。仕様は、no-store がプライバシーを守る確実な、あるいは十分な手段ではないとも明記しています。従わないキャッシュや盗聴は防げません。
CDN やブラウザーによって挙動が異なるところ
no-cache="Set-Cookie"のようにフィールドを指定すると、仕様上はそのフィールドを除いた場合に限り検証なしで再利用できます。ただしこの形は広く実装されておらず、多くのキャッシュは引数なしの no-cache と同じに扱います（5.2.2.4 節）。Set-Cookie ヘッダーだけでは、キャッシュ可能な応答がキャッシュされるのを防げません（7.3 節）。- Cloudflare のドキュメントによると、Origin Cache Control がオンなら no-cache の応答をキャッシュして毎回再検証し、オフならキャッシュしません。Free・Pro・Business プランではオンで、オフにできません。
- 戻る／進むキャッシュ（bfcache）は HTTP キャッシュではありません。web.dev によると、no-store の付いたページはこれまで bfcache の対象外とされてきており、Chrome ではこれを変える作業が進んでいます。bfcache から復元されるときは no-cache も max-age=0 も適用されません。そのため web.dev は、復元後に新しい内容が必要なら pageshow イベントで処理するよう勧めています。ブラウザーやバージョンによって変わりえます。
Pragma: no-cacheは HTTP/1.0 向けのリクエストヘッダーで、非推奨とされています。応答での意味は定義されたことがありません（5.4 節）。
機密でなく、再利用前の再検証で足りる HTML や API の応答には no-cache と ETag を使います。保存されてはいけない応答には no-store を使い、HTTPS などの保護は別に用意します。リダイレクトのキャッシュの扱いは 301・302・307・308 リダイレクトの違いで取り上げました。