Nginxの仕組み — 画像を返す係と、アプリへ渡す係

ひよこ

Nginxって、Webサイトのどこで働いているの？

ペンギン先生

例えば通販の入口で、画像ならファイルを返し、商品情報ならアプリへ渡す役を持てるよ。どのリクエストを、どこへ届けるかを見ると分かりやすいんだ。

ひよこ

画像と商品情報は、同じように返せないの？

ペンギン先生

保存済みの画像は静的ファイルとして配信できるよ。一方、商品価格や在庫をDBから調べる処理はアプリが担当する。Nginxが入口にいても、注文の計算まで自動で代わりに行うわけではないんだ。

ひよこ

アプリへ渡すのがリバースプロキシ？

ペンギン先生

そう。利用者はNginxへリクエストし、Nginxが背後のサーバーへ送って応答を返す。一般的なプロキシとの違いは、どちら側の窓口になるかを見ると理解しやすいよ。

ひよこ

どうやって振り分けるの？

ペンギン先生

serverの中にlocationを書き、URLのパスに応じた処理を設定するよ。下の例は/images/を静的配信、/api/をアプリへ転送する。実際にはlocationの選択規則もあるので、設定を増やしたら重なりを確かめよう。

ひよこ

たくさんの接続を扱えるのはなぜ？

ペンギン先生

workerがイベントを扱い、通信の準備ができた接続を処理する設計が特徴だよ。ただし待ち時間やCPUの処理がなくなるわけではない。実際の性能は設定、処理内容、OSや機器にも左右されるんだ。

ひよこ

Apacheは接続ごとに必ず1プロセスなの？

ペンギン先生

そうとは限らないよ。Apacheには複数のMPMがあり、event MPMはスレッドとイベント処理を使う。「Nginxだけがイベント駆動」と単純に分けず、使う方式を確認しよう。

ひよこ

HTTPSや負荷分散もできる？

ペンギン先生

設定すれば担当できるよ。複数のアプリへ渡す、TLS接続を受けるなど、役割を足せる。ただしバックエンドへの直接アクセスや、Nginxから先の暗号化は別に設計する。置くだけで全部安全になるわけではないんだ。

ひよこ

設定を変えたら、すぐ反映される？

ペンギン先生

通常は検査してから再読み込みするよ。まずnginx -tで構文などを確認し、対象のNginxにreloadを送る。その後、画像とAPIを実際に開き、アクセスログとエラーログで結果も確かめよう。

まずは「画像」と「商品API」の行き先を分ける

通販でりんごの商品ページを開くと、ブラウザーはHTMLのほかに画像や商品データを取得することがあります。NginxはWebサーバーやリバースプロキシとして、その入口を担当できます。

画像の読み出しと、DBを使った商品情報の生成は別の仕事です。Nginxが両方の窓口になっても、商品を検索するプログラムはアプリ側に必要です。

設定の読み方：locationで役割を分ける

次は仕組みを読むための設定断片です。Linux環境のnginx.confのhttp内へ置くserverの例で、これだけが完全な設定ファイルではありません。既存設定へそのまま追記すると競合する場合があるため、練習用環境で確認してください。

server {
    listen 127.0.0.1:8080;

    location /images/ {
        root /srv/hiyopen-site;
    }

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

この例では、/images/logo.svgを/srv/hiyopen-site/images/logo.svgから読みます。ファイルが存在し、Nginxが読める権限が必要です。rootは、ここではURLのパスをその後ろへ付けてファイルの場所を決めます。

/api/productsは、3000番ポートで動くアプリへ渡します。このproxy_passにはホスト・ポートの後に置き換え用URIを付けていないので、元の/api/productsが渡ります。proxy_pass http://127.0.0.1:3000/;のように末尾の/を付けた場合とは、パスの扱いが違います。

listenを127.0.0.1にしているので、この例の入口は同じマシンからのアクセス用です。本番の公開設定では、TLS・公開範囲・バックエンドのアクセス制限も別に決めます。

読めたら、3つの結果を確かめよう

導入から試す場合はNginx入門へ進んでください。設定を使うときは、対象の設定ファイルでnginx -tを実行し、問題がなければそのNginxを再読み込みします。サービス管理下では管理方法も確認します。

• 画像のURLで、意図した画像が表示されるか。
• APIのURLで、アプリの応答が返るか。アプリ側にも同じパスが届いているか。
• 存在しないファイルや、停止したアプリへのアクセスを、ログから区別できるか。

構文検査に通ることと、行き先のアプリやファイルが正常なことは別です。プロキシ先に接続できない場合などは、エラーログとアプリ側の起動状態を合わせて確認します。

もう少し詳しく：workerと追加の役割

masterは設定の読み込みとworkerの管理を担い、workerがリクエストを処理します。イベントを利用して接続を扱う構成がNginxの特徴ですが、処理内容によって負荷は変わります。「同時接続が何件でも軽い」とは言えません。Apacheもevent MPMなどを選べるため、製品名だけで性能を決めないようにしましょう。

負荷分散やキャッシュは、必要なときに設定する機能です。ログイン利用者ごとの応答を共用キャッシュへ入れると別の利用者に渡す危険があるため、何を共有してよいか、キーと除外条件を先に決めます。TLSをNginxで終端する構成では、Nginxからアプリまでの経路も確認します。

ingress-nginxの終了とNginx本体は別

KubernetesコミュニティのIngress NGINXは2026年3月で保守を終了する方針が公表されました。これはNginx本体のWebサーバー機能が終了するという意味ではありません。Kubernetesで使う場合は、どのコントローラーの話かを区別し、公式の移行案内を確認してください。

覚え方と次の一歩

「Nginx」って出てきたら「Webの入口で、返す・渡すを振り分ける係」と思えばだいたいOK！

Nginx入門で自分のファイルを配信し、ApacheとNginxの比較で構成の違いを整理できます。

参考資料

• Nginx：Beginner’s Guide — masterとworker、設定の階層、静的配信と再読み込み
• Nginx：Proxy module — リバースプロキシとURIの指定有無によるパスの違い
• Apache：event MPM — プロセス・スレッド・イベント処理を組み合わせる方式
• Kubernetes：Ingress NGINX Retirement — 2026年3月の保守終了方針と移行案内