短.beリダイレクトキャッシュとは、ブラウザーや CDN がリダイレクト応答 (3xx レスポンス) を保存し、次回以降のアクセス時にオリジンサーバーへ問い合わせずにリダイレクト先へ直接遷移する仕組みである。短縮 URL サービスにおいては、パフォーマンスとクリック計測の両立に関わる設計要素となる。
RFC 9110 は、301 (Moved Permanently) と 308 (Permanent Redirect) を、明示的なキャッシュの指定が無くてもキャッシュが発見的な有効期限で再利用してよい応答 (heuristically cacheable) と定め、302 (Found) と 307 (Temporary Redirect) はそう定めていない。発見的な有効期限の長さは、RFC 9111 ではキャッシュの側に任されている。キャッシュされた 301 が使われる間はオリジンサーバーにリクエストが届かず、レイテンシは下がるが、短縮 URL サービス側ではそのクリックを数えられない。302 や 307 は、Cache-Control などで明示しない限り毎回オリジンを経由するので、サーバー側でクリックを記録しやすい。
キャッシュの挙動は Cache-Control ヘッダーでも制御できる。RFC 9111 では、no-store を指定した応答はキャッシュに保存されず、max-age=0 を指定した応答は保存されてもすぐに古いものとして扱われ、原則として再利用の前にオリジンへの確認が要る。逆に、計測が不要なリダイレクトには public, max-age=3600 のように TTL を設定し、CDN レイヤーでキャッシュさせることでオリジンの負荷を軽減できる。
CDN でのリダイレクトキャッシュも考慮する例がある。CloudFront の文書は、3xx の応答をディストリビューションの設定と応答のヘッダーに従ってキャッシュすると説明している (2026 年 10 月時点)。エッジでキャッシュされた応答が返る間はオリジンにリクエストが到達しないため、クリック計測はエッジログに依存することになる。
短縮 URL サービスの設計では、リダイレクトキャッシュの挙動を踏まえ、クリックの記録とパフォーマンスのトレードオフを考えた Cache-Control の設計が求められる。用途に応じて 301 と 302 を使い分け、キャッシュ TTL を制御することになる。