ブログ | NGINX

NGINX Plus R10 の発表

NGINX-F5 水平黒タイプ RGB の一部
オーウェン・ギャレット サムネイル
オーウェン・ギャレット
2016 年 8 月 23 日公開


[編集者注– NGINX Plus 用のNGINX ModSecurity WAFモジュールは、 2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF はサポート終了に移行しています<.htmla>」をご覧ください。

これまでで最も重要なリリースである NGINX Plus リリース 10 (R10) を発表できることを嬉しく思います。 NGINX Plus は、NGINX Open Source を高度な機能と受賞歴のあるサポートで拡張し、顧客に完全なアプリケーション配信ソリューションを提供します。 このリリースでは、NGINX Plus によって配信されるアプリケーションのセキュリティとパフォーマンスを大幅に向上させるいくつかの新機能に加えて、ネットワーク統合の改善とスクリプトによる NGINX Plus のカスタマイズのサポートのための追加機能も提供しています。

[編集者注– NGINX Plus R10 の主な新機能の詳細については、以下の関連リソースを参照してください。

]

NGINX Plus R10 には、ModSecurity を搭載し、NGINX, Inc. によって完全にサポートされているWeb アプリケーション ファイアウォール (WAF)の最初のリリースが搭載されています。 Akamai によると、ウェブアプリケーション攻撃は過去 1 年間で 50% 増加し、 DDoS 攻撃は2 倍以上に増加しました。 すべてのアプリケーションが攻撃を受ける危険にさらされています。 NGINX ModSecurity WAF は、Web アプリケーションを悪意のあるユーザーから保護し、顧客にアプリとデータを安全に保つための多目的ツールを提供します。

NGINX Plus R10 リリースに含まれる NGINX ModSecurity WAF を使用してアプリケーションを保護します。
NGINX ModSecurity WAFは侵入者をブロックします

NGINX ModSecurity WAF は新しいModSecurity 3ソフトウェアに基づいており、NGINX Plus 内でネイティブに実行されます。 弊社の動的モジュール リポジトリで追加料金のオプションとして利用可能で、NGINX, Inc. によってサポートされており、NGINX Plus で徹底的にテストされています。 当社はTrustwaveと連携し、機能の追加、パフォーマンスの向上、問題への対処などを行いながら、テスト済みのアップデートを維持していきます。

次の 2 つの新機能により、NGINX Plus のセキュリティ機能がさらに強化されます。

  • JSON Web Token – 多くのお客様が NGINX Plus をAPI ゲートウェイとして使用しており、NGINX Plus レイヤーで API へのアクセスを認証する一般的な標準的な方法を求めています。 このニーズに対応するため、今回のリリースでは JSON Web Token (JWT) を使用した認証のサポートが追加されています。

    NGINX Plus では、クライアントに API へのアクセスを許可する前に JWT を検証できるようになりました。 この機能により、アプリケーション管理者はオープン スタンダードを使用して API へのアクセスを保護し、独自の標準へのベンダー ロックインを回避できます。 ネイティブ JWT サポートでは、OAuth 2.0 準拠の OpenID Connect トークンの検証などの認証操作をアプリケーション サーバーから NGINX Plus にオフロードすることで、アプリケーション管理者の複雑さも軽減されます。

  • ECC および RSA 証明書の「デュアルスタック」サポート– NGINX Plus R10 では、RSA 証明書と ECC 証明書の両方を使用して SSL/TLS サービスを公開できます。 NGINX Plus は、各クライアントの機能に基づいて最適な証明書を選択するため、最新のクライアントは、従来の RSA のみのクライアントをサポートしながら、より高速な ECC 証明書を使用できます。 ECC 証明書は、同等の強度の RSA 証明書よりも最大 3 倍高速です。つまり、サーバーあたりの SSL/TLS 接続数が増え、SSL/TLS ハンドシェイクが高速になります。

セキュリティ機能に加えて、NGINX Plus R10 には以下が含まれます。

  • 透過プロキシのサポート- 多くの最新の HTTP アプリケーションはX-Forwarded-Forヘッダーに依存するように構成できますが、一部のレガシー アプリケーションやその他の TCP または UDP サービスは、ログ記録、セキュリティ、または認証の目的でトランザクションの送信元 IP アドレスを参照します。

    NGINX Plus は、アップストリーム サーバーに転送するHTTPおよびTCP 接続と UDP データグラムの送信元 IP アドレスとポートを「偽装」できるようになりました。 これを使用すると、 IP 透過性 ( NGINX Plus がリモート クライアントの IP アドレスを使用してパケットを送信し、アップストリーム サーバーがパケットを NGINX Plus サーバー上のローカル IP アドレスではなくそのアドレスから送信されたものと認識する構成) を提供できます。 この機能を使用して、UDP ベースのプロトコルの Direct Server Return を有効にすることもできます。

  • NGINX JavaScript モジュールのサポート– NGINX JavaScript モジュールは、NGINX および NGINX Plus の次世代構成および制御言語であり、ユーザーはアプリケーションの配信方法とセキュリティ保護方法を詳細かつきめ細かく制御できます。 このプレビュー リリースでは、NGINX JavaScript モジュールによって HTTP、TCP、UDP トラフィックの制御が強化され、応答が生成され、リクエストを最適なサーバーにルーティングするための正確な決定が行われます。

  • TCP および UDP ロード バランシングのさらなる改善- Stream モジュールの拡張機能により、より多くのNGINX 変数のサポート、 mapディレクティブを使用した計算、 split_clientsディレクティブを使用した A/B テストのサポート、 GeoおよびGeoIP操作、選択的ルーティング ( proxy_passディレクティブへの変数パラメーター) が追加されました。 これらの拡張機能により、NGINX 構成言語と新しい NGINX JavaScript 統合によって、より洗練された TCP および UDP 負荷分散ポリシーを作成できます。

NGINX Plus R10 の詳細

NGINX ModSecurity Web アプリケーション ファイアウォール

NGINX Plus R10 の目玉機能は、よく知られた信頼性の高いModSecurityテクノロジーを基盤とした WAF の最初のリリースです。 ModSecurity は、2002 年の最初のオープン ソース リリース以来、世界最大級の Web プロパティを悪意のあるユーザーから保護するのに役立ってきました。 これは一般にセキュリティの「スイスアーミーナイフ」と呼ばれています。 NGINX ModSecurity WAF は追加料金のオプションであり、動的モジュール リポジトリを通じてサブスクライバーに提供されます。

NGINX ModSecurity WAF は、重要なアプリケーションのセキュリティを確保するために必須のソリューションです。 これは、F5、Citrix、Imperva などが提供するような柔軟性に欠け、高価なハードウェア アプライアンスに代わるコスト効率の高い代替手段であり、ソフトウェアの柔軟性によってそれらの機能も上回ります。 NGINX ModSecurity WAF は、オンプレミス サーバー、パブリック クラウド、プライベート クラウド、ハイブリッド クラウドなど、あらゆる環境に導入できます。

NGINX ModSecurity WAFは、ウェブサイトとアプリケーションをDDoS攻撃から保護します。
NGINX ModSecurity WAFはDDoS攻撃からの保護に役立ちます

WAF は、ブロックおよび/またはログに記録する悪意のある動作を定義する「ルール」のデータベースに基づいて動作します。 OWASP ModSecurity コア ルール セット(CRS) は、ModSecurity で最も広く使用されているルール セットの 1 つです。 NGINX ModSecurity WAF は、次のような機能により、OWASP CRS を使用して幅広いアプリケーション攻撃を識別してブロックします。

  • レイヤー 7 攻撃保護– HTTP 違反、SQL インジェクション、XSS、RFI、LFI 攻撃など、さまざまな攻撃からアプリケーションを保護します。
  • DDoS 緩和– 高度なアプリケーション レベルの DDoS 攻撃とボットネットの影響を軽減および軽減することで、継続的な稼働時間を維持します。
  • リアルタイムのブラックリスト– 評価に基づいて悪意があると判明している IP アドレスからのトラフィックを拒否することで、既知の悪意のあるユーザーを自動的にブロックします。
  • PCI-DSS 6.6 コンプライアンス– 安全なオンライン取引のために、PCI-DSS 6.6 要件に準拠し始めます。
  • 監査ログ– 詳細なログの情報を使用して、攻撃やその他の異常なアプリケーション トラフィックに迅速に対応します。

追加のルール セットも、 TrustWaveなどのさまざまなベンダーから、さまざまなコスト レベルで入手できます。 さらに、強力な ModSecurity ルール言語を使用して、使用しているルール セットを拡張する独自のカスタム ルールを定義することもできます。

NGINX ModSecurity WAF のサポートは、NGINX, Inc. によって直接提供されます。 当社のサポート チームは、WAF および OWASP コア ルール セットのインストール、構成、問題のデバッグをお手伝いします。

NGINX ModSecurity WAF は、標準のパッケージ管理ツールを使用してインストールする NGINX Plus リポジトリ内の動的モジュールとして利用できます。 これらのコマンドは Debian ベースのオペレーティング システム用です。

# apt-get update # apt-get install nginx-plus # apt-get install nginx-plus-module-modsecurity

NGINX ModSecurity WAF モジュールを購入したサブスクライバー、およびアクセスをリクエストしたサブスクライバーと評価者のみが、 nginx-plus-module-modsecurityパッケージをダウンロードできることに注意してください。

NGINX ModSecurity WAF モジュールをロードするには、NGINX Plus 設定ファイルの最上位レベルの「main」コンテキストにload_moduleディレクティブを含めます。

NGINX Plus で NGINX ModSecurity WAF を有効にするには、 modsecurityディレクティブとmodsecurity_rules_fileディレクティブを追加してルール セットを指定します。

次に、NGINX Plus 構成をリロードします。

# nginx -t && nginx -s リロード

OAuth 2.0 および OpenID Connect のネイティブ JWT サポート

NGINX Plus R10 は JSON Web Token (JWT) 認証標準をネイティブでサポートしており、アプリケーションや API に高度な認証ソリューションを簡単に追加できます。

RFC 7519で定義されている JWT (「ジョット」と発音) トークンは、OAuth 2.0 プロトコルの上にある標準の ID レイヤーであるOpenID Connect標準におけるユーザー情報の基盤となるデータ形式です。 API とマイクロサービスのデプロイメント担当者も、そのシンプルさと柔軟性から JWT 標準に注目し始めています。

[編集者– ネイティブ JWT サポートを活用するユースケースについては、次のブログを参照してください。

]

APIの認証サービスを提供するために、NGINX Plus R10はJWTを検証します。
NGINX Plusはクライアントのアクセスを許可する前にJWTを検証します

NGINX Plus はリバース プロキシおよびロード バランサーとしてアプリケーションの前に配置され、各 HTTP リクエストで提供される JWT の検証をオフロードすることでアプリケーション開発を簡素化するのに最適な位置にあります。 これには 2 つの利点があります。 まず、NGINX Plus は、認証されていない、不正な、悪意のあるリクエストがアプリケーションに到達するのを阻止し、そのようなリクエストの処理に伴う労力とリスクからアプリケーションを保護します。

2 つ目の利点は、NGINX Plus が検証済みの JWT 内のすべてのフィールドにアクセスでき (署名検証後)、構成構文の固有のパワーと柔軟性を使用して、マイクロサービスと API の両方に高度な認証ソリューションを提供できることです。

  • マイクロサービスの一般的な使用例は、NGINX Plus で JWT を検証し、認証されたユーザーの ID を HTTP ヘッダーとしてバックエンド アプリケーションに提供することです。 これにより、すべてのマイクロサービスで同じ認証機能を何度も実装する必要がなくなります。
  • API の場合、NGINX Plus は、IP アドレスとエンドユーザーのおおよそのマッピングに依存するのではなく、ユーザーごとにアクセスをレート制限できます。

次のサンプル NGINX Plus 構成スニペットは、JWT を使用して Web サイトを保護する方法を示しています。

auth_jwtディレクティブは、NGINX Plus に、ドメイン (この場合はmyrealm )へのリクエストを行うユーザーを認証するために JWT を使用するように指示します。 auth_jwt_key_fileディレクティブは、トークン署名の検証に使用する JSON Web Key (JWK) を示します。これは、SSL/TLS 暗号化の公開キーのように機能します。 ファイルの場所には、NGINX Plus からアクセスできる必要があります。

NGINX Plus はトークンを検証して解析すると、JWT 内の「クレーム」に対して NGINX 変数を自動的に作成します。この変数はトークンに関連付けられたエンティティ (発行者、発行先のユーザー、対象受信者など) を表します。 変数名はすべて$jwt_claim_で始まります。 次に、 add_headerディレクティブを使用して、 $jwt_claim_変数の値に設定された HTTP ヘッダーの形式で、NGINX Plus がバックエンド サーバーにクレームを渡すようにすることができます。 この例では、NGINX Plus は、JWT のユーザー ID ( subクレーム) に対応する$jwt_claim_sub変数でユーザー ID をバックエンド アプリケーションに渡します。

NGINX Plus R8では、OAuth2 サポートのテクノロジー プレビューをリリースしました。 NGINX Plus R10 の実装では、お客様からのフィードバックを取り入れて、ユーザーとコンピューターの認証という複雑な世界で最も価値のあるユースケースに対応する、本番環境対応の実装を提供しています。

「デュアルスタック」RSAおよびECC証明書のサポート

すべてのアプリケーション トラフィックを SSL/TLS で暗号化する理由はたくさんあります。 Google は SSL/TLS で暗号化されたサイトを、より高い検索エンジンランキングで評価します。 さらに、HTTP/2 などの最新の Web 標準では、すべての Web サイトに SSL/TLS 暗号化が義務付けられています。

NGINX Plus R10 を使用すると、RSA 証明書と ECC 証明書の両方を使用して SSL/TLS サービスを公開できます。 当社のテストでは、ECC 証明書は同等の強度の RSA 証明書よりも最大 3 倍高速でした。つまり、サーバーあたりの SSL/TLS 接続数が増え、SSL/TLS ハンドシェイクが高速化します。 NGINX Plus は、各クライアントの機能に基づいて最適な証明書を選択するため、最新のクライアントは、従来の RSA のみのクライアントをサポートしながら、より高速な ECC 証明書を使用できます。

RSA 証明書と ECC 証明書の両方をサポートするには、次の例に示すように、仮想サーバーの構成に、証明書の種類ごとにssl_certificateディレクティブとssl_certificate_keyディレクティブのペアを含めるだけです。

透過プロキシ

より幅広いアプリケーションと展開モデルをサポートするために、 TCPおよびUDPロード バランシングなどの機能を NGINX Plus に継続的に追加しています。 NGINX Plus R10 では、NGINX Plus が任意の送信元 IP アドレスとポートを使用してアップストリーム サーバーにパケットを送信できるようにする透過プロキシ機能が追加されました。 これにより、IP 透過性や Direct Server Return などの構成が可能になります。

IP 透過性は、ロード バランサ (NGINX Plus) がアップストリーム サーバーに送信するパケットの送信元 IP アドレスとしてリモート クライアントの IP アドレスを使用する構成です。 つまり、アップストリーム サーバーは、パケットがロード バランサー上のローカル IP アドレスからではなく、リモート クライアントの IP アドレスから発信されたものであると認識します。 これは、アプリケーションがログ記録、セキュリティ、レート制限、または認証の目的で送信元 IP アドレスを参照する場合に重要です。

IP 透過性は、 Direct Server Return (DSR) と呼ばれるネットワーク負荷分散技術の構成要素でもあります。 NGINX Plus は、UDP ベースのプロトコル (TCP または HTTP は除く) に対して DSR を実行できるため、戻りパケットはロード バランサーを完全にバイパスしてリモート クライアントに直接送信されます。

NGINX Plusはリリースr10でダイレクトサーバーリターンをサポートしており、サーバーがクライアントに直接応答します。
DSRモードでは、バックエンドサーバーがクライアントに直接応答します。

IP 透過性と DSR は、 proxy_bind 、 fastcgi_bind 、 memcached_bind 、 scgi_bind 、およびuwsgi_bindディレクティブの新しいtransparentパラメータを使用して設定されます。 次の例は、DNS バックエンドに DSR を設定する方法を示しています。 proxy_responsesディレクティブは、NGINX Plus がサーバー応答を確認する必要がないことを指定します (DSR の場合、適切な値はゼロです)。

DSR が有効になっている場合、パッシブ ヘルス チェックは効果がないことに注意してください。これは、NGINX Plus がサーバーがクライアントに応答を送信したことを確認するためです。 DSR 構成では、アクティブなアプリケーション対応ヘルス チェックを構成することが必須です。 たとえば、負荷分散された DNS サーバーを構成するための詳細な手順を参照してください。

IP 透過性と DSR の構成は複雑であり、NGINX Plus ソフトウェアの範囲外となる追加のルーティングとパケット書き換えの要件があります。 詳細な手順については、弊社のブログの「透過プロキシとしての NGINX および NGINX Plus を使用した IP 透過性と Direct Server Return」を参照してください。

HTTP、TCP、UDP ベースのアプリケーション向け NGINX JavaScript モジュール

[編集者– NGINX JavaScript モジュールは以前は nginScript と呼ばれていました。 このモジュールは、NGINX Plus R12 (および NGINX 1.11.10) で一般公開されました。

その他の NGINX JavaScript モジュールの使用例の詳細については、 「NGINX JavaScript モジュールの使用例」を参照してください。

このセクションのコードは、 js_インポート 指令は、 js_include 指令の NGINX プラス R23 そしてその後。 詳細については、 NGINX JavaScript モジュールのリファレンス ドキュメントを参照してください。構成例のセクションに、NGINX 構成と JavaScript ファイルの正しい構文が示されています。 ]

NGINX Plus R10 には、新しい NGINX JavaScript 構成言語のプレビュー リリースが含まれています。 まだ機能は完成していませんので、これまでの作業に関するフィードバックをお待ちしています。 NGINX JavaScript を使用すると、JavaScript コードを使用して、HTTP、TCP、UDP トラフィックに対して複雑なカスタム アクションを実行できます。 アプリケーションの配信方法とセキュリティ保護方法を制御するための強力な新しい方法を提供します。 NGINX JavaScript を使用すると、次のことが可能になります。

  • 強力なJavaScriptプログラミング言語を使用して、NGINX Plusで直接「サーバーレス」関数を記述します。
  • APIデータのフォーマット、操作、変換
  • タイムサーバーなどのシンプルなTCPサービスを提供する
  • JavaScript を使用して NGINX 変数を設定し、カスタムの負荷分散決定やキャッシュ キーなどを作成します。

NGINX JavaScript プレビューは、動的モジュール リポジトリで入手できます。 標準のパッケージ管理ツールを使用してインストールできます。 これらのコマンドは Debian ベースのオペレーティング システム用です。

# apt-get update # apt-get install nginx-plus # apt-get install nginx-plus-module-njs

HTTP および TCP/UDP 用の NGINX JavaScript モジュールをロードするには、NGINX Plus 設定ファイルの最上位レベルの「main」コンテキストにload_moduleディレクティブを含めます。

次に、NGINX Plus 構成を再ロードして、NGINX JavaScript モジュールをロードします。

# nginx -t && nginx -s リロード

NGINX オープンソース ユーザーは、オープンソース コード リポジトリから NGINX JavaScript を入手できます。

JavaScript コードは、NGINX Plus 構成に直接は含まれません。 代わりに、 js_importディレクティブを使用して読み込まれます。 この例では、単純な「サーバーレス」関数の JavaScript コードが/etc/nginx/conf.d/functions.jsから読み込まれます。 js_contentディレクティブは、NGINX Plus に JavaScript 関数を呼び出して結果をクライアントに返すように指示します。

/etc/nginx/conf.d/functions.jsの JavaScript コードは、指定された文字セットで文字列を埋め込みます。

追加機能

NGINX Plus R10 では、次のような、完璧なアプリケーション配信を支援するための追加の改善が数多く導入されています。

  • Streamモジュールに実装された TCP/UDP ロード バランシングは、HTTP ロード バランシングと同等の機能を備えるようになりました。 新しくサポートされるモジュールには、A/B テスト用のSplit Clients 、クライアントの地理的位置に基づいてアクションを実行するGeoIP 、IP アドレスに基づいて変数を定義するGeo などがあります。 追加の NGINX 変数を通じてさらに詳しい情報を入手でき、変数をproxy_passディレクティブのパラメータとして使用してルーティングの決定を実行できます。
  • トラフィック量の多いアプリケーションによくある問題は、一時的なポート枯渇です。これは、OS で使用可能なポート番号が不足しているため、上流サーバーへの新しい接続を作成できない状態です。 これを克服するために、NGINX Plus は、利用可能な場合はIP_BIND_ADDRESS_NO_PORTソケット オプションを使用するようになりました。 このオプションを使用すると、標準の「4 タプル」(送信元 IP アドレス、宛先 IP アドレス、送信元ポート、宛先ポート) が一意である場合に、上流サーバーへの送信接続に送信元ポートを再利用できます。 これは、Linux カーネル バージョン 4.2 以降、およびglibc 2.22 以降のシステムで利用できます。
  • NGINX Plus は、新しい HTTP リクエストごとに新しい変数$request_id を自動的に生成し、リクエストに一意の「トランザクション ID」を効果的に割り当てます。 これにより、アプリケーションのトレースが容易になり、ログ分析ツールに APM 機能が提供されます。 トランザクション ID はバックエンド アプリケーションとマイクロサービスにプロキシされるため、システムのすべての部分で各トランザクションの一貫した識別子をログに記録できます。
  • proxy_request_buffering 、 fastcgi_request_buffering 、 scgi_request_buffering 、およびuwsgi_request_bufferingディレクティブが HTTP/2 で機能するようになり、リクエストのバッファリングを切り替えるために使用できるようになりました。
  • 新しいhttp2_body_preread_sizeディレクティブにより、HTTP/2 クライアントはリクエスト本文の送信をすぐに開始できるようになります。 このディレクティブは、NGINX Plus がクライアントのリクエスト本体の読み取りを開始する前に使用するバッファのサイズを制御します。

NGINX Plus Extras パッケージは非推奨になりました

NGINX Plus R9 のリリース時に事前にお知らせしたように、R10 は NGINX Plus Extras パッケージが含まれる最後のリリースとなります。

nginx-plusパッケージを使用し、実際に使用するnginx-plus-extrasパッケージ内のモジュールを動的にロードするように、インストールおよび構成手順を変更することを強くお勧めします。 NGINX Plus R11 以降では、これがnginx-plusパッケージに組み込まれていないモジュールを使用する唯一の方法になります。

nginx-plusパッケージと動的モジュールに切り替えるには、次の手順を実行します。

  1. nginx-plus-extrasパッケージを削除し、 nginx-plusと使用したい動的モジュールをインストールします。 Debian ベースのシステムの場合、適切なコマンドセットは次のとおりです。

    # apt-get update # apt-get remove nginx-plus-extras # apt-get install nginx-plus # apt-get install module-name

  2. /etc/nginx/nginx.confのメイン（最上位）コンテキストで、動的にロードされるモジュールごとにload_moduleディレクティブを追加します。

  3. 新しい設定の構文の妥当性を確認し、再ロードします。

    # nginx -t && nginx -s リロード

NGINX Plus をアップグレードまたは試用する

NGINX Plus を実行している場合は、できるだけ早くリリース 10 にアップグレードすることを強くお勧めします。 数多くの修正と改善が行われており、サポート チケットを発行する必要がある場合に、当社がサポートしやすくなります。 インストールとアップグレードの手順については、 NGINX Plus カスタマー ポータルをご覧ください。

注記： NGINX Plus R10 は、nginx-plus-extrasパッケージが含まれる最後のリリースです。 上記の「NGINX Plus Extras パッケージは非推奨です」を参照してください。

NGINX Plus をまだお試しいただいていない方は、Web アクセラレーション、負荷分散、アプリケーション配信、または強化された監視および管理API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 今すぐ30 日間の無料評価版を始めて、NGINX Plus がアプリケーションの配信とスケールアウトにどのように役立つかを実際に確認することができます。

NGINX Plus R10 の詳細情報

NGINX Plus R10 の主な新機能の詳細については、次の関連リソースを参照してください。

[NGINX ModSecurity WAF は2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF のサポート終了へ移行中」をご覧ください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"