Nginx プロキシ転送構成を通じてクロスドメイン API プロキシ転送を実装する方法

序文

WEB 開発では、クロスドメインリクエストが頻繁に発生します。クロスドメインの問題を解決する方法は、window.name、iframe、JSONP、CORS など多数ありますが、ここでは詳しく説明しません。異なるプロトコルとポートが関係するクロスドメインリクエスト方法は、プロキシを使用することです。ここでは、Nginx プロキシメソッドに焦点を当てます。

シナリオ
フロントエンドとバックエンドが分離された Web アプリケーションが、ポート 3000 を使用してローカルで起動されます。フロントエンドページには、http://127.0.0.1:3000 からアクセスできます。ページ内の一部の Ajax リクエストのアドレスは、http://127.0.0.1:3000/api/getList です。通常、次の図に示すように、404 でなければリクエストは失敗します。

このバックエンドサービスのインターフェイスは他のサーバーに保存されます。たとえば、会社のイントラネットでは、http://172.30.1.123:8081/api/getList を通じてテスト環境のサービスインターフェイスにアクセスできます。

この場合のリクエストには、異なるポートを使用したクロスドメインリクエストが含まれるため、Nginx を使用してリクエストをプロキシできます。

Nginx プロキシ設定リファレンス

まず、Nginx 設定ファイルを見つけます。

Windows のパスは、Nginx をインストールしたディレクトリです。たとえば、私の場合はドライブ C のルートディレクトリ、つまり c:\nginx\conf\nginx.conf にあります。
Mac システム構成ファイルのパスは、/usr/local/etc/nginx/nginx.conf です。Finder で、Shift + Command + G を押して /usr/local/etc/nginx/ と入力し、ディレクトリに入ります。

Nginx 構成ファイルに次の構成を追加します。

サーバー{
 聞く 80;
 サーバー名 127.0.0.1;

 位置 / {
 プロキシパス http://127.0.0.1:3000;
 }

 場所 ~ /api/ {
 プロキシパス http://172.30.1.123:8081;
 }
}

上記の構成は次のように理解できます。

ポート 80 をリッスンし (Nginx はデフォルトでポート 80 から開始します)、http://127.0.0.1 のすべてのリクエストサービスを 127.0.0.1 ポート 3000 に転送します。
http://127.0.0.1/api/ または http://127.0.0.1/api/getList リクエストを http://172.30.1.123:8081 に転送します。

仕上げる

上記の設定後、http://127.0.0.1 (IP アクセスを使用する場合) を介して WEB アプリケーションに直接アクセスでき、関連する API リクエストも Nginx 設定に従って行われます。ブラウザに表示される /api/getList リクエストは 127.0.0.1 ポート 80 ですが、実際にはこのリクエストは Nginx によって http://172.30.1.123:8081/api/getList に転送されています。

最適化：

基本的なプロキシ機能は上記の設定と同じくらいシンプルです。

ただし、実際の IP サービスを取得する必要がある場合は、次のように実際の IP に関する構成も追加する必要があります。

サーバー{
 聞く 80;
 サーバー名 127.0.0.1;

 位置 / {
 プロキシパス http://127.0.0.1:3000;
 proxy_set_header ホスト $host:80;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }

 場所 ~ /api/ {
 プロキシパス http://172.30.1.123:8081;
 proxy_set_header ホスト $host:80;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

proxy_set_header 構成は、HTTP 要求ヘッダーを変更します。ここで、Host は要求されたホスト名、X-Real-IP は要求の実際の IP、X-Forwarded-For は要求を開始したユーザーを示します。

ここでは Nginx がプロキシサーバーであるため、proxy_set_header を通じてこの情報を構成する目的は、サーバーが実際のリクエストヘッダーを取得できるようにすることです。

フレンドリーなヒント:

Nginx の各構成ステートメントの後にポイントを追加する必要があります。そうしないと、構成エラーが報告され、混乱することになります。

拡大する

ホストをバインド

サーバーにアクセスするために IP アドレスを入力するのが面倒な場合は、ホストを自分で変更することもできます。ホスト変更ツール SwitchHosts をお勧めします。

ホスト変更リファレンス:

127.0.0.1 www.domain.com #必要なドメイン名に変更します

ホストがバインドされている場合は、Nginx 構成で指定したドメイン名を直接構成することもできます。次に例を示します。

サーバー{
 聞く 80;
 server_name www.domain.com; #ここで IP をドメイン名に変更します#...
}

ホストを変更した後は、http://www.domain.com などのドメイン名から直接アクセスできます。

場所について

上記の構成では、ローカライズ後の構成について混乱するかもしれません。ローカライズ後の一般的な要件は次のとおりです。

地域 / {
 # すべてのリクエストは次のルールに一致します # すべてのアドレスが / で始まるため、このルールはすべてのリクエストに一致します # xxx 設定はここに記述されます}

場所 = / {
 # 完全一致 /、任意の文字列が続くアドレスは一致しません}

ローケーション /api {
 # /api で始まるすべての URL に一致します。/api/getList など、/api の後の URL も含まれます。
 # 一致したら、検索を続けます。# これは、次の正規表現と一致しない場合にのみ使用されます。}

ローケーション ~ /api/abc {
 # /api/abc で始まるすべての URL に一致します。/api/abc/getList など、/api/abc の後の URL も含まれます。
 # 一致したら、検索を続けます。# これは、次の正規表現と一致しない場合にのみ使用されます。}
/ はユニバーサル マッチングに使用されます。他に一致するものがない場合、すべてのリクエストが一致します。先頭の = は完全一致を示します。たとえば、A では、ルート ディレクトリで終わるリクエストのみが一致し、その後に文字列を続けることはできません。
先頭の ^~ は、URI が正規一致ではなく通常の文字列で始まることを示します。先頭の ~ は、大文字と小文字を区別する正規一致を示します。
~*は大文字と小文字を区別しない正規の一致を示します

より詳細なロケーショニング正規マッチングルールについては、nginx 設定の場所の概要と書き換えルールの記述を参照してください。

追記

筆者もNginx初心者ユーザーです。この知識をわかりやすく記録し、困っている人と共有して一緒に勉強できればと思っています。抜けがあれば指摘してください。よろしくお願いします！

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。

以下もご興味があるかもしれません: