Nginx Cache Purge Preload Plugin HELP

問題点：NPPがキャッシュをウォームアップするが、訪問者が別のキャッシュを作成し、キャッシュミスが発生する
PHPが出力自体を圧縮する場合（php.iniでzlib.output_compression = Onを設定）、レスポンスヘッダーにVary: Accept-Encodingを追加します。Nginxのキャッシュエンジンは、リクエストのAccept-Encodingの値からMD5バリアントハッシュを計算し、それぞれの値ごとに個別のキャッシュファイルを作成します。

NPPのプリローダーは、デフォルトでAccept-Encoding: identityを送信します。これは、圧縮されていないプレーンなコンテンツをリクエストしていることを意味します。実際のブラウザは常に1つの値を送信するため、そのバリアントハッシュはプリロードされたエントリと一致しません。そのため、Nginxは2つ目のキャッシュファイルを作成し、ウォームアップされたキャッシュを完全にバイパスしてしまいます。NPPのプリローダーが送信する内容自体が問題なのではありません。たとえブラウザを完全に模倣していたとしても、ブラウザによって送信する値は異なります（Chromeはzstdを追加し、Safariはbrを省略し、古いクライアントはgzipのみを送信します）。そのため、すべての訪問者に対応する単一のエントリをウォームアップすることは不可能です。これがNPPによるNginxのキャッシュ管理ロジックを破綻させています。これは事実上NPPのキャッシュウォーミングを無効にし、プリロードされたエントリが実際の訪問者に配信されなくなります。唯一の正しい修正方法はNginx/PHP側で行うことです。

これはfastcgi_cache、proxy_cache、uwsgi_cache、scgi_cacheに等しく影響します。

修正方法：必要な変更点2つ
ステップ1 — PHPレベルの圧縮を無効にする（php.ini）
PHPは出力を圧縮したり、Vary: Accept-Encodingを追加したりしてはいけません。圧縮処理はすべてNginxに任せましょう。

; /etc/php/fpm-phpX.Y/php.ini
zlib.output_compression = Off

保存後、PHP-FPMをリロードしてください：systemctl reload php-fpm
ステップ2 — NginxのPHPブロックにfastcgi_ignore_headers Varyを追加する
PHPの圧縮を無効にしても、他のアップストリームコンポーネントがVaryヘッダーを出力する場合があります。このディレクティブは、キャッシュ操作中にNginxにこれを完全に無視するように指示します。

location ~ \.php$ {
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_pass unix:/var/run/php-fcgi-yoursite.sock;
include /etc/nginx/fastcgi_params;
fastcgi_param HTTP_ACCEPT_ENCODING ""; # ← PHPに到達する前にAccept-Encodingを削除します
fastcgi_ignore_headers Vary; # ← セカンダリキャッシュファイルの作成を防止します
fastcgi_cache YOUR_ZONE;
fastcgi_cache_valid 30d;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
fastcgi_cache_lock on;

} なぜ両方必要なのか？ fastcgi_param HTTP_ACCEPT_ENCODING “” は、PHP がクライアントの Accept-Encoding 値を認識することを防ぎます。そのため、PHP は圧縮出力を生成したり、Vary: Accept-Encoding を出力したりすることがそもそもできません。 fastcgi_ignore_headers Vary は、2 つ目の防御策です。Vary ヘッダーがアップストリームから届いた場合でも、Nginx はキャッシュ操作中にそれを処理しません。これら 2 つの設定により、クライアントが送信する内容に関わらず、URL ごとに単一のキャッシュファイルが保証されます。

📌 共有 fastcgi_params ファイルに fastcgi_param HTTP_ACCEPT_ENCODING “” を既に設定している場合は、ここで再度設定する必要はありません。include /etc/nginx/fastcgi_params によって自動的に適用されます。

保存後にNginxをリロードしてください：`nginx -t && systemctl reload nginx`

ステップ3 — Nginxにgzipを処理させる（nginx.confのhttpブロック）
PHPの圧縮を無効にすると、Nginxが唯一の圧縮レイヤーになります。これは正しいアーキテクチャです。http {}ブロックに以下の記述があることを確認してください。

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_types text/plain text/css application/javascript application/json text/xml application/xml text/javascript;

`gzip_vary on`は、Nginxから配信されるレスポンスに`Vary: Accept-Encoding`を追加します。ただし、これはキャッシュ検索後に実行されるため、キャッシュファイルの作成には影響しません。キャッシュキーは既に解決済みです。

`fastcgi_ignore_headers Vary`が安全な理由
通常、`Vary`を抑制すると、gzip圧縮されたコンテンツを解凍できないクライアントに配信してしまうリスクがあります。しかし、`zlib.output_compression = Off` の場合、PHP は圧縮出力を生成しないため、コンテンツのバリアントは 1 つしか存在しません。Nginx は、独自の gzip モジュールを使用してクライアントごとにオンザフライで圧縮します。キャッシュファイルは 1 つで、すべてのクライアントに正しく配信されます。

変更前 / 変更後
シナリオ URL ごとにキャッシュファイルを作成 実際の訪問者に対して NPP ウォームヒット リスク
`zlib.output_compression = On`、修正なし 2 (プライマリ + セカンダリ) ❌ ミス — 訪問者はセカンダリファイルを取得 RAM / ディスクの無駄遣い、NPP のプリロードが無効
`zlib.output_compression = Off` + `fastcgi_ignore_headers Vary` 1 ✅ ✅ ヒット — NPP ウォームエントリが配信される なし
📌 注: この問題は、Nginx のすべてのキャッシュタイプ (fastcgi_cache、proxy_cache、uwsgi_cache、scgi_cache) で発生します。設定に応じて、`fastcgi_ignore_headers Vary` / `proxy_ignore_headers Vary` / `uwsgi_ignore_headers Vary` を適用してください。