Squid が APT パッケージをキャッシュできる場合
パッケージ要求が Squid のヒットになることを期待する前に、HTTP トランスポート、キャッシュストレージ、オブジェクトサイズ、APT の cache-control 設定を確認してください。
APT と aptitude は HTTP 経由でリポジトリのファイルを取得できます。Squid は適格な HTTP 応答をキャッシュできます。クライアントは Web ブラウザである必要はありません。
Squid 6 または 7 の配備では、すべてのパッケージ転送が依然としてオリジンに到達する場合、次の入力項目を確認してください。
- ダウンロードが HTTP を使用しているか、Squid が何らかの形で HTTP 交換にアクセスできている。 HTTPS CONNECT トンネルだけではパッケージ応答はキャッシュに公開されません。
- キャッシュに適切なストレージが構成されている。転送の成功はディスクキャッシュの存在を証明しません。
- アーカイブが該当するキャッシュディレクトリの最大オブジェクトサイズに収まっている。小さなメタデータと大きな .deb では結果が異なることがあります。
- 要求と応答の cache-control ポリシーが保存と再利用を許可している。
APT は Acquire::http::No-Cache、Max-Age、No-Store を公開しています。No-Store は要求されたアーカイブファイルの保存を妨げることがあります。No-Cache は保存された応答を再利用する前に再検証を求めます。APT の実効構成と Squid のポリシーの両方を確認してください。
同じ完全な URL を比較し、access.log でキャッシュ結果を確認してください。 異なるミラーホスト、変更されたリポジトリパス、ローカルにキャッシュされたパッケージは、2 つのインストールが同じネットワークオブジェクトを決して要求しないことを意味する場合があります。
リポジトリミラーは、需要に応じた HTTP キャッシュの再利用だけに頼るのではなく、リポジトリの内容を意図的に維持します。