Nginxとは何か？役割と基本構成を初心者向けに解説

Nginxは、Webサーバーとして静的ファイルを返すだけでなく、アプリの前段で通信をさばくためのソフトウェアです。最初に押さえるべき役割は3つあります。HTMLや画像を配信する、リバースプロキシとしてアプリへ中継する、複数台へ振り分ける。この3つです。

たとえば「ブラウザからのアクセスは80番や443番で受けたいが、実際のアプリは3000番で動いている」という構成はよくあります。そのときNginxが入口になり、受けたリクエストをNode.jsやPHP、Pythonアプリへ渡します。初心者がNginxを理解するときは、単なるWebサーバーではなく、公開用の窓口と交通整理役として見るとつかみやすいです。

• できること: 静的ファイル配信、リバースプロキシ、負荷分散、キャッシュ、TLS終端
• 使う場面: Webサイト公開、アプリの前段配置、複数サーバーへの振り分け、DockerやVM上の公開口
• 最初に覚える構成: http → server → location
• 初心者の最重要ポイント: 「どのポートで受けるか」と「どこへ流すか」を読む

ここがポイント: Nginxは「ページを置く場所」そのものより、アクセスを受けて適切な処理先へ導く役割で使われることが多いです。

Nginxの役割を先に整理する

Nginxの説明では用語が増えがちですが、実務で見る役割は次の順で理解すると混乱しにくくなります。

1. Webサーバーとして静的ファイルを返す

画像、CSS、JavaScript、単純なHTMLをそのまま返す役割です。

たとえば https://example.com/images/logo.png へのアクセスに対して、Nginxがディスク上の logo.png を返します。アプリを起動しなくても済むので、処理が軽く、公開の土台として使いやすいのが強みです。

2. リバースプロキシとしてアプリへ中継する

いまのWeb運用では、この用途がかなり重要です。

利用者はNginxにアクセスし、Nginxがその後ろで動くアプリへリクエストを渡します。たとえば次のような構成です。

• 利用者: https://example.com/
• Nginx: 80番・443番で待ち受ける
• アプリ: http://127.0.0.1:3000 で動作

この形にすると、外部公開はNginxに集約し、アプリは内部ポートだけで動かせます。証明書設定、アクセス制御、ログ取得も前段でまとめやすくなります。

3. ロードバランサーとして複数台へ振り分ける

アクセスが増えたとき、同じアプリを複数台で動かし、Nginxが振り分けます。

公式ドキュメントでは、upstream に複数のアプリサーバーを定義し、proxy_pass でそのグループへ流す構成が紹介されています。小規模な1台構成から、後で2台、3台へ増やしやすいのが実務上の利点です。

まず覚えたい基本構成

Nginx設定は nginx.conf で管理するのが基本です。公式のBeginner’s Guideでは、主な設定ファイルの配置先として /etc/nginx などが案内されています。

初心者は、まずこの階層だけ読めれば十分です。

• main: 全体設定
• events: 接続処理まわりの設定
• http: HTTPサーバー全体の設定
• server: 仮想ホスト単位の設定
• location: URLパスごとの処理

最小イメージは次のとおりです。

worker_processes auto;

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        server_name example.com;

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

この設定で見るべき点は多くありません。

• listen 80;: 80番ポートで受ける
• server_name example.com;: どのホスト名を扱うかを決める
• location /: / 以下のリクエストをどう処理するか決める
• root /var/www/html;: どのディレクトリを起点にファイルを返すか決める
• index index.html;: ディレクトリアクセス時の初期ファイルを決める

リクエストがどう処理されるか

たとえば次のアクセスを考えます。

• 入力URL: http://example.com/
• Nginxの判定: server_name example.com に一致
• 続く判定: location / に一致
• 返される候補: /var/www/html/index.html

つまり初心者が設定を見るときは、受信ポート → 対象ドメイン → 対象パス → 実際の処理先の順で追えば読めます。

静的ファイル配信の最小例

まずはNginxをWebサーバーとして使う例です。アプリ連携なしで動きが見えるので、最初の学習に向いています。

http {
    server {
        listen 80;
        server_name localhost;

        location / {
            root /usr/share/nginx/html;
            index index.html;
        }

        location /images/ {
            root /usr/share/nginx/html;
        }
    }
}

このとき、URLと実ファイルの対応は次のようになります。

• http://localhost/ → /usr/share/nginx/html/index.html
• http://localhost/images/logo.png → /usr/share/nginx/html/images/logo.png

動作確認の例

curl -I http://localhost/

想定される出力例:

HTTP/1.1 200 OK
Server: nginx/1.30.0
Content-Type: text/html

ここで確認したいのは、HTMLの中身よりも「NginxがHTTPレスポンスを返せているか」です。Server ヘッダーや 200 OK が見えれば、入口としては動いています。

リバースプロキシの基本例

実務ではこちらのほうが出番が多いです。Nginxの前に利用者、後ろにアプリを置く形です。

http {
    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://127.0.0.1:3000;
        }
    }
}

この設定で起きることは単純です。

• ブラウザは example.com にアクセスする
• Nginxが80番で受ける
• location / に入ったリクエストを 127.0.0.1:3000 へ渡す
• アプリの返答を利用者へ返す

どういう場面で便利か

• Node.jsアプリを3000番で動かし、公開は80番・443番にしたい
• アプリ本体を直接インターネットへさらしたくない
• 複数アプリの入口を1か所で管理したい
• 証明書更新やアクセスログ取得を前段でまとめたい

Nginxを使う意味は、アプリを置き換えることではありません。アプリの前に一枚置いて、公開と制御を分離することにあります。

ロードバランサーとしての基本構成

アクセス集中や冗長化を考えるなら、upstream を知っておくと理解が一段進みます。

http {
    upstream app_backend {
        server 192.168.1.10:3000;
        server 192.168.1.11:3000;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://app_backend;
        }
    }
}

この構成では、Nginxが app_backend グループへリクエストを振り分けます。公式ドキュメントでは、HTTPロードバランシングの既定動作としてラウンドロビン方式が説明されています。

何がうれしいのか

• 1台停止しても全体停止を避けやすい
• 負荷を分散しやすい
• 後ろのアプリ台数を増やしやすい

初心者のうちは高度な方式を覚える必要はありません。まずは「Nginxは1台のアプリにも、複数台のアプリにも前段として置ける」と理解すれば十分です。

よく出るディレクティブの意味

設定ファイルを読めるようになるには、頻出項目を短く押さえるのが近道です。

listen

待ち受けるアドレスとポートを決めます。

listen 80;
listen 127.0.0.1:8080;

「どこで受けるか」を決めるので、設定確認の最初のチェック対象です。

server_name

どのホスト名のリクエストを扱うか決めます。

server_name example.com www.example.com;

1台のNginxで複数サイトを扱うときの切り分けに効きます。

location

URLパスごとに処理を分けます。

location /api/ {
    proxy_pass http://127.0.0.1:4000;
}

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

この例なら、/api/ はアプリへ中継し、それ以外は静的ファイルを返します。Nginxらしさが最も出る部分です。

root と index

ファイル配信の起点と初期表示ファイルを決めます。

root /var/www/html;
index index.html;

「どのディレクトリの何を返すか」がここで決まります。

proxy_pass

後段サーバーへ中継します。

proxy_pass http://127.0.0.1:3000;

Nginxを単なる静的配信サーバーではなく、アプリの入口として使う中心機能です。

初心者がつまずきやすいポイント

設定は短く見えても、つまずく場所はだいたい決まっています。

root のパス解釈を誤る

location /images/ に root /data; を書くと、/images/logo.png は /data/images/logo.png を見に行きます。/data/logo.png ではありません。

パスがずれて404になるのは定番です。URLと実ファイルの対応を一度紙に書くと整理できます。

設定変更後に再読み込みしていない

nginx.conf を編集しただけでは反映されません。

nginx -t
nginx -s reload

• nginx -t: 構文チェック
• nginx -s reload: 設定再読み込み

公式ドキュメントでも、再読み込み前に構文の妥当性を確認してから反映する流れが重要です。

いきなり複雑な1ファイルを書こうとする

最初からSSL、リダイレクト、API、静的配信、複数アプリを1つの server に全部詰めると、どこが壊れているか分からなくなります。

先に確認する順番はこの3つです。

• listen が正しいか
• server_name が合っているか
• location が期待どおりに分岐しているか

代替手段や関連ツールとの使い分け

Nginxが有力なのは確かですが、常に唯一の正解ではありません。

• Apache HTTP Server: .htaccess 文化や既存運用が強い環境では選ばれやすい
• Caddy: HTTPS自動化まで含めてシンプルに始めたいときに向く
• アプリ内サーバー単体運用: 開発中やローカル検証では十分なこともある

ただし、本番公開で「静的配信」「前段プロキシ」「複数アプリの入口整理」が必要になった時点で、Nginxの価値はかなり高くなります。

まず何を読めばよいか

初心者が最短で理解するなら、次の順で見ると迷いにくいです。

1. server ブロックを探す
2. listen と server_name を確認する
3. location ごとの処理先を見る
4. root なのか proxy_pass なのかを判定する
5. 変更時は nginx -t のあとに nginx -s reload を実行する

Nginxを難しく感じるのは、機能が多いからです。ただ、日常運用で読むべき設定はそこまで多くありません。「どこで受けて、どこへ流すか」だけ先に読めるようになると、設定ファイルの見え方が一気に変わります。

最後に見るべき実務上のポイントを絞るなら次の3つです。

• 静的配信なのか、アプリ中継なのか
• 1台構成なのか、複数台へ振り分ける構成なのか
• 設定変更後に構文確認と再読み込みをしているか

ここまで読めれば、次はHTTPS設定や upstream の詳細へ進んでも詰まりにくくなります。

参照リンク

• nginx 公式サイト
• nginx documentation
• Beginner’s Guide
• ngx_http_core_module
• Module ngx_http_index_module
• Using nginx as HTTP load balancer
• Controlling nginx