Header title

Nginx Upstream・ロードバランシング設定ジェネレーター 開発者ガイド

ラウンドロビン、least_conn、ip_hash、キープアライブ、パッシブヘルスチェックパラメータを備えた本番環境対応のNginx upstreamブロックを生成します。

Presets label
Input label
Server nodes label4 nodes
#1
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
#2
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
#3
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
#4
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
Performance tuning
Synchronizes node states across worker processes in multi-core environments.
Pool Conns:
Idle Timeout:
Reduces TCP handshake latency up to 60% by maintaining persistent HTTP/1.1 sockets.
Proxy settings
Server Port:
Server Name:
Location Path:
1# ========================================================
2# Upstream Pool: microservice_api_cluster
3# Load Balancing Method: LEAST_CONN
4# Generated by ToolsAA (100% Client-Side Private Generator)
5# ========================================================
6upstream microservice_api_cluster {
7 # Shared memory zone across all worker processes
8 zone microservice_api_zone 64k;
9
10 # Directs traffic to the server with fewest active connections
11 least_conn;
12
13 # Backend server cluster nodes
14 server 10.0.1.11:8080 weight=5 max_fails=3 max_conns=500;
15 server 10.0.1.12:8080 weight=5 max_fails=3 max_conns=500;
16 server 10.0.1.13:8080 weight=3 max_fails=3 max_conns=300;
17 server 10.0.1.99:8080 max_fails=3 backup;
18
19 # Upstream HTTP/1.1 persistent connection pool
20 keepalive 32;
21 keepalive_requests 1000;
22 keepalive_timeout 60s;
23}
Stats card1
3 Primaries/1 Backups
Active cluster load capacity: 75%
Stats card2
least conn
Worker sync enabled via 64k memory zone
Stats card3
32 idle sockets pool
Standard HTTP/1.1 connection reuse

Client-Side Processing

High-performance processing executed entirely in browser memory.

Zero Server Upload Privacy

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

技術リファレンス&アーキテクチャガイド

Nginx Upstream・ロードバランシング設定ジェネレーター 開発者ガイド — リファレンスガイド

ラウンドロビン、least_conn、ip_hash、キープアライブ、パッシブヘルスチェックパラメータを備えた本番環境対応のNginx upstreamブロックを生成します。

主要パラメータ&設定項目

serverディレクティブ (string)

バックエンドサーバーのアドレス(IPまたはFQDN)、ポート、および weight、max_fails、fail_timeout、backup、down などの制御フラグを指定します。

初期値: server 127.0.0.1:8080 weight=1 max_fails=1 fail_timeout=10s
algorithmディレクティブ (enum)

負荷分散アルゴリズムを選択します。加重ラウンドロビン(デフォルト)、least_conn(最少接続数優先)、ip_hash(クライアントIPに基づくセッション維持)、または一貫性ハッシュ(consistent hash)。

初期値: round-robin (暗黙的)
keepaliveinteger

各ワーカープロセスのキャッシュ内に維持するアップストリームサーバー宛てのアイドル状態キープアライブ接続の最大数を設定します。

初期値: 32
keepalive_requestsinteger

単一のキープアライブ接続を通じて処理できる最大リクエスト数を設定します。上限到達後に接続はクローズされます。

初期値: 1000
keepalive_timeout時間 (string)

アップストリームサーバーへのアイドルキープアライブ接続を開いたまま維持するタイムアウト時間を設定します。

初期値: 60s
zonestring

全ワーカープロセス間でアップストリームグループの実行時状態と構成情報を共有する共有メモリゾーンの名前と割り当てサイズを定義します。

初期値: upstream_backend 64k

プロの活用テクニック&推奨設定

アップストリームキープアライブにはHTTP/1.1の明示が必須

upstream内で「keepalive 32;」を宣言しただけでは接続プールは有効になりません。locationブロック内で「proxy_http_version 1.1;」を指定し、「proxy_set_header Connection "";」でConnectionヘッダーを初期化する必要があります。指定しない場合、NginxはHTTP/1.0の「Connection: close」にフォールバックし、リクエスト毎に新規TCPハンドシェイクが発生します。

downおよびbackupフラグを活用した無停止メンテナンス

撤退予定のサーバーには「down;」を付与することで、既存のハッシュインデックスを崩さずにトラフィック転送を停止できます。また、予備系には「backup;」を指定しておくことで、プライマリノードが全台フェイル時のみ安全にトラフィックを流す待機系を構築できます。

キャッシュクラスタにはConsistent Hash(一貫性ハッシュ)を採用

ステートフルなキャッシュサーバーやSSR描画ノードにリクエストを分散する場合は、ラウンドロビンではなく「hash $request_uri consistent;」を使用してください。ノードの追加・削除時におけるキャッシュ再配置の偏りを最小限に抑えられます。

proxy_next_upstreamのフェイルオーバー動作を安全に調整

DB書き込みトランザクションの重複を防ぐため、「proxy_next_upstream error timeout http_502 http_503;」を設定してください。POSTやPATCHリクエストが完全に冪等(Idempotent)に設計されていない限り、「non_idempotent」パラメータの追加は避けてください。

よくあるトラブルと解決策

Upstream timed out(110: Connection timed out)または 504 Gateway Timeout が発生する

バックエンド側のファイアウォール規則を確認し、proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout の値がアプリの処理時間に即しているか見直してください。高トラフィック環境では、OSのファイル記述子制限(worker_rlimit_nofile)と worker_connections を拡張してください。

ip_hash を使用しているのにすべてのアクセスが単一のバックエンドに集中する

CloudflareやAWS ALB等のリバースプロキシ/CDN配下に配置されている場合、クライアントIPがすべてCDNのエッジIPと認識されます。「hash $http_cf_connecting_ip consistent;」に変更するか、ngx_http_realip_moduleの「set_real_ip_from」と「real_ip_header X-Forwarded-For;」を適切に構成してください。

設定リロード時やトラフィック急増時に 502 Bad Gateway が断続的に発生する

バックエンドのソケット待機キューが溢れている可能性があります。OSの受信バックログ(net.core.somaxconn)を引き上げ、upstreamのserver行に「max_conns」を指定してアプリプロセスの過負荷クラッシュを未然に防止してください。

よくある質問 (FAQ)

Round Robin、least_conn、ip_hash の違いは何ですか?▼

Round Robinはサーバーの重み(weight)に応じて順番にリクエストを振り分けます。least_connは現在アクティブな接続数が最も少ないサーバーを優先するため、リクエスト処理時間のばらつきが大きいAPIに適しています。ip_hashはIPv4の上位3オクテット(またはIPv6全体)をキーにして同一クライアントを同一サーバーに固定(スティッキーセッション)します。

オープンソース版Nginxのパッシブヘルスチェックはどのように動作しますか?▼

オープンソース版では「max_fails」と「fail_timeout」による受動的監視が行われます。fail_timeout時間内にmax_fails回連続で通信失敗が起きると、そのサーバーはfail_timeoutの間ダウン扱いとみなされ通信が除外されます。能動的にテストリクエストを送信するアクティブヘルスチェック(health_check)はNginx Plusまたは外部Luaモジュールが必要です。

なぜキープアライブ接続に 'proxy_set_header Connection "";' が必要なのですか?▼

Nginxのリバースプロキシは標準でHTTP/1.0を使用し、クライアントから渡されたConnectionヘッダーを上書きします。プロキシ先との接続をプーリングするには、HTTP/1.1への切り替えと、Connectionヘッダーを空文字列にしてclose送信を抑止することがプロトコル仕様上不可欠です。

動的DNS(コンテナ環境等)とNginx upstreamを組み合わせる際の注意点は?▼

オープンソース版Nginxのupstreamブロック内に記述されたホスト名は、起動時(reload時)に一度だけ名前解決されます。KubernetesやAWS ECS等でPod/タスクIPが頻繁に変わる場合は、upstreamの代わりに「resolver 10.0.0.2 valid=10s;」を定義した上で、「set $backend "http://api.internal:8080"; proxy_pass $backend;」のように変数経由でプロキシする必要があります。

関連するおすすめ開発ツール

すべてのツール →
Cron から Kubernetes CronJob YAML 変換&スペックジェネレーター 開発者ガイドdeveloper

標準的な crontab スケジュール式を、restartPolicy、concurrencyPolicy、リソース制限、タイムゾーン対応を備えた本番仕様の Kubernetes CronJob マニフェストへ瞬時に変換します。

ツールを開く→
JSONからGraphQL SDLスキーマ生成(Types・Queries・Inputs)開発者ガイドdeveloper

JSONオブジェクトからGraphQLスキーマ定義言語(SDL)のオブジェクト型、Input型、Queryスキーマを即時生成します。

ツールを開く→
Prometheus アラートルール&レコーディングルール生成ツール (PromQL) 開発者ガイドdeveloper

PromQLアラートルール、レコーディングルール、アラートしきい値、ラベル、Runbookアノテーションを視覚的に構築・検証します。

ツールを開く→
GraphQL SDLからTypeScriptリゾルバー型生成ツール 開発者ガイドdeveloper

GraphQL SDL(スキーマ定義言語)から、完全な型安全性を備えたTypeScriptリゾルバーインターフェース、引数型、コンテキスト型を自動生成します。

ツールを開く→
cURL to C# 変換ツール (.NET HttpClient, RestSharp & Flurl) 開発者ガイドdeveloper

コマンドラインの cURL リクエストを、.NET HttpClient、RestSharp、Flurl.Http を用いた実用的な C# コードへ高精度に変換。非同期処理や接続プーリングのベストプラクティスに対応。

ツールを開く→
cURLからJavaへの変換ガイド(Java 11+ HttpClient、OkHttp & Spring WebClient)developer

cURLコマンドを標準のjava.net.http.HttpClient、OkHttp3、Spring WebClientのプロダクション品質なJavaコードへ瞬時に変換します。

ツールを開く→