nginxのクイックスタート Bステーションから学ぶ nginx 1時間集中講座

開発 2023-05-08 07:50:21 訪問数: null

nginxのクイックスタート Bステーションから学ぶ nginx 1時間集中講座

まず元のコースへのリンクを添付してください:
nginx 1 時間の集中講義コース
ビデオ コンテンツに基づいてメモを抽出し、学習記録を作成します. 原著者をサポートしていただければ幸いです.
コースウェア情報:コースウェア情報 (ユケ)
注: これは、ビデオを学習した後の注意事項の単なる復習です。

nginxの紹介と環境の準備

nginxの紹介

• Nginx は、軽量の Web サーバーおよびリバース プロキシ サーバーであり、メモリ フットプリントが小さく、起動が速く、同時実行性が高いため、インターネット プロジェクトで広く使用されています。

環境整備

• 仮想マシン
Centos7
• Web サーバー
Tomcat 8.5
• データベース
mysql 5.7
• JDK
JDK 8

/home目次の下

AdminLTE-3.2.0
apache-tomcat-8.5.81
apps
sql

/home/apps目次の下

ruoyi-admin.jar
ruoyi-admin.war

/home/app/sql目次の下

ry_20210924.sql
quartz.sql

1.nginxのインストール

  1. 仮想マシンがインターネットに正常にアクセスできることを確認する
  2. ファイアウォールをオフにする
# 关闭防火墙
systemctl stop firewalld

# 查看防火墙状态
systemctl status firewalld

# 关闭防火墙开机启动
systemctl disable firewald.service

docker を使用して nginx をプルし、命令を操作できます

docker pull nginx

docker run --name mn -p 80:80 -d nginx
# 进入nginx容器内部
docker exec -it mn bash
# 查看版本
nginx -v

dockerイメージ専用サーバーがある場合

#构建镜像
docker-compose up -d

docker run --name mn -p 80:80 -d ip地址:8080/nginx:1.0

1. yum を使用してインストールします

sudo yum install yum-utils net-tools

cat > /etc/yum.repos.d/nginx.repo << EOF
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/\$releasever/\$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
EOF

# 查看nginx仓库是否生效
yum repolist
# 安装nginx
sudo yum install nginx

このマシンで、仮想マシンの IP アドレスにアクセスすると、次の画面が表示され、インストールが成功したことが示されます。
ここに画像の説明を挿入

2. 共通コマンド

nginx 

#立即停止
nginx -s stop

#执行完当前请求再停止
nginx -s quit

#重新加载配置文件，相当于restart
nginx -s reload

#将日志写入一个新的文件
nginx -s reopen

#测试配置文件
nginx -t

ログにエラーがある/var/log/nginx/場合、ログで問題を取得できます
ここに画像の説明を挿入

tail -f error.log

3. systemctl を使用して、開始、停止、リロードします


注: centos 7 では、 nginx をsystemctl で起動すると、次のエラーが発生する場合があります
。解決策は次のとおりです。
● setenforce 0 (一時的)
● /etc/selinux/config を変更し、SELINUX=disabled に設定します (永続的に有効、再起動が必要)。

systemctl start nginx

systemctl status nginx

#产看日志
journalctl -xe
# 暂停
systemctl stop nginx

systemctl reload nginx

#配置开机启动
systemctl enable nginx

4. 設定ファイル

構成ファイルは にあり/etc/nginx/nginx.conf、次のコマンドは /etc/nginx/conf.d ディレクトリ内のすべての .conf ファイルを参照して、メイン構成ファイルを簡潔に保ち、同時に複数の .conf ファイルを構成します。簡単に区別でき、読みやすさが向上します。
構成ファイルは次のとおりです。
ここに画像の説明を挿入
構成ファイルは最後に次のように記述されます。
ここに画像の説明を挿入

include /etc/nginx/conf.d/*.conf;

デフォルトの割り当て/etc/nginx/conf.d/default.conf
ここに画像の説明を挿入

server {
    
    
    listen       80; #监听端口
    server_name  localhost;

    location / {
    
    
        root   /usr/share/nginx/html; #根目录
        index  index.html index.htm; #首页
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
    
    
        root   /usr/share/nginx/html;
    }
}

5. 設定ファイルの構造

http {
    
    

  server{
    
    #虚拟主机
     
    location {
    
    
      listen 80；
      server_name localhost;
    }
    location {
    
    
       
    }
      
  }

  server{
    
    
  
  }

}

2. 静的 Web を構成する

1. 静的 Web ページ構成

静的な AdminLTE バックグラウンド管理システムを構成します。
原作者情報からダウンロードできます
設定ファイル例：ディレクトリにファイルを作成し
ます/etc/nginx/conf.d/

touch AdminLTE.conf

次に編集

vim AdminLTE.conf

コマンド入力は次のとおりです。

server{
    
    
  
    listen 8000;
    server_name localhost;
    
    location / {
    
    
        root /home/AdminLTE-3.2.0;
        index index.html index2.html index3.html;
    }
  
}

仮想ホスト サーバーは、listen と server_name で区別されます。複数のサーバー構成がある場合、listen + server_name を繰り返すことはできません。

設定が完了したら、次のコマンドを使用してnginxをリロードします

nginx -s reload

その後、訪問したところ、訪問が失敗したことがわかりました

http://ip地址:8000/

大丈夫です。慌てる必要はありません。次の nginx ログを確認してください。

cd /var/log/nginx/
tail -f error.log

バインドされていないポートが
ここに画像の説明を挿入
解決策を見つけました


注: centos 7 では、 nginx をsystemctl で起動すると、次のエラーが発生する場合があります
。解決策は次のとおりです。
● setenforce 0 (一時的)
● /etc/selinux/config を変更し、SELINUX=disabled に設定します (永続的に有効、再起動が必要)。

セキュリティ ポリシーを 0 に設定

setenforce 0
# 重启nginx
nginx -s reload

再起動したら、またここに行きます

http://ip地址:8000/

訪問が成功したことが判明しました。
ここに画像の説明を挿入
これは一時的な解決策にすぎません。永続的なものに設定しました

vim /etc/selinux/config

次のように設定を変更し
ここに画像の説明を挿入
、仮想マシンを保存して再起動します

reboot

2.リスニングモニタリング

リッスンは、IP またはポート、または IP+ポートとして構成できます
listen 127.0.0.1:8000;
listen 127.0.0.1; (ポートは書き込まれません、デフォルト 80)
listen 8000;
listen *:8000;
listen localhost:8000;

3.サーバー名

server_name は主に区別するために使用され、任意に開始できます。
変数 $hostname を使用して、ホスト名として構成することもできます。
または、ドメイン名として構成します
。
次の例では:
curl http://localhost:80 は /usr/share/nginx/html にアクセスします
curl http://nginx-dev:80 は /home/AdminLTE-3.2.0 にアクセスします

仮想ホスト サーバーは、listen と server_name で区別されます。複数のサーバー構成がある場合、listen + server_name を繰り返すことはできません。

# curl http://localhost:80 会访问这个
server {
    
    
    listen       80;
    server_name  localhost;

    #access_log  /var/log/nginx/host.access.log  main;

    location / {
    
    
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

 # curl http://nginx-dev:80 会访问这个
server{
    
    
    listen 80;
    server_name nginx-dev;#主机名
    
    location / {
    
    
        root /home/AdminLTE-3.2.0;
        index index.html index2.html index3.html;
    }
  
}

4.場所

/Request は、常に / ディレクトリと一致するルート ディレクトリの
場所を指します。/css などのサブディレクトリがある場合は、/static/css を指します。

location /css {
    
    
  root /static;
}

3. HTTP リバース プロキシ

1. フォワード プロキシとリバース プロキシ

フォワード プロキシ

クライアント側でリクエストをプロキシすることは、フォワード プロキシと呼ばれます。たとえば、VPN .
ここに画像の説明を挿入

リバース プロキシ

サーバー側でのプロキシ転送リクエストは、リバース プロキシと呼ばれます。たとえば、nginx
ここに画像の説明を挿入

2. プロキシ サービスを構成する

ここに画像の説明を挿入
最初にデータベース テーブルをインポートします

# 进入mysql数据库端
mysql -u root -p

データベースを作成する

CREATE DATABASE ry CHARACTER SET utf8 COLLATE utf8_general_ci;
use ry

テーブルデータのコピー

source /home/sql/quartz.sql
source /home/sql/ry_20210924.sql

ここで、指定されたファイル内のテーブルの文字セットが指定されていないことに注意してください。文字セットを指定する必要があります。たとえば、次のように
追加します。CHARACTER SET utf8

create table QRTZ_LOCKS (
    sched_name           varchar(120)    not null            comment '调度名称',
    lock_name            varchar(40)     not null            comment '悲观锁名称',
    primary key (sched_name, lock_name)
)CHARACTER SET utf8 engine=innodb comment = '存储的悲观锁信息表';

ファイル ruoyi-admin.jar の application-druid.yml は、
ここに画像の説明を挿入
useSSL 設定を false に変更する必要があることに注意してください。
ここに画像の説明を挿入

ruoyi バックグラウンド サービスを開始します。ポートは 8088 です。

java -jar ruoyi-admin.jar

起動後、次のようにします。
ここに画像の説明を挿入

/etc/nginx/conf.d/ディレクトリにファイル ruoyi-8001.conf を作成し、
ここに画像の説明を挿入
次のように追加します。

server {
    
    
  listen 8001;
  server_name ruoyi.localhost;
  location / {
    
    
    proxy_pass http://localhost:8088;
  }
}

設定ファイルをリロードする

nginx -s reload

私たちは訪ねる

ip地址:8001

見られます
ここに画像の説明を挿入

proxy_pass 構成手順:

location /some/path/ {
    
    
    proxy_pass http://localhost:8080;
}

● プロキシ パス アドレスがポートにのみ設定され、他のパスが含まれていない場合、場所が転送アドレスに追加されます。
上記のように、アクセスはプロキシされhttp://localhost/some/path/page.html
ますhttp://localhost:8080/some/path/page.html

location /some/path/ {
    
    
    proxy_pass http://localhost:8080/zh-cn/;
}

proxy-pass のアドレスに / または他のパスが含まれている場合、上記のように /some/path が置き換えられ、アクセスはプロキシされhttp://localhost/some/path/page.html
ますhttp://localhost:8080/zh-cn/page.html

3. プロキシ リクエスト ヘッダーを設定する

ユーザーは、ヘッダー情報を再定義したり、バックエンド サーバーに追加したりできます。テキスト、変数、およびそれらの組み合わせを含めることができます。デフォルトでは、次の 2 つのフィールドのみが再定義されます。

proxy_set_header Host       $proxy_host;
proxy_set_header Connection close;

リバース プロキシを使用した後、バックエンド サービスはユーザーの実際の IP を取得できないため、通常、リバース プロキシは次のヘッダー情報を設定します。

location /some/path/ {
    
    
    #nginx的主机地址
    proxy_set_header Host $http_host;
    #用户端真实的IP，即客户端IP
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_pass http://localhost:8088;
}

一般的に使用される変数の値:
$host: 192.168.56.105 などの nginx ホスト IP
$http_host: nginx ホスト IP とポート、192.168.56.105:
$proxy_host8001: localhost:8088、proxy_pass で構成されたホスト名とポート
$remote_addr: ユーザーの実際の IP、つまり、クライアント IP です。

4. 非 HTTP プロキシ


HTTP 以外のプロキシサーバーにリクエストを渡したい場合は、次の手順を使用できます
。 PHP の場合)
● uwsgi_pass リクエストを uwsgi サーバーに転送します (主に Python で使用されます)
● memcached_pa​​ss はリクエストを memcached サーバーに転送します

4、静的および動的分離

1. 静的分離と動的分離の利点

Apache Tocmat は、厳密には Java EE サーバーであり、主にサーブレット リクエストの処理に使用されます。css、js、pictures などの静的ファイルを処理する IO パフォーマンスは十分ではありません.したがって、静的ファイルを nginx に渡すことで、システムのアクセス速度が向上し、Tomcat リクエストの数が減少し、効果的に負荷が軽減されます。バックエンド サーバー。

2. 個別の静的ファイル

ここに画像の説明を挿入
ruoyi-admin.war をデプロイする

# 移动并且重命名
mv /home/apps/ruoyi-admin.war /home/apache-tomcat-8.5.81/webapps/ROOT.war
# 删除原先的目录
rm -rf /home/apache-tomcat-8.5.81/webapps/ROOT
# 重新启动tomcat
cd /home/apache-tomcat-8.5.81/bin/
./startup.sh

ここに画像の説明を挿入
tomcat起動後、
ここに画像の説明を挿入
Tomcat起動後にログを確認

cd /home/apache-tomcat-8.5.81/logs/

ビュー・ログ

tail -f catalina.out

ログは、Tomcat が正常に起動したことを示しており、ポート 8080 です。
ここに画像の説明を挿入

デプロイが完了したら、プロジェクト ディレクトリを調整し、管理のために静的ファイルを nginx に渡します
注: i18n ディレクトリ全体をテンプレートに移動します

cd /home/apache-tomcat-8.5.81/webapps/ROOT
mv WEB-INF/classes/static/i18n  WEB-INF/classes/templates/i18n

application.yml を変更する

vim WEB-INF/classes/application.yml

ここに画像の説明を挿入

次のように変更します
ここに画像の説明を挿入

messages:
    # 国际化资源文件路径 
    # 将 static/i18n/messages 修改为 templates/i18n/messages
    basename: templates/i18n/messages

静的ファイル ディレクトリの説明:
js、css、およびイメージ ファイルに加えて、フォント ファイルと ie プロンプト ページもあります。
ここに画像の説明を挿入
ディレクトリを作成する

cd /home
mkdir www

次に、静的ファイルをTomcatの外に移動します

mv /home/apache-tomcat-8.5.81/webapps/ROOT/WEB-INF/classes/static /home/www

ここに画像の説明を挿入

最後に、nginx 構成ファイルを変更します.ディレクトリにファイル tomcat-8002.conf を作成し
、次のように内容を編集します:/etc/nginx/conf.d/
ここに画像の説明を挿入

server{
    
    
  listen:8002;
  server_name ruoyi.tomcat;
  
  location / {
    
    
    proxy_pass http://localhost:8080/;
  } 
  location = /html/ie.html {
    
    
    root  /home/www/static;
  }
  location ^~ /fonts/ {
    
    
    root  /home/www/static;
  }
  location ~ \.(css|js|png|jpg|gif|ico) {
    
    
    root /home/www/static;
}
}

次にnginxを再起動します

nginx -s reload

Tomcatを再起動する必要があります

# 重新启动tomcat
cd /home/apache-tomcat-8.5.81/bin/
./shutdown.sh
./startup.sh

ここに画像の説明を挿入
ビュー・ログ

cd /home/apache-tomcat-8.5.81/logs/

ビュー・ログ

tail -f catalina.out

スタートアップが成功したことがわかり
、私たちは訪問しました

ip地址:8080

静的読み込みが成功し
ここに画像の説明を挿入
、次に入ります

ip地址:8002

アクセスできないことが判明したのでnginxのログを見てみましょう
ここに画像の説明を挿入

cd /var/log/nginx/
tail -f error.log

ここに画像の説明を挿入
アクセス許可を静的ディレクトリに割り当てる

chmod -R 777 /home/www/static

再訪

ip地址:8002

ここに画像の説明を挿入

3. 位置修飾子

● location には、修飾子または正規表現を使用できます。
修飾子:
= equal to、厳密な一致、一致する優先度が最も高い。
^~ は通常の文字一致を意味します。プレフィックス マッチングを使用します。一致が成功した場合、他の場所は一致しません。2 番目に高いプライオリティです。
~ 大文字と小文字を区別します
~* 大文字と小文字を区別しません
●
優先度 優先度の高い順に次のとおりです。

  1. 完全一致 (=)
  2. 前方一致 (^~)
  3. 正規表現マッチング (~ および ~*)
  4. 書かないで
location ^~ /images/ {
    
    
    proxy_pass http://localhost:8080;
}

location ~ \.jpg {
    
    
    proxy_pass http://localhost:8080;
}

上記のように:
/images/1.jpgプロキシからhttp://localhost:8080/images/1.jpg
/some/path/1.jpgプロキシへhttp://localhost:8080/some/path/1.jpg

5. バッファリングとキャッシング

1. バッファー

バッファリングは通常メモリに配置されます. メモリに収まらない場合 (指定されたサイズを超えるなど), 応答はディスク上の一時ファイルに書き込まれます.
バッファリングが有効になった後、nginx は最初にバックエンド リクエストの応答 (応答) をバッファに入れ、応答全体が完了するまで待ってからクライアントに送信します。
ここに画像の説明を挿入

多くの場合、クライアントはユーザー ネットワークであり、状況は複雑であり、ネットワークが不安定で低速である可能性があります。
ただし、nginx とバックエンド サーバーは通常、同じコンピューター ルームまたはエリアに配置されており、ネットワーク速度は安定しており、非常に高速です。
ここに画像の説明を挿入
バッファリングが無効になっている場合、クライアントがプロキシ サーバーから応答を受信すると、同期的にクライアントに応答が送信されます。この動作は、できるだけ早く応答の受信を開始する必要がある高速な対話型クライアントにとって望ましい場合があります。
これは問題を引き起こします: クライアントから nginx へのネットワーク速度が遅すぎるため、nginx はより遅い速度でしかクライアントに応答を渡すことができず、バックエンド サーバーは同じより遅い速度でしか応答を送信できません。 nginx への応答が遅くなり、要求の接続に時間がかかりすぎます。
同時実行性が高い場合、バックエンド サーバーに大量のバックログ接続が存在する可能性があり、最終的にサーバーの負荷が低下します。

ここに画像の説明を挿入
プロキシ バッファリングを有効にすると、nginx は応答本文をできるだけ速く読み取ってローカル メモリまたはディスクにバッファリングし、クライアントのネットワーク品質に応じて適切なネットワーク速度でクライアントに応答を配信できます。
これにより、サーバー側での接続が多すぎるという問題が解決されるだけでなく、クライアントへの応答の継続的かつ安定した配信が保証されます。バッファリングを有効または無効にするには、 proxy_buffering を
使用します。nginx のデフォルトは、バッファリングを有効にするにはオン、オフにするにはオフに設定します。

proxy_buffering off;

proxy_buffersディレクティブは、接続ごとに応答を読み取るためのバッファーのサイズと数を設定します。デフォルトでは、バッファ サイズは、オペレーティング システムに応じて 4K または 8K の 1 つのメモリ ページに等しくなります。
バックエンド サーバーからの応答の最初の部分は、proxy_buffer_size ディレクティブによってサイズが設定された別のバッファーに格納されます。通常、この部分は比較的小さな応答ヘッダーであり、通常は既定値より小さく設定されます。

location / {
    
    
    proxy_buffers 16 4k;
    proxy_buffer_size 2k;
    proxy_pass http://localhost:8088;
}

応答全体がメモリに収まらない場合は、その一部をディスク上の 一時ファイル に保存します。
proxy_max_temp_file_size 一時ファイルの最大サイズを設定します。
proxy_temp_file_write_size一度書き込まれる一時ファイルのサイズを設定します。

2.キャッシュ

キャッシュが有効になると、nginx は応答をディスクに保存し、クライアントに返されるデータは最初にキャッシュから取得されるため、毎回同じ要求をバックエンド サーバーに送信する必要がなくなり、数が減ります。バックエンドリクエストの。
ここに画像の説明を挿入
キャッシュを有効にするには、 http コンテキストでproxy_cache_pathディレクティブを使用して、キャッシュのローカル ファイル ディレクトリ、名前、およびサイズを定義する必要があります。
キャッシュ領域は複数のサーバーで共有できます。proxy_cache を使用して、使用するキャッシュ領域を指定します。

http {
    
    
    proxy_cache_path /data/nginx/cache keys_zone=mycache:10m;
    server {
    
    
        proxy_cache mycache;
        location / {
    
    
            proxy_pass http://localhost:8000;
        }
    }
}

キャッシュ ディレクトリのファイル名は、proxy_cache_key の MD5 値です。
例:
/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c proxy_cache_key
デフォルト設定は次のとおりです。

proxy_cache_key $scheme$proxy_host$uri$is_args$args;

たとえば、キャッシュのキーをカスタマイズすることもできます。

proxy_cache_key "$host$request_uri$cookie_user";

キャッシュはあまり機密に設定しないでください。proxy_cache_min_uses を使用して同じキー リクエストを設定できます。指定した数を超える訪問数はキャッシュされます。

proxy_cache_min_uses 5;

デフォルトでは、応答は無期限にキャッシュに残ります。キャッシュが構成された最大サイズを超えた場合にのみ、最も古いデータが削除されます。
ここに画像の説明を挿入

ruoyi-8001.conf を修正

proxy_cache_path /var/cache/nginx/static keys_zone=static:100m;

server {
    
     
  listen 8001;
  server_name ruoyi.localhost;
  location / {
    
    
    proxy_buffers 16 4k;
    proxy_buffer_size 2k;
    proxy_pass http://localhost:8088;
  }

location ~ \.(js|css|png|jpg|gif|ico) {
    
    
        #设置cache

        proxy_cache static;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404      1m;
        proxy_cache_valid any 5m;  
        
        proxy_pass http://localhost:8088;
    }   
    
    location = /html/ie.html {
    
    
    
        proxy_cache static;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404      1m;
        proxy_cache_valid any 5m;  
        
        proxy_pass http://localhost:8088;
    }   
    
    location ^~ /fonts/ {
    
    
    
        proxy_cache static;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404      1m;
        proxy_cache_valid any 5m;  

        proxy_pass http://localhost:8088;
    }
}

変更後にnginxをリロードする

nginx -s reload

それから私たちは訪問します

IP地址:8001


ここに画像の説明を挿入
nginxのキャッシュログを見るにはブラウザのキャッシュ無効にチェックを入れる

cd /var/cache/nginx/static

キャッシュログが多いことが判明、通常、静的キャッシュはnginxに配置され、動的キャッシュはredisに配置されます
ここに画像の説明を挿入

6.負荷分散

複数のアプリケーション インスタンス間での負荷分散は、リソース使用率の最適化、スループットの最大化、待ち時間の短縮、およびフォールト トレラントな構成の確保に使用される一般的な手法です。nginx を非常に効果的な HTTP ロード バランサーとして使用し、トラフィックを複数のアプリケーション サーバーに分散することで、Web アプリケーションのパフォーマンスを向上させ、スケーラビリティと信頼性を向上させることができます。

1. サービス グループを構成する

ここに画像の説明を挿入
アップストリームを使用して一連のサービスを定義します。

注: アップストリームは http コンテキストにあり、サーバーと並置されます。サーバーには配置しないでください。

次のように、ディレクトリに/etc/nginx/conf.d/8003.conf 構成を作成します。
ここに画像の説明を挿入

upstream ruoyi-apps {
    
    
    #不写，采用轮循机制
    server localhost:8080;
    server localhost:8088;
}

server {
    
    
  
  listen 8003;
  server_name ruoyi.loadbalance;
  
  location / {
    
    
    proxy_pass http://ruoyi-apps;
  }
}

nginxを再起動するように設定

nginx -s reload

アクセス

ip地址:8003

ここに画像の説明を挿入
一部しかロードされていないことがわかりました.これは、以前の静的構成ファイルが 8002 になったためです
.8003.conf
を追加するように構成しましょう
ここに画像の説明を挿入

  location = /html/ie.html {
    
    
    root  /home/www/static;
  }
  location ^~ /fonts/ {
    
    
    root  /home/www/static;
  }
  location ~ \.(css|js|png|jpg|gif|ico) {
    
    
    root /home/www/static;
}

リロード

nginx -s reload

もう一度ここにアクセスして、ブラウザをチェックしてキャッシュを無効にしてください

ip地址:8003

ここに画像の説明を挿入
ログインすると表示されますが、これは
ここに画像の説明を挿入
ロードバランサーがデフォルトでラウンドロビン方式を採用しており、ポート8080と80882の間でジャンプを繰り返しているためです。

2.負荷分散戦略

(1). ラウンドロビン機構 (ラウンドロビン)

デフォルトのメカニズムは、ラウンドロビン方式で配布されます。

(2). 最小接続 (least-connected)

アクティブな接続が最も少ないサーバー (アイドラー サーバー) に次の要求を割り当てます。

upstream backend {
    
    
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

ラウンド ロビンまたは最小接続負荷分散では、各クライアントの要求が異なるサーバーに分散される可能性があることに注意してください。同じクライアントが常に同じサーバーに転送されるという保証はありません。を

(3)IPハッシュ

クライアントの IP アドレスがハッシュ キーとして使用され、同じ IP からの要求は同じサーバーに転送されます。

upstream backend {
    
    
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

この方法により、同じクライアントからの要求は、このサーバーが利用できない場合を除いて、常に同じサーバーに送られます。を
ここで 8003.conf を構成して
ここに画像の説明を挿入
追加します
ここに画像の説明を挿入

(4).ハッシュ

ユーザーがハッシュのキーをカスタマイズできるようにするユニバーサル ハッシュ キーは、文字列、変数、または組み合わせにすることができます。
たとえば、キーは、次の例に示すように、送信元 IP アドレスとポートのペア、または URI にすることができます。

upstream backend {
    
    
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

注意: IP ベースのハッシュ アルゴリズムには問題があります。つまり、上流のサーバーがダウンまたは拡張すると、多数のルーティングの変更が発生し、連鎖反応が発生して、大量のエラーが発生します。キャッシュ障害およびその他の問題。

Consistent パラメーターはketama一貫性のあるハッシュ アルゴリズムを有効にします。サーバーがアップストリーム グループに追加または削除された場合、キーの一部のみが再マッピングされるため、キャッシュの無効化が最小限に抑えられます。
キーに基づいてハッシュを行うとし
ここに画像の説明を挿入
サーバーがダウンすると、キーを再ハッシュする必要があり、最終的に対応するすべての関係が無効であることが判明し、キャッシュの大規模な無効化が発生します。
ここに画像の説明を挿入
解決策: コンシステント コンシステント ハッシュのパラメータを設定する
ここに画像の説明を挿入

(5).Random (ランダム）

各リクエストは、ランダムに選択されたサーバーに渡されます。
twoはオプションのパラメータです. NGINXはサーバーの重みを考慮して2つのサーバーをランダムに選択し, 次に指定された方法を使用してそのうちの1つを選択します. デフォルトでは, 接続数が最も少ないサーバーを選択します (least_conn ).

upstream backend {
    
    
    random two least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}

(6).ウエイト（重量）

ここに画像の説明を挿入

upstream my-server {
    
    
  
    server performance.server weight=3;
    server app1.server;
    server app2.server;

}

上記のように、5 つの新しいリクエストごとに、次のようにアプリケーション インスタンス間で分散されます。3 つのリクエストが performance.server に送信され、1 つのリクエストが app1.server に送信され、別のリクエストが app2.server に送信されます。を

(7).健康診断

リバース プロキシでは、バックエンド サーバーの応答失敗の数が一定期間内に指定された値を超えると、nginx はこのサーバーを失敗としてマークし、その後の期間はこのサーバーにリクエストを送信しません。
fail_timeoutで
チェックの失敗回数を max_fails で設定します。デフォルトは 1 回です。
次の例では

upstream backend {
    
    
  server backend1.example.com;
  server backend2.example.com max_fails=3 fail_timeout=30s; 
}

7、HTTPS 構成

HTTPS プロトコルは、HTTP と TLS/SSL プロトコルによって構築された、暗号化された伝送と身元認証のためのネットワーク プロトコルであり、主にデジタル証明書、暗号化アルゴリズム、非対称キーなどの技術を通じてインターネット データ伝送の暗号化を完了し、インターネット伝送のセキュリティ保護を実現します。

1.証明書を生成する

openssl genrsa -des3 -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

ここに画像の説明を挿入
生成されたファイルを/home/ssl以下に移動します
ここに画像の説明を挿入

構成ファイルをコピーする

cp 8003.conf 8004-https.conf

ここに画像の説明を挿入

2.sslを構成する

server {
    
    

  listen 8004 ssl;

   server_name         ruoyi.https;
   ssl_certificate     /home/ssl/server.crt;
   ssl_certificate_key /home/ssl/server.key;
   ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
   ssl_ciphers         HIGH:!aNULL:!MD5;

  server_name ruoyi.https.loadbalance;

  location / {
    
    
    proxy_pass http://ruoyi-apps;
  }
  location = /html/ie.html {
    
    
    root  /home/www/static;
  }
  location ^~ /fonts/ {
    
    
    root  /home/www/static;
    } 
  location ~ \.(css|js|png|jpg|gif|ico) {
    
    
    root /home/www/static;
}   
}

nginxを再起動するだけ

nginx -s reload

アクセス

https://ip地址:8004/

最後に、アクセスが成功しなかったことがわかりました.エラーを見てみましょう.エラー
メッセージは次のとおりです.
ここに画像の説明を挿入
証明書にパスワードがあるため.
パスワードが設定されている場合は、パスワードを追加して指定するファイルを作成する必要があります.パスワード。

vim /etc/nginx/conf.d/8004-https.conf

次のコンテンツを追加します。

server{
    
    
  ……
  ssl_password_file   /home/ssl/cert.pass;
  ……
}

ここに画像の説明を挿入
の下に/home/sslディレクトリを作成します。

touch cert.pass

次に、このファイルにパスワードを指定します. 設定後, 再起動します

nginx -s reload

アクセス

https://ip地址:8004/login

アクセス後、プロンプトは次のようになります。
ここに画像の説明を挿入
[詳細設定] をクリックしてアクセスを続行できます。
ここに画像の説明を挿入

3. https の最適化

SSL 操作は、追加の CPU リソースを消費します。最も CPU を集中的に使用する操作は、SSL ハンドシェイクです。クライアントごとのこれらの操作数を最小限に抑えるには、次の 2 つの方法があります。
● キープアライブ接続を有効にして、1 つの接続で複数のリクエストを送信します
● SSL セッション パラメータを再利用して、並列接続を回避し、後続の接続の SSL ハンドシェイク セッションは
ワーカー プロセスに保存されます。の間で共有され、ssl_session_cache ディレクティブによって構成された SSL セッション キャッシュ。1 メガバイトのキャッシュには、約 4000 のセッションが含まれます。デフォルトのキャッシュ タイムアウトは 5 分です。このタイムアウトは、ssl_session_timeout ディレクティブを使用して増やすことができます。以下は、10 MB の共有セッション キャッシュを持つマルチコア システム用に最適化された構成の例です。

8004-https.conf を変更します

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;

構成は次のとおりです。
ここに画像の説明を挿入

nginxを再起動する

nginx -s reload

八、TCPリバースプロキシ

次のように変更します。
ここに画像の説明を挿入

1.ストリーム

stream と http は並列であるため、変更できるのは nginx.conf のみであることに注意してください。
ここに画像の説明を挿入

#HTTP代理
http {
    
    
  server {
    
    
    listen 8002;
    proxy_pass http://localhost:8080/;
  }
}

#TCP代理
stream {
    
    
  server {
    
    
    listen 13306;
    proxy_pass localhost:3306;
  }
}

nginxを再起動する

nginx -s reload

仮想マシンのポート 13306 へのアクセスをテストして、リンクが成功していることを確認しましょう。
ここに画像の説明を挿入

2.tcp 負荷分散

nginx.conf を変更します。mysql 用に 8 の接続プールを定義できます。

stream {
    
    
  upstream backend-mysql {
    
    
  
    server localhost:3306;
    server localhost:3307;
    
    keepalive 8;
  }
  # TCP代理
  server {
    
    
    listen 13306;
    proxy_pass backend-mysql;
  }
}

キープアライブを使用して、接続プール内のアイドル接続の数を定義します。
keepalive_timeout のデフォルトは 60 秒です。接続プール内の接続のアイドル時間がこの値を超えると、接続は閉じられます。
HTTP の最も単純な実装では、クライアントは新しい接続を開き、要求を書き込み、応答を読み取り、接続を閉じて関連するリソースを解放します。
ここに画像の説明を挿入
クライアントが応答を読み取った後、後続の要求で再利用できるように、接続を開いたままにします。

ここに画像の説明を挿入
keepalive ディレクティブを使用して NGINX Plus からアップストリーム サーバーへのキープアライブ接続を有効にし、各ワーカー プロセスのキャッシュに保持するアップストリーム サーバーへのアイドル状態のキープアライブ接続の最大数を定義します。この数を超えると、使用頻度が最も低い接続が閉じられます。キープアライブがないと、オーバーヘッドがさらに増加し​​、接続とエフェメラル ポートの両方が非効率になります。
最新の Web ブラウザでは通常、6 ～ 8 個のキープアライブが開いています。

9. URL 書き換え

nginx には、return と rewrite の 2 つの書き換え命令があります。

1.戻る

サーバーは処理を停止し、ステータス コード status code をクライアントに返します。
return code URL
return code text
return code
return URL

1.1 すべてのリクエストに Https の使用を強制する


これで 8003 は http でアクセスでき、8004 は https です。次に、強制的に https にアクセスさせたいので、8004エラーをリダイレクトして8003 に書き込みます。

server {
    
    

    listen 8003;
    server_name ruoyi.loadbalance;

    return 301 https://localhost:8004;
}

正しいつづり

server {
    
    

    listen 8003;
    server_name ruoyi.loadbalance;

    return 301 https://192.168.56.105:8004;
}

8003.conf を変更し
ここに画像の説明を挿入
て nginx を再起動します

nginx -s load

私たちは訪ねる

ip地址:8003/

見つかった場所にジャンプします

https://ip地址:8004

1.2 転送とリダイレクト

転送はサーバー側の動作であり、リダイレクトはクライアント側の動作です。

Forwarding
プロキシ proxy_pass への送信は転送であり、ブラウザのアクセス バーに入力されたアドレスは変更されません。
ここに画像の説明を挿入
Redirection
return, rewrite は redirection に属し、クライアント側で実行されます。ブラウザのアクセスバーに入力したアドレスが変わります。
ここに画像の説明を挿入
ドメイン名の移行: ユーザーのお気に入りのリンクや検索エンジンのリンクを無効にしない.
www.old-name.com old-name.com (古いドメイン名) から www.new-name.com (新しいドメイン名) へのリクエストを永久にリダイレクトします. http および https 要求が含まれています

server {
    
    
    listen 80;
    listen 443 ssl;
    server_name www.old-name.com old-name.com;
    return 301 $scheme://www.new-name.com$request_uri;
}

URLのドメイン名以降の部分が取り込まれているため、新旧サイト間で1対1のページ対応があれば（例えばwww.new-name.com/aboutは基本的な内容が同じ）、この書き直しは適切です。ドメイン名の変更に加えてサイトが再編成された場合は、すべての要求を省略してホームページにリダイレクトする方が安全な場合があります。

server {
    
    
    listen 80;
    listen 443 ssl;
    server_name www.old-name.com old-name.com;
    return 301 $scheme://www.new-name.com;
}

wwwを追加

# add 'www'
server {
    
    
    listen 80;
    listen 443 ssl;
    server_name domain.com;
    return 301 $scheme://www.domain.com$request_uri;
}

1.3 ステータスコード

  • 2xx 成功

  • 3xx はリダイレクトを意味します

    • 301 パーマネント リダイレクト
    • 302一時リダイレクト

  • 4xx リクエストアドレスエラー

    • 403 拒否されたリクエスト
    • 404 リクエストが見つかりません

  • 5xx 内部サーバー エラー

2.書き換える

指定された正規表現がリクエスト URI と一致する場合、URI は文字列で指定されたとおりに変更されます。命令は、構成ファイルに記述されている順序で実行されます。

server {
    
    
    # ...
    rewrite ^(/download/.*)/media/(\w+)\.?.*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(\w+)\.?.*$ $1/mp3/$2.ra  last;
    return  403;
    # ...
}

上記は、このディレクティブを使用した NGINX 書き換えルールの例です。文字列 /download で始まり、/media/ または /audio/ ディレクトリがパスの後半に含まれる URL に一致します。これらの要素を /mp3/ に置き換え、適切なファイル拡張子 .mp3 または .ra を追加します。および変数は、変更されていないパス要素をキャプチャします。たとえば、/download/cdn-west/media/file1 は /download/cdn-west/mp3/file1.mp3 になります。ファイル名に拡張子 (.flv など) がある場合、エクスプレッションは拡張子を取り除き、.mp3 に置き換えます。
文字列に新しいリクエスト パラメータが含まれている場合、以前のリクエスト パラメータがこれらのパラメータに追加されます。これが必要ない場合は、置換文字列の末尾に疑問符を配置すると、それらの追加が回避されます。たとえば、次のようになります。

rewrite ^/users/(.*)$ /show?user=$1? last;

たとえば、
訪問する写真をアップロードするために 8002 を使用します。

ip:8004

サンプルの demo-form-file アップロードを開き、画像をアップロードします.
ここに画像の説明を挿入
訪問した画像の URL に
ここに画像の説明を挿入
アクセスできません
ここに画像の説明を挿入
. ログを確認して、訪問した URL が
ここに画像の説明を挿入
静的アドレスであることを確認しましょう.
ここに画像の説明を挿入
tomcat8002.conf を変更します.

rewrite ^/profile/upload http://localhost:8080$request_uri;


ここに画像の説明を挿入
再起動を増やす

nginx -s reload

私はまだ画像にアクセスしたくありません. localhost を IP アドレスに置き換え
ここに画像の説明を挿入
、nginx を再起動して
から画像にアクセスする必要があることがわかりました.

http://ip地址:8080/profile/upload/2023/03/21/rose1_20230321204522A001.jpg

設定成功
ここに画像の説明を挿入

3.ラストアンドブレイク

last: 現在のルールが一致しない場合、後続の書き換えルールの処理を停止し、書き換えられたパスを使用して、場所とそのブロック命令を再検索します。 break: 現在のルールが一致しない場合、後続の書き換えルールの処理を停止し、他の命令を実行します
。 {} ブロックで

4. last と break は使わない

root /home/AdminLTE-3.2.0/pages の下に 1.txt を作成します。

server {
    
    

    listen 8000;
    server_name nginx-dev;

    rewrite_log on;

    location / {
    
    
        rewrite ^/old/(.*) /new/$1;
        rewrite ^/new/(.*) /pages/$1;
        #根目录
        root /home/AdminLTE-3.2.0;
        #首页
        index index.html index2.html index3.html;
    }

    location  /pages/1.txt {
    
    
        return 200 "this is rewrite test!";
    }

}

デフォルトでは順次実行されます。
http://192.168.56.105:8000/old/1.txt にアクセスしてください
結果: これは書き換えテストです!
ログ:

[notice] 26837#26837: *1181 "^/old/(.*)" matches "/old/1.txt", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26837#26837: *1181 rewritten data: "/new/1.txt", args: "", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26837#26837: *1181 "^/new/(.*)" matches "/new/1.txt", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26837#26837: *1181 rewritten data: "/pages/1.txt", args: "", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"

5. ブレイクを使う

http://192.168.56.105:8000/old/1.txt にアクセスしてください
。 1. rewrite ^/old/(.*) /new/$1 に一致
2. break コマンドは後続の書き換えルールを実行せず、新しい /new / 1. ブロック内の他のコマンドを実行するための txt パス
3. ルート ディレクトリに移動してファイルを見つけます。ファイル /home/AdminLTE-3.2.0/new/1.txt が存在しないため、404 を返します。

server {
    
    

    listen 8000;
    server_name nginx-dev;

    rewrite_log on;

    location / {
    
    
        rewrite ^/old/(.*) /new/$1 break;
        rewrite ^/new/(.*) /pages/$1;
        #根目录
        root /home/AdminLTE-3.2.0;
        #首页
        index index.html index2.html index3.html;
    }

    location  /pages/1.txt {
    
    
        return 200 "this is rewrite test!";
    }

}

http://192.168.56.105:8000/old/1.txt にアクセスしてください
結果:
ここに画像の説明を挿入
アクセスログ:

[notice] 26772#26772: *1179 "^/old/(.*)" matches "/old/1.txt", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26772#26772: *1179 rewritten data: "/new/1.txt", args: "", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[error] 26772#26772: *1179 open() "/home/AdminLTE-3.2.0/new/1.txt" failed (2: No such file or directory), client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"

6.最後に使用

http://192.168.56.105:8000/old/1.txt にアクセスしてください。
1. 一致した書き換え ^/old/(. ) /new/$1
2. 最後の命令は後続の書き換えルールを実行せず、新しい /new/ を使用します。 1 場所に一致する .txt パス
3. 最初に一致する場所 /、場所に一致する書き換え ^/new/(. ) /pages/$1 ルールがある、/pages/
1.txtにリダイレクト
4. 一致する場所 /pages /1 .txt であるため、これは書き換えテストです!

server {
    
    

    listen 8000;
    server_name nginx-dev;

    rewrite_log on;

    location / {
    
    
        rewrite ^/old/(.*) /new/$1 last;
        rewrite ^/new/(.*) /pages/$1;
        #根目录
        root /home/AdminLTE-3.2.0;
        #首页
        index index.html index2.html index3.html;
    }

    location  /pages/1.txt {
    
    
        return 200 "this is rewrite test!";
    }

}

http://192.168.56.105:8000/old/1.txt にアクセスしてください
結果: これは書き換えテストです!
ログ:

[notice] 26969#26969: *1185 "^/old/(.*)" matches "/old/1.txt", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26969#26969: *1185 rewritten data: "/new/1.txt", args: "", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26969#26969: *1185 "^/old/(.*)" does not match "/new/1.txt", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26969#26969: *1185 "^/new/(.*)" matches "/new/1.txt", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"
[notice] 26969#26969: *1185 rewritten data: "/pages/1.txt", args: "", client: 192.168.56.1, server: nginx-dev, request: "GET /old/1.txt HTTP/1.1", host: "192.168.56.105:8000"

10. その他の共通コマンド

1.gzip圧縮

多くの場合、応答を圧縮すると、送信されるデータのサイズが大幅に縮小されます。ただし、圧縮は実行時に行われるため、かなりの処理オーバーヘッドが追加され、パフォーマンスに悪影響を及ぼす可能性があります。NGINX はクライアントに応答を送信する前に圧縮を実行しますが、バックエンド サーバーが既にコンテンツを圧縮している場合、nginx は圧縮しません。
圧縮を有効にするには、引数にgzipディレクティブを含めます。

gzip on; 
gzip_types text/plain application/xml; 
gzip_min_length 1000;

デフォルトでは、NGINX はMIME タイプがtext/htmlである応答のみを圧縮します。他の MIME タイプで応答を圧縮するには、gzip_typesディレクティブを使用して、他のタイプをリストします。
圧縮された応答の最小長を指定するには、gzip_min_lengthディレクティブを使用します。デフォルトは 20 バイトです (ここでは 1000 に調整されています)。

2.送信ファイル

デフォルトでは、NGINX はファイル転送自体を処理し、ファイルを送信する前にバッファにコピーします。sendfileディレクティブを有効にすると、データをバッファーにコピーする手順が不要になり、あるファイルが別のファイルに直接コピーされます。
Java のゼロ コピー (ゼロ コピー) と同様に、sendfile を有効にします。

location /download {
    
    
  sendfile           on;
  tcp_nopush         on; 
  #... 
}

sendfile ディレクティブとともにtcp_nopushディレクティブを使用します。これにより、NGINX は、データのチャンクを取得するとすぐに、1 つのパケットで HTTP 応答ヘッダーを送信できます。

3.try_files

指定したファイルまたはディレクトリが存在するかどうかを確認するには、try_filesディレクティブを使用できます。存在しない場合は、指定した場所にリダイレクトします。
次のように、元の URI に対応するファイルが存在しない場合、NGINX は内部的に /www/data/images/default.gif にリダイレクトします。

server {
    
    
    root /www/data;

    location /images/ {
    
    
        try_files $uri /images/default.gif;
    }
}

最後のパラメーターはステータス コードにすることもできます (ステータス コードの前に等号が必要です)。
以下の例では、ディレクティブの引数のいずれも既存のファイルまたはディレクトリに解決できない場合、404 エラーが返されます。

location / {
    
    
    try_files $uri $uri/ $uri.html =404;
}

次の例では、元の URI も末尾にスラッシュが追加された URI も既存のファイルまたはディレクトリに解決されない場合、要求は指定された場所にリダイレクトされ、プロキシ サーバーに渡されます。

location / {
    
    
    try_files $uri $uri/ @backend;
}

location @backend {
    
    
    proxy_pass http://backend.example.com;
}

4.error_page

エラー時に表示されるページを指定します。値には変数を含めることができます。

error_page 404             /404.html; 
error_page 500 502 503 504 /50x.html;

11. おすすめの書き方と注意点

おすすめの書き方

1. 重複した構成は親から継承できます

例えば：

server {
    
    
  server_name www.example.com;
  
  location / {
    
    
    root /var/www/nginx-default/;
    # [...]
  }
  location /foo {
    
    
    root /var/www/nginx-default/;
    # [...]
  }
  location /bar {
    
    
    root /some/other/place;
  # [...]
  }
}

推奨される書き方:

server {
    
    
    server_name www.example.com;
    root /var/www/nginx-default/;
    
    location / {
    
    
        # root继承父级配置
        # [...]
    }
    location /foo {
    
    
        # root继承父级配置
        # [...]
    }
    location /bar {
    
    
        # 覆盖
        root /some/other/place;
        # [...]
    }
}

このようにして、新しい場所を追加するときに構成の重複を避けることができます。

2. すべてのリクエストをバックエンド サーバーにプロキシしない

非推奨:

location / {
    
    
    proxy_pass http://localhost:8088;        
}

多くのリクエストが静的コンテンツ (画像、css、javascript、その他のファイルなど) にアクセスするためのものであることを考慮して、キャッシュを使用するか、静的ディレクトリを構成して、バックエンドに送信されるリクエストの数を減らすことができます。これにより、バックエンド サーバーのオーバーヘッドを削減できます。 .

server {
    
    

    listen 8002;
    server_name ruoyi.tomcat;
    root /home/www/static;

    location / {
    
    
        try_files $uri $uri/ @proxy;
    }

    location @proxy {
    
    
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://localhost:8080;
    }
  
}

これらの 2 つのルールに従って、tomcat-8002.conf を変更します。

server{
    
    
  listen 8002;
  server_name ruoyi.tomcat;
  # 公共的
  root /home/www/static;

  location / {
    
    
    try_files $uri $uri/ @proxy ;
  }

  location @proxy {
    
    
    proxy_pass http://localhost:8080;
  }

}

nginxを再起動する

nginx -s reload

通常アクセス

http://192.168.175.135:8002/login

ここに画像の説明を挿入

3. 必要がない場合は、動的リクエストをキャッシュせず、静的ファイルのみをキャッシュします

nginx关于缓存的指令非常多
     proxy_cache
     proxy_cache_background_update
     proxy_cache_bypass
     proxy_cache_convert_head
     proxy_cache_key
     proxy_cache_lock
     proxy_cache_lock_age
     proxy_cache_lock_timeout
     proxy_cache_max_range_offset
     proxy_cache_methods
     proxy_cache_min_uses
     proxy_cache_path
     proxy_cache_purge
     proxy_cache_revalidate
     proxy_cache_use_stale
     proxy_cache_valid
     proxy_no_cache

nginx サーバーのキャッシュは非常に複雑であるため、キャッシュを使用する場合、どのような条件でどのファイルがキャッシュされるかを明確に知る必要があります。
構成ファイルでは、キャッシュを使用するファイルを明確に指定することをお勧めします。

4. ファイルが存在するかどうかを確認するには、if -f の代わりに try_files を使用します

使用は推奨されません:

server {
    
    
    root /var/www/example.com;
    location / {
    
    
        if (!-f $request_filename) {
    
    
            break;
        }
    }
}

推奨される使用法:

server {
    
    
    root /var/www/example.com;
    location / {
    
    
        try_files $uri $uri/ /index.html;
    }
}

5. 書き換えパスに http:// または https:// を含める

#推荐写法
rewrite ^ http://example.com permanent; 

#不推荐的写法
rewrite ^ example.com permanent;

6. 書き換えルールをシンプルかつクリーンに保つ

たとえば、次の例は、より単純で理解しやすいものにすることができます。

#复杂的写法
rewrite ^/(.*)$ http://example.com/$1 permanent; 

#简单有效的写法
rewrite ^ http://example.com$request_uri? permanent; 
return 301 http://example.com$request_uri;

予防

1. 正しい構成が有効になりません。ブラウザのキャッシュをクリアしてください

変更した構成が正しいことを確認しても有効にならない場合は、ブラウザーのキャッシュをクリアするか、ブラウザーのキャッシュを無効にしてください。

2. HTTPS で SSLv3 を有効にしないでください

SSLv3 の POODLE 脆弱性のため、SSL 対応サイトで SSLv3 を使用することはお勧めしません。SSLv3 を非常に簡単に無効にして、次の行で TLS プロトコルのみを提供できます。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

3. ルート ディレクトリを / または /root として構成しないでください。

間違った使い方:

server {
    
    
  #错误用法
  root /;
  
  location /project/path {
    
    
    #错误用法
    root /root;
  }
}

4. 注意して chmod 777 を使用する

これはおそらく問題を解決する最も簡単な方法であり、何が問題なのかを本当に理解していないことも示しています. show パスのすべての権限を使用して、問題の根本原因を見つける
ことができます。namei -om /path/to/check

5.デプロイされたプロジェクトをデフォルトのディレクトリにコピーしないでください

nginx をアップグレードまたは更新すると、デフォルトのディレクトリが上書きされる場合があります。

おすすめ

転載: blog.csdn.net/sinat_38316216/article/details/129677759
おすすめ
ランキング
--- ELオプションを搭載するテンプレートを指定するオプションをレンダリング別テンプレート/使用を指定するためのオプションを使用して、インラインテンプレート/テンプレートの使用を指定するために、テンプレート/テンプレートオプションを使用してテンプレートを指定します
0216leetcodeはPythonで5つの質問をブラシします
ショック！七つの子どもたちは魂を拷問しました！暴露子どもたちはインサイダーを振っプログラム！
ターゲット属性タグをhtmlの
Linuxビルドnacosスタンドアロンバージョンとクラスター
Cálculo experimental da renda simulada de investimento fixo do fundo
Kali Linux は VMware ツールをインストールします (vmtools ボタンは灰色です)
程序员洞察报告：90后占比过半 搜索算法等岗位人才短缺
【Java基礎シリーズチュートリアル】第17章 Javaアノテーション
Javaでの空白を入力できないようにユーザー
アーカイブ
もっと
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)
2024-05-03(8)
2024-05-02(0)
2024-05-01(4)
2024-04-30(35)

コードワールド

© 2018 codetd.com