モジュール ngx_http_upstream_module

ngx_http_upstream_module モジュールは、proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、および grpc_pass ディレクティブで参照できるサーバーグループを定義するために使用されます。

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

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

定期的なヘルスチェックを備えた動的に設定可能なグループは、商用サブスクリプションの一部として利用できます。

resolver 10.0.0.1;

upstream dynamic {
    zone upstream_dynamic 64k;

    server backend1.example.com      weight=5;
    server backend2.example.com:8080 fail_timeout=5s slow_start=30s;
    server 192.0.2.1                 max_fails=3;
    server backend3.example.com      resolve;
    server backend4.example.com      service=http resolve;

    server backup1.example.com:8080  backup;
    server backup2.example.com:8080  backup;
}

server {
    location / {
        proxy_pass http://dynamic;
        health_check;
    }
}

サーバーのグループを定義します。サーバーは異なるポートで listen することができます。さらに、TCP と UNIX ドメインソケットで listen するサーバーを混在させることができます。

例

upstream backend {
    server backend1.example.com weight=5;
    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;

    server backup1.example.com  backup;
}

デフォルトでは、リクエストは加重ラウンドロビン方式を使用してサーバー間で分散されます。上記の例では、7つのリクエストは次のように分散されます。5つのリクエストはbackend1.example.comに送られ、残りの2つのサーバーにはそれぞれ1つのリクエストが送られます。サーバーとの通信中にエラーが発生した場合、リクエストは次のサーバーに渡され、すべての機能するサーバーが試行されるまでこれが繰り返されます。いずれのサーバーからも正常なレスポンスが得られない場合、クライアントは最後のサーバーとの通信結果を受け取ります。

サーバーのアドレスとその他のパラメータを定義します。アドレスは、ドメイン名または IP アドレスとオプションのポート、または「unix:」プレフィックスの後に指定された UNIX ドメインソケットパスとして指定できます。ポートが指定されていない場合は、ポート 80 が使用されます。複数の IP アドレスに解決されるドメイン名は、複数のサーバーを一度に定義します。

以下のパラメータを定義できます。

weight=number

サーバーの重みを設定します。デフォルトは 1 です。

max_conns=number

プロキシされたサーバーへの同時アクティブ接続の最大数を数値に制限します（1.11.5）。デフォルト値はゼロで、制限がないことを意味します。サーバーグループが共有メモリに存在しない場合、制限は各ワーカープロセスごとに機能します。

アイドルキープアライブ接続、複数のワーカー、および共有メモリが有効になっている場合、プロキシされたサーバーへのアクティブおよびアイドル接続の総数は、max_conns値を超える可能性があります。

バージョン 1.5.9 からバージョン 1.11.5 までは、このパラメータは商用サブスクリプションの一部として利用可能でした。

max_fails=number

fail_timeoutパラメータで設定された期間内に、サーバーとの通信に失敗する試行回数を設定します。この回数に達すると、サーバーはfail_timeoutパラメータで設定された期間 동안 利用不可とみなされます。デフォルトでは、失敗試行回数は1に設定されています。ゼロ値は試行回数のカウントを無効にします。失敗試行とみなされるものは、proxy_next_upstream、fastcgi_next_upstream、uwsgi_next_upstream、scgi_next_upstream、memcached_next_upstream、およびgrpc_next_upstreamディレクティブによって定義されます。

fail_timeout=time

以下の設定を行います。

• サーバーとの通信に失敗する試行回数が、サーバーを利用不可とみなすために指定された回数に達するまでの時間。
• サーバーが利用不可とみなされる期間。

デフォルトでは、パラメータは10秒に設定されています。

backup

サーバーをバックアップサーバーとしてマークします。プライマリサーバーが利用できない場合、リクエストはバックアップサーバーに渡されます。

このパラメータは、hash、ip_hash、およびrandomの負荷分散方式とは一緒に使用できません。

down

サーバーを永続的に利用不可としてマークします。

さらに、以下のパラメーターは、商用サブスクリプションの一部として利用可能です。

resolve

サーバーのドメイン名に対応するIPアドレスの変更を監視し、nginxを再起動することなくupstream設定を自動的に変更します（1.5.12）。サーバーグループは共有メモリに存在する必要があります。

このパラメータを動作させるには、httpブロックまたは対応するupstreamブロックにresolverディレクティブを指定する必要があります。

route=string

サーバールート名を設定します。

service=name

DNS SRVレコードの解決を有効にし、サービス名を設定します（1.9.13）。このパラメータを動作させるには、サーバーにresolveパラメータを指定し、ポート番号のないホスト名を指定する必要があります。

サービス名にドット（ "."）が含まれていない場合、RFC 準拠の名前が構築され、TCPプロトコルが serviceprefix に追加されます。たとえば、_http._tcp.backend.example.com SRV レコードを検索するには、次のディレクティブを指定する必要があります。

server backend.example.com service=http resolve;

サービス名に1つ以上のドットが含まれている場合、 serviceprefix とサーバー名を結合して名前が構築されます。たとえば、_http._tcp.backend.example.comおよびserver1.backend.example.com SRVレコードを検索するには、次のディレクティブを指定する必要があります。

server backend.example.com service=_http._tcp resolve;
server example.com service=server1.backend resolve;

優先順位が最も高い SRV レコード（優先順位の値が最も低いレコード）はプライマリサーバーとして解決され、残りの SRV レコードはバックアップサーバーとして解決されます。サーバーにbackupパラメータが指定されている場合、優先順位の高い SRV レコードはバックアップサーバーとして解決され、残りの SRV レコードは無視されます。

slow_start=time

健全でないサーバーが健全になったとき、またはサーバーが利用不可とみなされていた期間の後で利用可能になったときに、サーバーが重みをゼロから公称値に回復するまでの時間を設定します。デフォルト値はゼロです。つまり、スロースタートは無効になっています。

このパラメータは、hash、ip_hash、およびrandomの負荷分散方式とは一緒に使用できません。

drain

サーバーを「ドレイニング」モードにします（1.13.6）。このモードでは、サーバーにバインドされたリクエストのみがプロキシされます。

バージョン 1.13.6 より前では、パラメータはAPIモジュールでのみ変更できました。

グループにサーバーが1つしかない場合、max_fails、fail_timeout、およびslow_startパラメータは無視され、そのようなサーバーは利用不可とはみなされません。

ワーカープロセス間で共有されるグループの設定と実行時状態を保持する共有メモリゾーンの名前とサイズを定義します。複数のグループが同じゾーンを共有できます。この場合、サイズを一度だけ指定すれば十分です。

さらに、商用サブスクリプションの一部として、このようなグループでは、nginx を再起動することなく、グループメンバーシップの変更や特定のサーバーの設定の変更を行うことができます。設定はAPIモジュールを介してアクセスできます（1.13.3）。

バージョン 1.13.3 より前では、設定はupstream_confによって処理される特別なロケーションからのみアクセスできました。

動的に設定可能なグループの状態を保持するファイルを指定します。

例

state /var/lib/nginx/state/servers.conf; # path for Linux
state /var/db/nginx/state/servers.conf;  # path for FreeBSD

状態は現在、サーバーとそのパラメータのリストに限定されています。ファイルは設定の解析時に読み取られ、upstream 設定が変更されるたびに更新されます。ファイルの内容を直接変更することは避けてください。このディレクティブは、serverディレクティブと一緒に使用することはできません。

設定のリロードまたはバイナリアップグレード中に加えられた変更は失われる可能性があります。

このディレクティブは、商用サブスクリプションの一部として利用可能です。

クライアントサーバーマッピングがハッシュされたキー値に基づくサーバーグループの負荷分散方法を指定します。 キーには、テキスト、変数、およびそれらの組み合わせを含めることができます。グループにサーバーを追加または削除すると、ほとんどのキーが異なるサーバーに再マッピングされる可能性があることに注意してください。このメソッドは、Cache::Memcached Perl ライブラリと互換性があります。

consistentパラメータが指定されている場合、ketamaコンシステントハッシュメソッドが代わりに使用されます。このメソッドは、サーバーがグループに追加または削除されたときに、少数のキーのみが異なるサーバーに再マッピングされることを保証します。これにより、キャッシングサーバーのキャッシュヒット率を高くすることができます。このメソッドは、ketama_pointsパラメータを160に設定したCache::Memcached::Fast Perlライブラリと互換性があります。

リクエストがクライアントのIPアドレスに基づいてサーバー間で分散される負荷分散方法をグループが使用するように指定します。クライアントIPv4アドレスの最初の3オクテット、またはIPv6アドレス全体がハッシュキーとして使用されます。このメソッドは、同じクライアントからのリクエストが、このサーバーが利用できない場合を除き、常に同じサーバーに渡されるようにします。後者の場合、クライアントリクエストは別のサーバーに渡されます。ほとんどの場合、これも常に同じサーバーになります。

IPv6アドレスは、バージョン1.3.2および1.2.2以降でサポートされています。

サーバーの1つを一時的に削除する必要がある場合は、クライアントIPアドレスの現在のハッシュを保持するために、downパラメータでマークする必要があります。

例

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
    server backend4.example.com;
}

バージョン1.3.1および1.2.2までは、ip_hash負荷分散方式を使用してサーバーの重みを指定できませんでした。

upstreamサーバーへの接続のキャッシュをアクティブにします。

connectionsパラメータは、各ワーカープロセスのキャッシュに保持される、upstreamサーバーへのアイドルキープアライブ接続の最大数を設定します。この数を超えると、最も最近使用されていない接続が閉じられます。

特に、keepaliveディレクティブは、nginxワーカープロセスが開くことができるupstreamサーバーへの接続の総数を制限しないことに注意してください。 connectionsパラメータは、upstreamサーバーが新しい着信接続も処理できるように、十分に小さい数に設定する必要があります。

デフォルトのラウンドロビン方式以外の負荷分散方式を使用する場合は、keepaliveディレクティブの前にアクティブにする必要があります。

キープアライブ接続を使用したmemcached upstreamの設定例

upstream memcached_backend {
    server 127.0.0.1:11211;
    server 10.0.0.2:11211;

    keepalive 32;
}

server {
    ...

    location /memcached/ {
        set $memcached_key $uri;
        memcached_pass memcached_backend;
    }

}

HTTPの場合、proxy_http_versionディレクティブを「1.1」に設定し、「Connection」ヘッダーフィールドをクリアする必要があります。

upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    ...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}

代わりに、「Connection: Keep-Alive」ヘッダーフィールドをupstreamサーバーに渡すことで、HTTP / 1.0永続接続を使用できますが、この方法は推奨されません。

FastCGIサーバーの場合、キープアライブ接続を機能させるには、fastcgi_keep_conn を設定する必要があります。

upstream fastcgi_backend {
    server 127.0.0.1:9000;

    keepalive 8;
}

server {
    ...

    location /fastcgi/ {
        fastcgi_pass fastcgi_backend;
        fastcgi_keep_conn on;
        ...
    }
}

SCGIおよびuwsgiプロトコルには、キープアライブ接続の概念がありません。

keepalive_requests 1000;

1つのキープアライブ接続で処理できるリクエストの最大数を設定します。最大リクエスト数に達すると、接続は閉じられます。

接続ごとのメモリ割り当てを解放するために、接続を定期的に閉じる必要があります。そのため、リクエストの最大数を高く設定しすぎると、メモリ使用量が過剰になる可能性があり、推奨されません。

バージョン1.19.10より前は、デフォルト値は100でした。

keepalive_time 1h;

1つのキープアライブ接続を介してリクエストを処理できる最大時間を制限します。この時間に達すると、後続のリクエスト処理後に接続が閉じられます。

keepalive_timeout 60s;

アップストリームサーバーへのアイドル状態のキープアライブ接続が開いたままになるタイムアウトを設定します。

NTLM認証を使用してリクエストをプロキシすることを許可します。クライアントが「Authorization」ヘッダーフィールドの値が「Negotiate」または「NTLM」で始まるリクエストを送信すると、アップストリーム接続はクライアント接続にバインドされます。それ以降のクライアントリクエストは、同じアップストリーム接続を介してプロキシされ、認証コンテキストが保持されます。

NTLM認証を機能させるには、アップストリームサーバーへのキープアライブ接続を有効にする必要があります。proxy_http_version ディレクティブは「1.1」に設定し、「Connection」ヘッダーフィールドはクリアする必要があります。

upstream http_backend {
    server 127.0.0.1:8080;

    ntlm;
}

server {
    ...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}

デフォルトのラウンドロビン方式以外のロードバランサー方式を使用する場合は、ntlmディレクティブの前にそれらをアクティブにする必要があります。

このディレクティブは、商用サブスクリプションの一部として利用可能です。

グループが、サーバーの重みを考慮して、アクティブな接続数が最も少ないサーバーにリクエストを渡すロードバランシング方式を使用することを指定します。そのようなサーバーが複数ある場合は、重み付きラウンドロビンバランシング方式を使用して順番に試行されます。

グループが、サーバーの重みを考慮して、平均応答時間が最も短く、アクティブな接続数が最も少ないサーバーにリクエストを渡すロードバランシング方式を使用することを指定します。そのようなサーバーが複数ある場合は、重み付きラウンドロビンバランシング方式を使用して順番に試行されます。

header パラメータが指定されている場合、レスポンスヘッダーを受信するまでの時間が使用されます。 last_byte パラメータが指定されている場合、完全なレスポンスを受信するまでの時間が使用されます。 inflight パラメータが指定されている場合（1.11.6）、不完全なリクエストも考慮されます。

バージョン1.11.6より前は、不完全なリクエストはデフォルトで考慮されていました。

このディレクティブは、商用サブスクリプションの一部として利用可能です。

リクエストの処理中にアップストリームサーバーをすぐに選択できない場合、リクエストはキューに入れられます。このディレクティブは、キューに同時に存在できるリクエストの最大数 number を指定します。キューがいっぱいになった場合、またはリクエストを渡すサーバーを timeout パラメータで指定された期間内に選択できない場合、502（Bad Gateway）エラーがクライアントに返されます。

timeout パラメータのデフォルト値は60秒です。

デフォルトのラウンドロビン方式以外のロードバランサー方式を使用する場合は、queueディレクティブの前にそれらをアクティブにする必要があります。

このディレクティブは、商用サブスクリプションの一部として利用可能です。

グループが、サーバーの重みを考慮して、ランダムに選択されたサーバーにリクエストを渡すロードバランシング方式を使用することを指定します。

オプションの two パラメータは、nginxにランダムに2つのサーバーを選択し、次に指定された method を使用してサーバーを選択するように指示します。デフォルトのメソッドは least_conn で、アクティブな接続数が最も少ないサーバーにリクエストを渡します。

least_time メソッドは、平均応答時間が最も短く、アクティブな接続数が最も少ないサーバーにリクエストを渡します。 least_time=header が指定されている場合、レスポンスヘッダーを受信するまでの時間が使用されます。 least_time=last_byte が指定されている場合、完全なレスポンスを受信するまでの時間が使用されます。

least_time メソッドは、商用サブスクリプションの一部として利用できます。

アップストリームサーバーの名前をアドレスに解決するために使用されるネームサーバーを設定します。例えば、

resolver 127.0.0.1 [::1]:5353;

アドレスは、ドメイン名またはIPアドレスとして、オプションでポートを指定して指定できます。ポートが指定されていない場合は、ポート53が使用されます。ネームサーバーはラウンドロビン方式で照会されます。

デフォルトでは、nginxは解決中にIPv4アドレスとIPv6アドレスの両方を検索します。IPv4またはIPv6アドレスの検索が望ましくない場合は、ipv4=off（1.23.1）またはipv6=offパラメータを指定できます。

デフォルトでは、nginxはレスポンスのTTL値を使用して回答をキャッシュします。オプションの valid パラメータを使用すると、それをオーバーライドできます。

resolver 127.0.0.1 [::1]:5353 valid=30s;

DNSスプーフィングを防ぐために、適切に保護された信頼できるローカルネットワークにDNSサーバーを設定することをお勧めします。

オプションの status_zone パラメータは、指定された zone におけるリクエストとレスポンスのDNSサーバー統計の収集を有効にします。

このディレクティブは、商用サブスクリプションの一部として利用可能です。

resolver_timeout 30s;

名前解決のタイムアウトを設定します。例えば、

resolver_timeout 5s;

このディレクティブは、商用サブスクリプションの一部として利用可能です。

セッションアフィニティを有効にします。これにより、同じクライアントからのリクエストがサーバーグループ内の同じサーバーに渡されます。3つの方法が利用可能です。

cookie

cookie メソッドが使用される場合、指定されたサーバーに関する情報は、nginxによって生成されたHTTP Cookieで渡されます。

upstream backend {
    server backend1.example.com;
    server backend2.example.com;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

特定のサーバーにまだバインドされていないクライアントからのリクエストは、設定されたバランシングメソッドによって選択されたサーバーに渡されます。このCookieを持つそれ以降のリクエストは、指定されたサーバーに渡されます。指定されたサーバーがリクエストを処理できない場合、クライアントがまだバインドされていないかのように新しいサーバーが選択されます。

ロードバランシング方式は、常にすでにバインドされているリクエストを考慮して負荷を均等に分散しようとします。アクティブなバインドリクエスト数が多いサーバーは、新しいバインドされていないリクエストを取得する可能性が低くなります。

最初のパラメータは、設定または検査されるCookieの名前を設定します。Cookie値は、IPアドレスとポート、またはUNIXドメインソケットパスのMD5ハッシュの16進数表現です。ただし、serverディレクティブの「route」パラメータが指定されている場合、Cookie値は「route」パラメータの値になります。

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

この場合、「srv_id」Cookieの値は a または b になります。

追加パラメータは次のとおりです。

expires=time

ブラウザがCookieを保持する必要がある time を設定します。特別な値 max は、Cookieの有効期限を「31 Dec 2037 23:55:55 GMT」に設定します。パラメータが指定されていない場合、ブラウザセッションの終了時にCookieの有効期限が切れます。

domain=domain

Cookieが設定される domain を定義します。パラメータ値には変数を含めることができます（1.11.5）。

httponly

HttpOnly 属性をCookieに追加します（1.7.11）。

samesite=strict | lax | none | $variable

SameSite (1.19.4) 属性をCookieに追加します。値は、Strict、Lax、None のいずれか、または変数を使用 (1.23.3) します。後者の場合、変数値が空の場合、SameSite 属性はCookieに追加されません。値が Strict、Lax、または None に解決される場合、対応する値が割り当てられます。それ以外の場合、Strict 値が割り当てられます。

secure

Secure 属性をCookieに追加します（1.7.11）。

path=path

Cookieが設定される path を定義します。

パラメータが省略された場合、対応するCookieフィールドは設定されません。

route

route メソッドが使用される場合、プロキシされたサーバーは、最初のリクエストを受信したときにクライアントにルートを割り当てます。このクライアントからの後続のすべてのリクエストは、CookieまたはURIにルーティング情報を伝えます。この情報は、server ディレクティブの「route」パラメータと比較され、リクエストをプロキシするサーバーが識別されます。「route」パラメータが指定されていない場合、ルート名は、IPアドレスとポート、またはUNIXドメインソケットパスのMD5ハッシュの16進数表現になります。指定されたサーバーがリクエストを処理できない場合、リクエストにルーティング情報がないかのように、設定されたバランシングメソッドによって新しいサーバーが選択されます。

route メソッドのパラメータは、ルーティング情報を含むことができる変数を指定します。空でない最初の変数が、一致するサーバーを見つけるために使用されます。

例

map $cookie_jsessionid $route_cookie {
    ~.+\.(?P<route>\w+)$ $route;
}

map $request_uri $route_uri {
    ~jsessionid=.+\.(?P<route>\w+)$ $route;
}

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky route $route_cookie $route_uri;
}

ここでは、リクエストに「JSESSIONID」Cookieが存在する場合、ルートはそこから取得されます。それ以外の場合、URIからのルートが使用されます。

学習

learn メソッド (1.7.1) を使用すると、nginx はアップストリームサーバーのレスポンスを分析し、通常は HTTP クッキーで渡されるサーバー開始セッションを学習します。

upstream backend {
   server backend1.example.com:8080;
   server backend2.example.com:8081;

   sticky learn
          create=$upstream_cookie_examplecookie
          lookup=$cookie_examplecookie
          zone=client_sessions:1m;
}

この例では、アップストリームサーバーはレスポンスにクッキー "EXAMPLECOOKIE" を設定することでセッションを作成します。このクッキーを持つ以降のリクエストは、同じサーバーに渡されます。サーバーがリクエストを処理できない場合、クライアントがまだバインドされていないかのように新しいサーバーが選択されます。

パラメータ create と lookup は、それぞれ新しいセッションの作成方法と既存のセッションの検索方法を示す変数を指定します。どちらのパラメータも複数回指定できます。その場合、空でない最初の変数が使用されます。

セッションは共有メモリゾーンに保存されます。そのゾーンの name と size は zone パラメータで設定されます。1 メガバイトのゾーンには、64 ビットプラットフォームで約 4000 セッションを格納できます。 timeout パラメータで指定された時間内にアクセスされないセッションは、ゾーンから削除されます。デフォルトでは、timeout は 10 分に設定されています。

header パラメータ (1.13.1) を使用すると、アップストリームサーバーからレスポンスヘッダーを受信した直後にセッションを作成できます。

sync パラメータ (1.13.8) は、共有メモリゾーンの同期を有効にします。

このディレクティブは、商用サブスクリプションの一部として利用可能です。

このディレクティブはバージョン 1.5.7 以降は廃止されました。代わりに、新しい構文を使用した同等の sticky ディレクティブを使用する必要があります。

sticky cookie name [expires=time] [domain=domain] [path=path];

ngx_http_upstream_module モジュールは、次の組み込み変数をサポートしています。

$upstream_addr

アップストリームサーバーの IP アドレスとポート、または UNIX ドメインソケットへのパスを保持します。リクエスト処理中に複数のサーバーに接続した場合、それらのアドレスはコンマで区切られます。例： "192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock"。"X-Accel-Redirect" または error_page によって開始された、あるサーバーグループから別のサーバーグループへの内部リダイレクトが発生した場合、異なるグループのサーバーアドレスはコロンで区切られます。例： "192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80"。サーバーを選択できない場合、変数はサーバーグループの名前を保持します。

$upstream_bytes_received

アップストリームサーバーから受信したバイト数 (1.11.4)。複数の接続からの値は、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。

$upstream_bytes_sent

アップストリームサーバーに送信されたバイト数 (1.15.8)。複数の接続からの値は、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。

$upstream_cache_status

レスポンスキャッシュへのアクセス状態を保持します (0.8.3)。状態は、"MISS"、"BYPASS"、"EXPIRED"、"STALE"、"UPDATING"、"REVALIDATED"、または "HIT" のいずれかです。

$upstream_connect_time

アップストリームサーバーとの接続確立に費やされた時間を保持します (1.9.1)。時間はミリ秒単位の秒数で保持されます。SSL の場合は、ハンドシェイクに費やされた時間も含まれます。複数の接続の時間は、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。

$upstream_cookie_name

アップストリームサーバーが "Set-Cookie" レスポンスヘッダーフィールドで送信した、指定された name のクッキー (1.7.1)。最後のサーバーのレスポンスからのクッキーのみが保存されます。

$upstream_header_time

アップストリームサーバーからレスポンスヘッダーを受信するのに費やされた時間を保持します (1.7.10)。時間はミリ秒単位の秒数で保持されます。複数のレスポンスの時間は、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。

$upstream_http_name

サーバーレスポンスヘッダーフィールドを保持します。たとえば、"Server" レスポンスヘッダーフィールドは、$upstream_http_server 変数を使用してアクセスできます。ヘッダーフィールド名を変数名に変換するルールは、"$http_" プレフィックスで始まる変数と同じです。最後のサーバーのレスポンスからのヘッダーフィールドのみが保存されます。

$upstream_last_server_name

最後に選択されたアップストリームサーバーの名前を保持します(1.25.3)。SNI 経由での受け渡しを許可します。

proxy_ssl_server_name on;
proxy_ssl_name        $upstream_last_server_name;

この変数は、商用サブスクリプションの一部として利用可能です。

$upstream_queue_time

リクエストがアップストリームキューで費やした時間を保持します (1.13.9)。時間はミリ秒単位の秒数で保持されます。複数のレスポンスの時間は、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。

$upstream_response_length

アップストリームサーバーから取得したレスポンスの長さを保持します (0.7.27)。長さはバイト単位で保持されます。複数のレスポンスの長さは、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。

$upstream_response_time

アップストリームサーバーからレスポンスを受信するのに費やされた時間を保持します。時間はミリ秒単位の秒数で保持されます。複数のレスポンスの時間は、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。

$upstream_status

アップストリームサーバーから取得したレスポンスのステータスコードを保持します。複数のレスポンスのステータスコードは、$upstream_addr 変数のアドレスのように、コンマとコロンで区切られます。サーバーを選択できない場合、変数は 502 (Bad Gateway) ステータスコードを保持します。

$upstream_trailer_name

アップストリームサーバーから取得したレスポンスの末尾にあるフィールドを保持します (1.13.10)。