nginxフォワードプロキシとリバースプロキシの詳細な説明

フォワードプロキシ

イントラネットがあると仮定する

イントラネットには2台のマシンがあり、マシンaのみがインターネットにアクセスできます。

bはインターネットにアクセスできませんが、aとbはインターネットを介して接続されています

このとき、b が外部ネットワークにアクセスしたい場合は、a を転送プロキシとして使用して外部ネットワークにアクセスできます。

フォワード プロキシは、イントラネット内のターゲット サーバーをシミュレートし、イントラネット内の他のマシンからの要求をターゲット サーバーに転送します。

外部ネットワーク内の実際のターゲットサーバーに転送する

したがって、フォワード プロキシはイントラネット内の他のマシンからの要求を受け入れます。

リバースプロキシはその逆です

また、複数のマシンを備えたイントラネットであり、そのうちの 1 台だけが外部ネットワークに接続されています。

ただし、リバース プロキシはイントラネット マシンからのアクセス要求を受け入れません。

リバースプロキシは外部ネットワークからのアクセス要求を受け入れます

次に、イントラネット内の他のマシンにリクエストを転送します。

外部ネットワークからリクエストを送信したユーザーは、リバースプロキシサーバーがリクエストを誰に転送するかを知りません。

マシンにフォワードプロキシ機能を設定するには

図に示すように、nginx設定ファイルを編集します

上の図は設定ファイルの内容を示しています

サーバーをフォワードプロキシサーバーとして構成する場合

この仮想ホスト設定ファイルはデフォルトの仮想ホストである必要があります

このマシンにアクセスするためのすべてのネットワーク要求は、最初にこの仮想ホストにアクセスする必要があるためです。

ここでdefault_serverを設定する必要があります

次に、元のデフォルトの仮想ホスト構成ファイル名を変更する必要があります。

図に示すように、default.conf設定ファイルの名前を変更します。

これにより、元のデフォルトの仮想ホスト構成ファイルがキャンセルされます。

デフォルトの仮想ホスト設定ファイルはdefault.confであるため

設定ファイル内のリゾルバは119.29.29.29です

DNSアドレスを設定することを意味します

フォワードプロキシなので、イントラネットから要求されたドメイン名を受け入れた後

実際にアクセスしたいサーバーにリクエストを送信するには

しかし、イントラネットから送信されるドメイン名にはIPアドレスが含まれていません

そのため、IPアドレスを解決するためにドメイン名をDNSサーバーに送信する必要があります。

IPアドレスを取得したら、サーバーに転送してアクセスすることができます。

ここでDNSアドレスを設定する必要があります

イントラネットドメイン名を受け入れると、ドメイン名は解決のためにこのDNSに送信されます。

図に応じて以下の場所を設定できます

このようにして、フォワードプロキシサーバーがイントラネットマシンからの要求を受け入れた後、

ドメイン名は解決のために設定された DNS に送信され、その後、実際のサーバーにアクセスされます。

次に、実サーバーから返されたコンテンツを、リクエストを行ったイントラネットマシンに送信します。

nginx リバースプロキシ

リバースプロキシの例を作成する

図に示すようにテスト仮想ホスト構成ファイルを作成します。

リスニングポートは 8080、ドメイン名は www.test.com です

ルートディレクトリは/data/wwwroot/test.comです。

仮想ホストにアクセスしたときに表示されるホームページファイルはindex.htmlです。

図に示すように、仮想ホストのルートディレクトリ/data/wwwroot/test.comを作成します。

次に echo "test.com_8080" > !$/index.html を使用します。

test.com_8080というコンテンツを含むホームページファイルを作成します。

このファイルは/data/wwwroot/test.comディレクトリにあります

図に示すように、新しいリバースプロキシ仮想ホスト構成ファイルを作成します。

リスニングポートは 80、ドメイン名は www.test.com です

次の場所 / にはリバースプロキシ設定が含まれています

この仮想ホストにアクセスすると、アクセス要求は127.0.0.1:8080に送信されます。

図に示すように、curlを使用して127.0.0.1:8080仮想ホストにアクセスします。

結果は test.com_8080 となり、この仮想ホストにアクセスできることを意味します。

図に示すように、別の仮想ホスト構成ファイルを作成します。

前回のテスト仮想ホストと同様

しかし、この仮想ホストにはドメイン名が設定されていません

返される場所設定の内容は8080のデフォルト文字列です

保存して終了し、nginxをリロードします

テスト仮想ホストのデフォルトのサーバー設定もキャンセルします

つまり、127.0.0.1:8080は2つの仮想ホストに対応する。

1つはテスト仮想ホストで、もう1つは8080のデフォルト仮想ホストです。

これら2つの仮想ホストのIPとポートはまったく同じです

両者の違いは、テスト仮想ホストにはドメイン名があることです

8080のデフォルトの仮想ホストにはドメイン名がありません

8080デフォルトがデフォルトの仮想ホストとして設定されました

127.0.0.1:8080にのみアクセスする場合

アクセスは8080のデフォルト仮想ホストに対して行う必要があります

テスト仮想ホストにアクセスする場合は、テスト仮想ホストのドメイン名を追加する必要があります。

テスト仮想ホストに正常にアクセスするには

図に示すように、curl 127.0.0.1:8080/にアクセスして返される結果は8080デフォルトであることがわかります。

curl -x127.0.0.1:8080 www.test.com を使用します。

ここではドメイン名が含まれており、返される値はtest.com_8080です。

テスト仮想ホストにアクセスする場合は、IP ポートをドメイン名にバインドする必要があります。

図に示すように、curlは127.0.0.1:80ドメイン名www.test.comにアクセスします。

返される結果は test.com_8080 であり、リバース プロキシが成功したことを示しています。

ポート80にアクセスしたが、実際にはポート8080の仮想ホストの内容が返された

図に示すように、リバース プロキシ仮想ホストの proxy_pass 行の下の次の行をコメント アウトします。

保存して終了し、nginxをリロードします

図に示すように、curlを使用して127.0.0.1:80ドメイン名www.test.comにアクセスします。

返される実際の値はデフォルトで8080です

しかし、アクセスしたいのはテスト仮想ホストです

図に示すように、proxy_set_header Host $host;

このコード行はアクセスするドメイン名を指定します

上記は127.0.0.1:8080を設定します

リバースプロキシが使用される場合、このIPポートを指します

ホストを設定しない場合は、仮想ホスト127.0.0.1:8080にのみアクセスします。

ホストが設定されている場合は、指定されたホストにバインドされた127.0.0.1:8080を指します。

ここで、$host はシステム変数であり、その実際の値は現在の仮想ホストの server_name です。

つまり、www.test.com、server_nameとは何ですか、hostの値は何ですか

ここでホストを設定することは、curl -x127.0.0.1:8080 www.test.com と同等です。

ここでホストが設定されていない場合は、127.0.0.1:8080のみにアクセスされます。

このようにして、ドメイン名をIPポートにバインドすることができます

図に示すように、proxy_passはIPポートの記述に加えて、ドメイン名を直接記述することもできる。

ここではwww.123.com:8080/と書かれています

しかし、このように記述すると、nginxはこのドメイン名がどこを指しているかわかりません。

したがって、システム内の対応するIPもバインドする必要があります

たとえば、/etc/hostsファイルに、バインドするドメイン名とIPアドレスを記述します。

このようにして、nginxのproxy_passのドメイン名システムはIPアドレスを解決します。

次にこのIPポートにアクセスします

以下のproxy_headerホストはドメイン名を設定するために使用されます

このドメイン名はアクセスのために上記のIPポートにバインドされます

上記のIPポートがIPではなくドメイン名として記述されている場合

上記のドメイン名はIPアドレスの解決に使用されているため、下記のドメイン名と競合しません。

以下に指定されたドメイン名は、アクセスのために上記で解決されたIPポートにバインドされます。

この例では、nginxのグローバル変数である$hostを使用します。

この変数は実際には値に対応しており、現在の仮想ホストserver_nameの値です。

しかし、一般的に言えば、IPポートを直接記述する方が便利です。

上記はIPポートを指定するものです

以下は、IPポートにバインドされたホストドメイン名を指定します。

nginx リバースプロキシ 02

図に示すように、proxy_pass命令の後にURLを続けることができる。

フォーマットは3つあります: 伝送プロトコル + ドメイン名 + uri (アクセスパス)

トランスポート プロトコル + IP ポート + URI

トランスポートプロトコル + ソケット

ここで、unix、http、httpsはすべて伝送プロトコルの種類です。

ドメイン名 + uri と IP ポート + uri とソケットはすべてアクセス パスです

ソケットは通常、プログラム専用のアクセス ポートです。

ソケットへのアクセスは特定のプログラムへのアクセスなので、パスを使用する必要はありません。

図に示すように、proxy_passを書き込む場合、書き方によって結果が異なります。

たとえば、場所 /aming/

アクセスしたパスに/aming/が含まれている場合、トリガーされます

ここでproxy_passが実行されます

ただし、location に proxy_pass を書き込む方法が異なると、実際のアクセス パスも異なります。

アクセスしたパスに/aming/ディレクトリが含まれているためproxy_passが実行されますが

ただし、実際のアクセスパスには必ずしも/aming/が含まれているわけではありません。

この例では、仮想ホスト内の /aming/a.html ファイルにアクセスします。

proxy_pass の記述方法に応じて、実際にアクセスされるパスは異なります。

IPポートの後にディレクトリ記号がない場合

/aming/a.htmlにアクセスする。これが我々が望んでいることだ。

IPポートの後にルートディレクトリ記号/が続く場合

すると、ルート ディレクトリ内の a.html ファイルに直接アクセスされることになりますが、これは明らかに間違っています。

IP ポートの後に /linux/ が続く場合は、/linux/ 内の a.html ファイルにアクセスします。

IPポートの後に/linuxが続き、最後にディレクトリシンボル/がない場合

/linuxa.html にアクセスします

したがって、/aming/a.htmlに正しくアクセスしたい場合は

書き方は 2 通りあります。1 つは IP ポートの後にディレクトリ シンボルを追加しないことです。

2番目は、ip port/aming/と完全に記述することです。

上記の例によれば、IPポートの背後にどんなディレクトリがあっても、

実際のアクセスパスは、アクセスするファイルの名前（a.html）になります。

IPポートの後ろのディレクトリに直接追加する

したがって、IPポートの後にディレクトリシンボルがない場合、システムは自動的にディレクトリパス/aming/a.htmlを追加します。

ディレクトリシンボルが存在する場合、a.html はこのディレクトリシンボルの直後に配置されます。

2番目のケースは、ip port + /linux

実際の結果は/linuxa.htmlにアクセスすることです

これは、linuxの後にディレクトリシンボル/が続かないことが原因である可能性があります。

そのため、システムはlinuxを未完成のファイル名とみなします

次にファイル名a.htmlをlinuxと一緒に貼り付けます。

これは、アクセスするファイルが/linuxa.htmlであることを意味します。

したがって、どのパスを記述する場合でも、ディレクトリ記号/が続く必要があります。

リバースプロキシ03

図に示すように、proxy_set_header は、プロキシされたサーバーが受信できるヘッダー情報を設定するために使用されます。

たとえば、3台のコンピュータabcがある。

アクセスに使用するコンピュータはaで、アクセス要求はaから送信されます。

b はリバース プロキシ サーバーであり、送信されたアクセス要求を受信します。

cはリバースプロキシされているサーバーであり、実際にアクセスしたいサーバーです。

bはアクセス要求をcに転送します

proxy_set_header が設定されていない場合、b がリクエストを c に転送するときに、対応するヘッダー情報は転送されません。

このパラメータが設定されている場合、リクエストを転送するときに対応するヘッダー情報が含まれます。

変数$remote_addrと$proxy_add_x_forwarded_forはnginxの組み込み変数です。

$remote_addr 変数には、リバース プロキシ サーバー自体の IP アドレスが格納されます。

$proxy_add_x_forwarded_for 変数には、クライアント コンピューターの IP アドレスが格納されます。

この変数が設定されていない場合、c サーバーはアクセス要求の実際の送信元アドレスを認識しません。

この変数を設定することで、C サーバーはアクセス要求がどの IP アドレスから送信されたかを知ることができます。

図に示すように、www.test.com仮想ホストの設定ファイルを編集します。

この仮想ホストがアクセスしたいcサーバーであると仮定します

アクセス要求の送信元アドレスと実際の送信元アドレスを表示するために、2つのエコーが場所に設定されます。

$remote_addrはリバースプロキシサーバーのアドレスを記録します

$proxy_add_x_forwarded_forはアクセス要求の実際の送信元アドレス、つまりクライアントアドレスを記録します。

この設定により、この仮想ホストにアクセスすると、これら 2 つの変数に格納されている値が表示されます。

保存して終了し、設定ファイルを再読み込みします。

図に示すように、リバースプロキシサーバーの仮想ホストの設定ファイルを編集します。

写真の通り、場所がわかります

proxy_set_header X-Real-IP 行と proxy_set_header X-Forwarded-For 行はコメントアウトされています。

まずテストを行い、保存して終了し、設定ファイルを再読み込みします。

図に示すように、curlを使用して192.168.133.140:80からのアクセス要求をテストします。

IP アドレス 192.168.133.140 は、実際にはクライアント IP アドレスです。

アクセス要求はこのIPから送信されるため

ただし、テスト後、実際には 2 つの 127.0.0.1 ループバック アドレスが表示されていることがわかります。

IP 192.168.133.140 がありません

このテストでは、リバース プロキシ サーバーと実際のサーバーの両方がローカル マシン上に存在します。

したがって、実サーバ c が受信したアクセス要求の送信元 IP アドレスは、ローカル マシンのループバック アドレスになります。

リバースプロキシサービスbは、内部ループバックアドレス127.0.0.1を介して実サーバcに要求を送信します。

両方のサーバーが同じマシン上にあるため、同じマシン上のプログラム間の通信は基本的に 127.0.0.1 ループバック アドレスを介して行われます。

したがって、cの$remote_addrの値は127.0.0.1です。

リバースプロキシサーバーBは$proxy_add_x_forwarded_forを設定していないため

したがって、実サーバー c が受信した $proxy_add_x_forwarded_for 変数の値は、要求が送信された IP アドレスになります。

それは127.0.0.1です

$proxy_add_x_forwarded_for この変数は実際に

リクエストが通過した IP アドレスの合計の変数値。複数の IP アドレスはカンマで区切られます。

送信されたアクセス要求が$proxy_add_x_forwarded_for変数を設定しない場合

すると、受信側でのこの変数の値は、アクセス要求によって送信された最後の IP アドレスとなり、remote_addr と同じになります。

たとえば、アクセス要求はaからb、そしてcです

bが$proxy_add_x_forwarded_forを設定した場合

この変数の形式はa_ip、b_ipです。

つまり、aのIPとbのIPが記録されます。

途中にさらにサーバーがある場合は、それらの IP アドレスもコンマで区切られて記録されます。

もちろん、各プロキシサーバーは変数$proxy_add_x_forwarded_forを設定する必要があります。

そうしないと、次のプロキシ サーバーの変数 $proxy_add_x_forwarded_for に、以前に渡された IP アドレスが記録されません。

以前のサーバーのIPアドレスのみ記録できます

このテストでは、bは$proxy_add_x_forwarded_forを設定していないため

したがって、cサービスの$proxy_add_x_forwarded_for変数の値は$remote_addrの値と等しくなります。

図に示すように、2番目のテストでは、リバースプロキシサーバーbの設定ファイルを編集します。

場所のX-Real-IPとX-Forwarded-Forの2行のコメントを解除します。

保存して終了し、設定ファイルを再読み込みします

図のように再度テストします

返された結果を見ることができます。最初の行のremote_addrの値は127.0.0.1です。

これはプロキシサーバー B の IP アドレスです。

2 行目の $proxy_add_x_forwarded_for の値は 2 つの IP アドレスです。

curlコマンドでは、アクセス要求は192.168.133.140から送信されます。

つまり、クライアントAのIPアドレスは192.168.133.140です。

bのIPは127.0.0.1です

$proxy_add_x_forwarded_for は、c へのアクセス要求が通過する IP アドレスを記録します。

アクセス要求はaからbへ、そしてbからcへ

したがって、$proxy_add_x_forwarded_for 変数には、A の IP アドレスと B の IP アドレスが記録されます。

アクセス要求は、cに到達する前にこれらの2つのIPアドレスを通過するため、

将来リバースプロキシを実行するときは、これらの変数の行を設定する必要があります

背後にある実サーバーはアクセス要求の実IPアドレスを取得できる

リバースプロキシ04

図に示すように、リダイレクト適用のシナリオはそれほど多くなく、主に 3 つの書き方があります。

この関数は、プロキシサーバーから返される場所とヘッダー情報を更新します。

最初の書き方は、返されたヘッダー情報をリダイレクトすることです。

置換は変更される情報である

リダイレクトは置換に変更されます

2 番目の書き方は default で、これはデフォルト設定を意味します。

3番目のオフはリダイレクト機能をオフにすることを意味します

図に示すように、プロキシサーバーの設定ファイルをテストして編集します。

テストが成功するにはいくつかの条件を満たす必要があります

まず、場所の後に続くことができるのはルート ディレクトリ/のみであり、他のものは続くことができません。

2番目の条件は、proxy_passの後のURLの後に/記号を続けることができないことです。

通常は / で終わる必要がありますが、ここでは / で終わることはできません。

アクセスするディレクトリは実際に存在している必要があります。存在しない場合は、作成できます。

次に、ディレクトリ内にindex.htmlファイルを作成し、その中の文字列コンテンツを編集することもできます。

保存して終了し、設定ファイルを再読み込みします

図に示すように、プロキシサーバーの設定ファイルを編集します。

図に示すように、このシンプルな形式で記述します

保存して終了し、設定ファイルを再読み込みします

図に示すように、curl がアクセスをテストするときに、aming の後に / が続くと、index.html ファイルにアクセスします。

しかし、アクセスしたいのはディレクトリ自体であり、その中のファイルではありません。

したがって、crulling の場合、アクセスするアドレスは / 記号で終わることはできません。

この方法でamingディレクトリにアクセスできます

ご覧のとおり、返されたコードは301で、これは永続的なリダイレクトを意味します。

下記の場所の後のフィールドはポート8080のアクセスパスです

図に示すように、プロキシサーバーの設定ファイルを編集します。

access_log /tmp/456.log を追加します。

これにより、サーバーのアクセス ログが開きます。アクセス ログを確認すると、アクセス プロセスをより明確に理解できます。

保存 終了 再読み込み

図に示すように、再カールテストでは、今度はテストは/記号で終わります

cat /tmp/456.log アクセスログを表示

ログ情報にホストやポートなどの情報が含まれていないことが判明

この場合、nginx.conf設定ファイル内のフォーマット設定を変更することができます。

図に示すように、設定ファイル内の log_format main の 3 行は元々コメント アウトされていました。

これらの行を有効にするには、コメントを削除します。これは、ログ返送情報の形式設定です。

図に示すように、最後に 2 つの nginx 変数 $host $server_port を追加します。

次に、保存して終了し、再ロードすると、アクセス ログに表示される情報に、これら 2 つの変数の情報が追加されます。

図に示すように、プロキシ サーバー構成ファイルを編集し、access_log 構成も追加します。

ログアドレスは/tmp/proxy.logです

nginx.confの設定形式はmainで命名されているので、最後にmainを追加します。

ここでmainを追加すると、ログ情報を表示するためにmain命名形式を使用することを意味します。

図に示すように、プロキシサーバーのaccess_logも

ログ情報をメイン形式で表示するには、最後に main を追加する必要があります。

保存して終了し、再読み込み

図に示すように、今回はcurlは最後に/記号を付けてテストします。

456.log バックエンド サーバー ログを確認すると、ポート 8080 にアクセスされていることが分かります。

proxy.log プロキシ サーバー ログを確認すると、ポート 80 がアクセスされていることがわかります。

ネットワークコードは200で、正常です。

写真に示すように、今回はアクセスは/記号なしで終了します

戻り値は301であることがわかります

proxy.logを確認すると301が返されます

図に示すように、2つのログを再テストして確認します。

301～200のログ情報を見る

つまり、ポート80にアクセスし、ポート8080にジャンプしたことが確認されました

しかし、クライアントはポート8080にアクセスできません

図に示すように、proxy_redirectを使用するとこの問題を解決できます。

ここは http://$host:8080/ / です。

この方法では、最初に返された 8080 ポート情報を削除できます。

保存 終了 再読み込み

示されているように、再テスト

ご覧のとおり、返された値は301です。

次に、場所の後のアドレスには、ポート 8080 に関する情報がありません。

リバースプロキシ05

proxy_bufferingはバッファリングを意味します

バッファリングとは、メモリ内に領域を割り当て、そこにデータを書き込むことです。

一定量のデータが書き込まれると、バッファ内のデータがハードディスクに書き込まれます。

これにより、ハードディスクの読み取りと書き込みの頻度を大幅に削減できます。

バッファリングを行わないと、データが生成されるたびにハードディスクの読み取りと書き込みを行う必要があり、ハードディスクに大きな負担がかかります。

クライアント a、プロキシ サーバー b、プロキシ サーバー c という 3 つのオブジェクトがあるとします。

aがリクエストを送信し、bがリクエストを受信して​​cに転送する

cはbにデータを返し、bはそのデータをaに送信する。

これは一般的な操作ですが、アクセス要求が多数ある場合

または、アクセス要求を行うクライアントが多数いる

次にプロキシサーバーbとプロキシサーバーcについて

各リクエストはこのプロセスに従って処理する必要があり、大きな負担となる。

Proxy_buffering は、プロキシ サーバー b のメモリ内に 1 つ以上のバッファー領域を設定します。

バッファ領域がいっぱいになると、データは対応するクライアントに転送されます。

これにより、プロキシサーバーbのデータ転送回数が大幅に削減され、負担が軽減されます。

proxy_bufferingがオンの場合、proxy_busy_buffer_sizeはデータをいつ送信するかを決定します。

このプロセス中にバッファ領域がいっぱいになると、データオーバーフローが発生します。

追加データは、ハードディスクに保存される一時ファイルである temp_file に書き込まれます。

proxy_bufferingがオフの場合、cによって返されたデータはbからaに直接転送されます。

その他の操作は行われません

図に示すように、proxy_bufferingがオンかオフかに関係なく

proxy_buffer_size このオプションは有効です。このパラメータはバッファサイズを設定するために使用されます

このバッファには、サーバーからフィードバックされたヘッダー情報が格納されます。

ヘッダー情報を格納するのに十分なサイズがない場合は、502 エラー コードが表示されます。

4Kに設定することをお勧めします

図に示すように、proxy_buffersは各リクエストのバッファ数と各バッファの特定のサイズを定義します。

ここでは 8 4k が定義されています。これは、それぞれサイズが 4k のバッファーが 8 つあることを意味します。

バッファサイズの合計は8*4 = 32 kです。

リクエストが 10,000 件あると仮定すると、バッファは 8 * 10,000 バッファになります。

この設定はリクエストごとに行われるため、合計8つのバッファだけではない。

proxy_busy_buffer_sizeは、クライアントにデータを転送する前に必要なデータ量を定義します。

ここでの定義は16kなので、このリクエストに属するbのバッファが16kのデータを受信すると

データは

ここには 8 つのバッファがあり、合計サイズは 32k です。バッファは通常、次の 2 つの状態になります。

1 つはデータ受信用、もう 1 つはデータ送信用です。データの受信と送信を同時に行うことはできません。

proxy_busy_buffer_sizeはデータを送信するためのバッファのサイズを定義します

したがって、proxy_busy_buffer_size のサイズは、バッファの合計サイズよりも小さくする必要があります。

受信したデータがproxy_busy_buffer_sizeで設定されたデータ量に達したとき

これらのバッファはデータ送信状態になり、残りのバッファはデータ受信状態になります。

要求されたデータの合計量がproxy_busy_buffer_sizeで設定された値より少ない場合

その後、b は受信後 a に直接転送されます。

要求されたデータの合計量がproxy_busy_buffer_sizeで設定された値より大きい場合

バッファが受信したデータの量がproxy_busy_buffer_sizeで設定された値に達すると

この部分のデータは最初に

図に示すように、proxy_temp_pathは一時ファイルの保存ディレクトリを定義します。

たとえば、aがリクエストを送信し、プロキシサーバーbがこのリクエストに対してaに割り当てるバッファサイズの合計が32kであるとします。

ただし、C サービスがこの要求に応答するデータの量は 100 MB であり、バッファ サイズよりもはるかに大きくなります。

この場合、b が c のデータを受信すると、大量のデータがバッファからオーバーフローします。

これらのオーバーフロー データは、b のハード ディスク上の一時ファイルに保存されます。

proxy_temp_pathは一時ファイルが保存されるパスとサブディレクトリ階層を定義します。

ここで定義されているパスは/usr/local/nginx/proxy_tempで、これはディレクトリ名です。

一時ファイルはこのディレクトリに保存されます

後ろの数字 1 と 2 はサブディレクトリ レベルを示します。

前のディレクトリパスは自分で定義し、サブディレクトリはシステムによって自動的に作成されます。

作成するサブディレクトリレベルの数は、後ろの数字で設定できます。

例えば、1 とだけ書いた場合、サブディレクトリは 1 レベルのみ存在し、サブディレクトリ名は 0 ～ 9 の形式で命名されていることを意味します。

定義上、proxy_temp_path は 3 レベルのサブディレクトリをサポートしているため、3 つの数値を記述できます。

例えば1と書いた場合、サブディレクトリの数と命名方法は0～9で合計10

2と書いた場合は00～99、合計100、3と書いた場合は000～999、合計1000のサブディレクトリを意味します。

サブディレクトリはこれらの番号に従って名前が付けられます。

1 3と書くと、サブディレクトリが2つのレベルに分かれていることを意味し、最初のレベルは10のサブディレクトリ0-9です。

2番目のレベルは000-999 1000サブディレクトリであり、逆順に記述することもできる3 1

このように、最初のレベルには 1000 個のサブディレクトリがあり、各ディレクトリには 2 番目のレベルに 10 個のサブディレクトリがあります。

proxy_max_temp_file_sizeは一時ファイルの合計サイズを定義します

例えば、ここで100Mに設定されている場合、各一時ファイルは最大100Mであることを意味します。

一時ファイルのデータが転送されると自動的に削除されます

proxy_temp_file_write_sizeは、一時ファイルに同時に書き込まれるデータの合計サイズを定義します。

ここで8kや16kなどの値を定義します

同時に書き込まれるデータの量がこの値より少ない場合は、同時に書き込まれるデータの量を増やします。

この値より大きい場合は、同時に書き込まれるデータの量を減らしてください。

同時に書き込まれるデータの量が多すぎるとハードディスクの IO 負荷が大きくなりすぎ、少なすぎるとハードディスクのパフォーマンスが十分に活用されません。

したがって、ハードディスクに過負荷をかけずにそのパフォーマンスを最大限に活用できるように、速すぎず遅すぎない値を設定してください。

図に示すように、これはproxy_bufferingを使用する例です。

まず、オンに設定します。つまり、バッファ機能をオンにします。

ヘッダーファイルが格納されるバッファ領域のサイズは4kです

そして、他のデータ用のバッファ領域が2つあり、それぞれサイズは4kです。

するとbusy_buffersのデータ量は4kになる。

バッファに受信されたデータの量が4kに達すると、データは送信されます。

次に、一時ファイルのパス定義が定義され、2 つのレベルのサブディレクトリが定義されます。

それぞれ 1 と 2 であり、最初のレベルには 0 から 9 までの 10 個のサブディレクトリがあることを意味します。

そして、各サブディレクトリの下の 2 番目のレベルには、00 から 99 までの 100 個のサブディレクトリがあります。

各一時ファイルのサイズは20Mです

一時ファイルに同時に書き込まれるデータの量は8kと定義されます

リバースプロキシ06

図に示すように、proxy_cache を使用するには、まず proxy_buffering 機能をオンにする必要があります。

proxy_cacheはキャッシュ関数です

クライアントaがリクエストを送信します。aが要求したデータがプロキシサーバーbのキャッシュに保存されている場合、

次に、b はサーバー c からデータを要求せずに、関連データを a に直接送信します。

キャッシュ機能が有効になっていない場合、サーバー a からの要求ごとに、プロキシ サーバー b はサーバー c にデータを要求します。

a が 2 回要求したデータが同じである場合、サーバー c にも 2 回データを要求します。

キャッシュ機能がオンになっている場合、最初に要求されたデータはキャッシュに保存されています。同じデータを2回目に要求すると

bはcにアクセスしてデータを取得する代わりにキャッシュから直接データを取得するため、サーバーcの負担が軽減されます。

要約すると、バッファリングによりプロキシ サーバー b の負荷を軽減でき、キャッシュによりプロキシ サーバー c の負荷を軽減できます。

図に示すように、proxy_cache関数はオンとオフを切り替えることができます。

proxy_cache offはキャッシュ機能をオフにすることを意味します

proxy_cacheゾーンはキャッシュゾーンを開くためのもので、ゾーンはキャッシュゾーンの名前です

キャッシュエリア名は任意に付けることができ、ゾーンや123などの名前にすることができます。

ここでキャッシュ名を書き込むと、この名前にちなんで命名されたキャッシュが開かれます。

nginxバージョン0.7.66以降では、proxy_cacheを有効にした後

また、プロキシされたサーバーの http 応答ヘッダー内の Cache-Control および Expire ヘッダー フィールドも検出します。

cache-control の値が no-cache の場合、このリクエストのデータはキャッシュされません。

図に示すように、curl -Iはウェブサイトからデータを要求します

返されたヘッダー ファイル情報には、Cache-Control の後の値が含まれていることがわかります。

no-cache が存在する場合、このリクエストによって返されるデータはキャッシュされません。

図に示すように、proxy_cache_bypassパラメータは特定の状況で設定されます。

要求されたデータはキャッシュからではなく、バックエンドサーバーから直接取得されます。

このパラメータの後の文字列は通常、nginxのいくつかの変数です

たとえば、proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;

この設定は、これら3つの変数のいずれかの値が0または空でない場合、

応答データはキャッシュからではなく、バックエンドサーバーから直接取得されます。

現時点ではほとんど使用されていないので、覚えておくだけで十分です

図に示すように、proxy_no_cache は上記のパラメータと同様です。

主にいくつかのケースで設定され、取得したデータはキャッシュされません

例 proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;

この設定は、次の3つの変数のいずれかの値が0または空でない場合、

取得したデータはキャッシュされません。

図に示すように、このパラメータの形式は上記のパラメータと似ています。通常は設定する必要はなく、デフォルトのままにしておきます。

図に示すように、proxy_cache_pathはキャッシュ領域の具体的な構成を設定するためのパラメータである。

キャッシュは、メモリ内のスペースに加えて、ハードディスク上のスペースもキャッシュ用に割り当てることができます。

パスはキャッシュパスとしてディレクトリパスを指定するもので、キャッシュはここに保存されます。

levels=1:2 これはディレクトリ レベルを示します。最初の数字は最初のレベルを設定します。

2番目の数字は2番目のレイヤーを設定します

1は0～9 af、合計16文字を意味し、各ディレクトリは1文字で構成され、合計16のディレクトリがあります。

2は0～9 afの合計16文字を意味しますが、各ディレクトリは00、01、04、2fなどの2文字で構成され、200以上の組み合わせがあります。

つまり、このパラメータはサブディレクトリ レベルを設定します。最初の数字は最初のレベルを表します。

2番目の数字は2番目の層を示します

keys_zoneはメモリゾーンの名前とサイズを設定するために使用されます

keys_zone=my_zone:10mはゾーンの名前がmy_zoneであることを意味します

ゾーンサイズは10MBです

非アクティブは、キャッシュが削除されるまでの時間です。

例えば、図の値が300秒に設定されている場合、300秒以内にデータにアクセスされなかった場合、

その後、データはキャッシュから削除されます。

max_sizeはハードディスクキャッシュに保存できるデータの最大量です。

例えば、ここでは5gに設定されており、上記で設定されたディレクトリは/data/nginx_cache/です。

このハードディスクのディレクトリは、最大5gのデータを超える場合、

システムは、最初に訪問の最小でデータを削除し、次に新しいデータを配置します。

proxy_cache_path行は、構成ファイルのサーバーブラケット内で書き込むことはできません。

HTTPブラケットに記述されます

たとえば、最初にnginx.conf構成ファイルを編集します

図に示すように、サーバーの外側にproxy_cache_pathコードを追加します

図に示すように、

指定されたcacheディレクトリ/データ/nginx_cache/は存在しないため、ここで作成する必要があります

図に示すように、仮想ホスト構成ファイルをコンパイルし、場所にproxy_cache my_zoneを追加します。

このようにして、この仮想ホストがリクエストを受信すると、キャッシュスペースmy_zoneが使用されます

my_zoneキャッシュスペースの特定の定義は、nginx.conf構成ファイルで定義されています

nginx.confの構成コンテンツは、すべての仮想ホストに有効です

したがって、my_zoneがnginx.confで定義されている場合

次に、すべての仮想ホスト構成ファイルでproxy_cachemy_zoneを使用します

これらの仮想ホストはすべてキャッシュスペースmy_zoneを使用できます

次に、保存して終了して構成ファイルをリロードして有効にします

通常の使用のためには、キャッシュを正常に構成するために、これら2つのコードを追加する必要があります。

図に示されているように、別の問題は、Nginxサービス自体の許可が誰もいないということです

ディレクトリは今、ルート特権で作成されました

したがって、ここでは、キャッシュディレクトリの所有者グループを誰にも変更する必要があります

このようにして、NGINXサービスがこのディレクトリを操作する場合、許可の問題はありません

図に示すように、/data/nginx_cache/ディレクトリの内容を確認してください

0-9 AFの最初のレベルのディレクトリを見ることができます

0のディレクトリを入力すると、2桁で構成される2番目のレベルのディレクトリが表示されます。

要約すると、キャッシュスペース構成は主にproxy_cache_pathを定義します

nignx.confで定義できるため、仮想ホストが使用できるように

proxy_cache_pathを定義した後、キャッシュを使用する必要がある仮想ホストサーバーで

proxy_cache Zone_nameを構成します

ZONE_NAMEは、proxy_cache_pathで定義されているキャッシュスペース名です

このように、対応する仮想ホストはこのキャッシュスペースを使用できます

上記は、nginxフォワードプロキシと逆プロキシの詳細な説明の詳細なコンテンツです。