# 6. キャッシュ > キャッシュの制約と cache および proxy セクションでの設定 --- LLMSインデックス: [llms.txt](/ja/llms.txt) --- HAProxy は、favicon や css などの小さなオブジェクトを対象とするキャッシュを提供します。RAM 上で動作する、最小限の保守で済む簡素なキャッシュです。 キャッシュには全スレッドで共有するメモリ領域を使用し、1kB のブロックに分割します。 オブジェクトが使われなくなると、有効期限にかかわらず、新しいオブジェクトを保存するために削除できます。新しいオブジェクトを割り当てる際は、最も古いオブジェクトから削除します。 キャッシュのキーには、host ヘッダーと URI のハッシュを使用します。 Unix ソケットの "show cache" コマンドでキャッシュの状態を確認できます。詳細は管理ガイドの[第 9.3 節](/ja/docs/haproxy/filters/#section-9-3)「Unix ソケットコマンド」を参照してください。 キャッシュからオブジェクトを配信すると、ログのサーバー名は "``" に置き換えられます。 ## 6.1. 制約 {#section-6-1} 次の場合、キャッシュはオブジェクトを保存せず、配信もしません。 - レスポンスが 200 ではない場合。 - レスポンスに Vary ヘッダーがあり、process-vary オプションが無効になっているか、Vary の値に現在未対応のヘッダーが指定されている場合。現時点で対応しているのは accept-encoding、referer、origin のみです。 - Content-Length とヘッダーサイズの合計が "max-object-size" を超える場合。 - レスポンスをキャッシュできない場合。 - レスポンスに明示的な有効期限（Cache-Control の s-maxage または max-age ディレクティブ、または Expires ヘッダー）も、検証子（ETag または Last-Modified ヘッダー）もない場合。 - process-vary オプションが有効で、現在のレスポンスと同じプライマリーキーのエントリーがすでに max-secondary-entries 個存在する場合。 - process-vary オプションが有効で、クライアントの accept-encoding ヘッダーによってレスポンスが変化する一方、そのエンコーディングが未知の場合。 に記載されていないエンコーディングが該当します。 - リクエストが GET ではない場合。 - リクエストの HTTP バージョンが 1.1 未満の場合。 - リクエストに Authorization ヘッダーが含まれる場合。 ## 6.2. 設定 {#section-6-2} キャッシュを設定するには、cache セクションを定義し、対応する http-request アクションと http-response アクションを使ってプロキシから利用する必要があります。 ### 6.2.1. cache セクション {#section-6-2-1} **`cache `** ```haproxy cache ``` cache セクションを宣言し、`` という名前の共有キャッシュメモリを割り当てます。キャッシュサイズの指定は必須です。後述の "total-max-size" キーワードを参照してください。 **`max-age `** ```haproxy max-age ``` 有効期間の上限を定義します。有効期限には、レスポンスの Cache-Control ヘッダーにある s-maxage、なければ max-age ディレクティブの値と、この設定値のうち小さいほうを使用します。デフォルト値は 60 秒なので、デフォルトではオブジェクトを 60 秒より長くキャッシュできません。 **`max-object-size `** ```haproxy max-object-size ``` キャッシュするオブジェクトの最大サイズを定義します。"total-max-size" の半分を超えてはいけません。未設定の場合はキャッシュサイズの 256 分の一になります。"max-object-size" より大きいオブジェクトは、すべてキャッシュされません。 **`max-secondary-entries `** ```haproxy max-secondary-entries ``` キャッシュ内で同じプライマリーキーを持つセカンダリーエントリーの同時存在数の上限を定義します。Vary のサポートを有効にする必要があります。デフォルト値は 10 で、正の整数を指定してください。 **`process-vary `** ```haproxy process-vary ``` Vary ヘッダーの処理を有効または無効にします。無効の場合、このヘッダーを含むレスポンスはキャッシュされません。有効の場合は、すべての受信リクエストについて、リクエストヘッダーの一部から予備的なハッシュを計算し、それを使って各リクエストのセカンダリーキーを構成します（RFC 7234#4.1 参照）。これには CPU コストがかかる場合があります。現在、セカンダリーキーは 'accept-encoding'、'referer'、'origin' ヘッダーの内容から構成します。RFC では 'origin' と 'referer' ヘッダーは単一値とされているため、いずれかを複数含むリクエストは不正な形式とみなすべきです。そのようなリクエストではセカンダリーキーを構成せず、キャッシュからレスポンスを配信することもありません。対処方法をサーバーに判断させるためです。デフォルト値は off（無効）です。 **`total-max-size `** ```haproxy total-max-size ``` RAM 上のキャッシュサイズをメガバイト単位で定義します。この領域は 1kB のブロックに分割され、キャッシュエントリーが使用します。最大値は 4095 です。 ### 6.2.2. proxy セクション {#section-6-2-2} キャッシュを利用する proxy セクションでは、要求されたオブジェクトをキャッシュから検索するため、"http-request" ルールセットに "cache-use" アクションを含める必要があります。また、取得したオブジェクトをキャッシュに保存または更新するため、"http-response" ルールセットに "cache-store" アクションを含める必要があります。いずれのアクションにも任意で条件を指定できます。たとえば、キャッシュできないことがわかっているサブディレクトリでは "cache-use" を省略したり、キャッシュする価値がない content-type では "cache-store" を省略したりできます。キャッシュのインデックスキーは "cache-use" アクションの実行時に計算されるため、このアクションを省略すると、レスポンス処理時にキャッシュを更新することもありません。 例： ```text backend bck1 mode http http-request cache-use foobar http-response cache-store foobar server srv1 127.0.0.1:80 cache foobar total-max-size 4 max-age 240 ```