Nginxのopen_file_cacheの設定方法｜各パラメータの意味と注意点

open_file_cache は、Nginx がファイルを返すときに行う「ファイルを開く」「存在や権限を調べる」といった処理の結果を覚えておき、同じファイルへの次のリクエストで使い回す機能です。静的ファイルを多く返すサイトで、ファイルシステムへの問い合わせを減らせます。

この記事のディレクティブの説明は nginx.org の公式ドキュメント（ngx_http_core_module）で2026年10月時点の内容を確認し、動作は nginx 1.30 の検証環境で確かめています。

open_file_cache が覚えるもの

公式ドキュメントでは、次の3つをキャッシュできると説明されています。

• 開いたファイルの記述子（ファイルディスクリプター）、ファイルのサイズと更新日時
• ディレクトリが存在するかどうか
• 「ファイルが見つからない」「読み取り権限がない」といった、ファイルを探したときのエラー（open_file_cache_errors on のときだけ）

ファイルの中身そのものを保存する機能ではありません。中身の読み込みには OS のページキャッシュが使われます。また、キャッシュは Nginx のワーカープロセスごとに持ち、ワーカー間では共有されません。

既定値は open_file_cache off; で、何も書かなければ使われません。

設定例

http ブロック（または server・location）に書きます。Debian / Ubuntu の場合は /etc/nginx/nginx.conf の http { … } の中、または /etc/nginx/conf.d/ に置いた設定ファイルに書くと http ブロックに読み込まれます。

http {
    # 最大1万件、60秒アクセスがなければ削除
    open_file_cache          max=10000 inactive=60s;
    # 60秒ごとにキャッシュの内容がまだ正しいか確かめる
    open_file_cache_valid    60s;
    # inactive の間に2回以上使われたファイルだけ記述子を開いたまま保持
    open_file_cache_min_uses 2;
    # 「ファイルが無い」などのエラーもキャッシュする
    open_file_cache_errors   on;
}

/etc/nginx/conf.d/ に置くファイルは、すでに http ブロックの中に読み込まれるため、http { } で囲まずに4行だけを書きます。

各ディレクティブの意味

open_file_cache_errors はエラーを記録・出力する機能ではなく、「ファイルが無かった」という結果を覚えておく機能です。min_uses は「何回読まれたら削除するか」ではなく、「何回以上使われたら残すか」の下限です。

設定を反映する

# 構文を確認する
sudo nginx -t

# 再読み込みで反映する（再起動は不要）
sudo systemctl reload nginx

# 実際に読み込まれた値を確認する
sudo nginx -T 2>/dev/null | grep open_file_cache

効いているかを確かめる

open_file_cache の中身を表示するコマンドやファイルはありません。代わりに、ワーカープロセスが開いているファイルを見ると、記述子が保持されていることを確かめられます。

# ワーカープロセスのプロセスIDを調べる
pgrep -f 'nginx: worker'

# そのプロセスが開いているファイルを見る（12345 は上で調べたID）
sudo ls -l /proc/12345/fd | grep /var/www

上の設定例（min_uses 2）で検証したところ、同じファイルに2回アクセスした後に、そのファイルの記述子がワーカーに開いたまま残りました。1回だけのアクセスでは残りませんでした。ワーカーが複数ある場合は、リクエストがどのワーカーに届くかで結果が変わります。

速度への効果は、ファイルの数・アクセスの偏り・ストレージの速さによって変わります。導入する場合は、負荷試験ツールなどで設定の前後を比べてから判断してください。

注意点

ファイルの変更がすぐに反映されないことがある

キャッシュした情報は open_file_cache_valid の時間ごとに確認し直されます。そのため、ファイルを置き換えたり削除したりしてから、この時間が過ぎるまでは前の状態で応答することがあります。

特に open_file_cache_errors on のときは、「ファイルが無い」という結果も覚えます。検証環境では、存在しないファイルに一度アクセスした後でそのファイルを作っても、確認し直すまでの間は 404 が返り続けました。デプロイ直後に新しいファイルを公開する運用では、open_file_cache_valid を短めにするか、反映時に sudo systemctl reload nginx を実行してください。

開いたままのファイル数が増える

記述子を開いたまま保持するため、ワーカーごとに最大で max に近い数のファイルを開いたままにすることがあります。ワーカーが開けるファイル数の上限が足りないと、ログに Too many open files が出ます。上限は nginx.conf の worker_rlimit_nofile で設定できます。

# nginx.conf の最上位（http ブロックの外）に書く
worker_rlimit_nofile 65535;

WordPress での効果

WordPress のページそのもの（PHP の実行結果）は PHP-FPM が作るため、open_file_cache の対象ではありません。効果があるのは、画像・CSS・JavaScript などの静的ファイルを Nginx が直接返す部分と、try_files によるファイルの存在確認です。ページの表示速度を上げたい場合は、ページのキャッシュ（WordPressでNginxのプロキシキャッシュを設定する方法）なども検討してください。

まとめ

• open_file_cache は、ファイルの記述子・サイズ・更新日時、ディレクトリの有無、検索エラーをワーカーごとに覚える機能で、既定では無効。
• min_uses は記述子を残すための最低使用回数、open_file_cache_errors はエラー結果をキャッシュする設定。
• ファイルの変更は open_file_cache_valid の時間だけ遅れて反映されることがある。
• 開いたままのファイル数が増えるため、worker_rlimit_nofile と合わせて設定を見直す。