【徹底解説】nginx try_files とは？設定方法と活用例

はい、承知いたしました。Nginxのtry_filesディレクティブに関する徹底解説記事を約5000語で記述し、内容を直接表示します。

【徹底解説】Nginx try_files とは？設定方法と活用例

WebサイトやWebアプリケーションを公開する上で、Webサーバーは重要な役割を果たします。静的なHTMLファイル、CSSファイル、JavaScriptファイル、画像ファイルなどをクライアントのブラウザに効率的に配信したり、PHPやPythonなどのサーバーサイド言語で記述されたアプリケーションの実行結果を返したりします。数あるWebサーバーの中でも、その高いパフォーマンスと柔軟性から広く利用されているのがNginxです。

Nginxを設定する上で、ファイルの配信やリクエストのルーティングを制御するための様々なディレクティブが存在しますが、その中でも特に頻繁に利用され、Webアプリケーションの設計に大きな影響を与えるのがtry_filesディレクティブです。

このtry_filesディレクティブは、指定されたファイルやディレクトリが存在するかを順番に確認し、最初に見つかったものを返す、あるいは最後に指定された処理を実行するという強力な機能を提供します。静的ファイルの配信から、複雑なフレームワークのルーティング、シングルページアプリケーション（SPA）の制御、カスタムエラーページの表示に至るまで、その活用範囲は非常に広いです。

しかし、その柔軟性ゆえに、設定方法や挙動を正確に理解していないと、意図しない動作を招いたり、パフォーマンスの問題を引き起こしたりする可能性もあります。

本記事では、このNginxのtry_filesディレクティブについて、その基本的な概念から詳細な設定方法、多様な活用例、そして利用上の注意点までを、初心者にも分かりやすく、かつ網羅的に徹底解説します。この記事を読み終える頃には、try_filesを自信を持って使いこなし、より効率的で堅牢なNginx設定を構築できるようになるでしょう。

1. NginxとWebサーバーの基本

try_filesについて深く理解するために、まずはNginxとWebサーバーの基本的な役割をおさらいしましょう。

Webサーバーの主な役割は、クライアント（通常はWebブラウザ）からのリクエストを受け付け、それに対応するリソース（ファイルや動的な応答）を返すことです。

静的ファイルの配信: クライアントがHTML、CSS、JavaScript、画像などのファイルを要求した場合、Webサーバーはファイルシステム上の該当ファイルを探し、その内容をクライアントに送信します。
動的なコンテンツの生成: クライアントがPHPやPythonなどのプログラムの実行を要求した場合、Webサーバーはアプリケーションサーバー（例: PHP-FPM）に処理を依頼し、その結果を受け取ってクライアントに送信します。
リクエストのルーティング: どのURLにどのリソースを割り当てるか、どのような処理を実行するか（例: リダイレクト、認証、キャッシュ）、といったリクエストの振り分けを行います。

Nginxは、これらの役割を非常に効率的にこなすことに特化したイベント駆動型アーキテクチャを採用しており、大量の同時接続を処理することに優れています。特に静的ファイルの配信においては、そのパフォーマンスは特筆すべきものです。

クライアントからのリクエストURI（例えば /about/index.html や /products/123 など）を受け取ったNginxは、設定ファイル（nginx.confなど）に記述されたルールに従って、どのファイルを探すべきか、どのプログラムを実行すべきか、あるいはどのような応答を返すかを決定します。

ここで問題になるのが、「要求されたリソースが見つからなかった場合、どのように振る舞うべきか？」という点です。例えば /about/ というURLにアクセスがあった際に、/path/to/website/about/index.html というファイルが存在すればそれを返せば良いですが、存在しない場合はどうでしょうか？あるいは /legacy/old-page.html という古いURLへのリクエストがあった際に、新しい /new-page/ にリダイレクトしたい場合は？

このような、「あるリソースが存在しない場合に、代替となるリソースを探したり、別の処理にフォールバックしたりする」というニーズに応えるために設計されたのが、try_filesディレクティブなのです。

2. `try_files`とは何か？基本概念

try_filesディレクティブは、NginxがリクエストされたURIに対応するファイルを順次探し、最初に見つかったものを使用するためのメカニズムです。もしリスト内のすべてのファイルやディレクトリが見つからなかった場合、最後に指定されたフォールバック処理を実行します。

簡単に言えば、try_filesは「これらを順番に試してみて、最初に見つかったものを使ってね。もし何も見つからなかったら、代わりにこれをやってね。」という指示をNginxに与えるディレクティブです。

この「試す」対象は、ファイルパスであったり、ディレクトリパスであったりします。そして、「何も見つからなかった場合に代わりに行う処理」は、別のURIへの内部的なリダイレクトであったり、特定のHTTPステータスコードを返すことであったりします。

try_filesの主な目的は以下の通りです。

静的ファイルのフォールバック: 特定のファイルが存在しない場合に、代替のファイル（例: デフォルト画像、メンテナンスページ、404ページなど）を提供する。
ディレクトリインデックスの制御: /about/ のようなディレクトリへのリクエストが来た際に、/about/index.html のようなデフォルトのファイルを探す（これはindexディレクティブと連携します）。
フロントコントローラーパターンの実装: /products/123 のようなクリーンURLへのリクエストを、内部的には /index.php?uri=/products/123 のような単一のPHPスクリプトに振り分ける（モダンなWebフレームワークでよく使われるパターン）。
シングルページアプリケーション（SPA）のルーティング: SPAではクライアントサイドでルーティングを行うため、存在しないファイルへのリクエスト（例: /users/profile）が来た場合でも、必ずアプリケーションのエントリーポイントである /index.html を返したい場合に利用する。

これらの機能を、シンプルな記述で、かつ効率的に実現できるのがtry_filesの強みです。

3. `try_files`の構文と基本動作

try_filesディレクティブの構文は以下の通りです。

nginx try_files file ... uri;

または

nginx try_files file ... =code;

file ...: Nginxが順番に存在確認を行うファイルパスまたはディレクトリパスをスペース区切りで複数指定します。
uri: file ... の中に指定されたどのファイル/ディレクトリも存在しなかった場合に、最後にフォールバックとして内部リダイレクトする先のURIを指定します。
=code: file ... の中に指定されたどのファイル/ディレクトリも存在しなかった場合に、最後にフォールバックとして指定されたHTTPステータスコード（例: =404）を返します。

基本的な動作シーケンス:

Nginxは、try_filesディレクティブに左から順番に指定されたパス（file）を評価します。
各パスについて、Nginxはそれがファイルシステム上に存在するかどうかを確認します。この確認は、設定されているrootまたはaliasディレクティブで指定されたディレクトリを基点として行われます。
ファイルとして存在する場合: 最初に見つかったファイルの内容をクライアントに返します。これ以降のパスは評価されません。
ディレクトリとして存在する場合: パスがディレクトリとして存在する場合、Nginxはそのディレクトリに対して内部的なリクエストを行います。この際、そのロケーションに設定されているindexディレクティブが評価され、指定されたデフォルトファイル（例: index.html）を探します。もしindexディレクティブで指定されたファイルが見つかれば、そのファイルの内容を返します。何も見つからなければ、次のtry_files引数の評価に進みます。ただし、最後の引数としてディレクトリを指定することは推奨されていません。 最後の引数はURIとして扱われるため、try_files $uri/ のように指定すると、それは/で終わるURIへの内部リダイレクトとして解釈され、その後の処理（indexディレクティブの評価など）はリダイレクト先のロケーションブロックで行われることになります。
リスト内のすべてのfileパスが見つからなかった場合、Nginxは最後の引数を評価します。
最後の引数がURIの場合: Nginxは指定されたURIに対して内部的にリダイレクトします。これはクライアントへのHTTPリダイレクト（ステータスコード3xx）とは異なり、Nginx内部でリクエストURIを書き換えて、最初からその新しいURIに対する処理を開始するものです。通常、このURIは別のlocationブロックにマッチするように指定され、そこでファイル配信やプロキシ処理などが実行されます。例えば /index.php や /index.html のようなパスがよく使われます。
最後の引数が =code の場合: Nginxは指定されたHTTPステータスコードをクライアントに返します。これにより、カスタムエラーページを表示したり、意図的に404 Not Foundや403 Forbiddenなどの応答を返したりすることができます。例えば =404 と指定すると、Nginxは404エラーを発生させます。このエラーは、設定ファイルでerror_pageディレクティブを使って捕捉し、カスタムエラーページを表示させることができます。

パスの指定について:

try_filesで指定するパスは、通常、現在のlocationブロックや親のserverブロックで定義されているrootまたはaliasディレクティブを基点とした相対パスとして解釈されます。

例えば、root /var/www/html; と設定されている状態で try_files $uri $uri/ =404; と記述すると、Nginxは以下の順番でファイルを探します。

/var/www/html/$uri というファイルが存在するか？
/var/www/html/$uri/ というディレクトリが存在するか？（ディレクトリの場合、indexディレクティブを評価しようとします）
上記が見つからなければ、404 Not Foundを返します。

特別な変数 $uri:

try_filesの中で最も頻繁に使われる変数の一つが $uri です。これは、ホスト名やクエリストリングを含まない、正規化された（パーセントエンコードされていない）現在のリクエストURIのパス部分を表します。例えば、/path/to/resource?query=string というリクエストに対しては、$uri は /path/to/resource となります。

$request_uri という変数もありますが、こちらはクエリストリングを含む生のURIを表すため、ファイルパスの存在確認には通常 $uri を使用します。try_files $request_uri のように指定すると、クエリストリングを含んだパスでファイルを探そうとしてしまい、期待通りに動作しないことがほとんどです。

内部リダイレクト vs 外部リダイレクト:

try_filesの最後の引数にURIを指定した場合、Nginxは内部リダイレクトを実行します。これは、クライアントにHTTPリダイレクト応答（ステータスコード301や302）を返すのではなく、Nginx自身が内部でリクエストURIを書き換えて、新しいURIに対する処理を最初からやり直すものです。クライアントはリダイレクトされたことに気づきません。

一方、returnディレクティブやrewrite ... last;以外のrewriteディレクティブでHTTPステータスコード3xxを指定すると、これは外部リダイレクトとなり、クライアントにリダイレクト先のURLを通知し、クライアント自身が新しいURLに再度リクエストを送信します。

try_filesの内部リダイレクトは、特にモダンなWebフレームワークのフロントコントローラーパターンや、SPAのルーティングにおいて非常に重要になります。

4. `try_files`の設定場所

try_filesディレクティブは、以下のコンテキストで使用できます。

server ブロック
location ブロック
if ブロック

最も一般的な使い方は、特定のパスに対する処理を定義するlocationブロック内です。

“`nginx
server {
listen 80;
server_name example.com;
root /var/www/html; # root ディレクティブでドキュメントルートを指定

location / {
    # ルート以下の全てのリクエストに対して try_files を適用
    try_files $uri $uri/ /index.html;
}

location /docs/ {
    # /docs/ 以下のリクエストに対して try_files を適用
    # root が /var/www/html なので、試されるパスは /var/www/html/docs/$uri ... となる
    try_files $uri $uri/ /docs/index.html =404;
}

location ~ \.php$ {
    # .php ファイルへのリクエストは try_files を使わず、
    # FastCGIなどでPHPインタプリタに渡すのが一般的
    # try_files を使うことも可能だが、通常は不要
    # ... php-fpm settings ...
}

# if ブロック内でも使えるが、if ディレクティブ自体が非推奨とされる場合もある
# また、if 内での try_files の挙動は複雑になることがあるため注意が必要
# if (-f /tmp/maintenance) {
#     try_files /maintenance.html =503;
# }

}
“`

通常はlocationブロック内で、そのlocationにマッチしたリクエストURIに対してどのようにファイルを試すかを定義します。serverブロックで定義すると、そのサーバー内の全てのlocationブロックにtry_filesが設定されていない場合に継承されますが、個別のlocationで上書きするのが一般的です。ifブロック内での使用は可能ですが、ifディレクティブの一般的な注意点（特に複雑な条件での予期しない挙動）が伴うため、注意が必要です。

5. `try_files`の活用例

ここからは、try_filesディレクティブの具体的な活用例をいくつか見ていきましょう。それぞれの例がどのようなシナリオで役立つのか、コードと併せて詳細に解説します。

例 1: 基本的な静的ファイルの配信とフォールバック

最もシンプルで一般的な使い方は、リクエストされたURIに対応するファイルを直接探し、見つからなければディレクトリとして探し、それでも見つからなければ特定のファイルにフォールバックするというパターンです。

“`nginx
server {
listen 80;
server_name example.com;
root /var/www/html;

location / {
    # リクエストURI ($uri) に対応するファイルを試す
    # もしファイルが存在しなければ、リクエストURIに '/' を追加してディレクトリとして試す ($uri/)
    #   ディレクトリとして存在する場合、root + $uri/ + index ディレクティブで指定されたファイルを探す (例: index.html)
    # 上記すべてが見つからなければ、内部的に /index.html にリダイレクトする
    try_files $uri $uri/ /index.html;
}

}
“`

この設定の動作は以下のようになります。

/about.html へのリクエスト: Nginxは /var/www/html/about.html ファイルを探します。見つかればそれを返します。
/css/style.css へのリクエスト: Nginxは /var/www/html/css/style.css ファイルを探します。見つかればそれを返します。
/blog/ へのリクエスト:
1. Nginxは /var/www/html/blog というファイルを探しますが、通常ディレクトリなので見つかりません。
2. 次に /var/www/html/blog/ というディレクトリを探します。見つかりました。
3. /var/www/html/blog/ ディレクトリが見つかったため、indexディレクティブ（デフォルトでは index.html や index.htm）で指定されたファイル、例えば /var/www/html/blog/index.html を探します。見つかればそれを返します。
4. もし /var/www/html/blog/index.html も見つからなければ、次のtry_files引数の評価に進みます。
存在しない /non-existent-page.html へのリクエスト:
1. Nginxは /var/www/html/non-existent-page.html ファイルを探しますが、見つかりません。
2. 次に /var/www/html/non-existent-page.html/ ディレクトリを探しますが、見つかりません。
3. リスト内のすべてのパスが見つからなかったため、最後の引数 /index.html への内部リダイレクトを実行します。Nginxは /index.html へのリクエストとして処理をやり直し、最終的に /var/www/html/index.html ファイルを返します。

この例は、静的なWebサイトで、ルート以下の /index.html をデフォルトページとして利用する場合に非常に有効です。存在しないパスへのアクセスに対しても、常に/index.htmlを表示させるといった、SPAのような挙動の一部も実現できます。

例 2: カスタム404エラーページ

存在しないファイルへのリクエストがあった場合に、デフォルトの404エラーページではなく、独自のカスタム404ページを表示したい場合は、try_filesとerror_pageディレクティブを組み合わせて使用します。

“`nginx
server {
listen 80;
server_name example.com;
root /var/www/html;

# 404エラーが発生した場合に /404.html を表示するよう設定
error_page 404 /404.html;

location / {
    # リクエストURIに対応するファイルまたはディレクトリを探す
    # 何も見つからなければ、=404 で404エラーを発生させる
    try_files $uri $uri/ =404;
}

location = /404.html {
    # 404エラー発生時に内部リダイレクトされる /404.html の処理
    # このlocationはtry_filesの内部リダイレクト先として機能するため、
    # ここでtry_filesを使う必要はない（使っても良いが通常は不要）
    # root ディレクティブに基づき、/var/www/html/404.html が配信される
    internal; # このlocationには外部からの直接アクセスを許可しない
}

}
“`

この設定では、まずerror_page 404 /404.html;で、404エラーが発生したら/404.htmlというURIに内部リダイレクトするように定義しています。

location /ブロックのtry_files $uri $uri/ =404;は、リクエストされたURIに対応するファイルやディレクトリが見つからなかった場合に、明示的に404エラーを発生させます。この404エラーは、error_pageディレクティブの設定によって捕捉され、Nginxは/404.htmlへの内部リダイレクトを実行します。

最後のlocation = /404.htmlブロックは、その内部リダイレクトされた/404.htmlを処理します。internal;ディレクティブは、このロケーションへの外部からの直接アクセス（例: ブラウザでhttp://example.com/404.htmlと直接入力してアクセスすること）を防ぎ、内部リダイレクトの場合のみ処理を許可します。これにより、カスタムエラーページが意図しない方法でアクセスされるのを防ぐことができます。

例 3: メンテナンスページの表示

サイトメンテナンス中に、全てのアクセスをメンテナンスページにリダイレクトしたい場合があります。ファイルシステム上に特定のフラグファイル（例: .maintenance）が存在するかどうかをチェックし、存在すればメンテナンスページを表示する、というような制御をtry_filesとifを組み合わせて行うことができます。ただし、ifディレクティブは複雑な条件分岐に不向きな場合があるため、より堅牢な方法はLuaモジュールなどを使うことですが、シンプルなケースではtry_filesとifで実現可能です。

“`nginx
server {
listen 80;
server_name example.com;
root /var/www/html;

# ルートディレクトリに .maintenance ファイルが存在するかチェック
# 存在する場合、$maintenance_mode は true (ここでは '' ではない値) になる
if (-f $document_root/.maintenance) {
    set $maintenance_mode true;
}

# $maintenance_mode が true の場合
if ($maintenance_mode = true) {
    # try_files を使ってメンテナンスページが存在するか確認
    # 存在すればそれを表示し、なければ 503 Service Unavailable を返す
    try_files /maintenance.html =503;
}

# メンテナンスモードでない場合、通常のファイル配信
location / {
    try_files $uri $uri/ =404; # 通常の404処理など
}

# ... 他のlocationブロック ...

}
“`

この例では、まずif (-f $document_root/.maintenance)でドキュメントルート直下の.maintenanceファイルが存在するか確認し、存在する場合にカスタム変数$maintenance_modeをtrueに設定します。

次に、別のif ($maintenance_mode = true)ブロックで、$maintenance_modeがtrueの場合のみ、try_files /maintenance.html =503;を実行します。これは、/maintenance.htmlファイルが存在すればそれを返し、存在しなければ503 Service Unavailableエラーを返すという意味です。

この設定のポイントは、try_filesディレクティブは内部リダイレクトを行うため、メンテナンスページ自体（/maintenance.html）へのアクセスも、このifブロックのtry_filesによって捕捉・処理される必要があるという点です。また、ifブロックの評価順序や、$document_rootなどの変数の利用には注意が必要です。より複雑なメンテナンスモードの実装には、IPアドレスによる除外などが必要になる場合があり、その場合はLuaなどのNginxモジュールを利用する方が管理しやすくなります。

例 4: Webフレームワークのフロントコントローラーパターン

Laravel, Symfony, Zend Framework, CakePHPなどのモダンなPHPフレームワークや、Ruby on Rails, Djangoなどのフレームワークの多くは、「フロントコントローラーパターン」を採用しています。これは、全てのHTTPリクエストを単一のファイル（通常は index.php）に集約し、そのファイル内でリクエストのルーティングや処理を行うという設計です。

Nginxでこのパターンを実現するために、try_filesが非常に効果的に利用されます。リクエストされたURIに対応する静的ファイル（CSS、JS、画像など）が存在する場合はそれを直接配信し、存在しない場合は全てを index.php に振り分ける、という設定を行います。

“`nginx
server {
listen 80;
server_name example.com;
root /var/www/html/public; # フレームワークの公開ディレクトリを指定

location / {
    # リクエストURI ($uri) に対応するファイルが存在するか試す
    # もしファイルが存在しなければ、リクエストURIに '/' を追加してディレクトリとして試す ($uri/)
    # 上記すべてが見つからなければ、内部的に /index.php にリダイレクトする
    # ($args は元のリクエストのクエリストリングを引き渡すための変数)
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    # .php ファイルへのリクエストは FastCGI (php-fpm) に渡す
    # ここに到達するリクエストは、try_files で /index.php へ内部リダイレクトされたもの、
    # または直接 .php ファイルを指定されたもの（後者は非推奨だが設定上は可能）
    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # 環境に合わせて変更
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params; # 基本的なFastCGIパラメータを読み込む
    fastcgi_param PATH_INFO $fastcgi_path_info; # PATH_INFO を渡す（フレームワークによっては必要）
    fastcgi_param REQUEST_URI $request_uri; # オリジナルのリクエストURIを渡す（フレームワークによっては必要）
}

# 隠しファイル（.envなど）やフレームワークの設定ファイルへのアクセスを禁止
location ~ /\. {
    deny all;
}

}
“`

この設定の核となるのは location / ブロック内の try_files $uri $uri/ /index.php?$args; です。

$uri: Nginxはまず root + $uri で指定されるパスにファイルが存在するか試します。例えば、/css/style.css へのリクエストなら /var/www/html/public/css/style.css を探します。見つかればそれを直接返します（静的ファイルの配信）。
$uri/: $uri でファイルが見つからなかった場合、Nginxは次に root + $uri/ で指定されるパスにディレクトリが存在するか試します。例えば、/blog/ へのリクエストなら /var/www/html/public/blog/ を探します。ディレクトリが見つかった場合、indexディレクティブに基づいてデフォルトファイル（例: index.html）を探します。見つかればそれを返します。
/index.php?$args: $uri でファイルも $uri/ でディレクトリ（およびその中のインデックスファイル）も見つからなかった場合、Nginxは最後の引数 /index.php?$args へ内部リダイレクトします。例えば、/products/123 というURIで静的ファイルが存在しなかった場合、リクエストは /index.php へ内部リダイレクトされ、元のクエリストリングがあればそれが引き継がれます（?$argsの部分）。

内部リダイレクトされた /index.php へのリクエストは、次の location ~ \.php$ ブロックにマッチし、そこでFastCGIを通じてPHP-FPMに渡されます。PHPスクリプト（index.php）は、元のリクエストURI（通常は $_SERVER['REQUEST_URI'] や $request_uri を利用して取得可能）を見て、どのコントローラーやルートを実行すべきかを判断し、動的な応答を生成します。

このように、try_filesを使うことで、静的ファイルの高速配信と、存在しないパスに対する動的なルーティングをシームレスに実現できます。

例 5: シングルページアプリケーション (SPA)

React, Vue.js, Angularなどのフレームワークで構築されたSPAでは、通常、アプリケーションの全てのリソース（HTML, CSS, JS）は最初に /index.html にアクセスすることでロードされ、その後のナビゲーションはJavaScriptでクライアントサイドで行われます（クライアントサイドルーティング）。

この場合、ブラウザのリロードや、外部からの直接リンクで /users/profile のようなSPA内の特定パスにアクセスされた際に、Nginxは /users/profile という名前のファイルを探しに行ってしまいます。しかし、/users/profile に対応する静的ファイルは通常存在しません。このとき、静的ファイルが見つからなかった場合に常に /index.html を返すように設定することで、クライアントサイドのルーターがURLを適切に処理できるようになります。

“`nginx
server {
listen 80;
server_name spa.example.com;
root /var/www/spa/dist; # SPAのビルド済みファイルが配置されているディレクトリ

location / {
    # リクエストURI ($uri) に対応するファイルが存在するか試す (例: /css/style.css, /js/app.js)
    # もしファイルが存在しなければ、リクエストURIに '/' を追加してディレクトリとして試す ($uri/)
    # 上記すべてが見つからなければ、内部的に /index.html にリダイレクトする
    try_files $uri $uri/ /index.html;
}

# APIエンドポイントなど、SPAのindex.htmlにフォールバックさせたくないパスがある場合は、
# try_files より前に別の location ブロックで処理を定義する
location /api/ {
    proxy_pass http://backend_service; # 例: バックエンドAPIへのプロキシ
}

# 静的ファイルの種類によっては適切な MIME タイプ設定が必要
# include mime.types; # nginx.conf にて global で設定されていることが多い

}
“`

この設定では、/ ロケーションで、まずリクエストURIに対応する静的ファイル（/css/style.css や /images/logo.png など）を探します。それらが見つかれば直接配信します。静的ファイルが見つからず、ディレクトリでもない場合（例えば /users/profile のようなSPA内のパス）、try_filesは /index.html へ内部リダイレクトします。これにより、ブラウザは常にSPAのエントリーポイントである /index.html を受け取り、クライアントサイドのJavaScriptがURLを見て正しいビューを表示する責任を負います。

location /api/ のように、SPAとは別にバックエンドAPIなどがある場合は、try_filesを含む / ロケーションよりも前に、それらのパスに対するlocationブロックを定義することが重要です。Nginxはlocationブロックを定義順やマッチングの優先度に従って評価するため、より具体的なパス（/api/）のロケーションが先に評価され、SPAのフォールバック処理が適用されるのを防ぎます。

例 6: キャッシュ Busting 対応（応用）

Webサイトのパフォーマンス最適化手法の一つとして、静的ファイル（CSS, JS, 画像など）のファイル名にバージョン情報やハッシュ値を含めることで、ブラウザやCDNのキャッシュを効率的に制御する方法があります（例: /css/style.12345.css）。ビルドプロセスでこのようなファイル名を生成した場合、元のファイル名（/css/style.css）でアクセスがあった際に、バージョン付きのファイル名に内部的に解決したい場合があります。

try_filesはファイル名のパターンマッチングは直接行えませんが、特定のディレクトリ内のファイルを順番に試す、といった形で部分的に活用したり、rewriteと組み合わせて使用したりすることが考えられます。しかし、ファイル名のハッシュ値を動的に推測するのは難しいため、より一般的なパターンとしては、バージョン付きファイル名を直接参照するようにHTMLなどを生成するか、特定のディレクトリ構造を試す方法が考えられます。

ここでは、try_filesをシンプルに使い、バージョン付きファイルが存在するかどうかを確認する例を示しますが、ファイル名からバージョンを取り除く、といった変換はtry_files単体では困難であり、より高度なケースではrewriteディレクティブやLuaモジュールの利用が一般的です。

“`nginx
server {
listen 80;
server_name static.example.com;
root /var/www/static;

# 例: /css/style.css?v=123456 のようなリクエストが来た場合に、
# クエリストリングの 'v' パラメータを使ってファイルを探す（複雑になるので$uriのみで考える）

location ~* \.(css|js|png|jpg|jpeg|gif)$ {
    # 例: /static/css/style.css へのリクエストに対して
    # まず /var/www/static/css/style.css を試す
    # 見つからなければ、バージョン付きファイル名（例: style.12345.css）を探すのは try_files の範疇を超える
    # try_files はあくまで指定されたパスそのものの存在を確認する

    # もし try_files を使うなら、考えられるファイル名を列挙するか、特定のディレクトリ構成を試すことになる
    # 例: try_files $uri /path/to/versioned/$uri =404; のように、バージョン管理された別ディレクトリを試す

    # より現実的なキャッシュ busting のための try_files 利用法としては、
    # バージョン付きファイル名でアクセスされた際に、元のファイル名でアクセスした場合のフォールバックとして使う、
    # あるいは、古いファイル名でアクセスがあった際に、新しいファイル名へのリダイレクトを試す、などが考えられる。

    # 例: /old-image.jpg でアクセスがあった際に、/new-images/old-image.jpg を試す
    # try_files $uri /new-images/$uri =404;

    # 別の try_files とは少し異なるアプローチだが、リライトと組み合わせる例として
    # リクエストURIが特定のパターンにマッチした場合に、ファイル名の特定の箇所を書き換えて存在を確認する
    # 例: /static/style-12345.css -> /static/style.css を探す
    # rewrite ^/static/(.*)-\w+\.(css|js)$ /static/$1.$2 break; # これは try_files の前で行われる
    # try_files $uri =404; # 書き換えられた $uri でファイルを探す

    # try_files 単体でのキャッシュ busting は限定的。
    # 基本的にはファイルパスの存在確認とフォールバックに特化した機能であるため、
    # ファイル名パターンに基づく複雑な処理には rewrite など他のディレクティブとの連携が必要。

    # シンプルに、$uri と $uri/ を試して、静的ファイルが見つからなければ 404
    try_files $uri $uri/ =404;

    # 静的ファイルには適切な Cache-Control ヘッダーを設定
    expires max;
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}

}
`` この例は、try_files単体で複雑なキャッシュ Busting ファイル名の解決を行うのが難しいことを示しています。try_filesはあくまで指定された文字列のパスがファイルシステム上に存在するかを確認するものであり、パターンマッチングや文字列操作機能は持ちません。バージョン付きファイル名に対応するには、通常、rewriteディレクティブを使ってリクエストURIを書き換えてからtry_filesで存在を確認するか、アプリケーション側でバージョン付きファイル名へのリンクを生成するといった対応が必要です。上記の例では、try_files`を使った簡単なフォールバックと、リライトとの連携の可能性に触れています。

例 7: ディレクトリインデックスの制御と index ディレクティブ

try_files $uri $uri/ ... のように $uri/ を指定した場合、Nginxはそれをディレクトリとして解釈しようとします。ディレクトリとして存在する場合、Nginxはそのディレクトリ内でindexディレクティブで指定されたファイル（デフォルトでは index.html, index.htm）を探します。

“`nginx
server {
listen 80;
server_name directory.example.com;
root /var/www/site;

# /var/www/site/about/ ディレクトリが存在し、
# その中に index.php または index.html があれば、それを優先して返す
index index.php index.html;

location / {
    # リクエストURI ($uri) に対応するファイルを試す
    # ファイルが見つからなければ、ディレクトリとして試す ($uri/)
    #   ディレクトリとして存在する場合、上記の index ディレクティブが評価され、
    #   index.php -> index.html の順で探される
    # それでも何も見つからなければ、404エラーを返す
    try_files $uri $uri/ =404;
}

}
“`

この設定では、/about/ へのリクエストがあった場合、try_files $uri $uri/ =404; の $uri/ 部分が /about/ ディレクトリとして評価されます。Nginxは /var/www/site/about/ ディレクトリが存在することを確認すると、次にindexディレクティブに従って /var/www/site/about/index.php を探し、見つからなければ /var/www/site/about/index.html を探します。最初に見つかったファイルが返されます。

このように、try_filesの $uri/ は、indexディレクティブと連携してディレクトリインデックスファイルを提供する際に機能します。try_filesの最後の引数に/で終わるURI（例: / や /index.html）を指定する場合、それはディレクトリではなくURIへの内部リダイレクトとして扱われ、リダイレクト先のlocationブロックで改めて処理が開始されるため、そのリダイレクト先のlocationブロックに適切なindexディレクティブやtry_files設定が必要です。

例 8: try_filesとrewriteの比較と連携

try_filesとrewriteはどちらもURIの書き換えやリクエストのルーティングに関わるディレクティブですが、その目的と動作は異なります。

try_files: 指定されたパスの存在を確認し、最初に見つかったものを返すか、フォールバックとしてURIまたはステータスコードを返す。主にファイルシステム上のリソース存在チェックに基づいたルーティングやフォールバックに使用される。
rewrite: 正規表現を使ってリクエストURIをパターンマッチングし、URIを書き換える。書き換えられたURIで内部リダイレクト（lastフラグ）または外部リダイレクト（redirect, permanentフラグ）を実行する。主にURIの構造変更やリダイレクトに使用される。

多くのケースでは、ファイルが存在するかどうかで処理を分けたい場合はtry_filesを、URIの文字列パターンに基づいて処理を分けたり書き換えたりしたい場合はrewriteを使用するのが適切です。

しかし、これらを組み合わせて使うことも可能です。例えば、特定の正規表現パターンにマッチするURIでファイルが見つからなかった場合に、別のパターンに書き換えて再度ファイルを探す、あるいは特定の動的スクリプトに渡す、といったことができます。

“`nginx
server {
listen 80;
server_name combined.example.com;
root /var/www/html;

location / {
    # 例: /articles/slug-title-1234 のようなURLを処理したい
    # try_files でまずファイルを探す
    # なければ、rewrite でパラメータを抽出して index.php に渡すような処理にフォールバック

    # まず静的ファイルとして $uri を試す
    # それが見つからなければ、最後の引数として @dynamic_route という名前のロケーションに内部リダイレクト
    try_files $uri @dynamic_route;
}

# try_files から内部リダイレクトされるロケーション
location @dynamic_route {
    # ここで rewrite ディレクティブを使ってURIを書き換える
    # 例: /articles/slug-title-1234 を /index.php?type=article&slug=slug-title-1234 のように書き換える
    # rewrite ^/articles/([^/]+)-(\d+)$ /index.php?type=article&slug=$1&id=$2 last; # 例: /articles/slug-123 -> /index.php?type=article&slug=slug&id=123
    # rewrite ^/articles/([^/]+)$ /index.php?type=article&slug=$1 last; # 例: /articles/slug-title -> /index.php?type=article&slug=slug-title

    # rewrite ルールがマッチして URI が書き換えられた場合、その新しい URI で処理が継続される (last フラグの場合)
    # 通常、その新しい URI は .php ファイルを指し、location ~ \.php$ ブロックにマッチする

    # もし rewrite ルールがどれもマッチしなかった場合、または rewrite 後もファイルが見つからなかった場合、
    # ここでさらに try_files を使うか、エラーを返すなどの処理を行う
    # 例えば、どのパターンにもマッチしなかったら 404 エラーを返す
    return 404;
}

location ~ \.php$ {
    # PHP処理（FastCGIへパス）
    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_param REQUEST_URI $request_uri; # オリジナルのリクエストURIを渡す
    fastcgi_param ARGS $args; # Rewrite 後に生成されたクエリパラメータを渡すために $args を渡す（rewrite ルールによっては $args を含む）
}

}
“`

この例では、まず try_files $uri @dynamic_route; で、静的ファイルが存在するか確認し、なければ @dynamic_route という名前付きロケーションに内部リダイレクトしています。名前付きロケーションは、ファイルシステム上のパスには対応せず、内部リダイレクトのターゲットとしてのみ機能します。

location @dynamic_route ブロックでは、rewriteディレクティブを使って、特定のURLパターン（例: /articles/slug-title-1234）を解析し、PHPスクリプト（/index.php）とそれに渡すクエリパラメータに変換しています。rewrite ... last; は、書き換えられたURIで処理を再開させる指示です。これにより、例えば /articles/slug-123 というリクエストは /index.php?type=article&slug=slug&id=123 という内部リクエストに変換され、最終的に location ~ \.php$ ブロックによってPHP-FPMに処理が渡されます。

もし @dynamic_route 内のどのrewriteルールもマッチしなかった場合、またはtry_filesで @dynamic_route 以外にフォールバック先がない場合は、そのロケーションの最後にあるreturnや別のtry_filesによって処理されます。上記の例では return 404; としているため、該当する静的ファイルも dynamic rewrite ルールもなかったリクエストは404エラーとなります。

このように、try_filesで静的ファイルの存在確認を行い、存在しない場合にrewriteで複雑なルーティング処理を行うロケーションにフォールバックさせる、という使い方が可能です。

6. `try_files`を使う上での注意点とトラブルシューティング

try_filesは強力で柔軟なディレクティブですが、その利用にあたってはいくつかの注意点があります。

パフォーマンスへの影響: try_filesは、指定されたパスに対してファイルシステムへの存在確認を行います。特に多数のパスを指定したり、複雑なディレクトリ構造に対して頻繁にアクセスが発生する場合、ファイルシステムI/Oがオーバーヘッドとなり、パフォーマンスに影響を与える可能性があります。これは特にHDDを使用している環境や、仮想環境などI/O性能が制限される環境で顕著になることがあります。SSDを使用したり、open_file_cacheなどのディレクティブを設定してNginxのファイルメタデータキャッシュを有効にしたりすることで、ある程度パフォーマンスを改善できます。
パスの解釈と root/alias: try_filesで指定するパスは、現在のコンテキスト（serverまたはlocation）に設定されているrootまたはaliasディレクティブに基づいて解釈されます。rootはリクエストURI全体を基点ディレクトリからの相対パスと見なしますが、aliasはlocationにマッチしたパスの一部を置き換えて基点ディレクトリを指定します。try_files内のパスが、これらのディレクティブとどのように組み合わされて実際のファイルシステムパスになるのかを正確に理解することが重要です。一般的には、rootディレクティブを使用し、try_files内のパスは$uriや/path/to/fileのように記述することが多いです。aliasを使用する場合、try_files内のパス指定に特に注意が必要です。
最後の引数としてのディレクトリ: try_files $uri $uri/ /index.html; のように $uri/ を中間引数として指定することは一般的であり、ディレクトリが存在する場合にindexディレクティブを評価するトリガーとなります。しかし、最後の引数として / で終わるパスを指定する場合、それはディレクトリとしてではなくURIとして扱われます。 例えば try_files $uri /some/directory/; のように指定すると、これは /some/directory/ というURIへの内部リダイレクトとなり、そのリダイレクト先のロケーションブロックで再度処理が開始され、そこでindexディレクティブなどが評価されることになります。意図しない無限ループや処理の繰り返しを防ぐため、最後の引数には通常、特定のファイル（例: /index.html）やスクリプト（例: /index.php?$args）へのURI、あるいはステータスコード（例: =404）を指定するのが安全です。
セキュリティ: try_filesで指定するパスに、ユーザーからの入力が含まれる可能性がある変数（例: $uri, $request_uri）を使用する場合、Nginxが意図しないファイル（設定ファイル、ログファイルなど）を公開してしまうリスクがないか慎重に確認する必要があります。特に、rootディレクトリの外にあるファイルを指定していないか、隠しファイルへのアクセスが許可されていないか（location ~ /\. { deny all; } のような設定が必要）、などをチェックすることが重要です。
デバッグ: try_filesが期待通りに動作しない場合、Nginxのエラーログレベルをdebugに設定すると、try_filesがどのパスをどのような順番で試しているかの詳細なログを確認することができます。これにより、設定ミスやパスの解釈に関する問題を特定しやすくなります。ただし、debugレベルは非常に大量のログを生成するため、必要なときだけ有効にし、デバッグ後は元のログレベルに戻すようにしましょう。

“`nginx

nginx.conf の http ブロックまたは main コンテキストに記述

error_log /var/log/nginx/error.log debug;

デバッグが完了したらコメントアウトまたは info/warn/error に戻す

“`
ディレクティブの評価順序: Nginxの設定ファイルは特定の評価順序に従って処理されます。特にlocationブロックのマッチング順序（等号= > 完全一致 > 正規表現 ~/~* > 接頭辞一致^~ > 通常の接頭辞一致）と、server/locationブロック内のディレクティブの評価順序（例: rewrite は try_files より前に評価されることが多い）を理解しておく必要があります。try_filesは通常、rewriteディレクティブによるURI書き換えが完了した後に評価されます（ただし、try_filesの最後の引数による内部リダイレクトが発生した場合、そのリダイレクト先のロケーションで再度rewriteなどが評価される可能性があります）。

これらの注意点を踏まえることで、try_filesをより安全かつ効率的に利用できます。

7. まとめ

Nginxのtry_filesディレクティブは、ファイルやディレクトリの存在確認に基づいた柔軟なルーティングとフォールバックを可能にする非常に強力なツールです。静的なファイルの配信効率を最大化しつつ、存在しないリソースへのリクエストを動的なアプリケーション、SPAのエントリーポイント、あるいはカスタムエラーページにシームレスに振り分けるために不可欠な機能です。

try_filesは指定されたパスを左から順に試行し、最初に見つかったファイルまたはディレクトリを使用します。
リスト内のすべてが見つからなかった場合、最後の引数として指定されたURIに内部リダイレクトするか、指定されたHTTPステータスコードを返します。
モダンなWebフレームワークのフロントコントローラーパターンや、SPAのクライアントサイドルーティングを実現する上で中心的な役割を果たします。
カスタムエラーページやメンテナンスページの表示にも応用できます。
パスの解釈（root/aliasとの関連）、最後の引数の挙動、パフォーマンスへの影響、セキュリティ上の注意点などを理解しておくことが重要です。
複雑なURI操作が必要な場合は、rewriteディレクティブと組み合わせて使用することを検討します。

try_filesを適切に使いこなすことで、Webサーバーの設定をより効率的、柔軟、そして堅牢にすることができます。この記事で解説した基本概念、構文、多様な活用例、そして注意点を参考に、ぜひご自身のNginx設定にtry_filesを取り入れてみてください。デバッグが必要な場合は、エラーログのレベルを調整して、Nginxの内部動作を詳しく追跡することも有効です。

Nginxの設定は、Webサイトやアプリケーションのパフォーマンスと安定性に直結します。try_filesのような基本的ながらも強力なディレクティブを深く理解し、適切に利用することが、効果的なWebインフラストラクチャを構築するための鍵となるでしょう。

これで、約5000語のNginx try_filesディレクティブに関する詳細な解説記事となります。Markdown形式で直接表示しています。