nginxの使用法と設定

開発 2023-09-09 09:49:30 訪問数: null

nginxの使用法と設定

1.nginxとは

1. nginx の定義: Nginx は、高性能 HTTP およびリバース プロキシ サービス、および IMAP/POP3/SMTP サービスです。

  1. 応答リクエストの処理が速い
  2. 高い同時接続数
  3. メモリ消費量が少ない
  4. 高信頼性
  5. 高い拡張性
  6. ホットデプロイメント

マスター管理プロセスとワーカー作業プロセスの分離設計により、Nginx はホット デプロイメント機能を備え、7 × 24 時間の中断のないサービスを前提として Nginx の実行ファイルをアップグレードしたり、構成を変更することなく変更したりすることができます。サービスファイルの停止、ログファイルの置換、その他の機能

2.多数の並列処理が可能：Nginx は公式テスト結果では 50,000 並列接続をサポートできますが、実際の動作では 20,000 ～ 40,000 並列接続をサポートできます。数百

3. Apacheとの比較
Nginx は、Apache Web サーバーのパフォーマンスを超えるという明確な目標を持って作成されました。

  • Nginx は、すぐに使用できる静的ファイルを提供し、Apache よりもはるかに少ないメモリ使用量で、Apache よりも 1 秒あたり約 4 倍のリクエストを処理できます。同時実行性が低い場合のパフォーマンスは Apache に匹敵し、場合によってはそれよりも低い場合もありますが、同時実行性が高い場合、Nginx は低いリソース消費と高いパフォーマンスを維持できます。高度にモジュール化された設計もあり、モジュールの記述はシンプルかつ簡潔です。
  • このパフォーマンスの向上は、ファイルごとにシステム全体のアクセス設定をオーバーライドする機能などの柔軟性の低下を犠牲にして実現されます (Apache は を使用します。サードパーティのモジュールを Nginx に追加するには、静的にリンクされたモジュールを使用してソースからアプリケーションを再コンパイルする必要があります)。この問題は、動的なモジュールの読み込みを追加したバージョン 1.9.11 で部分的に解決されました。ただし、モジュールは依然として Nginx と同時にコンパイルする必要があり、すべてのモジュールがこのシステムと互換性があるわけではありません。一部のモジュールは古い静的リンク プロセスを必要とします。

4.Apache VS Nginx

ここに画像の説明を挿入します
ここに画像の説明を挿入します
ここに画像の説明を挿入しますここに画像の説明を挿入します

5. 一般的に使用されるWebサーバーの比較

アイテム\サーバーの比較 アパッチ Nginx ライトTPD
プロキシ とても良い とても良い 一般的に
リライター 良い とても良い 一般的に
Fcgi 良くない 良い とても良い
ホットデプロイメント サポートしません サポート サポートしません
システム圧力 とても大きい 非常に少ない 小さい
安定性 良い とても良い 良くない
安全性 良い 一般的に 一般的に
静的ファイルの処理 一般的に とても良い 良い
リバースプロキシ 一般的に とても良い 一般的に

2.nginxモジュール

1. 全体的なモジュール設計が Nginx の大きな特徴であり、http サーバーのコア機能もモジュールです。

2. 古いバージョンの Nginx のモジュールは静的であるため、モジュールの追加と削除は Nginx を再コンパイルする必要があります。1.9.11 以降のバージョンはすでに動的モジュールの読み込みをサポートしています

3. 高度なモジュール設計が Nginx のアーキテクチャ基盤です。Nginx サーバーは複数のモジュールに分解されます。各モジュールは機能モジュールであり、独自の機能のみを担当します。モジュールは「凝集性が高く、結合性が低い」という原則に厳密に従っています。原則として「カップリング」

4. モジュール図は次のとおりです。
ここに画像の説明を挿入します
5.コア モジュール: コア モジュールは、Nginx サーバーの通常の動作に不可欠なモジュールであり、エラー ログ、構成ファイル分析、イベント駆動メカニズム、プロセス管理などのコア機能を提供します。

6.標準 HTTP モジュール: 標準 HTTP モジュールは、ポート設定、Web ページのエンコード設定、HTTP 応答ヘッダーの設定など、HTTP プロトコル分析に関連する機能を提供します。

7.オプションの HTTP モジュール: オプションの HTTP モジュールは主に標準の HTTP 機能を拡張するために使用され、Nginx が次のような特別なサービス (Flash マルチメディア送信、GeoIP リクエストの解決、SSL サポートなど) を処理できるようにします。

8.メール サービス モジュール: メール サービス モジュールは、主に、POP3 プロトコル、IMAP プロトコル、SMTP プロトコルのサポートなど、Nginx のメール サービスをサポートするために使用されます。

9.サードパーティ モジュール: サードパーティ モジュールは、Nginx サーバー アプリケーションを拡張し、Json サポート、Lua サポートなどの開発者定義の機能を完成させるために使用されます。

3.nginx アプリケーション シナリオ:

Nginx は、無料のオープンソースの高性能 HTTP サーバーおよびリバース プロキシ サーバーであり、IMAP、POP3、SMTP プロキシ サーバーでもあり、Web サイトのリリース処理用の HTTP サーバーとして使用でき、Nginx は Web サイトのリリース処理用の HTTP サーバーとして使用できます。リバースプロキシサーバー プロキシ負荷分散の実装
ここに画像の説明を挿入します

1. エージェントについて: この時点では、エージェント ロールとターゲット ロールの 2 つのロールが関係しており、エージェント キャラクターがこのエージェントを介してターゲット ロールにアクセスし、いくつかのタスクを完了するプロセスをエージェントと呼びます。操作プロセス; 人生における独占のようなもの ストア~顧客がアディダス ストアで靴を購入しました。このストアはエージェントであり、エージェントの役割はアディダスのメーカーであり、ターゲットの役割はユーザーです。

2.フォワードプロキシ：「クライアントのプロキシとして動作し、クライアントに代わってリクエストを送信する」クライアントと元のサーバー（オリジンサーバー）の間にあるサーバーで、元のサーバーからコンテンツを取得するために、クライアントはプロキシ A リクエストを送信し、ターゲット (オリジン サーバー) を指定します。その後、プロキシはリクエストを元のサーバーに転送し、取得したコンテンツをクライアントに返します。クライアントはフォワード プロキシを使用するためにいくつかの特別な設定を行う必要があります。

栗をあげます：

現在のネットワーク環境では、技術的な理由から海外の Web サイトにアクセスしたい場合、ブラウザから海外の Web サイトにアクセスすることはできません。このとき、誰もが FQ という操作を使用してアクセスすることができます。海外の Web サイトにアクセスできるプロキシ サーバーを見つけるために、プロキシ サーバーにリクエストを送信します。プロキシ サーバーは海外の Web サイトにアクセスし、アクセスされたデータを当社に渡します。

上記のプロキシ モードはフォワード プロキシと呼ばれます。フォワード プロキシの最大の特徴は、クライアントがアクセスするサーバーのアドレスを非常に明確に認識していることです。サーバーは、リクエストがどのプロキシ サーバーからのものであるかだけを認識し、どの特定のクライアントからのリクエストであるかは認識しません。由来; フォワード プロキシ このモードは、実際のクライアント情報をマスクまたは非表示にします。概略図を見てみましょう。
ここに画像の説明を挿入します
クライアントはフォワード プロキシ サーバーをセットアップする必要があります。もちろん、前提条件はフォワード プロキシ サーバーの IP アドレスとプロキシ プログラムのポートを知っていることです。写真に示すように
ここに画像の説明を挿入します

3. フォワードプロキシの目的:

  1. Googleなど、以前はアクセスできなかったリソースにアクセスできます
  2. キャッシュしてリソースへのアクセスを高速化できる
  3. クライアントのアクセスを許可し、オンラインで認証する
  4. エージェントはユーザーのアクセス記録（オンライン行動管理）を記録し、ユーザー情報を外部から隠すことができます。

4.リバースプロキシ: 「サーバーのプロキシとして機能し、サーバーに代わってリクエストを受信します。」主にサーバークラスターの分散展開の場合に使用され、サーバーの情報を隠します。

栗をあげます：

たとえば、毎日同時に Web サイトに接続する訪問者の数は爆発的に増加しており、単一のサーバーでは人々の高まる購入意欲を満たすことはできません。このとき、分散配置というよく知られた用語が登場しました。つまり、訪問者数の制限の問題は複数のサーバーを配置することで解決され、ある Web サイトのほとんどの機能もリバース プロキシ用の Nginx を使用して直接実装され、Nginx とその他のコンポーネントをカプセル化することで、次のような派手な名前が付けられています。 Tengine に興味のあるお子様は、Tengine の公式 Web サイトにアクセスして特定の情報をご覧ください: http://tengine.taabao.org/

では、リバース プロキシはどのような方法で分散クラスタ動作を実現しているのでしょうか? まず概略図を見てみましょう
ここに画像の説明を挿入します
1. 上の図を通して、複数のクライアントからサーバー (Nginx サーバーに送信されたリクエスト) が受信された後に送信されたことがよくわかります。 , バックエンドの業務処理サーバーに振り分けられ、一定のルールに従って処理されます このとき～リクエストの送信元がクライアントであることは明らかですが、どのサーバーがリクエストを処理するかは不明です Nginxはその役割を果たしますこれはリバース プロキシ ロール
2 です。クライアントはプロキシの存在を認識せず、リバース プロキシは外部に対して透過的です。クライアントは構成なしでアクセスできるため、訪問者はプロキシにアクセスしていることを知りません。

5. リバースプロキシの役割:

  1. 内部ネットワークのセキュリティを確保するために、通常、リバース プロキシがパブリック ネットワーク アクセス アドレスとして使用され、Web サーバーが内部ネットワークになります。
  2. リバース プロキシ サーバーを介した負荷分散により、Web サイトの負荷を最適化します。

6. プロジェクトシナリオ: 通常、実際のプロジェクトを運用する場合、アプリケーションシナリオにはフォワードプロキシとリバースプロキシが存在することが多く、クライアントからのターゲットサーバーへのアクセス要求をフォワードプロキシが代行します。複数の実際のビジネス処理サーバーをリバース プロキシするリバース単一関心サーバーです。具体的なトポロジは次のとおりです。
ここに画像の説明を挿入します

7. 2 つの違い: 以下の図は、フォワード プロキシとリバース プロキシの違いを示しています。
ここに画像の説明を挿入します

  • フォワードプロキシでは、ProxyとClientは同じLANに属し(図の枠内)、クライアント情報は隠蔽されます。
  • リバース プロキシでは、プロキシとサーバーが同じ LAN (図のボックス内) に属し、サーバー情報が隠蔽されます。
  • 2つのプロキシにおいてProxyが実際に行うことはリクエストとレスポンスを送受信するサーバーを入れ替えることですが、構造的には左右を入れ替えるだけなので、後から出てくるプロキシ方式をリバースと呼びます。プロキシ。

4.nginxのインストール

centos に nginx をインストールするには 2 つの方法があります。1 つは yum install で、もう 1 つはコンパイルしてインストールします。もちろん、最初の方法の方が簡単ですが、いくつかの欠点があります。たとえば、特定のサードパーティ モジュールを使用する必要があるなどです。 . 、この時点では、コンパイルとインストールを使用する必要があります。

1.makeをインストールする

yum -y install autoconf automake make

ここに画像の説明を挿入します

2.g++をインストールする

yum -y install gcc gcc-c++

ここに画像の説明を挿入します

3. nginx 依存ライブラリをインストールする

yum -y install wget pcre pcre-devel zlib zlib-devel openssl openssl-devel

ここに画像の説明を挿入します

4.nginxをダウンロードする

wget http://nginx.org/download/nginx-1.24.0.tar.gz

ここに画像の説明を挿入します
5.解凍する

tar -zxvf nginx-1.24.0.tar.gz

ここに画像の説明を挿入します
6. コンパイルしてインストールします (nginx ディレクトリに移動します)。

./configure  --prefix=/root/nginx  # 编译源码，指定安装位置

ここに画像の説明を挿入します

make && make install

ここに画像の説明を挿入します

7. 環境変数を構成する

  1. プロファイルファイルを編集する
vi /etc/profile
  1. 最後の行にnginxの場所を追加します
export PATH=$PATH:/root/nginx/sbin
  1. 環境変数を更新する
source /etc/profile

8. ファイアウォールをオフにする

  1. 臨時休業
systemctl stop firewalld.service
  1. 永久閉鎖
systemctl disable firewalld.service

5. Nginxの共通コマンド

1.スタート

#不指定启动配置文件，默认为NGINX_HOME/conf/nginx.conf
nginx

# 如果指定配置文件
nginx -c nginx.conf

2.停止

nginx -s stop

3.出口

nginx -s quit

4.閉じる

# 查看nginx进程号
ps -aux | grep nginx

# 杀掉进程
kill -9 nginx

5. 設定ファイルをリロードします

nginx -s reload

6. 設定ファイルが正しいか確認します

nginx -t -c /路径/nginx.conf

7. 設定ファイルを表示する

nginx -T

8.nginxのバージョン情報を確認する

nginx -v

6. 設定ファイルの構造

1. ファイル構造

1. Nginx 構成ファイルは通常、Nginx インストール ディレクトリの conf ディレクトリにあります。ファイル全体はブロックで構成されています。各ブロックは "{}" 中括弧で表されます。ブロック内には他のブロック レベルをネストできます。それら、メイン層は最上位のレベル
2 です。 nginx 設定ファイルは主に 4 つの部分、メイン (グローバル設定)、サーバー (ホスト設定)、アップストリーム (アップストリーム サーバー設定、主にリバース プロキシ、ロード バランシング関連の設定)、および場所 ( URL は特定の場所の設定に一致します)、各セクションにはいくつかの手順が含まれています

  • Main セクションの設定は、他のすべてのセクションの設定に影響します。
  • サーバー部分は主に、仮想マシンのホストのドメイン名、IP、ポートを指定するために使用されます。
  • アップストリーム命令は、一連のバックエンド サーバーのセットアップ、リバース プロキシのセットアップ、およびバックエンド サーバーの負荷分散に使用されます。
  • Location 部分は、Web ページの場所 (たとえば、ディレクトリ "/"、"/images" など) と一致するために使用されます。

3. 両者の関係は、server は main を継承し、location はserver を継承し、上流は命令を継承することも継承されることもありません。

4. 4 つの部分のうち、各部分には複数の命令が含まれています。これらの命令には主に Nginx メイン モジュール命令、イベント モジュール命令、HTTP コア モジュール命令が含まれます。各部分は、Http SSL モジュール、HttpGzip Static などの他の HTTP モジュール命令も使用できます。モジュールやHTTP追加モジュールなど

ここに画像の説明を挿入します
5. 実際の nginx 設定ファイルは次のとおりです。

########### 每个指令必须有分号结束。#################
#user administrator administrators;  #配置用户或者组，默认为nobody nobody。
#worker_processes 2;  #允许生成的进程数，默认为1
#pid /nginx/pid/nginx.pid;   #指定nginx进程运行文件存放地址
error_log log/error.log debug;  #制定日志路径，级别。这个设置可以放入全局块，http块，server块，级别以此为：debug|info|notice|warn|error|crit|alert|emerg
events {
    
    
    accept_mutex on;   #设置网路连接序列化，防止惊群现象发生，默认为on
    multi_accept on;  #设置一个进程是否同时接受多个网络连接，默认为off
    #use epoll;      #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport
    worker_connections  1024;    #最大连接数，默认为512
}
http {
    
    
    include       mime.types;   #文件扩展名与文件类型映射表
    default_type  application/octet-stream; #默认文件类型，默认为text/plain
    #access_log off; #取消服务日志    
    log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式
    access_log log/access.log myFormat;  #combined为日志格式的默认值
    sendfile on;   #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。
    sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。
    keepalive_timeout 65;  #连接超时时间，默认为65s，可以在http，server，location块。

    upstream mysvr {
    
       
      server 127.0.0.1:7878;
      server 192.168.10.121:3333 backup;  #热备
    }
    error_page 404 https://www.baidu.com; #错误页
    server {
    
    
        keepalive_requests 120; #单连接请求上限次数。
        listen       4545;   #监听端口
        server_name  127.0.0.1;   #监听地址       
        location  ~*^.+$ {
    
           #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。
           #root path;  #根目录
           #index vv.txt;  #设置默认页
           proxy_pass  http://mysvr;  #请求转向mysvr 定义的服务器列表
           deny 127.0.0.1;  #拒绝的ip
           allow 172.18.5.54; #允许的ip           
        }
        # 第一个程序，hellow world
        location /sayhello {
    
    
            default_type text/html;
            return 200 "nginx hello world";
        }
    }
}

2. グローバル構成

user nobody nobody;
worker_processes 2;
error_log logs/error.log notice;
pid logs/nginx.pid;
 
events{
    
    
    use epoll;
    worker_connections 65536;
}

1.user: メイン モジュール コマンド。Nginx Worker プロセスを実行するためのユーザーとユーザー グループを指定します。デフォルトでは、nobody アカウントによって実行されます。

User は、Nginx Worker プロセスを実行するためのユーザーとユーザー グループを指定するメイン モジュール コマンドです。デフォルトでは、nobody アカウントによって実行されます。
ここに画像の説明を挿入します

2.worker_processes: メインモジュールのコマンドは、Nginx が起動するプロセスの数を指定します。Nginx の各プロセスは平均して 10M ～ 12M のメモリを消費します。CPU の数と同じ数を指定することをお勧めします。

ここで worker_processes 2 が設定されている場合、ワーカー プロセスは 2 つになります。
ここに画像の説明を挿入します

3. error_log: メイン モジュール コマンドは、グローバル エラー ログ ファイルを定義するために使用されます。ログ出力レベルは、debug、info、notice、warn、error、crit から選択できます。その中で、デバッグ出力ログが最も詳細です。 、クリティカル出力ログは最も少ないですが、

ログ ファイルのパスは通常、nginx インストール ディレクトリの logs ディレクトリにあります。
ここに画像の説明を挿入します

4.pid: プロセス pid のストレージ ファイルの場所を指定するために使用されるメイン モジュール命令

プロセス番号はnginxマスターのプロセス番号と同じで、nginxが起動している間のみ存在し、nginxが停止するとpidも削除されます。
ここに画像の説明を挿入します

5. events イベントコマンド: Nginx の動作モードと接続数の上限を設定します。

3.eventsイベントコマンド

events コマンドは、Nginx の動作モードと接続数の上限を設定します。

1.use: イベント モジュール コマンド。Nginx の動作モードを指定するために使用されます。

Nginx でサポートされている動作モードは、select、pol、kqueue、epoll、rtsig、/dev/poll です。このうち、select と poll は標準の動作モードで、kqueue と epoll は効率的な動作モードです。違いは、epoll が Linux で使用されることです。 platform 、および kqueue は BSD システムで使用されます。Linux システムの場合、epoll 作業モードが最初の選択肢です。

2.worker_connections: イベント モジュール ディレクティブ。各 Nginx プロセスの最大接続数を定義するために使用されます。デフォルトは 1024 です。

クライアント接続の最大数は、worker_processes と worker_connections によって決まります。つまり、 Max_client=worker_processes*worker_connections
リバース プロキシとして機能する場合、max_clients は次のようになります: max_clients = worker_processes * worker_connections/4。
プロセスの最大接続数は、Linux システム プロセスのオープン ファイルの最大数によって制限され、worker_connections の設定は、オペレーティング システム コマンド「ulimit -n 65536」が実行されるまで有効になりません。

4.HTTPサーバーの設定

HTTP サーバー関連のプロパティの Nginx 構成コードは次のとおりです。

http {
    
    
    # 引入文件类型映射文件
    include       mime.types;
    # 如果没有找到指定的文件类型映射 使用默认配置
    default_type  application/octet-stream;
    # 日志打印格式
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    # 启动零拷贝提高性能
    sendfile        on;
    # 设置keepalive长连接超时时间
    keepalive_timeout  65;
    # 引入子配置文件
    include /nginx/conf/conf.d/*.conf;
}

1.include: メイン モジュール コマンドは、構成ファイルに含まれるファイルの設定を実現します。これにより、メイン構成ファイルの複雑さが軽減され、他のモジュールの特定の構成が異なるフォルダーに分散されます。

2.default_type: HTTP コア モジュール コマンドに属します。ここでは、デフォルト タイプはバイナリ ストリームとして設定されます。つまり、このメソッドは、ファイル タイプが定義されていない場合に使用されます。たとえば、PHP 環境が設定されていない場合、 Nginx では解析されないので、このときブラウザで PHP ファイルにアクセスすると、ダウンロード画面が表示されます。

3.log_format: log_format は Nginx の HttpLog モジュール命令で、Nginx ログの出力形式を指定するために使用されます。main はログ出力形式の名前で、次の access_log 命令で参照できます。

log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"';

log_format download '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_range" "$sent_http_content_range"';

7. Nginx仮想ホスト

  1. Web サービスにおけるいわゆる仮想ホストは、独立した Web サイト サイトです。このサイトは、独立したドメイン名 (IP またはポートの場合もあります) に対応し、独立したプログラムとリソースを持ち、ユーザーがアクセスする外部サービスを独立して提供できます。 。
  2. Nginx では、サーバー ラベルを使用して仮想ホストを識別します。ウェブ サービスは複数の仮想ホスト ラベルのペアを持つことができます。つまり、複数の仮想ホスト サイトを同時にサポートできます。{} 仮想ホストには、ドメイン名ベースの仮想ホストと IP+ポートベースの仮想ホストの 2 種類があります。

1. 準備

1. まず、以下のテストディレクトリを初期化します。

mkdir -p /root/nginx/html/{
    
    andy01,andy02}/

ここに画像の説明を挿入します
2. インデックスファイルの作成

andy01 ディレクトリにインデックス ファイルを作成します。

vi /root/nginx/html/andy01/index.html

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>andy01</title>
  <head>
  <body>
      <H1>
          Andy01   --->   这是Andy01测试文件
      </H1>
  </body>
</html>

andy02 ディレクトリにインデックス ファイルを作成します。

vi /root/nginx/html/andy02/index.html

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>andy01</title>
  <head>
  <body>
      <H1>
          Andy02   --->   这是Andy02测试文件
      </H1>
  </body>
</html>

2. 仮想ホストの構成

1. nginx インストール ディレクトリの conf ディレクトリに conf.d フォルダを作成し、独自の nginx 設定を保存します

mkdir -p /root/nginx/conf/conf.d

ここに画像の説明を挿入します
2. nginx 設定ファイルを変更し、次の内容を追加します

  1. nginx.conf ファイルを入力します
vi /root/nginx/conf/nginx.conf
  1. コンテンツの追加
# 在http模块末尾添加配置，引入我们自己写的所有配置文件
include conf.d/*.conf;

3. 次の内容を含む hostserver.conf 構成ファイルを conf.d フォルダーに作成します。
1. conf.d ファイルを編集します。

vi hostserver.conf

2.以下の内容を追加します

server {
    
    
    listen       80;
    charset utf-8;
    server_name  www.andy01.com;
    location /{
    
    
        root html/andy01;
        index  index.html index.htm;
        expires  7d;
    }
}

server {
    
    
    listen      80 ;
    charset utf-8;
    server_name  www.andy02.com;
    location /{
    
    
        root html/andy02;
        index  index.html index.htm;
        expires  7d;
    }
}

4. ローカルホストの設定

192.168.44.116 www.andy01.com
192.168.44.116 www.andy02.com

5. アクセステスト
1. www.andy01.com にアクセスします。
ここに画像の説明を挿入します
2. www.andy02.com にアクセスします
ここに画像の説明を挿入します
。 6. 次のエラーが発生した場合は
ここに画像の説明を挿入します
、nginx.conf ファイルを変更します
ここに画像の説明を挿入します
。 7. 仮想ホストの一致順序

  • 最も高い優先度: 完全一致
  • 2 番目の優先順位: ワイルドカードが最初
  • 3 番目の優先順位: ワイルドカードの後

3.デフォルトのホストマッチング

デフォルトの仮想ホストの役割は次のとおりです。この Web サーバーを指しているアクセスされたドメイン名が複数あるが、ドメイン名が nginx 仮想ホストに追加されていない場合、デフォルトの仮想ホストがアクセスされます (汎分析)。

server {
    
    
    # 将域名www.andy02.com 设置为默认虚拟主机
    listen       80 default;
    charset utf-8;
    server_name  www.andy02.com;
    location /{
    
    
        root html/andy02;
        index  index.html index.htm;
        expires  7d;
    }
}

ここに画像の説明を挿入します
テスト: 192.168.44.136
ここに画像の説明を挿入します

8. 場所の役​​割

ロケーションとは「場所」を意味します。要求された URL に応じて異なる処理が実行されます。仮想ホスト (サーバー) では、場所の構成が不可欠であり、Web サイトのさまざまな部分をさまざまな処理方法で配置できます。

1. 場所のルール

1. ロケーション ルール: ロケーション セクションは、パターンを指定することによってクライアントによって要求された URI と一致します。ユーザーが要求した URI に従って、定義されたロケーションを照合することができます。一致が発生すると、アクセス制御やその他の機能など、対応するロケーション構成の構成によって要求が迅速に処理されます。

2. 文法

location [修饰符] pattern {…}

3. 一般的に使用される修飾子の説明

修飾子 関数
ヌル プレフィックス マッチングでは、照合する必要があるパスがプレフィックスとして付けられた URI と照合できます。
= 完全に一致
～ 正規表現パターンマッチング、大文字と小文字を区別
~* 正規表現パターン マッチング、大文字と小文字は区別されません
^~ 修飾子のない動作と同様に、完全なプレフィックス マッチングも指定されたモジュールから開始されます。違いは、パターンが一致した場合に他のパターンの検索を停止し、正規表現をサポートしていないことです。
/ ユニバーサルマッチング。あらゆるリクエストがマッチングされます。

2. 準備

1. ローカルホストの設定

192.168.44.136 www.andy.com

2. 新しい設定ファイル location.conf を ngxin インストール ディレクトリの下の conf/con.d ディレクトリに追加します。

touch location.conf

3. プレフィックスマッチング

修飾子がない場合は、指定されたパターンで始まらなければならないことを意味します。指定されたパターンの前に修飾子はなく、照合する URI は位置の直後に記述されます。その優先順位は通常の照合の 2 番目です。

server {
    
    
    listen       80;
    server_name www.location.com;
    charset   utf-8;
    location /abc {
    
    
        default_type text/html;
         return 200 "前缀匹配-abc...";
    }
}

これにより、次のコンテンツが正しく照合されます。

  • www.andy.com/abc
  • www.andy.com/abc/
  • www.andy.com/abc?..

4.完全一致

完全一致では = を使用して、nginx がルート マッチングを実行するときに、完全一致が最も優先されることを示します。完全一致が成功すると、nginx は他の一致の検索を停止します。

server {
    
    
    listen       80;
    server_name www.andy.com;
    charset   utf-8;
    location = /abc {
    
    
        default_type text/html;
        return 200 "精确匹配-abc-accurate";
    }
}

1. これにより、次のコンテンツが正しく照合されます。

  • www.andy.com/abc
  • www.andy.com/abc?..

2、以下の内容はマッチングできません

  • www.andy.com/abc/
  • www.andy.com/abc/def

5. プレフィックスの正確な一致

完全なプレフィックス マッチングの優先順位は完全一致に次ぐもので、nginx はリクエストのプレフィックスと完全に一致すると、他の一致する項目の検索を停止します。

server {
    
    
    listen       80;
    server_name www.andy.com;
    charset   utf-8;
    location ^~ /abc {
    
    
        default_type text/html;
        return 200 "精确前缀匹配-abc-prefix";
    }
}

そうすれば、次のコンテンツは正しく照合できます

  • www.andy.com/abc
  • www.andy.com/abc/
  • www.andy.com/abc?..

6. 正規表現

通常のマッチングは、大文字と小文字を区別するものと大文字と小文字を区別しないものの 2 つのタイプに分けられ、それぞれ ~ と ~* で表されます。リクエストが完全一致とプレフィックス一致に失敗した後、関連する正規一致の場所が設定されている場合、nginx は一致を試みます。リクエスト 通常のマッチングを実行します。通常の一致には優先順位はありませんが、一致は設定ファイルに出現する順序で実行されます。前の一致が一致すると、検索は停止し、下方向に続行されます。

1. 大文字と小文字を区別する

~: 指定された正規表現が大文字と小文字を区別することを示します。次に例を示します。

server {
    
    
    listen       80;
    server_name www.andy.com;
    charset   utf-8;
    location ~ ^/abc$ {
    
    
        default_type text/html;
        return 200 "正则区分大小写-abc-regular-x";
    }
}

その場合、次は正しく一致します。

  • www.andy.com/abc
  • www.andy.com/abc?.…

以下は一致しません:

  • www.andy.com/abc/
  • www.andy.com/ABC
  • www.andy.com/abcde

2. 大文字と小文字は区別されません

~*: 次のように、指定された正規表現が大文字と小文字を区別しないことを示します。

server {
    
    
    listen       80;
    server_name www.andy.com;
    charset   utf-8;
    location ~* ^/abc$ {
    
    
         default_type text/html;
         return 200 "正则不区分大小写-abc-regular-Y";
    }
}

その場合、以下は正しく一致します。

  • www.location.com/abc
  • www.location.com/abc?.…
  • www.location.com/ABCの次のコンテンツは
    一致しません:
  • www.location.com/abc/
  • www.location.com/abcde

7.ユニバーサルマッチング

一般的な一致では、/ を使用して、すべてのリクエストに一致することを示します。通常、nginx 設定ファイルの最後には一般的な一致ルールがあります。他の一致ルールが失敗した場合、リクエストは処理のために一般的な一致ルールにルーティングされます。そうでない場合は、リクエストは一般的な一致ルールにルーティングされます。一般的なマッチングが設定されており、その他のマッチング ルールがすべて失敗すると、nginx は 404 エラーを返します。

server {
    
    
    listen       80;
    server_name www.andy.com;
    charset   utf-8;
    location /{
    
    
        default_type text/html;
        return 200 "通用匹配-default";
    }
}

8. 優先順位の比較

server {
    
    
    listen       80;
    server_name www.andy.com;
    charset   utf-8;
    default_type text/html;
    location = /abc {
    
    
        return 200 "精确匹配-abc";
    }
    location ^~ /abc {
    
    
        return 200 "精确前缀匹配-abc";
    }
    location ~ ^/abc$ {
    
    
        return 200 "正则匹配-abc";
    }
    location /abc {
    
     
        return 200 "前缀匹配-abc";
    }
    location /{
    
    
        return 200 "通用匹配-default";
    }
}

andy /abc と andy ^~ /abc はどちらも /abc で始まるものと一致します。これらが同時に存在するとエラーが報告されます。

9. 完全な例

server {
    
    
    listen       80;
    server_name www.andy.com;
    default_type text/html;
    charset   utf-8;
    location = / {
    
    
        return 200 "规则A";
    }
    location = /login {
    
    
        return 200 "规则B";
    }
    location ^~ /static/ {
    
    
        return 200 "规则C";
    }
    location ^~ /static/files {
    
    
        return 200 "规则X";
    }
    location ~ \.(gif|jpg|png|js|css)$ {
    
    
        return 200 "规则D";
    }
    location ~* \.js$ {
    
    
        return 200 "规则E";
    }
    location /img {
    
    
        return 200 "规则Y";
    }
    location / {
    
    
        return 200 "规则F";
    }
}
リクエストウリ ルーティングルールの一致
http://www.andy.com/ ルールA
http://www.andy.com/ログイン ルールB
http://www.andy.com/register ルール F
http://www.andy.com/static/a.html ルールC
http://www.andy.com/static/files/a.txt ルールX
http://www.andy.com/a.png 支配
http://www.andy.com/a.PNG ルール F
http://www.andy.com/img/a.gif 支配
http://www.andy.com/img/a.tiff ルールY

10. マッチング順序

ここに画像の説明を挿入します
1. 順序と優先順位を高から低に一致させます。

  • 「=」による完全一致が優先されます。
  • 正規表現
  • 修飾子なしの完全一致

2. 具体的な一致ルールは次のとおりです。

  • =正確な一致がヒットした場合、位置アクションを停止し、直接正確な一致に進みます。
  • 一般的な一致 (前方一致の完全な一致を含む) がヒットすると、最初にすべての共通の一致が収集され、最後に最も長い一致が比較されます。
  • 通常の最長一致が完全な前方一致として宣言されている場合、この一致は直接実行され、位置は停止されます。
  • 通常の最長一致が完全なプレフィックス一致ではない場合は、通常の場所に進みます。
  • コード順に通常のマッチングを実行し、最初の通常の位置にヒットしたときに位置を停止します。

注: 複数の正規表現が表示される場合は、構成ファイルで定義されている順序に従ってください。

11.パスマッチング処理

ここに画像の説明を挿入します
http リクエスト パスが http://192.168.0.132:8088/mvc/index?id=2 であると仮定すると、照合プロセスは次のようになります。

  • URL 全体をドメイン名/ポート/パス/パラメータに分解します。
  • まず、ドメイン名/ポートをターゲット サーバーの仮想ホストにマッピングします。
  • パス部分は位置マッチングに参加します。パス = パス 1 マッチング部分 + パス 2 残り部分
  • ロケーションメソッド本体の内部処理を入力します。
  • 静的ファイル処理の場合は、ターゲット ディレクトリを入力してファイルを検索します。root コマンドを使用する場合は、path1+path2 に対応するファイルを検索します。alias コマンドを使用する場合は、path2 に対応するファイルを検索します。
  • プロキシ プロキシの場合、proxy_pass=ip:port の形式の場合は path1+path2 パスを tomcat に転送し、proxy_pass=ip:port/xxx の形式の場合は path2 パスを転送します。 Tomcat に送信され、params は常に転送の後に続きます。

12. 実用化への提案

したがって、実際に使用する場合、個人的には、少なくとも次の 3 つの一致ルール定義があると感じます。

#直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理，官网如是说。
#这里是直接转发给后端应用服务器了，也可以是一个静态首页
# 第一个必选规则
location = / {
    
    
    proxy_pass http://tomcat:8080/index
}
# 第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项
# 有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用
location ^~ /static/ {
    
    
    alias /webroot/static/;
}

location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
    
    
    root /webroot/res/;
}
# 第三个规则就是通用规则，用来转发动态请求到后端应用服务器
# 非静态文件请求就默认是动态请求，自己根据实际把握
# 毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了
location / {
    
    
    proxy_pass http://tomcat:8080/
}

9. Nginx リバースプロキシ

1. andy_test.conf を nginx インストール ディレクトリの conf/conf.d ディレクトリに追加します

touch  andy_test.conf

2. ローカルホストの設定

192.168.44.136 www.andy_test.com

3. andy_test.conf ファイルを編集し、次の内容を追加します。

server {
    
    
    listen 80;
    server_name www.andy_test.com;
    default_type text/html;
    charset   utf-8;
    location /{
    
    
        proxy_pass http://192.168.44.136:8081;
    }                                                                                                 
}

10. Nginx ロード バランシング

1.基本構成

負荷分散は、「アップストリーム」モジュールによって定義されたバックエンド サーバーのリストからサーバーを選択し、ユーザー リクエストを受け入れるために使用されます。最も基本的なアップストリーム モジュールは次のようになり、モジュール内のサーバーはサーバーのリストです。

#动态服务器组
upstream dynamicserver {
    
    
    server 192.168.44.136:8081; #tomcat 1
    server 192.168.44.136:8082; #tomcat 2
    server 192.168.44.136:8083; #tomcat 3
}

アップストリーム モジュールの構成が完了したら、指定されたアクセスをサーバー リストにリバース プロキシする必要があります。

#其他页面反向代理到tomcat容器
location /{
    
    
    proxy_pass http://dynamicserver;
}

これは最も基本的な負荷分散インスタンスですが、実際のニーズを満たすには十分ではありません。現在、Nginx サーバーの上流モジュールは 6 つの分散方法をサポートしており、完全な構成は次のとおりです。

upstream dynamicserver {
    
    
    server 192.168.44.136:8081; #tomcat 1
    server 192.168.44.136:8082; #tomcat 2
    server 192.168.44.136:8083; #tomcat 3
}
server {
    
    
    server_name www.andy_test.com;
    default_type text/html;
    charset   utf-8;
    location /{
    
    
        proxy_pass http://dynamicserver;
    }
}

2. 上流共通パラメータ

パラメータの説明

サーバ リバースサービスアドレスとポート
重さ 重み
失敗タイムアウト max_fails と組み合わせて使用​​されます。
max_fails failed_timeout パラメータで設定した時間内での失敗の最大数を設定します。この時間内にサーバーへのすべてのリクエストが失敗した場合、サーバーはダウンしているとみなされます
max_conns 許可される接続の最大数
失敗時間 サーバーがダウンしているとみなされる時間の長さ。デフォルトは 10 秒です。
バックアップ このサーバーを、プライマリ サーバーの停止時にリクエストが送信されるバックアップ サーバーとしてマークします。
下 サーバーを永久にダウンしているとマークする
スロースタート ノードが復旧したら、すぐには参加しないでください

3.负载均衡策略

在这里，只详细说明Nginx自带的负载均衡策略，第三方不多描述

负载策略 描述
轮询 默认方式
weight 权重方式
ip_hash 依据ip分配方式
least_conn 最少连接方式
fair（第三方） 响应时间方式
url_hash（第三方） 依据URL分配方式

1.轮询：最基本的配置方法，上面的例子就是轮询的方式，它是upstream模块默认的负载均衡默认策略，每个请求会按时间顺序逐一分配到不同的后端服务器

#动态服务器组
upstream dynamicserver {
    
    
    server 192.168.44.136:8081; #tomcat 1
    server 192.168.44.136:8082; #tomcat 2
    server 192.168.44.136:8083; #tomcat 3
}

注意：

  • 在轮询中，如果服务器down掉了，会自动剔除该服务器
  • 缺省配置就是轮询策略
  • 此策略适合服务器配置相当，无状态且短平快的服务使用

配置示例：

upstream dynamicserver {
    
    
    server 192.168.44.136:8081; #tomcat 1
    server 192.168.44.136:8082; #tomcat 2
    server 192.168.44.136:8083; #tomcat 3
}

server {
    
    
    server_name www.andy_test.com;
    default_type text/html;
    charset   utf-8;
    location /{
    
    
        proxy_pass http://dynamicserver;
    }
}

2.weight：权重方式，在轮询策略的基础上指定轮询的几率

#动态服务器组
upstream dynamicserver {
    
    
    server 192.168.44.136:8081  weight=2;#tomcat 1
    server 192.168.44.136:8082;          #tomcat 2
    server 192.168.44.136:8083;          #tomcat 3
}

weight参数用于指定轮询几率，weight的默认值为1,；weight的数值与访问比率成正比，比如Tomcat 7.0被访问的几率为其他服务器的两倍

注意:

  • 权重越高分配到需要处理的请求越多。
  • 此策略比较适合服务器的硬件配置差别比较大的情况

3.ip_hash:指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端的请求一直发送到相同的服务器，以保证session会话，这样每个访客都固定访问一个后端服务器，可以解决session不能跨服务器的问题

upstream dynamicserver {
    
    
    #保证每个访客固定访问一个后端服务器
    ip_hash;  
    server 192.168.44.136:8081;#tomcat 1
    server 192.168.44.136:8082;#tomcat 2
    server 192.168.44.136:8083;#tomcat 3  
}

注意：

  • 在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）
  • ip_hash不能与backup同时使用
  • 此策略适合有状态服务，比如session
  • 当有服务器需要剔除，必须手动down掉

4,least_conn：把请求转发给连接数较少的后端服务器，轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高，这种情况下，least_conn这种方式就可以达到更好的负载均衡效果

upstream dynamicserver {
    
    
    #把请求转发给连接数较少的后端服务器
    least_conn;  
    server 192.168.44.136:8081;#tomcat 1
    server 192.168.44.136:8082;#tomcat 2
    server 192.168.44.136:8083;#tomcat 3
}

注意：此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况

3.负载均衡重试策略

基础失败重试：为了方便理解，使用了以下配置进行分析（proxy_next_upstream 没有特殊配置

upstream dynamicserver {
    
    
    server 192.168.44.136:8081 fail_timeout=60s max_fails=3;
    server 192.168.44.136:8082 fail_timeout=60s max_fails=3;
    server 192.168.44.136:8083 fail_timeout=60s max_fails=3;
}

配置说明：max_fails=3 fail_timeout=60s代表在60秒内请求某一应用失败3次，认为该应用宕机，后等待60秒，这期间内不会再把新请求发送到宕机应用，而是直接发到正常的那一台，时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次，如果还是失败，则继续等待60秒…以此循环，直到恢复

模拟异常：模拟后端异常的方式是直接将对应服务关闭，造成 connect refused 的情况，对应 error 错误

最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个 Server 处理。假设这时 A 节点服务崩溃，端口不通，则会出现这种情况：

  • 请求 1 转到 A 异常，再重试到 B 正常处理，A fails +1
  • 请求 2 转到 B 正常处理
  • 请求 3 转到 A 异常，再重试到 B 正常处理，A fails +1 达到 max_fails 将被屏蔽 60s
  • 屏蔽 A 的期间请求都只转给 B 处理，直到屏蔽到期后将 A 恢复重新加入存活列表，再按照这个逻辑执行

如果在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现：

  1. 请求 1 转到 B 异常，此时所有线上节点异常，会出现：
    • AB 节点一次性恢复，都重新加入存活列表
    • 请求转到 A 处理异常，再转到 B 处理异常
    • 触发 no live upstreams 报错，返回 502 错误
    • 所有节点再次一次性恢复，加入存活列表
  2. 请求 2 依次经过 AB 均无法正常处理， 触发 no live upstreams 报错，返回 502 错误

错误重试：有时候我们系统出现500等异常的情况下，希望nginx能够到其他的服务器进行重试，我们可以配置那些错误码才进行重试

配置说明：在nginx的配置文件中，proxy_next_upstream项定义了什么情况下进行重试，官网文档中给出的说明如下

Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ...;
Default:    proxy_next_upstream error timeout;
Context:    http, server, location

默认情况下，当请求服务器发生错误或超时时(error timeout)，会尝试到下一台服务器，还有一些其他的配置项如下

错误状态 描述
error 与服务器建立连接，向其传递请求或读取响应头时发生错误;
timeout 在与服务器建立连接，向其传递请求或读取响应头时发生超时;
invalid_header 服务器返回空的或无效的响应;
http_500 服务器返回代码为500的响应;
http_502 服务器返回代码为502的响应;
http_503 服务器返回代码为503的响应;
http_504 服务器返回代码504的响应;
http_403 服务器返回代码为403的响应;
http_404 服务器返回代码为404的响应;
http_429 服务器返回代码为429的响应（1.11.13）;
non_idempotent 通常，请求与 非幂等 方法（POST，LOCK，PATCH）不传递到请求是否已被发送到上游服务器（1.9.13）的下一个服务器; 启用此选项显式允许重试此类请求;
off 禁用将请求传递给下一个服务器

这里面我们配置了500等错误的时候会进行重试:

upstream dynamicserver {
    
    
    server 192.168.44.136:8081 fail_timeout=60s max_fails=3; #tomcat 1
    server 192.168.44.136:8082 fail_timeout=60s max_fails=3; #tomcat 2
}

server {
    
    
        server_name www.andy_test.com;
        default_type text/html;
        charset   utf-8;
        location/{
    
    
            proxy_pass http://dynamicserver;
            #下一节点重试的错误状态
            proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
       }
}

模拟异常：在正常的情况下如果500错误会直接出现异常页面，现在我们加入了以上500重试策略，重试错误的流程和上面流程是一样的

限制重试方式：默认配置是没有做重试机制进行限制的，也就是会尽可能去重试直至失败，Nginx 提供了以下两个参数来控制重试次数以及重试超时时间

  1. proxy_next_upstream_tries：设置重试次数，默认 0 表示无限制，该参数包含所有请求 upstream server 的次数，包括第一次后之后所有重试之和
  2. proxy_next_upstream_timeout：设置重试最大超时时间，默认 0 表示不限制，该参数指的是第一次连接时间加上后续重试连接时间，不包含连接上节点之后的处理时间

配置说明:

upstream dynamicserver {
    
    
      server 192.168.44.136:9001 fail_timeout=60s max_fails=3; #Server A
      server 192.168.44.136:9002 fail_timeout=60s max_fails=3; #Server B
}

server {
    
    
        server_name www.andy_test.com;
        default_type text/html;
        charset   utf-8;
        location /{
    
    
            proxy_pass http://dynamicserver;
            # 连接超时时间是3s
            proxy_connect_timeout 3s;
            #表示在 6 秒内允许重试 3 次，只要超过其中任意一个设置，Nginx 会结束重试并返回客户端响应
            proxy_next_upstream_timeout 6s;
            proxy_next_upstream_tries 3;
       }
}

backup 服务器：Nginx 支持设置备用节点，当所有线上节点都异常时启用备用节点，同时备用节点也会影响到失败重试的逻辑，因此单独列出来介绍

backup 处理逻辑：upstream 的配置中，可以通过 backup 指令来定义备用服务器，其含义如下

  1. 正常情况下，请求不会转到到 backup 服务器，包括失败重试的场景
  2. 当所有正常节点全部不可用时，backup 服务器生效，开始处理请求
  3. 一旦有正常节点恢复，就使用已经恢复的正常节点
  4. backup 服务器生效期间，不会存在所有正常节点一次性恢复的逻辑
  5. 如果全部 backup 服务器也异常，则会将所有节点一次性恢复，加入存活列表
  6. 如果全部节点（包括 backup）都异常了，则 Nginx 返回 502 错误

配置说明：

upstream dynamicserver {
    
    
  server 192.168.44.136:8081; #Service A
  server 192.168.44.136:8082; #Server B
  server 192.168.44.136:8083 backup; #backup
}

server {
    
    
        server_name www.andy_test.com;
        default_type text/html;
        charset   utf-8;
        location /{
    
    
            proxy_pass http://dynamicserver;
       }
}

在最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个节点处理，当只有 A 异常的情况下，与上文没有 backup 服务器场景处理方式一致，这里就不重复介绍了

假设在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现:

  1. 请求 1 转到 B 处理，异常，此时所有线上节点异常，会出现
    • AB 节点一次性恢复，都重新加入存活列表
    • 请求转到 A 处理异常，再重试到 B 处理异常，两者 fails 都 +1
    • 因 AB 都异常，启用 backup 节点正常处理，并且 AB 节点一次性恢复，加入存活列表
  2. 请求 2 再依次经过 A、B 节点异常，转到 backup 处理，两者 fails 都达到 max_fails：
    • AB 节点都将会被屏蔽 60s，并且不会一次性恢复
    • backup 节点正式生效，接下来所有请求直接转到 backup 处理
    • 直到 AB 节点的屏蔽到期后，重新加入存活列表

假设 AB 的屏蔽期都还没结束时，C 节点的服务也崩溃，端口不通，则会出现

  1. 请求 1 转到 C 异常，此时所有节点（包括 backup）都异常，会出现
    • ABC 三个节点一次性恢复，加入存活列表
    • 请求转到 A 处理异常，重试到 B 处理异常，最后重试到 C 处理异常
    • 触发 no live upstreams 报错，返回 502 错误
    • 所有节点再次一次性恢复，加入存活列表
  2. 请求 2 依次经过 AB 节点异常，重试到 C 异常，最终结果如上个步骤，返回 502 错误

十一.Nginx 常用案例

1. 静的ファイルのプロキシ:

server {
    
    
    listen       10086;
    server_name  www.andy_test.com;
    location / {
    
    
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_redirect off;
    }

    location /data/ {
    
    
         #这里是重点，就是代理这个文件夹
        alias '/usr/local/data/'; 
        expires    7d;
    }
}

http://localhost:10086/data/にアクセスし、/usr/local/dataフォルダにアクセスするためのリソースは以下のとおりです。

2. リバースプロキシ

server {
    
    
    listen       80;
    server_name  www.adny_test.com;;
    location / {
    
    
        proxy_pass http://127.0.0.1:8080;
        index  index.html index.htm .jsp;
    }
}

3. クロスドメイン構成

server {
    
    
        listen       80;
        server_name  www.andy_test.com;

    if ( $host ~ (.*).andy_test.com){
    
    
        set $domain $1;##记录二级域名值
    }
    #是否允许请求带有验证信息
    add_header Access-Control-Allow-Credentials true;
    #允许跨域访问的域名,可以是一个域的列表，也可以是通配符*
    add_header Access-Control-Allow-Origin  *;
    #允许脚本访问的返回头
    add_header Access-Control-Allow-Headers 'x-requested-with,content-type,Cache-Control,Pragma,Date,x-timestamp';
    #允许使用的请求方法，以逗号隔开
    add_header Access-Control-Allow-Methods 'POST,GET,OPTIONS,PUT,DELETE';
    #允许自定义的头部，以逗号隔开,大小写不敏感
    add_header Access-Control-Expose-Headers 'WWW-Authenticate,Server-Authorization';
    #P3P支持跨域cookie操作
    add_header P3P 'policyref="/w3c/p3p.xml", CP="NOI DSP PSAa OUR BUS IND ONL UNI COM NAV INT LOC"';
    if ($request_method = 'OPTIONS') {
    
    ##OPTIONS类的请求，是跨域先验请求
            return 204;##204代表ok
     }
}

おすすめ

転載: blog.csdn.net/weixin_44702984/article/details/131164119
おすすめ
ランキング
Android 自定义Gradle插件（六）：打包时修改assets中的文件
使用Volley框架发起网络访问的写法
[Calcul haute performance] Installation d'Opencl et concepts associés
POJ 1410（線分が交差する場合、ポリゴンの点が多角形+の範囲内です）
「アセンブリ言語」 - 読書ノート - 実験6実践コースのプログラム
Pythonのベース - >文字列、数値、変数
centos fedora 安装ffmpeg
ゼロポイント会長のユアン・ユエ氏：アルゴリズムの産業化は中国モデルの開発にもっと重点を置くべきだ
テストリリース、およびので、削除させていただきます
Pythonの研究ノート8：完全なオブジェクト指向プログラミング
アーカイブ
もっと
2024-06-07(0)
2024-06-06(0)
2024-06-05(0)
2024-06-04(0)
2024-06-03(1)
2024-06-02(0)
2024-06-01(1)
2024-05-31(1)
2024-05-30(0)
2024-05-29(1)

コードワールド

© 2018 codetd.com