コンテンツにスキップ

wan0ri Note

Nginx

Nginx¶

Nginx は、Web サーバー、リバースプロキシ、ロードバランサーとしてよく使われるソフトウェア。

インフラをやっていると、静的ファイル配信、プロキシ、TLS 終端などで触れる可能性が高い。

まず押さえたいこと¶

Web サーバーとして使える
リバースプロキシとして使える
ロードバランサーとしても使える
軽量で高速な印象が強い

役割の切り分け¶

Web サーバー HTML、CSS、画像などを返す
リバースプロキシ クライアントの代わりに後段アプリへ転送する
ロードバランサー 複数の後段サーバーへ振り分ける

インフラで見ると、Nginx 自体がアプリを動かすというより、「通信をさばく前段」として使われることが多い。

何に使うか¶

静的ファイル配信
アプリケーションサーバーの前段
HTTPS 終端
パスやホスト名でのルーティング

ざっくり構成図¶

[Client]
   |
   v
[Nginx]
   |
   +--> [App Server A]
   |
   `--> [App Server B]

静的配信とプロキシを混ぜると、以下のような構成になる。

[Client]
   |
   v
[Nginx]
   | \
   |  `--> /static --> [Static Files]
   |
   `--> /api --> [App Server]

よく見る設定要素¶

server
location
proxy_pass
listen
ssl_certificate
upstream
access_log
error_log

最低限の設定の読み方¶

server {
    listen 80;
    server_name example.com;

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

listen どのポートで待ち受けるか
server_name どのホスト名向けか
location どのパスに対する設定か
proxy_pass どこへ転送するか

upstream の考え方¶

複数台のアプリへ振り分けるときに upstream を使う。

upstream app_backend {
    server app1:8080;
    server app2:8080;
}

これで、proxy_pass http://app_backend; のように書ける。

リバースプロキシとしてよくやること¶

クライアントからのリクエストを受ける
ヘッダーを後段へ引き継ぐ
TLS を前段で終端する
gzip 圧縮やキャッシュ制御を入れる
アクセスログを残す

後段アプリから見ると、Nginx は「外との境界」であり、通信の整形役になる。

実務で詰まりやすい点¶

1. パスの転送¶

/api をそのまま送るのか
/api を消して送るのか

location と proxy_pass の書き方で挙動が変わるため、ここは事故が多い。

2. ヘッダー¶

後段アプリで元のクライアントIPや Host を使う場合、ヘッダー引き継ぎが必要になる。

よく見るもの:

X-Forwarded-For
X-Forwarded-Proto
Host

3. タイムアウト¶

アップロードや重い API では、Nginx 側のタイムアウトで先に切れることがある。

4. TLS 証明書¶

どこで HTTPS を終端しているかを明確にしないと、証明書更新やリダイレクトで混乱しやすい。

Nginx と Apache のざっくり違い¶

Nginx リバースプロキシや高並列な静的配信の印象が強い
Apache 歴史が長く、モジュールが豊富な印象

今は Apache を完全に置き換えるというより、用途に応じて選ばれている。

AWS と絡むときの見方¶

EC2 上で Nginx を動かす
ECS コンテナ内の Web サーバーとして使う
ALB の後段でアプリ前段として使う
CloudFront の origin として使う

よく確認するのは以下。

セキュリティグループで開けているポート
80/443 で待ち受けているか
アプリへの転送先ポート
証明書の配置場所
ログの保存先

障害調査で見るポイント¶

502 Bad Gateway 後段アプリが落ちている、到達できない、ポート違い
504 Gateway Timeout 後段が遅い、タイムアウトが短い
403/404 location 設定や権限、配信パスを確認する
リダイレクトループ HTTP/HTTPS のリダイレクトや X-Forwarded-Proto を確認する

実務で見るポイント¶

どのポートで待ち受けているか
どこへ proxy_pass しているか
TLS 証明書はどこで終端しているか
access log / error log はどこに出るか
upstream の定義先はどこか
systemd やコンテナでどう起動しているか

メモ¶

Nginx は「アプリの前に立つサーバー」として見ると入りやすい
まずは reverse proxy と static file serving の2用途を押さえるとよい
その次に TLS 終端 upstream ヘッダー引き継ぎ を押さえると実務で役立ちやすい