リバースプロキシ ― nginxの後ろにアプリを置く

導入

前のレッスンでは、nginx が HTML ファイルをそのまま配信する例を見ました。しかし多くの Web サービスでは、ログインや検索のような「動的な処理」を行うのは nginx 自身ではなく、別に動いているアプリケーションプログラムです。その橋渡し役を、nginx が担うことがよくあります。

説明

アプリケーション（たとえば Node.js や Python で書かれたプログラム）は、localhost:3000 のような外部に公開しない内側のポートで動いていることが一般的です。nginx が代わりに 80/443番で外部からのリクエストを受け、内側のアプリへ転送します。これを リバースプロキシ と呼びます。

flowchart LR
    U["利用者<br/>ブラウザ"] -->|"HTTPS :443"| N["nginx<br/>（受付・転送）"]
    N -->|"内部だけの通信<br/>localhost:3000"| A["アプリケーション<br/>（業務ロジック）"]

設定では proxy_pass というディレクティブを使って「このパスへのリクエストは、あのアドレスへ回してください」と指示します。

# /etc/nginx/sites-available/default（抜粋）
server {
    listen 443 ssl;
    server_name example.com;

    location / {
        proxy_pass http://localhost:3000;   # ここから先はアプリへ丸投げ
    }
}

なぜ、アプリを直接インターネットに公開せず、わざわざ nginx を経由させるのでしょうか。理由は主に3つです。

暗号化の集約（TLS終端） … HTTPS の暗号化・復号を nginx 側でまとめて担当し、アプリ本体はシンプルな HTTP のままで済む
静的ファイルの高速配信 … 画像や CSS のような変化しないファイルは nginx が直接返し、アプリの負担を減らす
複数台への振り分け（負荷分散） … アプリを複数台に増やしても、nginx がその手前で受付を一本化できる

「利用者→nginx→アプリ→データベース」という組み合わせは、Web サービスの定番の姿の1つです。この全体像（三層構成）と、公開・運用までの流れは、次の章でさらに広い視点から扱います。ここで押さえてほしいのは「nginx はアプリの前に立つ受付であり、proxy_pass がその橋渡しを設定する仕組みだ」ということです。

この章のまとめ

リバースプロキシ＝nginx が外部からのリクエストを受け、内側のアプリへ転送する仕組み
proxy_pass で「このパスは、このアドレスへ転送する」と設定する
アプリを直接公開しない理由＝TLS終端の集約・静的配信の高速化・負荷分散のしやすさ