WordPressのサーバーキャッシュ設定｜NginxのFastCGIキャッシュとApacheでの選び方

サーバーキャッシュ（ページキャッシュ）は、WordPress が作った HTML をサーバー側に保存し、次に同じページが要求されたときに PHP とデータベースを通さずに返す仕組みです。ページを作る処理が省けるため、最初の1バイトが届くまでの時間（TTFB）が短くなり、アクセスが集中したときのサーバーの負荷も下がります。

この記事では、VPS などで Nginx と PHP-FPM を使っている場合の FastCGI キャッシュの設定を中心に説明し、Apache の場合の考え方を整理します。Nginx の設定項目は nginx.org の公式ドキュメント、更新時の削除はプラグイン Nginx Helper の配布ページとソースコードで、2026年11月時点で確認したものです。

先に決めておくこと

サーバーキャッシュで一番気をつけるのは、個人向けのページを保存して他人に返さないことです。次のページはキャッシュの対象から外します。

• ログイン中のユーザーへのページ（管理バーや個人向けの表示を含む）
• コメントを投稿した人向けのページ（名前やメールアドレスが入力欄に入る）
• パスワード保護された投稿
• 管理画面、wp-login.php、xmlrpc.php、REST API、フィード
• POST リクエスト、クエリ文字列の付いた URL
• WooCommerce などのカート・購入手続き・マイアカウント

もう1つは、記事を更新したときに保存済みの古い HTML を消す方法です。消す仕組みがないと、キャッシュの有効期限が切れるまで更新前の内容が表示されます。

Nginx の FastCGI キャッシュを設定する

以下は Ubuntu 24.04 の Nginx と PHP 8.3 の PHP-FPM の例です。ディストリビューションや PHP のバージョンによって、ソケットのパスや設定ファイルの場所が異なります。

キャッシュの保存場所を定義する

fastcgi_cache_path は http ブロックに書く必要があります。Ubuntu では /etc/nginx/conf.d/ 以下のファイルが http ブロックに読み込まれるので、ここに新しいファイルを作ります。

# /etc/nginx/conf.d/fastcgi-cache.conf
fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

保存先のディレクトリを作っておきます。

sudo mkdir -p /var/cache/nginx/wordpress
sudo chown www-data:www-data /var/cache/nginx/wordpress

キャッシュしない条件を決める

サイトの server ブロックに、キャッシュを使わない条件を書きます。$skip_cache が 1 になったリクエストは、キャッシュから返さず、保存もしません。

# /etc/nginx/sites-available/example.com の server ブロック内
set $skip_cache 0;

# POST とクエリ文字列付きの URL
if ($request_method = POST) {
    set $skip_cache 1;
}
if ($query_string != "") {
    set $skip_cache 1;
}

# 管理画面・ログイン・REST API・フィード・サイトマップなど
if ($request_uri ~* "/wp-admin/|/xmlrpc\.php|wp-.*\.php|/wp-json/|/feed/|index\.php|sitemap(_index)?\.xml") {
    set $skip_cache 1;
}

# WooCommerce のカート・購入手続き・マイアカウント（使っている場合）
if ($request_uri ~* "/cart/|/checkout/|/my-account/") {
    set $skip_cache 1;
}

# ログイン中・コメント投稿者・パスワード保護・カートに商品がある訪問者
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session_") {
    set $skip_cache 1;
}

WooCommerce のページのスラッグを変えている場合は、パスを実際のものに合わせます。

PHP の location でキャッシュを使う

同じ server ブロックの PHP の location に、キャッシュの指定を加えます。

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache_use_stale error timeout updating http_500 http_503;
    fastcgi_cache_background_update on;
    fastcgi_cache_lock on;

    add_header X-Cache-Status $upstream_cache_status;
}

Nginx は、応答に Set-Cookie が付いていたり、Cache-Control: no-cache などで保存を禁じられていたりする場合は、既定では保存しません。ログイン中のユーザーへの応答には WordPress が保存を禁じるヘッダーを付けますが、それに頼らず、上の $skip_cache で除外しておきます。

add_header を location に書くと、server ブロックに書いた add_header（セキュリティ用のヘッダーなど）はこの location では使われなくなります。必要なヘッダーは location にも書いてください。

設定を確認して反映する

sudo nginx -t
sudo systemctl reload nginx

nginx -t が「syntax is ok」と「test is successful」を表示してから反映します。

更新したときにキャッシュを消す

標準の Nginx には、キャッシュを URL ごとに消す機能がありません。WordPress では、プラグインの Nginx Helper（WordPress.org で配布）を使うのが一般的です。消し方は2つあります。

ここでは追加のモジュールが要らない「Delete local server cache files」を使います。Nginx Helper の説明では、この方法は levels=1:2 と fastcgi_cache_key "$scheme$request_method$host$request_uri" の組み合わせを前提にしています。上の設定はこの条件に合わせてあります。

まず wp-config.php に、キャッシュの保存先を書きます（/* That's all, stop editing! */ の行より上）。

define( 'RT_WP_NGINX_HELPER_CACHE_PATH', '/var/cache/nginx/wordpress' );

続いて、プラグインを設定します。

1. プラグインの新規追加で「Nginx Helper」を検索してインストールし、有効化します。
2. 「設定」→「Nginx Helper」で「Enable Purge」にチェックを入れ、キャッシュの種類に nginx の FastCGI キャッシュを選び、「Purge Method」で「Delete local server cache files」を選んで保存します。
3. どのタイミングで消すか（投稿の公開・更新時、コメントの承認時、トップページやアーカイブも消すかなど）を同じ画面で選びます。

PHP-FPM の実行ユーザーが、Nginx が作ったキャッシュのファイルを削除できる必要があります。Ubuntu の初期設定ではどちらも www-data なので、そのままで削除できます。

すべてのキャッシュを手動で消すときは、管理バーの「Purge Cache」を使うか、サーバーで次のコマンドを実行します。

sudo find /var/cache/nginx/wordpress -type f -delete

動作を確認する

ログアウトした状態の訪問者として、同じページを2回取得します。curl -I は HEAD リクエストを送り、キャッシュのキーに含まれるメソッドが GET と別になるため、GET で本文を取得してヘッダーだけを表示します。

curl -s -o /dev/null -D - https://example.com/ | grep -i x-cache-status
curl -s -o /dev/null -D - https://example.com/ | grep -i x-cache-status

1回目が MISS、2回目が HIT になれば保存と配信ができています。

何度取得しても MISS のままなら、curl -s -o /dev/null -D - URL で全部のヘッダーを表示し、Set-Cookie や Cache-Control: no-cache が付いていないかを確認します。セッションを使うプラグインなどが Cookie を発行していると保存されません。

ログインした状態のブラウザで BYPASS が表示されれば、除外の条件が働いています。

Apache の場合

Apache の mod_cache は、HTTP のキャッシュの規則に従って保存を判断する汎用的な仕組みで、WordPress のログイン Cookie を見てページを切り替える機能はありません。保存済みの匿名向けページが、ログイン中のユーザーに返されることもあります。設定例と注意点は「Apacheのキャッシュ設定（mod_cache）」で説明しています。

Apache で動いている WordPress では、ログイン状態やコメント投稿者の Cookie を理解して切り替えるページキャッシュプラグインのほうが扱いやすいのが実情です。LiteSpeed Web Server を使うレンタルサーバーなら、サーバーのキャッシュと連携する LiteSpeed Cache を使えます。プラグインの選び方は「WordPressのキャッシュプラグインを比較して選ぶ方法」を参考にしてください。

WP_CACHE とオブジェクトキャッシュについて

wp-config.php の define( 'WP_CACHE', true ); は、wp-content/advanced-cache.php を読み込むための設定で、WP Super Cache などのページキャッシュプラグインが使います。Nginx の FastCGI キャッシュは WordPress の外で動くため、この設定は必要ありません。

データベースへの問い合わせ結果を保存するオブジェクトキャッシュは、ページキャッシュとは別の仕組みです。キャッシュから外したログイン中のページや管理画面も速くしたい場合は、Redis などのオブジェクトキャッシュを組み合わせます。設定は「WordPressのオブジェクトキャッシュをRedisで高速化する方法」で説明しています。

注意点

• キャッシュの設定を変えたあとは、ログアウトした状態とログインした状態の両方で確認してください。ログイン中のページがキャッシュから返されると、管理バーや個人の情報が他人に表示されるおそれがあります。
• 会員制のページや、訪問者ごとに内容が変わるページがある場合は、そのページのパスや Cookie も除外の条件に加えます。
• fastcgi_cache_valid の時間を長くすると、更新時の削除がうまく動かなかったときに古い内容が長く残ります。最初は短めにして、更新時に消えることを確かめてから延ばします。