CentOS7のインストールとエントリからマスターまでのnginxのメンテナンス

Nginxは、プロキシHTTP、HTTPS、およびメール関連（SMTP、POP3、IMAP）プロトコルリンクを逆にすることができるパフォーマンス指向のHTTPサーバーです。また、[ロードバランシング]（https://cloud.tencent.com/product/clb?from=10680）とHTTPキャッシングを提供します。その設計は、非同期イベントモデルを最大限に活用し、コンテキストスケジューリングのオーバーヘッドを削減し、サーバーの同時実行機能を向上させます。モジュラー設計を採用し、豊富なモジュールを備えたサードパーティ製モジュールを提供しています。

したがって、Nginxについては、次のタグがあります。「非同期」「イベント」「モジュール性」「高性能」「高い同時実行性」「逆プロキシ」「負荷分散」

Linuxシステム： Centos 7 x64 Nginxバージョン： 1.11.5

インストール##

インストールの依存関係###

prce（リダイレクトサポート）およびopenssl（httpsサポート、httpsが必要ない場合は、インストールする必要はありません。）

yum install -y pcre-devel 
yum -y install gcc make gcc-c++ wget
yum -y install openssl openssl-devel

CentOS 6.5インストール時に「基本サーバー」を選択しました。デフォルトでは、これら2つのパッケージはどちらもインストールされていないため、両方をインストールできます。

ダウンロード＃＃＃

nginxのすべてのバージョンはここにあります

wget http://nginx.org/download/nginx-1.13.3.tar.gz
wget http://nginx.org/download/nginx-1.13.7.tar.gz
# wgetがインストールされていない場合#コンパイルされたバージョンをダウンロードする
$ yum install wget
# 圧縮されたパッケージを解凍します
tar zxf nginx-1.13.3.tar.gz

コンパイルしてインストール###

次に、コンパイルしてインストールするディレクトリを入力し、パラメータの説明を構成します

cd nginx-1.11.5./configure

....
Configuration summary
 + using system PCRE library
 + OpenSSL library is not used
 + using system zlib library

 nginx path prefix:"/usr/local/nginx"
 nginx binary file:"/usr/local/nginx/sbin/nginx"
 nginx modules path:"/usr/local/nginx/modules"
 nginx configuration prefix:"/usr/local/nginx/conf"
 nginx configuration file:"/usr/local/nginx/conf/nginx.conf"
 nginx pid file:"/usr/local/nginx/logs/nginx.pid"
 nginx error log file:"/usr/local/nginx/logs/error.log"
 nginx http access log file:"/usr/local/nginx/logs/access.log"
 nginx http client request body temporary files:"client_body_temp"
 nginx http proxy temporary files:"proxy_temp"
 nginx http fastcgi temporary files:"fastcgi_temp"
 nginx http uwsgi temporary files:"uwsgi_temp"
 nginx http scgi temporary files:"scgi_temp"

たとえば、「Cコンパイラccが見つかりません」というインストールエラーが報告された場合、これはコンパイル環境がないためです。インストールするだけです。yum-yinstall gcc make gcc-c ++ openssl-devel

エラーメッセージが表示されない場合は、次のインストールを実行できます。

make
make install

nginx test

次のコマンドを実行すると、2つの結果が得られます。通常、nginxは / usr / local / nginxディレクトリにインストールされます。

cd /usr/local/nginx/sbin/./nginx -t
# nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
# nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

グローバルnginxコマンドを設定する###

vi ~/.bash_profile

次のコンテンツを 〜/ .bash_profileファイルに追加します

PATH=$PATH:$HOME/bin:/usr/local/nginx/sbin/export PATH

コマンド source〜 / .bash_profileを実行して、構成をすぐに有効にします。 nginxコマンドはグローバルに実行できます。

最初から起動##

セルフスタート方法1：

タッチnginx.serviceを作成せずに、vi /lib/systemd/system/nginx.serviceファイルを編集してから、特定の状況に応じて次のコンテンツを変更し、nginx.serviceファイルに追加します。

[ Unit]
Description=nginx
After=network.target remote-fs.target nss-lookup.target

[ Service]

Type=forking
PIDFile=/var/run/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s QUIT $MAINPIDPrivateTmp=true[Install]
WantedBy=multi-user.target

説明：サービスについて説明します
変更後：サービスカテゴリについて説明してください
[ サービス]サービス動作パラメータ設定
Type = forkingはバックグラウンド操作の形式です
ExecStartは、サービスの特定の実行中のコマンドです
ExecReloadは再起動コマンドです
ExecStopは停止コマンドです
PrivateTmp = Trueは、独立した一時スペースをサービスに割り当てることを意味します
注：[サービス]の開始、再起動、および停止コマンドにはすべて絶対パスが必要です
[ インストール]実行レベルでのサービスインストールの関連設定は、マルチユーザーに設定できます。つまり、システム実行レベルは3です。

保存して終了。

構成を有効にするためにスタートアップを設定します。

systemctl enable nginx.service
# 次の出力は成功を示しています

Created symlink from/etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.

ブート方法2：

vi /etc/rc.local
# rcで.ローカルファイルに、次のコマンドを追加します
/usr/local/nginx/sbin/nginx start

起動後にセルフスタートスクリプトが実行されない場合は、rc.localはデフォルトでは実行できないため、ファイルrc.localのアクセス許可が実行可能かどうかを確認する必要があります。 rc.localアクセス許可を変更し、実行可能許可を増やします。

chmod +x /etc/rc.d/rc.local

運用・保守##

サービス管理＃＃＃

# 起動
/usr/local/nginx/sbin/nginx
# リブート
/usr/local/nginx/sbin/nginx -s reload
# シャットダウンプロセス
/usr/local/nginx/sbin/nginx -s stop
# nginxをスムーズに閉じる
/usr/local/nginx/sbin/nginx -s quit
# nginxのインストール状況を確認してください。
/usr/local/nginx/sbin/nginx -V

ファイアウォールをオフにするか、テストするファイアウォールルールを追加します

service iptables stop

または、構成ファイルを編集します。

vi /etc/sysconfig/iptables

このようなルールを追加してポート80を開き、保存します。

- A INPUT -m state --state NEW -m tcp -p tcp --dport 80-j ACCEPT

次の目的でサービスを再起動します。

service iptables restart
# 現在のnatを表示するコマンド
iptables -t nat -L

サービスファイアウォールのエラー解決を再開します###

service iptables restart
# Redirecting to /bin/systemctl restart  iptables.service
# Failed to restart iptables.service: Unit iptables.service failed to load: No such file or directory.

CentOS7またはRHEL7またはFedoraでは、ファイアウォールはfirewalldによって管理されます。もちろん、従来の管理方法を復元することもできます。または、管理に新しいコマンドを使用します。従来型を使用する場合は、次のコマンドを実行してください。

# 従来のコマンド
systemctl stop firewalld
systemctl mask firewalld

# インストールコマンド
yum install iptables-services
systemctl enable iptables 
service iptables restart

nginxアンインストール##

yum経由でインストールする場合は、次のコマンドを使用してインストールします。

yum remove nginx

/ usr / local / nginxディレクトリをコンパイルしてインストールし、削除します。セルフスタートスクリプトが設定されている場合は、それも削除する必要があります。

パラメータ説明##

Nginxのインストールパス。指定しない場合、デフォルトは/usr/local/nginx。

構成##

Centosでは、デフォルトの構成ファイルは/usr/local/nginx-1.5.1/conf/nginx.confです。ここでいくつかのファイルを構成する必要があります。 nginx.confは、いくつかの部分で構成されるメインの構成ファイルであり、各中括弧 {}は部分を表します。命令の各行は、行の終わりを示すセミコロン ;で終わります。

一般的に使用される通常の###

レギュラー	説明	レギュラー	説明
.	新行文字以外の任意の文字に一致	$	文字列の末尾に一致
?	0回または1回繰り返す	{n}	n回繰り返す
+	1回以上繰り返す	{n、}	n回以上繰り返す
*	0回以上繰り返す	[c]	単一の文字に一致するc
\ d	一致番号	[az]	az小文字のいずれかに一致
^	文字列の先頭に一致する	-	-

グローバル変数###

変数	説明	変数	説明
$ args	この変数は、クライアントの$ query_string	$ remote_port	portと同じ、要求行のパラメーターと同じです。
$ content_length	リクエストヘッダーのContent-lengthフィールド。	$ remote_user	Auth BasicModuleによって検証されたユーザー名。
$ content_type	リクエストヘッダーのContent-Typeフィールド。	$ request_filename	rootまたはaliasコマンドとURIリクエストによって生成された現在のリクエストのファイルパス。
$ document_root	現在のリクエストのrootディレクティブで指定された値。	$ schema	HTTPメソッド（http、httpsなど）。
$ host	ホストヘッダーフィールドを要求します。それ以外の場合はサーバー名を要求します。	$ server_protocol	リクエストで使用されるプロトコル。通常はHTTP / 1.0またはHTTP / 1.1です。
$ http_user_agent	クライアントエージェント情報	$ server_addr	サーバーアドレス。この値は、システム呼び出しの完了後に決定できます。
$ http_cookie	クライアントcookie情報	$ server_name	サーバー名。
$ limit_rate	この変数は、接続速度を制限できます。	$ server_port	サーバーに到達するためのリクエストのポート番号。
$ request_method	クライアントによって要求されたアクション、通常はGETまたはPOST。	$ request_uri	/foo/bar.php?arg=bazのように、ホスト名を含まない、要求パラメーターを含む元のURI。
$ remote_addr	クライアントのIPアドレス。	$ uri	リクエストパラメータのない現在のURI。$ uriには、/ foo /bar.htmlなどのホスト名は含まれていません。
$ document_uri	$ uriと同じです。	-	-

リクエストの例： http：// localhost：3000 / test1 / test2 / test.php

$host：localhost
$server_port：3000
$request_uri：/test1/test2/test.php
$document_uri：/test1/test2/test.php
$document_root：/var/www/html
$request_filename：/var/www/html/test1/test2/test.php

シンボルリファレンス###

シンボル	説明	シンボル	説明	シンボル	説明
k、K	キロバイト	m、M	メガバイト	ms	ミリ秒
s	秒	m	分	h	時間
d	日	w	週	M	1か月、30日

たとえば、「8k」と「1m」はバイトカウントを表します。
たとえば、「1時間30分」、「1年6分」などです。「1時間30分」「1年6ヶ月」を表します。

構成ファイル###

nginxの構成システムは、メイン構成ファイルとその他の補助構成ファイルで構成されています。これらの構成ファイルはすべてプレーンテキストファイルであり、すべてnginxインストールディレクトリの下のconfディレクトリにあります。

命令はnginxのさまざまなモジュールによって提供され、モジュールごとに構成を実装するためのさまざまな命令が提供されます。 Key-Valueコマンドの形式に加えて、スコープコマンドもあります。

nginx.confの構成情報は、論理的な意味に従って分類されます。論理的な意味は、複数のスコープに分割されるか、構成命令コンテキストと呼ばれます。異なるスコープには、1つ以上の構成アイテムが含まれています。

次のコンテキスト命令がより使用されます。

Directive	Description	Contains Directive
実行時の特定のビジネス機能（httpサービスや電子メールサービスプロキシなど）とは関係のないmain	nginxのパラメーター（ワークプロセスの数、実行中のIDなど）。	user、worker_processes、error_log、events、http、mail
http	httpサービスの提供に関連するいくつかの構成パラメーター。例：keepaliveを使用するかどうか、圧縮にgzipを使用するかどうかなど。	サーバー
server	httpサービスではいくつかの仮想ホストがサポートされています。各仮想ホストには、仮想ホストに関連する構成を含む、対応するサーバー構成アイテムがあります。メールサービスのプロキシを提供する場合、複数のサーバーを確立することもできます。各サーバーはリスニングアドレスによって区別されます。	listen、server_name、access_log、location、protocol、proxy、smtp_auth、xclient
location	httpサービスで、特定の特定のURLに対応する一連の構成アイテム。	インデックス、ルート
mail	電子メール関連のSMTP / IMAP / POP3プロキシを実装する場合、一部の構成アイテムが共有されます（複数のプロキシが実装されている可能性があるため、複数のリスニングアドレスで動作します）。	サーバー、http、imap_capabilities
include	構成ファイルの読みやすさを向上させ、構成ファイルの一部を再利用できるようにするため。	-
valid_referers	HttpリクエストヘッダーのRefererが有効かどうかを確認するために使用されます。	-
try_files	はサーバー部分で使用されますが、最も一般的なものは依然としてロケーション部分で使用され、指定されたパラメーターの順序に従って試行され、最初に一致したものが使用されます。	-
if	ロケーションブロックでif命令を使用する場合、期待どおりに機能しない場合があります。通常、if命令の使用は避けてください。	-

たとえば、nginx.confの2つの構成、vhost /example.com.confとvhost / gitlab.com.confを引用します。これらはすべて、私が作成した新しいディレクトリvhostの下に配置されます。 nginx.confの構成は次のとおりです。

worker_processes  1;
events {    
 worker_connections  1024;}
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"';

 # access_log  logs/access.log  main;

 sendfile        on;    
 # tcp_nopush     on;

 # keepalive_timeout  0;
 keepalive_timeout  65;    
 # gzip  on;
 server {        
  listen       80;        
  server_name  localhost;        
  location /{            
   root   html;            
   index  index.html index.htm;}        
  error_page   500502503504/50x.html;        
  location =/50x.html {            
   root   html;}}    
 include  vhost/example.com.conf;    
 include  vhost/gitlab.com.conf;}

簡単な構成：example.com.conf

server {    
 # リスニングポート80
 listen       80;    
 server_name  baidu.com app.baidu.com; #ここでドメイン名を指定します
 index        index.html index.htm;    #ここでデフォルトのエントリページを指定します
 root /home/www/app.baidu.com;         #ここでディレクトリを指定します
}

組み込みの定義済み変数###

Nginxには多くの定義済み変数があり、setを使用して設定することもできます。 ifで事前定義された変数を使用するか、それらをプロキシサーバーに渡すことができます。以下は、いくつかの一般的な定義済み変数です。詳細を参照してください

変数名	値
$ args_name	リクエストのnameパラメータ
$ args	すべてのリクエストパラメータ
$ query_string	$ argsのエイリアス
$ content_length	リクエストヘッダーContent-Length値
$ content_type	リクエストヘッダーContent-Type値
$ host	現在Hostがある場合、それはリクエストヘッダーHostの値です。そのようなヘッダーがない場合、値はリクエストに一致するserver_nameの値と等しくなります
$ remote_addr	クライアントのIPアドレス
$ request	Httpリクエストメソッド、URI、Httpプロトコル、ヘッダー、リクエスト本文を含む、クライアントから受信した完全なリクエスト
$ request_uri	完全なリクエストURI、パラメータを含むクライアントからのリクエスト
$ schema	現在要求されているプロトコル
$ uri	現在のリクエストの標準化されたURI

リバースプロキシ###

リバースプロキシは、クライアント接続要求を受け入れ、その要求をアップストリームサーバーに転送し、サーバーから取得した結果を接続されたクライアントに返すWebサーバーです。次の簡単な逆プロキシの例：

server {  
 listen       80;                                                        
 server_name  localhost;                                              
 client_max_body_size 1024M;  #クライアントが許可する単一ファイルの最大バイト数

 location /{    
 proxy_pass                         http://localhost:8080;    
 proxy_set_header Host              $host:$server_port;    
 proxy_set_header X-Forwarded-For   $remote_addr; #HTTPリクエスターの実際のIP
 proxy_set_header X-Forwarded-Proto $scheme;      #実際のユーザーが送信したプロトコルがhttpかhttpsかを正しく識別するため
  }}

複雑な構成：gitlab.com.conf。

server {    
 # リスニングポート80
 listen       80;    
 server_name  git.example.cn;    
 location /{        
  proxy_pass   http://localhost:3000;        #以下は、削除できるいくつかのリバースプロキシ構成です。
  proxy_redirect             off;        #バックエンドWebサーバーはXを渡すことができます-Forwarded-ユーザーの実際のIPを取得するため
  proxy_set_header           Host $host;        
  client_max_body_size       10m; #クライアントが許可する単一ファイルの最大バイト数
  client_body_buffer_size    128k; #クライアントをバッファリングするためにバッファエージェントによって要求された最大バイト数
  proxy_connect_timeout      300; #Nginxはバックエンドサーバーのタイムアウト時間に接続します(エージェント接続がタイムアウトしました)
  proxy_send_timeout         300; #バックエンドサーバーデータの戻り時間(プロキシ送信タイムアウト)
  proxy_read_timeout         300; #接続が成功した後、バックエンドサーバーの応答時間(プロキシ受信タイムアウト)
  proxy_buffer_size          4k; #プロキシサーバー（nginx）のバッファーサイズを設定して、ユーザーヘッダー情報を保存します
  proxy_buffers              4 32k; #proxy_バッファ、平均Webページが32k未満の場合は、このように設定します
  proxy_busy_buffers_size    64k; #高負荷時のバッファサイズ（プロキシ_buffers*2）
    }}

アップストリームサーバーへのプロキシの構成で最も重要なことは、proxy_pass命令です。プロキシモジュールの一般的な手順は次のとおりです。

指示	説明
proxy_connect_timeout	Nginxがリクエストを受け入れてからアップストリームサーバーに接続するまでの最大待機時間
proxy_send_timeout	バックエンドサーバーデータの戻り時間（プロキシ送信タイムアウト）
proxy_read_timeout	接続が成功した後、バックエンドサーバーの応答時間（プロキシ受信タイムアウト）
proxy_cookie_domain	アップストリームサーバーからSet-Cookieヘッダーのドメイン属性を置き換えます
proxy_cookie_path	アップストリームサーバーからのSet-Cookieヘッダーのパス属性を置き換えます
proxy_buffer_size	ユーザーヘッダー情報を格納するためのプロキシサーバー（nginx）のバッファーサイズを設定します
proxy_buffers	proxy_buffersバッファー、平均してk未満のページ数
proxy_set_header	アップストリームサーバーに送信されるヘッダーの内容を書き換えます。または、ヘッダーを送信する代わりに、ヘッダーの値を空の文字列に設定することで実現できます
proxy_ignore_headers	このディレクティブは、プロキシサーバーからの応答の処理を禁止します。
proxy_intercept_errors	nginxにHTTP応答コード400以上の応答をブロックさせます。

ロードバランシング###

アップストリームディレクティブは、アップストリームサーバーのグループが定義されている新しい構成セクションを有効にします。これらのサーバーは、異なる重みで設定されている場合や、サーバーのメンテナンスのためにダウンとしてマークされている場合があります。

upstream gitlab {
 ip_hash;    #アップストリームロードバランシングの場合、重量は重量であり、マシン構成に従って定義できます。重みパラメータは重みを表し、重みが大きいほど、割り当てられる可能性が高くなります。
 server 192.168.122.11:8081;    
 server 127.0.0.1:82 weight=3;    
 server 127.0.0.1:83 weight=3 down;    
 server 127.0.0.1:84 weight=3; 
 max_fails=3  fail_timeout=20s;    
 server 127.0.0.1:85 weight=4;;    
 keepalive 32;}
server {    
 # リスニングポート80
 listen       80;    
 server_name  git.example.cn;    
 location /{        
  proxy_pass   http://gitlab;    #ここで、アップストリームと同じ名前のプロキシを設定します
  # 以下は、削除できるいくつかのリバースプロキシ構成です。
  proxy_redirect             off;        #バックエンドWebサーバーはXを渡すことができます-Forwarded-ユーザーの実際のIPを取得するため
  proxy_set_header           Host $host;        
  proxy_set_header           X-Real-IP $remote_addr;        
  proxy_set_header           X-Forwarded-For $proxy_add_x_forwarded_for;        
  client_max_body_size       10m;  #クライアントが許可する単一ファイルの最大バイト数
  client_body_buffer_size    128k; #クライアントをバッファリングするためにバッファエージェントによって要求された最大バイト数
  proxy_connect_timeout      300;  #Nginxはバックエンドサーバーのタイムアウト時間に接続します(エージェント接続がタイムアウトしました)
  proxy_send_timeout         300;  #バックエンドサーバーデータの戻り時間(プロキシ送信タイムアウト)
  proxy_read_timeout         300;  #接続が成功した後、バックエンドサーバーの応答時間(プロキシ受信タイムアウト)
  proxy_buffer_size          4k; #プロキシサーバー（nginx）のバッファーサイズを設定して、ユーザーヘッダー情報を保存します
  proxy_buffers              4 32k;#バッファ、平均Webページが32k未満の場合は、これを設定します
  proxy_busy_buffers_size    64k; #高負荷時のバッファサイズ（プロキシ_buffers*2）
  proxy_temp_file_write_size 64k; #この値より大きいキャッシュフォルダのサイズを設定すると、アップストリームサーバーからアップロードされます
    }}

各リクエストは、異なるバックエンドサーバーに時系列で1つずつ割り当てられます。バックエンドサーバーがダウンしている場合は、自動的に削除できます。

負荷分散：

アップストリームモジュールは、ポーリング、IPハッシュ、および最小接続の3つの負荷分散アルゴリズムを使用できます。

ポーリング：ポーリングアルゴリズムはデフォルトで使用され、アクティブ化するための構成手順は必要ありません。これは、アクセスが各アップストリームサーバーに均等に分散されるように、キューの次のユーザーの原則に基づいています。
IPハッシュ：ip_hashコマンドでアクティブ化します。Nginxは、IPv4アドレスの最初の3バイトまたはIPv6アドレス全体をハッシュキーとして使用します。同じIPアドレスを常に同じアップストリームサーバーにマップできます。
最小接続数：least_conn命令でアクティブ化します。アルゴリズムは、接続するアクティブ接続の数が最も少ないアップストリームサーバーを選択します。アップストリームサーバーの処理機能が異なる場合は、サーバーの重みを構成することで説明できます。アルゴリズムでは、異なるサーバーの重み付き最小接続数が考慮されます。

RR

簡単な構成です。ここでは2つのサーバーを構成しました。もちろん、実際には1つですが、ポートが異なり、8081サーバーが存在しません。つまり、アクセスできませんが、http：// localhostにアクセスします。サーバーにアクセスできない場合（サーバーがハングアップしている場合）、サーバーにアクセスできない場合（サーバーがハングアップしている場合）はジャンプしません。デフォルトでは http：// localhost：8080にジャンプします。これは、Nginxがサーバーのステータスを自動的に判断するためです。このサーバーでは、サーバーがハングして使用に影響を与える状況も回避されます。NginxはデフォルトでRRポリシーであるため、他の設定は必要ありません。

upstream test {    
 server localhost:8080;    
 server localhost:8081;}
server {    
 listen       81;    
 server_name  localhost;    
 client_max_body_size 1024M; 
 location /{        
  proxy_pass http://test;        
  proxy_set_header Host $host:$server_port;}}

負荷分散のコアコードは

upstream test {    
 server localhost:8080;    
 server localhost:8081;}

重み####

ポーリング確率を指定します。重みはアクセス率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。例えば

upstream test {    
 server localhost:8080 weight=9;    
 server localhost:8081 weight=1;}

次に、10回、通常は1回だけ8081にアクセスし、9回は8080にアクセスします。

ip_hash

上記の2つの方法には問題があります。つまり、次のリクエストが来たときにリクエストが別のサーバーに配信される可能性があります。プログラムがステートレスでない場合（セッションを使用してデータを保存する）、現時点では大きな問題があります。これは非常に問題があります。たとえば、セッションにログイン情報を保存する場合、別のサーバーにジャンプするときに再度ログインする必要があります。1つのサーバーにのみアクセスするクライアントが必要になることが多いため、iphash、iphashを使用する必要があります。各リクエストは、アクセスIPのハッシュ結果に従って割り当てられるため、各訪問者はバックエンドサーバーへの固定アクセスを持ち、セッションの問題を解決できます。

upstream test {    
 ip_hash;    
 server localhost:8080;    
 server localhost:8081;}

fair

これは、バックエンドサーバーの応答時間に従って要求を割り当てるサードパーティのモジュールであり、短い応答時間が優先されます。

upstream backend {
 fair;    
 server localhost:8080;    
 server localhost:8081;}

url_hash

これは、アクセスURLのハッシュ結果に従って要求を分散するサードパーティのモジュールであるため、各URLは同じバックエンドサーバーに送信されます。これは、バックエンドサーバーがキャッシュである場合により効果的です。アップストリームにハッシュステートメントを追加すると、重みなどの他のパラメーターをサーバーステートメントに書き込むことができなくなります。hash_methodは使用されるハッシュアルゴリズムです。

upstream backend {    
 hash $request_uri;    
 hash_method crc32;    
 server localhost:8080;    
 server localhost:8081;}

上記の5種類の負荷分散はさまざまな状況に適用できるため、実際の状況に応じて使用する戦略モードを選択できますが、fairおよびurl_hashは、使用するサードパーティモジュールをインストールする必要があります。

サーバーコマンドのオプションパラメータ：

weight：サーバーのアクセスの重みを設定します。値が大きいほど、より多くの要求が受信されます。
fail_timeout：サーバーは、この指定された時間内に応答を提供する必要があります。この時間内に応答が受信されない場合、サーバーはダウンとしてマークされます。
max_fails：fail_timeout時間内にサーバーに接続する最大試行回数を設定します。この回数を超えると、サーバーはダウンとしてマークされます。
ダウン：サーバーがリクエストを受け付けなくなったことをマークします。
バックアップ：他のサーバーがダウンすると、このマークが付いたマシンがリクエストを受信します。

キープアライブ命令：

Nginxサーバーは、各ワーカーのアップストリームサーバーとの接続を維持します。

ブロックIP

次の構成をnginx構成ファイル nginx.confに追加します。このファイルはhttp、server、location、limit_exceptステートメントブロックに配置できます。相対パスに注意してください。この例では、 nginx.confと blocksip.confは同じです。ディレクトリ。

include blockip.conf;

次のようなコンテンツをblockip.confに入力します。

deny 165.91.122.67;
deny IP;   #単一のIPアクセスをブロックする
allow IP;  #シングルIPアクセスを許可する
deny all;  #すべてのIPアクセスをブロックする
allow all; #すべてのIPアクセスを許可する
deny 123.0.0.0/8   #セグメント全体を123からブロックします.0.0.1から123.255.255.254訪問したコマンド
deny 124.45.0.0/16 #123からIPセグメントをブロックする.45.0.1から123.45.255.254訪問したコマンド
deny 123.45.6.0/24 #123からIPセグメントをブロックする.45.6.1から123.45.6.254訪問したコマンド
# いくつかのIPを除いて、そのようなアプリケーションを実装したい場合、他のすべては拒否されます
allow 1.1.1.1; 
allow 1.1.1.2;deny all;

サードパーティモジュールのインストール方法##

. /configure --prefix=/インストールディレクトリ--add-module=/サードパーティのモジュールカタログ

リダイレクト＃＃

永続的な永続的なリダイレクト。リクエストログのステータスコードは301です
redirect一時的なリダイレクト。リクエストログのステータスコードは302です

サイト全体をリダイレクトする###

server {    
 server_name old-site.com
 return301 $scheme://new-site.com$request_uri;}

単一ページをリダイレクトする###

server {    
 location =/oldpage.html {return301 http://example.org/newpage.html;}}

サブパス全体をリダイレクトする###

location /old-site {    
 rewrite ^/old-site/(.*) http://example.org/new-site/$1 permanent;}

パフォーマンス##

コンテンツキャッシュ###

ブラウザが静的コンテンツを本質的に永続的にキャッシュできるようにします。 Nginxは、有効期限とCache-Controlヘッダー情報を設定します。

location /static{    
 root /data;    
 expires max;}

ブラウザが応答をキャッシュしないようにする必要がある場合（たとえば、要求を追跡する場合）、-1を使用します。

location =/empty.gif {    
 empty_gif;    
 expires -1;}

Gzip圧縮###

gzip  on;
gzip_buffers 16 8k;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types
 text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml
 text/javascript application/javascript application/x-javascript
 text/x-json application/json application/x-web-app-manifest+json
 text/css text/plain text/x-component
 font/opentype application/x-font-ttf application/vnd.ms-fontobject
 image/x-icon;
gzip_disable  "msie6";

ファイルキャッシュを開く###

open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

SSLキャッシュ###

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

アップストリームキープアライブ###

upstream backend {    
 server 127.0.0.1:8080;    
 keepalive 32;}
server {...    
 location /api/{        
  proxy_pass http://backend;        
  proxy_http_version 1.1;        
  proxy_set_header Connection "";}}

モニター＃＃＃

ngxtopを使用して、nginxアクセスログをリアルタイムで解析し、システムコマンドtopと同様に、処理結果を端末に出力します。すべての例で、nginx構成ファイルのアクセスログの場所と形式を読み取ります。アクセスログファイルやログ形式を指定する場合は、-fおよび-aオプションを使用します。

注： / usr / local / nginx / conf / nginx.confログファイルは、nginx構成の絶対パスである必要があります。

# ngxtopをインストールします
pip install ngxtop
# リアルタイムステータスngxtop
# ステータス404の最初の10件のリクエストのパス：

ngxtop top request_path --filter 'status == 404'
# 合計バイト数が最も多い上位10件のリクエストを送信します
ngxtop --order-by 'avg(bytes_sent) * count'
# たとえば、あなたを最も攻撃した上位10のIP
ngxtop --group-by remote_addr
# 4xxまたは5xxステータス、およびステータスとhttpリファラーを使用してリクエストを印刷します
ngxtop -i 'status >= 400' print request status http_referer
# 200の要求パス応答によって送信された平均本文バイト'foo'開始：
ngxtop avg bytes_sent --filter 'status == 200 and request_path.startswith("foo")'
# 「共通」ログ形式を使用して、リモートマシンからのapacheアクセスログを分析します
ssh remote tail -f /var/log/apache2/access.log | ngxtop -f common

一般的な使用シナリオ##

クロスドメインの問題###

作業中、一部のインターフェイスがクロスドメインをサポートしない場合があります。現時点では、add_headersを追加するだけでcorsクロスドメインをサポートできます。構成は次のとおりです。

server {  
 listen 80;  
 server_name api.xxx.com;    
 add_header 'Access-Control-Allow-Origin''*';  
 add_header 'Access-Control-Allow-Credentials''true';  
 add_header 'Access-Control-Allow-Methods''GET,POST,HEAD';  
 location /{    
  proxy_pass http://127.0.0.1:3000;    
  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;}}

上記のヘッダー情報を変更します。rewriteコマンドを使用してURIをリダイレクトし、クロスドメインの問題を解決する別の方法があります。

upstream test {  
 server 127.0.0.1:8080;  
 server localhost:8081;}
server {  
 listen 80;  
 server_name api.xxx.com;  
 location /{ 
 root  html;                   #リクエストに行く../htmlフォルダー内のファイル
 index  index.html index.htm;  #ホームページの応答アドレス
  }  
 # リクエストをインターセプトし、/api/冒頭の住所、
 # 一致が一致したら、通常の検索を停止します。
 location ^~/api/{ 
 # 着信要求をインターセプトするための書き換えを表し、渡されたパラメーターを除いて、ドメイン名の後の文字列でのみ機能します。
 # たとえばwww.a.com/proxy/api/msg?meth=1&par=2書き換えのみ/proxy/api/メッセージの書き換え。
 # 書き換え後のパラメータは単純なレギュラーです^/api/(.*)$，
 # $1は通常の最初のものを表します()，$2は2番目を表します()の値など。
 rewrite ^/api/(.*)$ /$1break;    
 # 他のホストへのプロキシリクエスト
 # http://www.b.com/書き込みとhttp://www.b.com書き込みの違いは次のとおりです
 # リクエストアドレスが彼のhttpの場合://server/html/test.jsp
 # 構成1：http://www.b.com/に続く &quot;/” 
 #   httpへの逆プロキシ://www.b.com/html/test.jspアクセス
 # 構成1：http://www.b.「ありません」/” 
 #   httpへの逆プロキシ://www.b.com/test.jspアクセス
 proxy_pass http://test;    #プロキシの場合_パスURLはhttpです://a.xx.com/platform/この状況
 # proxy_cookie_パスはに設定する必要があります/platform//(2つのスラッシュの間のスペースに注意してください)。
 proxy_cookie_path /platfrom/ /;    # http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header
 # を介してCookieヘッダーを設定します
 proxy_pass_header Set-Cookie;}}

www ###でドメインにジャンプします

server {    
 listen 80;    
 # wwwで通常のドメイン名を構成します
 server_name www.wangchujiang.com;    
 root /home/www/wabg/download;    
 location /{        
 try_files $uri $uri//index.html =404;}}
server {    
 # これは下に配置する必要があります、
 # wwwなしの王中江.comは恒久的にhttpsにリダイレクトされます://www.wangchujiang.com
 server_name wangchujiang.com;    
 rewrite ^(.*) https://www.wangchujiang.com$1 permanent;}

プロキシ転送###

upstream server-api{    
 # apiプロキシサービスアドレス
 server 127.0.0.1:3110;}
upstream server-resource{    
 # 静的リソースプロキシサービスアドレス
 server 127.0.0.1:3120;}
server {    
 listen       3111;    
 server_name  localhost;      #ここでドメイン名を指定します
 root /home/www/server-statics;    #APIサービスへのAPIルートの逆プロキシマッチング
 location ^~/api/{        
 rewrite ^/(.*)$ /$1break;        
 proxy_pass http://server-api;}   
 # 検証コードがAPIサービスにもあると仮定します
 location ^~/captcha {        
 rewrite ^/(.*)$ /$1break;        
 proxy_pass http://server-api;}    
 # 画像リソースがすべて別のサービス上にあるとします
 location ^~/img/{        
  rewrite ^/(.*)$ /$1break;        
  proxy_pass http://server-resource;}    
 # ルーティングはフロントエンドにあり、バックエンドには実際のルーティングはなく、ルーティングが存在しない404ステータスのページが返されます。/index.html
 # この方法ではシナリオを使用します。ReactまたはVueプロジェクトを作成する場合、実際のルーティングはありません。
 location /{        
  try_files $uri $uri//index.html =404;
  #        ^ スペースは重要です
    }}

プロキシ転送接続の置き換え###

location ^~/api/upload {    
 rewrite ^/(.*)$ /wfs/v1/upload break;
 proxy_pass http://wfs-api;}

ssl構成###

Hypertext Transfer Protocol Secure（略称：HTTPS、英語：Hypertext Transfer Protocol Secure）は、Hypertext TransferProtocolとSSL / TLSを組み合わせて、暗号化された通信とネットワークサーバーIDの認証を提供します。 HTTPS接続は、World Wide Webでのトランザクションの支払いや、企業情報システムでの機密情報の送信によく使用されます。 HTTPSは、RFC2660で定義されているSecureHypertext Transfer Protocol（S-HTTP）と混同しないでください。 HTTPSは現在、プライバシーとセキュリティに重点を置いたすべてのWebサイトの最初の選択肢です。テクノロジーの継続的な開発により、HTTPS Webサイトは大規模なWebサイトの特許ではなくなりました。通常の個人のWebマスターやブログはすべて、安全な暗号化されたWebサイトを自分で構築できます。ウェブサイト。

SSL証明書を作成します。証明書を購入すると、直接ダウンロードできます。

sudo mkdir /etc/nginx/ssl
# 有効期間が100年、暗号化強度がRSA2048のSSLキーキーとX509証明書ファイルを作成します。

sudo openssl req -x509 -nodes -days 36500-newkey rsa:2048-keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt
# 上記のコマンドの場合、国名を入力する次のコンテンツがあります(2 letter code)[AU]:US
State or Province Name(full name)[Some-State]:New York
Locality Name(eg, city)[]:New York City
Organization Name(eg, company)[Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name(eg, section)[]:Ministry of Water Slides
Common Name(e.g. server FQDN or YOUR name)[]:your_domain.com
Email Address []:admin@your_domain.com

自己署名証明書を作成する

まず、証明書と秘密鍵のディレクトリを作成します
# mkdir -p /etc/nginx/cert# cd /etc/nginx/cert

サーバーの秘密鍵を作成すると、コマンドでパスワードの入力を求められます。
# openssl genrsa -des3 -out nginx.key 2048

署名要求（CSR）の証明書を作成します。
# openssl req -new-key nginx.key -out nginx.csr

SSLをサポートするNginxをロードし、上記の秘密鍵を使用する場合は、必要なパスワードを削除してください。
# cp nginx.key nginx.key.org

# openssl rsa -in nginx.key.org -out nginx.key

最後に、上記の秘密鍵とCSRを使用して証明書にマークを付けます。
# openssl x509 -req -days 365-in nginx.csr -signkey nginx.key -out nginx.crt

現在のnginxコンパイルオプションを表示する

sbin/nginx -V

以下の内容を出力します

nginx version: nginx/1.7.8
built by gcc 4.4.720120313(Red Hat 4.4.7-4)(GCC)
TLS SNI support enabled
configure arguments:--prefix=/usr/local/nginx-1.7.8--with-http_ssl_module --with-http_spdy_module --with-http_stub_status_module --with-pcre

依存モジュールが存在しない場合は、インストールディレクトリに入り、次のコマンドを入力して再コンパイルしてインストールできます。

. /configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module

実行後、 makeが必要です（make installではありません）

# nginxバイナリファイルのバックアップ
cp -rf /usr/local/nginx/sbin/nginx　 /usr/local/nginx/sbin/nginx.bak
# nginxバイナリファイルを上書きする
cp -rf objs/nginx   /usr/local/nginx/sbin/

HTTPS server

server {    
 listen       443 ssl;    
 server_name  localhost;    
 ssl_certificate /etc/nginx/ssl/nginx.crt;    
 ssl_certificate_key /etc/nginx/ssl/nginx.key;    
 # ハッカーがバージョンの脆弱性を悪用するのを防ぐために、ヘッダーでサーバーのバージョンを禁止します
 server_tokens off;   
 # sslを設定する/tlsセッションキャッシュのタイプとサイズ。このパラメータが設定されている場合、通常は共有され、ビルトインはメモリの断片化をパラメータ化できます。デフォルトはnoneで、これはoffと同様であり、キャッシュは無効になっています。共有など:SSL:10mは、すべてのnginxワーカープロセスがsslセッションキャッシュを共有することを意味します。公式Webサイトによると、1Mは約4000セッションを保存できます。
 ssl_session_cache    shared:SSL:1m; 

 # クライアントは、セッションキャッシュ内のsslパラメータの有効期限を再利用できます。イントラネットシステムのデフォルトの5分は短すぎるため、30m、つまり30分または4時間に設定できます。
 ssl_session_timeout  5m; 

 # 暗号化スイートを選択してください。異なるブラウザでサポートされているスイート（および順序）は異なる場合があります。
 # ここで指定された文言はOpenSSLライブラリによって認識され、opensslを使用できます-v cipher 'RC4:HIGH:!aNULL:!MD5'（以下は、指定したパッケージ暗号化アルゴリズムです）サポートされているアルゴリズムを見てみましょう。
 ssl_ciphers  HIGH:!aNULL:!MD5;    
 # ネゴシエートされた暗号化アルゴリズムを設定するときは、クライアントブラウザの暗号化スイートではなく、サーバーの暗号化スイートの使用を優先してください。
 ssl_prefer_server_ciphers  on;    
 location /{        
 root   html;        
 index  index.html index.htm;}}

httpをhttps ###に強制的にリダイレクトします

server {    
 listen       80;    
 server_name  example.com;    
 rewrite ^ https://$http_host$request_uri? permanent;    
 # httpをhttpsに強制的にリダイレクトします
 # エラーページおよび「サーバー」応答ヘッダーフィールドでのnginxバージョンの発行を有効または無効にします。ハッカーがバージョンの脆弱性を悪用するのを防ぎます
 server_tokens off;}

2つの仮想ホスト###

純粋なstatic-htmlサポート

http {    
 server {        
  listen          80;        
  server_name     www.domain1.com;        
  access_log      logs/domain1.access.log main;
  location /{            
  index index.html;            
  root  /var/www/domain1.com/htdocs;}}    
 server {        
  listen          80;        
  server_name     www.domain2.com;        
  access_log      logs/domain2.access.log main;
  location /{            
  index index.html;            
  root  /var/www/domain2.com/htdocs;}}}

仮想ホストの標準構成###

http {  
 server {    
 listen          80default;
 server_name     _ *;
 access_log      logs/default.access.log main;
 location /{       
  index index.html;
  root  /var/www/default/htdocs;}}}

盗難防止チェーン###

location ~* \.(gif|jpg|png|swf|flv)$ {
 root html
 valid_referers none blocked *.nginxcn.com;if($invalid_referer){
  rewrite ^/ www.nginx.cn       
  # return404;}}

仮想ディレクトリ構成###

エイリアスで指定されたディレクトリは正確であり、rootは指定されたディレクトリの親ディレクトリであり、親ディレクトリには、場所で指定された同じ名前のディレクトリが含まれている必要があります。

location /img/{    
 alias /var/www/image/;}
# アクセス/img/Ningxは自動的にディレクトリ内のファイルに移動します/var/www/image/ファイルを見つけるためのディレクトリ

location /img/{    
 root /var/www/image;}
# アクセス/img/ディレクトリの下のファイル、nginxは行きます/var/www/image/img/ディレクトリでファイルを見つけます。]

盗難防止図の構成###

location ~ \/public\/(css|js|img)\/.*\.(js|css|gif|jpg|jpeg|png|bmp|swf){
 valid_referers none blocked *.jslite.io;if($invalid_referer){        
  rewrite ^/  http://wangchujiang.com/piratesp.png;}}

.gitおよびその他のファイルをブロックする###

location ~(.git|.gitattributes|.gitignore|.svn){
 deny all;}

ドメイン名パスには、###を必要とせずに、通常どおりアクセスできます。

http://wangchujiang.com/api/index.php?a=1&name=wcj
         ^ 接尾辞付き

http://wangchujiang.com/api/index?a=1&name=wcj
         ^ 接尾辞なし

nginxの書き換えのルールは次のとおりです。

rewrite ^/(.*)/$ /index.php?/$1 permanent;if(!-d $request_filename){set $rule_1 1$rule_1;}if(!-f $request_filename){set $rule_1 2$rule_1;}if($rule_1 ="21"){ 
 rewrite ^//index.php last;}

エラー問題##

The plain HTTP request was sent to HTTPS port

解決策、 fastcgi_param HTTPS $ https if_not_emptyは、このルールを追加します。

server {    
 listen 443 ssl; #このルールに注意してください
 server_name  my.domain.com;    
 fastcgi_param HTTPS $https if_not_empty; 
 fastcgi_param HTTPS on;    
 ssl_certificate /etc/ssl/certs/your.pem;
 ssl_certificate_key /etc/ssl/private/your.key;
 location /{
  # Your config here...}}