Nginxの設定を詳しく解説（コード付き）

この記事ではNginxの設定を詳しく解説(コード付き)していますので、参考になると思いますので、困っている方は参考にしていただければ幸いです。

一般的に使用される構成項目

職場では、主に構成ファイルを通じて Nginx を扱います。次に、これらの構成要素のそれぞれの機能を理解する必要があります。

まず、nginx.conf の内容は通常次のようになります:

...              
...            #核心摸块

events {        #事件模块
 
   ...
}

http {     # http 模块

    server {      # server块
     
        location [PATTERN] {  # location块
        
            ...
        }
        location [PATTERN] {
        
            ...
        }
    }
    server {
      ...
    }
    
}

mail {     # mail 模块
     
     server {    # server块
          ...
    }

}

各モジュールに一般的にどのような構成項目があるかを見てみましょう:

コア モジュール

user admin; #配置用户或者组。

worker_processes 4; #允许生成的进程数，默认为1 

pid /nginx/pid/nginx.pid; #指定 nginx 进程运行文件存放地址 

error_log log/error.log debug; #错误日志路径，级别。

イベント モジュール

events { 
    accept_mutex on; #设置网路连接序列化，防止惊群现象发生，默认为on 
    
    multi_accept on; #设置一个进程是否同时接受多个网络连接，默认为off 
    
    use epoll; #事件驱动模型select|poll|kqueue|epoll|resig
    
    worker_connections 1024; #最大连接数，默认为512
}

http モジュール

http {
    include       mime.types;   #文件扩展名与文件类型映射表
    
    default_type  application/octet-stream; #默认文件类型，默认为text/plain
    
    access_log off; #取消服务日志    

    sendfile on;   #允许 sendfile 方式传输文件，默认为off，可以在http块，server块，location块。
    
    sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。
    
    keepalive_timeout 65;  #连接超时时间，默认为75s，可以在http，server，location块。

    server 
    {
            keepalive_requests 120; #单连接请求上限次数。
            
            listen 80; #监听端口
            
            server_name  127.0.0.1;   #监听地址      
            
            index index.html index.htm index.php;
            
            root your_path;  #根目录
          
            location ~ \.php$
            {
                  fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
                  
                  #fastcgi_pass 127.0.0.1:9000;
                  
                  fastcgi_index index.php;
                  
                  include fastcgi_params;
            }

    }
}

構成項目分析

• worker_processes
  worker_processes は次の目的で使用されます。 Nginx サービスをセットアップするプロセスの数。この値は、推奨される CPU コア数です。
• worker_cpu_affinity
  worker_cpu_affinity は、CPU の作業コアを各プロセスに割り当てるために使用されます。パラメータは複数のバイナリ値で表されます。各グループはプロセスを表し、各グループの各ビットはプロセスの使用を表します。の場合、1 は使用、0 は使用しないことを意味します。したがって、worker_cpu_affinity 0001 0010 0100 1000; を使用して、プロセスを異なるコアにバインドします。デフォルトでは、ワーカー プロセスはどの CPU にもバインドされません。
• worker_rlimit_nofile

  プロセスごとにオープンできるファイルの最大数を設定します。設定されていない場合、上限はシステムの ulimit –n 数値で、通常は 65535 です。

• worker_connections

  プロセスで許可される接続の最大数を設定します。理論的には、大きいほど良いですが、worker_rlimit_nofile の値を超えることはできません。

• use epoll

  epoll を使用するようにイベント駆動モデルを設定します。 epoll は、Nginx でサポートされている高性能イベント駆動型ライブラリの 1 つです。非常に優れたイベントドリブンモデルとして評価されています。

• accept_mutex off

  ネットワーク接続のシリアル化をオフにします。オンに設定すると、複数のプロセスが接続を求めて競合するのを防ぐために、複数の Nginx プロセスがシリアル化のための接続を受け入れます。サーバー接続が少ない場合、このパラメータをオンにすると負荷がある程度軽減されます。ただし、サーバーのスループットが非常に高い場合は、効率を高めるためにこのパラメータをオフにしてください。また、このパラメータをオフにすると、リクエストが複数のワーカー間でより均等に分散されるようになります。そこで、accept_mutex off;

• multi_accept on

  複数のネットワーク接続を同時に受け入れるプロセスを設定します

• Sendfile on

  Sendfile は Linux2 です。 0 以降 ネットワーク送信プロセスの手順を簡素化し、サーバーのパフォーマンスを向上させるシステム コールが開始されました。

  sendfile を使用しない従来のネットワーク送信プロセス:

  ハードディスク>> カーネル バッファ >> ユーザー バッファ >> カーネル ソケット バッファ >> プロトコル スタック

  ネットワーク送信に sendfile() を使用するプロセス:

  ハードディスク>> カーネル バッファ (カーネルソケット バッファへのクイック コピー)>>プロトコル スタック

• tcp_nopush on ;

  データ パケットを蓄積してまとめて送信するように設定すると、送信効率が向上します。 tcp_nopush は sendfile とともに使用する必要があります。

• tcp_nolay on;

  小さなデータ パケットは待機せずに直接送信されます。デフォルトはオンです。 tcp_nopush とは逆の機能のように見えますが、両方がオンの場合、nginx はこれら 2 つの機能をバランスよく使用することもできます。

• keepalive_timeout

  HTTP 接続の継続時間。設定が長すぎると、無駄なスレッドが多くなります。サーバーのアクセス数や処理速度、ネットワークの状況などを考慮して考慮されます。

• send_timeout

  Nginx サーバーがクライアントに応答するまでのタイムアウトを設定します。このタイムアウトは、2 つのクライアントとサーバーが接続を確立した後の特定のアクティビティの間の時間のみです。この時間が経過した場合は、 , クライアントにアクティビティがない場合、Nginx サーバーは接続を閉じます

• gzip on

  gzip を有効にして応答データをオンラインでリアルタイムに圧縮し、データ送信量を削減します。

• gzip_disable "msie6"

  Nginx サーバーは、これらの種類のクライアント要求に応答するときに、アプリケーション データをキャッシュするために Gzip 関数を使用しません。gzip_disable "msie6" は、IE6 からのデータに対して GZIP 圧縮を実行しません。ブラウザ。

一般的に使用される構成項目は大まかに次のとおりです。さまざまなビジネス シナリオでは、追加の構成項目が必要になる場合がありますが、ここでは説明しません。

その他

http 設定には location 項目があり、リクエスト内の URI に基づいて対応する処理ルールを照合するために使用されます。

場所検索ルール

location  = / {
  # 精确匹配 / ，主机名后面不能带任何字符串
  [ config A ]
}

location  / {
  # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
  # 但是正则和最长字符串会优先匹配
  [ config B ]
}

location /documents/ {
  # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ config C ]
}

location ~ /documents/Abc {
  # 匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ config CC ]
}

location ^~ /images/ {
  # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。
  [ config D ]
}

location ~* \.(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 结尾的请求
  # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
  [ config E ]
}

location /images/ {
  # 字符匹配到 /images/，继续往下，会发现 ^~ 存在
  [ config F ]
}

location /images/abc {
  # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
  # F与G的放置顺序是没有关系的
  [ config G ]
}

location ~ /images/abc/ {
  # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用
    [ config H ]
}

通常の検索優先順位は高から低まで次のとおりです。

「 = 」の先頭は完全一致を意味します。 、A のように、ルート ディレクトリの末尾にあるリクエストのみに一致し、その後に文字列を続けることはできません。

" ^~ " の先頭は、uri が通常の一致ではなく、通常の文字列で始まることを示します。

" ~ " の先頭は、大文字と小文字が区別される通常の一致を示します。

" ~ * "大文字と小文字を区別しない通常の一致で始まります

" / " ユニバーサル一致。他に一致するものがない場合、すべてのリクエストが

負荷分散に一致します。構成＃＃＃＃＃ ＃

Nginx 的负载均衡需要用到 upstream 模块，可通过以下配置来实现：

upstream test-upstream {
    ip_hash; # 使用 ip_hash 算法分配
 
    server 192.168.1.1; # 要分配的 ip
    server 192.168.1.2;
}

server {

    location / {       
        proxy_pass http://test-upstream;
    }
    
}

上面的例子定义了一个 test-upstream 的负载均衡配置，通过 proxy_pass 反向代理指令将请求转发给该模块进行分配处理。

以上がNginxの設定を詳しく解説（コード付き）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。