HOME > 技術ドキュメント > Nginx ロードバランシング・リバースプロキシ詳細設定（Ubuntu 24.04 LTS）

Nginx ロードバランシング・リバースプロキシ詳細設定（Ubuntu 24.04 LTS）

Nginx は Web サーバーとしてだけでなく、バックエンドアプリ（Go・Node.js・Rails・PHP-FPM など）への リバースプロキシ・ロードバランサーとして広く使われています。
本記事では upstream ブロックによるロードバランシング設定から、ヘルスチェック・ プロキシキャッシュ・WebSocket プロキシまで実設定例で解説します。

1. upstream ブロックの基本構文

upstream ブロックでバックエンドサーバー群を定義し、proxy_pass で参照します。

upstream backend {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    server 127.0.0.1:8003;
}

server {
    listen 80;
    server_name example.com;

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

デフォルトは round-robin（順番に振り分け）です。upstream 名は任意で、 proxy_pass の http:// に続けて指定します。

2. ロードバランシング方式の比較

方式	ディレクティブ	特徴・用途
round-robin	（デフォルト、指定不要）	リクエストを順番に均等に振り分ける。最もシンプル
weight	weight=N	サーバーごとに重みを設定。スペックが異なるサーバー群に有効
ip_hash	ip_hash;	クライアント IP で振り分け先を固定。セッションアフィニティが必要な場合
least_conn	least_conn;	アクティブ接続数が最少のサーバーへ振り分け。処理時間が不均一な場合に有効

3. weight（重み付き）設定例

スペックの高いサーバーに多くのリクエストを流したい場合に weight を使います。 backup を指定したサーバーは他のサーバーがすべてダウンしたときのみ使われます。

upstream backend {
    server 127.0.0.1:8001 weight=3;   # リクエストの 3/5 を担当
    server 127.0.0.1:8002 weight=1;   # リクエストの 1/5 を担当
    server 127.0.0.1:8003 weight=1 backup;  # 障害時のみ稼働
}

4. パッシブヘルスチェック

Nginx オープンソース版はパッシブ（実際のリクエスト結果を監視）ヘルスチェックのみ対応しています。 max_fails 回失敗したサーバーを fail_timeout 秒間除外します。

upstream backend {
    server 127.0.0.1:8001 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:8002 max_fails=3 fail_timeout=30s;
}

パラメーター	説明
max_fails	この回数失敗したらサーバーを一時的に除外（デフォルト: 1）
fail_timeout	除外する期間 兼 失敗カウントのリセット間隔（デフォルト: 10s）

5. keepalive 設定

バックエンドとの接続を使いまわすことでオーバーヘッドを削減します。 keepalive にはキャッシュするアイドル接続数を指定します。

upstream backend {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    keepalive 32;
}

keepalive を使う場合は proxy_http_version 1.1; と proxy_set_header Connection ""; の設定も必要です（後述）。

6. proxy_set_header（必須設定）

リバースプロキシとして動作させる際は、バックエンドにクライアント情報を正しく伝えるために 以下のヘッダー設定が必須です。

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Connection        "";  # keepalive 使用時

    proxy_connect_timeout 10s;
    proxy_read_timeout    60s;
    proxy_send_timeout    60s;
}

ヘッダー	用途
X-Real-IP	クライアントの実 IP アドレスをバックエンドへ伝える
X-Forwarded-For	プロキシ経由の IP チェーンを伝える
X-Forwarded-Proto	元のプロトコル（http/https）をバックエンドへ伝える

7. バッファ設定

バックエンドからのレスポンスをバッファリングすることで、バックエンドとの接続を早く解放できます。

proxy_buffer_size      4k;
proxy_buffers          8 4k;
proxy_busy_buffers_size 8k;

レスポンスが大きいファイルダウンロード系の場合は proxy_buffers の数・サイズを増やします。 ストリーミングや SSE（Server-Sent Events）ではバッファリングを無効化します（proxy_buffering off;）。

8. プロキシキャッシュの設定

静的コンテンツや変化の少ない API レスポンスをキャッシュしてバックエンド負荷を下げます。 proxy_cache_path は http コンテキスト（server の外）に記述します。

# /etc/nginx/nginx.conf の http ブロック内
proxy_cache_path /var/cache/nginx
                 levels=1:2
                 keys_zone=my_cache:10m
                 max_size=1g
                 inactive=60m
                 use_temp_path=off;

server {
    location / {
        proxy_cache             my_cache;
        proxy_cache_valid       200 10m;
        proxy_cache_valid       404 1m;
        proxy_cache_use_stale   error timeout updating;
        proxy_cache_lock        on;
        add_header X-Cache-Status $upstream_cache_status;

        proxy_pass http://backend;
    }
}

add_header X-Cache-Status で HIT / MISS / BYPASS を レスポンスヘッダーで確認できます。
キャッシュしたくない URL は proxy_cache_bypass や proxy_no_cache で制御します。

# 動的 API はキャッシュをバイパス
location /api/ {
    proxy_cache_bypass 1;
    proxy_no_cache     1;
    proxy_pass http://backend;
}

9. WebSocket プロキシ

WebSocket は HTTP の Upgrade ヘッダーで接続を切り替えます。 Nginx が WebSocket を通すには以下の設定が必要です。

location /ws/ {
    proxy_pass         http://backend;
    proxy_http_version 1.1;
    proxy_set_header   Upgrade    $http_upgrade;
    proxy_set_header   Connection "upgrade";
    proxy_read_timeout 86400s;  # 接続を長時間維持
}

proxy_read_timeout はデフォルト 60 秒なので、WebSocket の長時間接続には引き上げが必要です。

10. 設定反映と動作確認

# 設定ファイルの構文チェック
sudo nginx -t

# 問題なければリロード（ダウンタイムなし）
sudo systemctl reload nginx

# キャッシュヒット確認
curl -I https://example.com/
# X-Cache-Status: HIT  ← キャッシュから返却
# X-Cache-Status: MISS ← バックエンドから取得

# キャッシュの手動クリア
sudo rm -rf /var/cache/nginx/*

関連ドキュメント

Nginx SSL/TLS 設定（Ubuntu 24.04） — HTTPS 設定、TLS 1.2/1.3、SSL証明書の設定
HTTP/2・HTTP/3（QUIC）設定（Nginx） — HTTP/2 有効化、HTTP/3 と QUIC の設定
Go 言語 Web アプリ入門 — Nginx リバースプロキシ対象となる Go バックエンドの構築

ロードバランサー（Nginx）での SSL 終端

Nginx がリバースプロキシとして HTTPS を終端する構成では、Nginx に SSL証明書を設定します。 バックエンドサーバー（Go・Node.js・Rails など）へは HTTP で通信できるため、 証明書の管理が Nginx の1箇所に集約できるメリットがあります。
エスロジカルではデジサート・サイバートラストの正規取扱代理店として、 2009年から16年以上、RapidSSL 3,960円/1年（税込）〜でSSL証明書を販売しています。審査サポート・インストール代行も対応しています。

SSL証明書の購入はこちら / SSL証明書とは？ / インストール代行サービス

← 技術ドキュメント一覧へ戻る