nginxの：
1.クラスター何である
複数のサーバ（コンピュータ）の間で状態ユニコムでは、これらのサーバは、クラスタと呼ばれる、同じことを行います
2.エージェントの
仲買人は、違いを生む
：とき剤の非存在下で
突然Moutai蒸留所--->物流を通じて顧客に直接ワインを購入する顧客の自宅/ワイナリーに送信されたワインの数--->の製作--->顧客は夜に食べる必要がある場合（今15:00）（東北内のクライアント）がある-状況の各種の遅れ>
エージェントを：
Moutai蒸留所は--->スタートリクルートエージェント（地方）--->プロキシ市- >顧客は茅台酒を購入する必要がある場合にのみ、エージェントが購入することができます
3.フォワードプロキシ
シナリオ：
ボローお金をBへ- > Bは、貸付- > AとB、Cは（AとCは非常に良好な関係）との良好な関係を発見した- > A Bからお金を借りて（ないに言及しCください私は）借り- Cにお金を貸して> B - - > CはBを見つけるためにお金を借りる> Cにお金を与えるために- > Bは本当に自分自身の借用金には誰を知っていません- >リーチその目的は、
定義されています。
クライアントは、実サーバに要求を送信しますが、あなたには、いくつかの理由で実際のクライアントにリクエストを送信することはできません、クライアントが要求をプロキシサーバに送信され、プロキシサーバーを見つけるだろうし、プロキシサーバー実サーバへの要求、実サーバは、特に私のクライアントを訪問者知らない（プロキシへのアクセスを参照するには、実サーバではなく、本当のクライアント）がされ
ています：
フォワードプロキシとクライアントが一緒にいますすべての設定は、クライアント側になければなりません、サーバーは、クライアントが誰であるかの本当の真実を知りません
4.リバースプロキシ
シナリオ：
ユニットに呼ばれる誰か- >ユニットの交換機のコールは- >人のこの説明に基づいて、総機会（部署、人を見つけるために） - >この部署に転送します（部門は5人を持っている） - >呼び出し側がこのセクターに答えるためにどの人物、特に知っている
有料法案不着---> 10086/10010/10001 --->モバイル交換を- >手動操作- >完全人工に転送する機会が-特定の回答に電話を知らない>発信者は- >その望ましい結果を達成
定義：
クライアントがサーバにリクエストを送信する（サーバーがクラスタです（クライアントが特定の要求にアクセスするサーバー知らない、クライアントがプロキシサーバによって傍受され、その後、プロキシサーバが実サーバのクラスタにリクエストを送信し、サーバ4））、実サーバは最終的につながりますプロキシサーバに応じて、プロキシサーバは、クライアントに結果を返し、クライアントは、サーバの特定の要求を知らない実サーバまたはプロキシサーバーのある
機能：
リバースプロキシは、サーバー側で、一緒に、すべての設定を行う必要があり サーバー側では、クライアントは誰実サーバ（クライアントが自分の要求プロキシサーバまたは実サーバを知らない）わかりません
フォワードプロキシの比率とは、プロキシリバース
一緒に、2人がパートナーシップサーバー欺くされているフォワードプロキシとクライアントを
、サーバー側が一緒にある不正な要求をし、リバースプロキシプロキシフィルタリング/一部のクライアントのうち、逆
ときnginxの実行するリバースプロキシ
システム全体のセキュリティを保証するには1.
2.配信要求で役割を果たしました
6.linuxに設定さnginxのリバースプロキシ
6.1。レビューHOSTNAME
VIの/ etc / sysconfig / networkファイル
6.2。ホスト名の変更およびIPマッピング
VIの/ etc / hosts
6.3。ファイアウォールを閉じる
-サービス停止iptablesの
6.4。ファイアウォールのブート閉め
のchkconfig iptablesのOFF
6.5。再起動し
、再起動
のLinuxサーバーにアップロードnginxのアーカイブを使用する6.6。xftpツールを
6.7。解凍nginxのの
タール-zxvf XXXXX
6.8。ショートカットを作成する
nginxのディレクトリ入力すること
は./configureを--prefix =は/ usr / local / nginxの-1.17。 3（Linux上で手動で入力、パスではなく）
与えられた：
./configureを：ザ・:.エラーがPCREライブラリを書き換えるHTTPのModule1を必要と
CANのModule1を使用して--without-http_rewrite_moduleのいずれかによって無効にあなたによって
オプション、またはPCREライブラリにインストールしますシステム、またはPCREライブラリを構築
静的用いてnginxのとソースから --with-PCRE = <path>はオプション。
何nginxのパッケージはサーバのLinux上に構成されてはならない
6.9。nginxの必要な設置構成パッケージ
GCC PCRE-のdevelのOpenSSLインストール-y YUM OpenSSLを-devel
参照してください。次のインストールに成功しました：
依存関係の更新：
0 4.4.7-23.el6 e2fsprogs.x86_64：cpp.x86_64 0 1.41.12-24.el6のe2fsprogs-libs.x86_64 0：1.41.12-24。 EL6
libcom_err.x86_64 0：1.41.12-24.el6 libgcc.x86_64 0：0 4.4.7-23.el6 libgomp.x86_64：4.4.7-23.el6
libss.x86_64 0：1.41.12-24.el6
コンプリート！
。6.10は、再びショートカット作成
nginxのディレクトリ内に
は./configure --prefix =は/ usr / local / nginxの-1.17.3を
：成功を作成するには、次の手順を参照してください
設定に概要を
+使用してPCREライブラリシステム
+ OpenSSLのライブラリが使用されていません
システムのzlibライブラリを使用して+
nginxのパス接頭辞： "/usr/local/nginx-1.17.3"
nginxのバイナリファイル： "/usr/local/nginx-1.17.3/sbin/nginx"
nginxのモジュールパス：「/usr/local/nginx-1.17。 3 /モジュール"
nginxの構成のプレフィックス： "" /usr/local/nginx-1.17.3/conf
nginxの設定ファイル： "/usr/local/nginx-1.17.3/conf/nginx.conf"
nginxののpidファイル：" / USR /ローカル/ nginxの-1.17.3 /ログ/ nginx.pid "
nginxのエラーログファイル： "/usr/local/nginx-1.17.3/logs/error.log"
nginxのHTTPアクセスログファイル："は/ usr / local /nginx-1.17.3/logs/access.log "
nginxのHTTPクライアントのリクエストボディの一時ファイル： "client_body_temp"
nginxのHTTPプロキシの一時ファイル： "proxy_temp"
nginxのHTTP FastCGIの一時ファイル："fastcgi_temp」
nginxのHTTP uwsgi一時ファイル： "uwsgi_temp"
HTTP SCGI一時ファイルのnginxの"scgi_temp"
。6.11コンパイルnginxのは、
また、nginxののディレクトリに必要な
作り&& make installを
、以下の情報が正常にコンパイルされている説明：
メイク[1]：残しディレクトリ`/home/apps/nginx-1.17.3"
6.12。nginxの起動
パッケージnginxのディレクトリ操作解凍しない
ディレクトリ（/usr/local/nginx-1.17.3）ショートカットを実行するために必要な
（sbinにディレクトリ内）./nginxを
正常に起動示す、エラーがない場合に
6.13。ブラウザを使用します検出し
192.168.1.150は、
インストールが成功した以下のページを参照してください
！nginxのための購入のために利用可能である
場合には、あなたがこのページを参照してください、nginxのでWeb Serverが正常にインストールされ、さらに設定が必要ですワーキング..
オンラインドキュメントとサポートについてnginx.orgを参照してください。
商用サポートはnginx.comで入手可能です。
nginxのをご利用いただきありがとうございます。
リバースプロキシ設定：
6.14 /usr/local/nginx-1.17.3は設定で設定される。
Vimのnginx.conf
注：
内部構成HTTP {}タグの全て実装しなければならない
上流tomcat_server（名前容易遊び、楽しいですなど）{
サーバー192.168.23.151:8080;（セミコロンは忘れない！！）
}
上流ラベルサーバ{}の上方に配置されなければならない
ロード順序を有する：
サーバーは以下に配置されている場合、最終的なロード順序ため理由（上から下へのロード順序）、サーバーの負荷が上流未満である、それは誤りだろう！！！！
サーバーを設定します{}タグの位置/ {}タグ
の位置/ {}、すべてのコンテンツのラベルすべて削除
LOCATION / {
proxy_passのHTTP：// tomcat_server;（それ以外の場合は、マップを見つけることができない、名前の上流に一致している必要がありますが）
}
6.15 nginxの再
必要sbinにディレクトリ
./nginx -sリロード
6.16。Tomcatの設定サーバ151上の
....
6.17。nginxのプロキシ設定成功リバース検出
2台のサーバーの
nginxのプロキシサーバに192.168.23.150
（Webプロジェクトを実行している）Webサーバを192.168.23.151
クライアントが要求を送信します。---> Webサーバ--->は、プロキシサーバ--->その後、プロキシサーバーでWebサーバーに要求を転送ブロックされた
、nginxのプロキシサーバーのIPクライアントのアクセスにTomcatのWebページへのアクセスを
6.18。実際には、優れたリバースプロキシサーバは、サーバの実アドレスを隠す本当のセキュリティを確保するために！！！
クライアントは、実サーバへの直接要求の形式でプロキシサーバーを介してアクセスすることができ、クライアントは知りませんでした