【Nginx講座 第3回】静的コンテンツ配信の極意。root/aliasの使い分けとインデックス設定

「画像が表示されない！」その原因、パスの設定ミスかもしれません。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、設定ファイルの構造とバーチャルホストについて学びました。
複数のドメインをさばけるようになり、いよいよサーバーらしくなってきましたね。

さて、Webサーバーの基本機能といえば、「HTMLファイルや画像ファイルをブラウザに届けること」です。
簡単そうに聞こえますが、Nginxの設定には「初見殺しの罠」が潜んでいます。
「設定通りに書いたはずなのに、なぜか404 Not Foundになる」「CSSが読み込まれない」…そんな経験はありませんか？

本記事では、ドキュメントルートの定義、root と alias の決定的な違い、インデックスファイルの設定、そしてSPA（シングルページアプリケーション）やWordPressで必須となる try_files について徹底解説します。

---

第1章：基本の「root」ディレクティブ

Webサーバーにおける「ドキュメントルート」とは、Webサイトのトップページ（/）が、サーバー上のどのディレクトリ（フォルダ）に対応するかを指定するものです。
Nginxでは root ディレクティブを使用します。

基本的な使い方

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
    }
}

この設定の場合、URLとサーバー上のファイルパスの関係は以下のようになります。

• URL: http://example.com/index.html
• 実体: /var/www/html/index.html

つまり、「rootで指定したパス ＋ URLのパス」 が、最終的なファイルの場所になります。
非常にシンプルですね。

特定のディレクトリだけ場所を変える

画像ファイルだけ別のディスクに置きたい場合などは、location ブロックを追加して root を再定義します。

location /images/ {
    root /mnt/storage;
}

さて、ここで問題です。
http://example.com/images/photo.jpg にアクセスした場合、Nginxはどこのファイルを探しに行くでしょうか？

正解: /mnt/storage/images/photo.jpg

「え？ /mnt/storage/photo.jpg じゃないの？」と思った方。
それが root の仕様であり、多くの人がハマる罠です。
root はあくまで「根っこ」を指定するものであり、URLの /images/ 部分もそのまま後ろにくっついてしまうのです。

---

第2章：最大の罠「root」と「alias」の違い

「URLの /images/ 部分を取り除いて、/mnt/storage/ の直下を見に行かせたい」。
そんな時に使うのが alias ディレクティブです。

比較：root vs alias

ディレクティブ	動作イメージ	計算式
root	指定したパスを付け足す	root + URI
alias	指定したパスに置き換える	alias + (URIからlocation部分を除いたもの)

aliasを使った設定例

location /images/ {
    alias /mnt/storage/;
}

この場合、http://example.com/images/photo.jpg へのアクセスは以下のように解決されます。

1. URLから /images/ 部分がカットされる。
2. 残った photo.jpg が /mnt/storage/ に結合される。
3. 最終パス: /mnt/storage/photo.jpg

これなら、ディレクトリ構造を変えずにURLだけ見せ方を変えることができます。

---

第3章：インデックスファイルとAutoindex

ディレクトリ（/ など）にアクセスされた時、どのファイルを表示するかを決めるのが index ディレクティブです。

1. indexの優先順位

index index.html index.htm index.php;

左から順番に探します。
index.html があればそれを表示し、なければ index.htm、それもなければ index.php を探します。
どれも見つからない場合は 403 Forbidden エラーになります。

2. ファイル一覧を表示する「autoindex」

開発中のサーバーや、社内のファイル共有サーバーなどでは、「ファイルの一覧（ディレクトリの中身）」をそのまま表示させたいことがあります。
その場合は autoindex を有効にします。

location /files/ {
    root /var/www/shared;
    autoindex on;             # 一覧表示を有効化
    autoindex_exact_size off; # ファイルサイズを KB/MB/GB で表示
    autoindex_localtime on;   # タイムスタンプを現地時間で表示
}

こうすると、ブラウザで /files/ にアクセスした時、ファイル一覧がリスト表示され、クリックしてダウンロードできるようになります。

セキュリティ警告:
一般公開するWebサイトでは、意図せず内部ファイルが見えてしまうリスクがあるため、autoindex は必ず off（デフォルト）にしておきましょう。

---

第4章：エラーページをカスタマイズする

Nginxのデフォルトのエラー画面（404 Not Foundや500 Internal Server Error）は、白背景に黒文字だけの素っ気ないものです。
これをサイトのデザインに合わせたオリジナルの画面に変更しましょう。

error_pageディレクティブ

server {
    ...
    # 404エラー用
    error_page 404 /404.html;

    # 500系エラー用（まとめて指定可能）
    error_page 500 502 503 504 /50x.html;

    location = /404.html {
        root /usr/share/nginx/html;
    }

    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

仕組み:

1. 404エラーが発生する。
2. Nginxは内部的に /404.html へアクセスを転送（リダイレクトではない）する。
3. location = /404.html の設定に従ってファイルを表示する。

これにより、URLは変わらずに中身だけカスタムエラーページを表示できます。

jsonでエラーを返す（APIサーバー向け）

Web APIの場合、HTMLではなくJSONでエラーを返したいことがあります。

error_page 404 = @json_error;

location @json_error {
    default_type application/json;
    return 404 '{"error": "Not Found", "code": 404}';
}

@ で始まる名前付きロケーション（Named Location）を使うのがテクニックです。

---

第5章：現代Webの必須知識「try_files」

WordPressや、React/VueなどのSPA (Single Page Application) をNginxで動かす場合、必ずと言っていいほど登場するのが try_files です。
これが理解できていないと、「トップページは出るけど下層ページが全部404になる」という現象に悩まされます。

try_filesの構文

try_files file1 file2 ... uri;

「左から順にファイルが存在するかチェックし、最初に見つかったものを返す。全部なければ最後の引数（URI）へ転送する」という動きをします。

ケーススタディ1：WordPressの設定

WordPressは、すべてのリクエストを index.php に集めて処理させたい（フロントコントローラーパターン）システムです。

location / {
    try_files $uri $uri/ /index.php?$args;
}

動作解説:

1. $uri: リクエストされたファイル（画像やCSSなど）が実在すれば、それを返す。
2. $uri/: リクエストされたディレクトリが実在すれば、そこを探す。
3. /index.php?$args: 上記がなければ、全て index.php に処理を投げる。

ケーススタディ2：React/Vue (SPA) の設定

SPAでは、URLが変わっても実際には index.html 1枚だけで動いています（クライアントサイド・ルーティング）。
そのため、サーバー上に実在しないパス（例: /user/123）にアクセスされたら、404ではなく index.html を返す必要があります。

location / {
    root /var/www/my-app;
    index index.html;
    try_files $uri $uri/ /index.html;
}

これがないと、ページをリロードした瞬間に404エラーになってしまいます。

---

第6章：トラブルシューティング（MIMEタイプと権限）

最後に、よくあるトラブルとその解決策を紹介します。

1. CSSが適用されない（MIMEタイプ問題）

「デザインが崩れて文字だけになる」場合、ブラウザの開発者ツールを見ると「Resource interpreted as Stylesheet but transferred with MIME type text/plain」という警告が出ていることがあります。
これはNginxがCSSファイルを「ただのテキスト」として送ってしまっているのが原因です。

http ブロックに以下の記述があるか確認してください。

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    ...
}

mime.types ファイルには、「.css は text/css」「.png は image/png」といった対応表が書かれています。
これを読み込むことで、正しい種類としてファイルを配信できます。

2. 403 Forbidden が出る（権限問題）

ファイルは存在するのに 403 エラーになる場合、原因の9割は「パーミッション（権限）」です。

• ファイルの権限: Nginxの実行ユーザー（通常 nginx）が読み取れる必要があります（644など）。
• ディレクトリの権限: 実行権限（x）が必要です（755など）。
• SELinux: RHEL系OSの場合、SELinuxがブロックしている可能性があります。
  ls -Z でコンテキストを確認し、必要なら chcon コマンドで修正するか、一時的にSELinuxをPermissiveにして切り分けます。

---

まとめ：静的配信を制する者はNginxを制す

お疲れ様でした！
今回は、Nginxの基本であるファイル配信について深く掘り下げました。

今回の重要ポイント：

• root はパスを「結合」し、alias はパスを「置換」する。
• alias を使うときは末尾のスラッシュに注意する。
• SPAやWordPressには try_files が必須。
• エラーページは error_page でサイトに合わせてカスタマイズする。

これで、Webサイトを公開するための基礎力は完璧です。
しかし、現代のWebシステムでは、Nginx単体で完結することは稀です。
後ろにいるPHPやPython、Node.jsなどのアプリケーションサーバーと連携して初めて、動的なサービスが提供できます。

次回、第4回は「リバースプロキシの構築。APサーバーへの転送とロードバランシング」です。
Nginxの真骨頂である「プロキシ機能」を使って、バックエンドサーバーへリクエストを中継する方法や、負荷分散（ロードバランサー）としての使い方をマスターします。
ここから一気に本格的なインフラ構築に入ります。お楽しみに！