Varnish Cacheとは:Varnish Cache Serverのインストールと基本設定

テスト環境 RHEL系AlmaLinux 9.8rootアカウント2026-10-16 確認

Varnish Cacheは、Webサーバーの前でHTTPレスポンスをメモリに保存しておき、同じリクエストにはオリジンサーバーを通さずに応答するリバースプロキシキャッシュです。AlmaLinux 9.8サーバーのVarnish 6.6.2をWordPressの前に置いたところ、max-age=0のためにページがキャッシュされず、VCLで保存時間を指定して解決しました。

どのリクエストをキャッシュし、どのくらいの間保存するかは、VCL(Varnish Configuration Language)ファイルに記述します。

1️⃣ Varnish Cacheの概念:リバースプロキシキャッシュ

Varnishはリクエストごとに、保存されたレスポンスがあるかを先に確認します。保存されたレスポンスで処理すればキャッシュヒット(HIT)、オリジンサーバー(バックエンド)から取得する必要があればキャッシュミス(MISS)です。ミスで取得したレスポンスは保存時間のあいだ保存され、次のリクエストに使われます。

オープンソースのVarnishはTLSに対応していないため、HTTPSリクエストを直接受け取れません。443番ポートではNginxやHAProxyがTLSを処理したあと、Varnishへリクエストを渡します。

オープンソースのVarnish Cacheプロジェクトは、2026年3月に公開された9.0バージョンから名前をVinyl Cacheに変えました。Varnish Cacheという名前は、Varnish SoftwareがTLS機能を加えて配布するバージョンが引き続き使っています。

2️⃣ Varnish Cache Serverのインストール

AlmaLinux 9では標準リポジトリ(AppStream)のvarnishパッケージでインストールし、このパッケージのバージョンは名前が変わる前のVarnish 6.6.2です。

dnf -y install varnish

インストールが終わったら、[varnishd -V]でバージョンを確認します。

varnishd -V
varnishd (varnish-6.6.2 revision 17c51b08e037fc8533fb3687a042a867235fc72f)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2020 Varnish Software

RHEL系のパッケージは、開発プロジェクトのサポートが終了した6.6.2バージョンをそのまま残し、セキュリティ修正だけを加えて配布しています。2025年6月に公開された6.6.2-7パッケージには、HTTPリクエストスマグリングの脆弱性(CVE-2025-47905)の修正が含まれています。

インストールすると、[/etc/varnish/default.vcl]と[/usr/lib/systemd/system/varnish.service]が一緒に作成されます。

grep ExecStart= /usr/lib/systemd/system/varnish.service
ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,256m

[-a :6081]はリクエストを受け取るポート、[-s malloc,256m]はキャッシュの保存領域として使うメモリ256MBを指定します。

3️⃣ 基本設定:バックエンドとポート

標準のVCLファイルである[/etc/varnish/default.vcl]には、最初から同じサーバーの8080番ポートがバックエンドとして設定されています。

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

Apacheは[httpd.conf]の[Listen]の値を8080に変え、Varnishが渡したリクエストを受け取るように設定します。

# /etc/httpd/conf/httpd.conf
Listen 8080

HTTPSを使うサイトでは、Varnishを6081番ポートのまま残し、TLSを処理するNginxがVarnishへリクエストを渡すようにつなぎます。

Varnishが80番ポートで直接リクエストを受け取る構成は、HTTPだけを使うサイトに向いています。この場合は、Varnish Softwareのインストール文書どおりにサービスファイルのコピーを作り、[ExecStart]行の6081を80に変えます。

systemctl edit --full varnish

エディターで保存したコピーは[/etc/systemd/system/varnish.service]に作成され、パッケージを更新しても変更したポートが保たれます。

systemctl enable --now varnish

どちらの構成でも、最後にenableコマンドとnowオプションで、ブート時の自動起動を登録すると同時にVarnishをすぐに起動します。

4️⃣ 動作確認:X-VarnishとAgeヘッダー

Varnishを起動したら、WordPressのページが実際にキャッシュから返っているかをレスポンスヘッダーで確認します。リクエストはNginxを通さずVarnishの6081番ポートへ送るため、ドメインとHTTPSかどうかは[Host]と[X-Forwarded-Proto]ヘッダーで指定します。

curl -sI -H "Host: example.com" -H "X-Forwarded-Proto: https" http://127.0.0.1:6081/ | grep -iE "^(HTTP|cache-control|x-varnish|age|via)"
HTTP/1.1 200 OK
Cache-Control: max-age=0
X-Varnish: 1001
Age: 0
Via: 1.1 varnish (Varnish/6.6)

[X-Varnish]はVarnishがリクエストに付けた番号で、[Via: 1.1 varnish]はレスポンスがVarnishを通ったという印です。[Age]はレスポンスがキャッシュに保存されてから経過した時間(秒)です。

3秒後に同じリクエストをもう一度送っても、[X-Varnish]の番号は1つ、[Age]は0で、今回もオリジンサーバーが応答しました。キャッシュプラグインが[.htaccess]に入れたルールがHTMLに[max-age=0]を付け、Varnishの標準設定が保存時間を0秒と計算したためです。

Cookieが付いたリクエストも、標準設定ではキャッシュを通りません。アクセス解析ツールのCookieも同じなので、そうしたCookieを持つ訪問者のリクエストはすべてオリジンサーバーへ渡ります。

下のVCLは、ログインや管理画面へのリクエストと、GETやHEADではないリクエストをオリジンサーバーへ渡し、残りのリクエストはCookieを取り除いてからキャッシュします。保存時間が0秒でCookieを作らないレスポンスは10分間保存し、[no-cache]のように保存しないよう指示するレスポンスは保存しません。

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }
    if (req.url ~ "^/(wp-admin|wp-login\.php)" || req.http.Cookie ~ "wordpress_logged_in_|wp-postpass_|comment_author_") {
        return (pass);
    }
    unset req.http.Cookie;
}

sub vcl_backend_response {
    if (beresp.ttl <= 0s && !beresp.http.Set-Cookie) {
        set beresp.ttl = 10m;
    }
}

VCLファイルを変えたら、[systemctl reload varnish]で読み込み直します。以下は、このVCLを適用したVarnishに同じリクエストを2回送った結果のうち、2回目のレスポンスです。

curl -sI -H "Host: example.com" -H "X-Forwarded-Proto: https" http://127.0.0.1:6081/ | grep -iE "^(HTTP|cache-control|x-varnish|age|via)"
HTTP/1.1 200 OK
Cache-Control: max-age=0
X-Varnish: 1004 1002
Age: 3
Via: 1.1 varnish (Varnish/6.6)

VCLを適用して3秒後に送った2回目のリクエストは、[X-Varnish]の番号が2つで、[Age]は3でした。番号が2つならキャッシュから応答したということで、後ろの番号はそのページをオリジンサーバーから取得して保存したリクエストの番号です。

ログインCookieを付けたリクエストは番号が1つでオリジンサーバーが応答し、解析ツールのCookieだけを付けたリクエストはキャッシュから応答しました。

🔢 FAQ & おすすめコンテンツ

VCLで保存時間を10分にすると、その10分間はキャッシュに保存された修正前のページで応答します。記事を保存したときにキャッシュもすぐ消すには、PURGEリクエストを処理するVCLのルールと、Proxy Cache Purgeのようなプラグインが必要です。PURGEリクエストは同じサーバーから送られたものだけを受け付けるよう、VCLで制限します。

キャッシュプラグインが作ったHTMLファイルをWebサーバーがPHPなしでそのまま送る構成なら、Varnishは同じ仕事をもう一度することになります。キャッシュされたページもPHPを通して応答する構成なら、Varnishがその前で応答してPHPの実行を減らします。

ヘッダーが見えなくてもVarnishを使っているサイトの可能性があり、サーバー運営者がレスポンスヘッダーの名前を変えたり削除したりすることもあります。Varnishを有効にしたCloudwaysサーバーのWordPressのレスポンスには、[X-Varnish]の代わりに[x-cache: HIT]と[age]ヘッダーが付いていました。

ℹ️ 提携について
当サイトのコンテンツにはアフィリエイトリンクが含まれています。訪問者がこのリンクを通じて商品やサービスを購入すると、当サイトは販売元から手数料を受け取ります。この過程において、購入者が支払う金額(イベント割引適用で金額が下がります↓)は上昇しません。掲載されている価格・割引・在庫情報は作成時点のものであり、実際とは異なる場合がありますので、ご購入前に販売元にて最終確認をお願いいたします。商品の選定および評価は独自の基準に基づいて行われており、手数料の支払いの有無は紹介順や評価内容に影響を与えません。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

人間であることを証明してください: 7   +   7   =