运维 --- Nginx中的概念和配置详解

Nginx中的概念

Nginx指令

Nginx 中的配置选项称为指令。该选项有名称和参数，必须以分号 (? 结尾，否则 Nginx 将无法加载配置并产生错误。

例子：

gzip on;  

普通指令

每个上下文有一个值。我们只能在上下文中定义它一次。子上下文可以覆盖父指令，但此覆盖仅在给定的子上下文中有效。

gzip on;  
gzip off; # 在同一个上下文中有两个普通指令是非法的   
  
server {  
  location /downloads {  
    gzip off;  
  }  
  
  location /assets {  
    # gzip 在这里有效  
  }  
}  

数组指令

在同一上下文中添加多条指令会增加值而不是完全覆盖它们。在子上下文中定义指令将覆盖给定子上下文中父级的所有值。

error_log /var/log/nginx/error.log;  
error_log /var/log/nginx/error_notive.log notice;  
error_log /var/log/nginx/error_debug.log debug;  
  
server {  
  location /downloads {  
    # 这将覆盖父级所有指令  
    error_log /var/log/nginx/error_downloads.log;  
  }  
} 

行动指令

动作是用于改变事物的指令。它们的继承行为将取决于模块。

**例如：**在 rewrite 指令的情况下，每个匹配的指令都会被执行。

server {  
  rewrite ^ /foobar;  
  
  location /foobar {  
    rewrite ^ /foo;  
    rewrite ^ /bar;  
  }  
}  

如果我们尝试访问**/sample**：

• 执行服务器重写，重写从 /sample 到 /foobar。
• 然后匹配位置 /foobar。
• location 里第一个重写被执行，从重写 /foobar 到 /foo。
• location 里第二个重写被执行，从重写 /foo 到 /bar。

让我们看看return指令提供的不同行为：

server {  
  location / {  
    return 200;  
    return 404;  
  }  
}

从上面的情况来看，200 状态立即返回。

root, location 和 try_files 指令

root指令

server {  
  listen 80;  
  server_name cainiaojc.com;  
  root /var/www/cainiaojc.com;  
} 

它允许nginx根据请求返回服务器内容：

cainiaojc.com/index.html     # returns /var/www/cainiaojc.com/index.html  
cainiaojc.com/foo/index.html # returns /var/www/cainiaojc.com/foo/index.html  

Location指令（介绍）

location 指令用于根据请求的 URI（统一资源标识符）设置配置。

语法是：

location [modifier] path  

例子：

location /foo {  
  # ...  
}  

当没有给出修饰符时，路径被视为前缀，之后可以跟任何东西。上面的例子将匹配：

/foo  
/fooo  
/foo123  
/foo/bar/index.html  
... 

我们还可以在给定的上下文中使用多个位置指令：

server {  
  listen 80;  
  server_name cainiaojc.com;  
  root /var/www/cainiaojc.com;  
  
  location / {  
    return 200 "root";  
  }  
  
  location /foo {  
    return 200 "foo";  
  }  
}  
cainiaojc.com/       # => "root"  
cainiaojc.com/foo    # => "foo"  
cainiaojc.com/foo123 # => "foo"  
cainiaojc.com/bar    # => "root"  

Nginx 还提供了一些可以与location指令结合使用的修饰符。

try_files 指令（避免使用）

该指令尝试不同的路径，并将返回找到的任何一个。

try_files $uri index.html =404;  

所以 /foo.html 将尝试按以下顺序返回文件：

• $uri (/foo.html);
• index.html
• If none is found:404

如果我们在服务器上下文中定义 try_files，然后定义一个查找所有请求的blocation，我们的 try_files 将不会被执行。发生这种情况是因为服务器上下文中的 try_files 定义了伪 location，这是可能的最不具体的 location。因此，定义 location / 将比伪 location 更具体。

Nginx上下文

当我们在文本编辑器中打开核心 Nginx 配置文件时，首先我们会注意到配置被组织成树状结构，并被花括号包围，即“{”和“}”。这些被大括号包围的位置称为放置配置指令的上下文。此外，配置指令及其参数以分号结尾。

这是我们可以声明指令的部分。它类似于编程语言中的作用域。

上下文可以嵌套在其他上下文中，从而创建上下文层次结构。

例子：

worker_processes 2; # 全局上下文中的指令  
http {              # http 上下文  
    gzip on;        # http 上下文中的指令  
  
  server {          # 服务器上下文  
    listen 80;      # 服务器上下文中的指令  
  }  
}

用# 填充的行是注释，Nginx 不会解释。

让我们看一个例子。

# 全局上下文  
 ...  
 ...  
 # http 上下文  
http{  
     ...  
     ...  
     # 服务器上下文  
     server {  
              listen 80;  
              server_name example.com;  
              ...  
              ...  
              # Location 上下文  
              location / {              
                          root /var/www/html;              
                          try_files $uri $uri/ =404;          
                          ...  
                          ...  
             }  
    }  
    # 服务器上下文  
    server {  
             ...  
             ...  
             # Location 上下文  
             location / {   
                         ...  
                         ...  
             }  
    }  
    ...  
    ...  
}  

从上面的例子中，我们可以看到 HTTP 上下文声明了 HTTP 协议的设置。虚拟主机设置在服务器上下文中声明，包含在 http 上下文中。用于存储 URL 设置的 location 上下文包含在服务器上下文中。

主要上下文

最一般的上下文是主上下文。它也称为全局上下文。主上下文全局设置 Nginx 的设置，并且是唯一未被花括号包围的上下文。

主上下文位于核心 Nginx 配置文件的开头。此上下文的指令不能在任何其他上下文中继承，因此不能被覆盖。

主上下文用于配置在基本级别上影响整个应用程序的详细信息。在主上下文中配置的一些常见详细信息是运行工作进程的用户和组、工作进程总数以及保存主进程 ID 的文件。可以在主上下文级别设置整个应用程序的默认错误文件。

user nginx;  
worker_processes auto;  
pid /run/nginx.pid;  
...  
... 

事件上下文

事件上下文为连接处理设置全局选项。事件上下文包含在主上下文中。Nginx 配置中只能定义一个事件上下文。

Nginx 使用基于事件的连接处理模型，因此在此上下文中定义的指令决定了工作进程应如何处理连接。

# main context  
events {  
        # events context  
        worker_connections 768;   
        multi_accept on;  
}  
...  
...  

HTTP 上下文

HTTP 上下文用于保存处理 HTTP 或 HTTPS 流量的指令。

HTTP 上下文是事件上下文的兄弟，因此它们必须并排列出，而不是嵌套。他们都是主要上下文的孩子。

较低的上下文处理请求，此级别的指令控制每个虚拟服务器的定义默认值。

ser nginx;  
worker_processes auto;  
pid /run/nginx.pid;  
...  
...  
events {  
        # events context  
        worker_connections 768;   
        multi_accept on;  
        ...  
        ...  
}  
http {  
       sendfile on;   
       tcp_nopush on;     
       tcp_nodelay on;    
       keepalive_timeout 65;  
       ...  
       ...  
}  

服务器上下文

此上下文中的指令可以覆盖许多可能在 http 上下文中定义的指令，包括文档位置、日志记录、压缩等。 除了从 http 上下文中获取的指令之外，我们还可以配置文件以尝试响应请求、发出重定向和重写，并设置任意变量。

user nginx;  
worker_processes auto;  
pid /run/nginx.pid;  
...  
...  
events {  
         # events context  
         worker_connections 768;      
         multi_accept on;  
         ...  
         ...  
 }  
http {  
       sendfile on;   
       tcp_nopush on;     
       tcp_nodelay on;    
       keepalive_timeout 65;  
       ...  
       ...  
  
       server {  
                listen 80;  
                server_name domain1.com;  
                root /var/www/html/wordpress;  
                ...  
       
       }  
       server {  
                listen 80;  
                server_name domain2.com;  
                root /var/www/html/drupal;  
                ...  
       
       }  
}  

location上下文

location上下文定义指令来处理客户端的请求。当任何对资源的请求到达 Nginx 时，它会尝试将 URI（统一资源标识符）与其中一个location匹配并相应地处理它。

可以在服务器块内定义多个location上下文。此外，一个location上下文也可以嵌套在另一个location上下文中。

http {  
       ...  
       ...  
  
       server {  
                listen 80;  
                server_name domain1.com;  
                root /var/www/html/wordpress;  
                ...  
                location /some_url {    
                # configuration for processing URIs starting with /some_url  
                }  
                location /another_url {    
                # configuration for processing URIs starting with /another_url  
                }      
       }  
       server {  
                listen 80;  
                server_name domain2.com;  
                root /var/www/html/drupal;  
                ...  
                location /some_url {    
                # configuration for processing URIs starting with /some_url    
                }  
                location /some_other_url {    
                # configuration for processing URIs starting with /some_other_url  
                }    
       
       }  
}  

upstream上下文

upstream 上下文用于配置和定义上游服务器。允许此上下文定义后端服务器池，Nginx 可以代理请求时使用的后端服务器。这个上下文通常是我们正在配置的各种类型的代理。

upstream 上下文使 Nginx 能够在代理请求的同时执行负载平衡。此上下文在 HTTP 上下文内部和任何服务器上下文外部定义。

upstream 上下文在服务器或 location 块中按名称引用。然后将某种类型的请求传递给定义好的服务器池。然后 upstream 将使用算法（默认为轮询）来确定需要使用哪个特定服务器来处理请求。

http{  
     ...  
     ...  
     upstream backend_servers {  
                                server host1.example.com;  
                                server host2.example.com;  
                                server host3.example.com;  
     }  
  
server {  
             listen 80;  
             server_name example.com;  
             location / {  
                           proxy_pass http://backend_servers;  
             }  
  }  
}  

邮件上下文

尽管 Nginx 最常用作 Web 或反向代理服务器，但它也可以用作高性能邮件代理服务器。用于此类指令的上下文称为邮件上下文。邮件上下文定义在主上下文或全局上下文内或 http 上下文外。

邮件上下文的主要目的是为在服务器上配置邮件代理解决方案提供一个区域。Nginx 可以将身份验证请求重定向到外部身份验证服务器。然后，它可以提供对 POP3、SMTP 和 IMAP 邮件服务器的访问，以提供实际邮件数据。

通常，邮件上下文如下所示：

# main context  
mail {  
       server_name mail.example.com;  
       auth_http   localhost:9000/cgi-bin/nginxauth.cgi;  
       proxy_pass_error_message on;  
       ...  
}  
http {  
  
}  
...  
...  

if 上下文

if 上下文用于允许有条件地执行其中定义的指令。if 上下文就像任何其他编程语言的“if 语句”。如果给定条件返回 true，则 if 上下文将执行包含的指令。

由于某些限制，应尽可能避免使用 if 上下文。

http {  
        server {  
                     location /some_url {  
                     if (test_condition) {  
                          # do some stuff here  
                   }  
  
         }  
    }  
}  

limit_except 上下文

limit_except 上下文用于防止在 location 上下文中使用除我们明确允许的方法之外的所有 HTTP 方法。例如，如果某些客户端应该有权访问POST 内容并且每个人都应该有能力阅读内容，那么我们可以为此使用limit_except上下文。

...  
...  
location /wp-admin/ {   
    limit_except GET {   
      allow 127.0.0.1;   
      deny all;   
    }   
}  
...  
...  

杂项上下文

除了上述上下文之外，Nginx 中可用的上下文很少，如下所述。这些上下文依赖于可选模块并且很少使用。

• split_clients： split_client 上下文将客户端的请求拆分为两个或多个类别。该上下文定义在 HTTP 上下文中，主要用于 A/B 测试。
• geo： geo 上下文对客户端 IP 地址进行分类。它用于根据连接的 IP 地址映射变量的值。
• **charset_map：**此上下文用于将特定字符集添加到“Content-Type”响应头字段。此外，使用上下文，可以将数据从一个字符集转换为另一个字符集，但有一些限制。
• map： map上下文用于创建变量，其值依赖于其他变量的值，并在http上下文中定义。
• **perl/perl_set：**用于在 Perl 中实现位置和变量处理程序，并将 Perl 调用插入 SSI。此外，在 perl_set 上下文的帮助下，我们可以为特定变量安装 Perl 处理程序。
• **类型：**类型上下文用正确的文件扩展名映射 MIME 类型。此上下文可能出现在 http 上下文、服务器上下文或位置上下文中。

Nginx最小配置

安全的服务器是只配置所需内容的服务器。

理想情况下，应基于最小配置构建服务器，不要配置多余的选项。

使用最小的配置也有助于调试。如果错误在最小配置中，可以通过增加或减少配置来排查错误。

下面是运行 nginx 所需的最低配置：

# /etc/nginx/nginx.conf  
  
events {}         # event context have to be defined to consider config valid  
  
http {  
 server {  
    listen 80;  
    server_name  cainiaojc.com;  
  
    return 200 "Hello";  
  }  
}  

Nginx目录结构

[root@localhost ~]# tree /usr/local/nginx
/usr/local/nginx
├── client_body_temp                 # POST 大文件暂存目录
├── conf                             # Nginx所有配置文件的目录
│   ├── fastcgi.conf                 # fastcgi相关参数的配置文件
│   ├── fastcgi.conf.default         # fastcgi.conf的原始备份文件
│   ├── fastcgi_params               # fastcgi的参数文件
│   ├── fastcgi_params.default       
│   ├── koi-utf
│   ├── koi-win
│   ├── mime.types                   # 媒体类型
│   ├── mime.types.default
│   ├── nginx.conf                   #这是Nginx默认的主配置文件，日常使用和修改的文件
│   ├── nginx.conf.default
│   ├── scgi_params                  # scgi相关参数文件
│   ├── scgi_params.default  
│   ├── uwsgi_params                 # uwsgi相关参数文件
│   ├── uwsgi_params.default
│   └── win-utf
├── fastcgi_temp                     # fastcgi临时数据目录
├── html                             # Nginx默认站点目录
│   ├── 50x.html                     # 错误页面优雅替代显示文件，例如出现502错误时会调用此页面
│   └── index.html                   # 默认的首页文件
├── logs                             # Nginx日志目录
│   ├── access.log                   # 访问日志文件
│   ├── error.log                    # 错误日志文件
│   └── nginx.pid                    # pid文件，Nginx进程启动后，会把所有进程的ID号写到此文件
├── proxy_temp                       # 临时目录
├── sbin                             # Nginx 可执行文件目录
│   └── nginx                        # Nginx 二进制可执行程序
├── scgi_temp                        # 临时目录
└── uwsgi_temp                       # 临时目录

Nginx主配置文件解析

Nginx 主配置文件 /etc/nginx/nginx.conf 是一个纯文本类型的文件，整个配置文件是以区块的形式组织，通常每一个区块以一对大括号{}来表示开始与结束。

• Main 位于 nginx.conf 配置文件的最高层；
• Main 层下可以有 Event、HTTP 层；
• Http 层下面允许有多个 Server 层，用于对不同的网站做不同的配置；
• Server 层下面允许有多个 Location，用于对不同的路径进行不同模块的配置。

可使用如下命令对配置文件进行查看

$ cat nginx.conf文件路径

如使用yum安装就是

$ cat /etc/nginx/nginx.conf

各层配置

Main层配置

Main层配置的参数对所有Server都生效，在这一层主要会设置一些影响 nginx 服务器整体运行的配置指令，主要包括配置运行 Nginx 服务器的用户（组）、允许生成的 worker process 数，进程 PID 存放路径、日志存放路径和类型以 及配置文件的引入等。

例如：

  user  nginx;					        #进程用户
  worker_processes  1;				        #工作进程，配合和CPU个数保持一致
  error_log  /var/log/nginx/error.log warn;	        #错误日志路径及级别
  pid        /var/run/nginx.pid;			#Nginx服务启动的pid

events层配置

events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 worker process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 worker process 可以同时支持的最大连接数等。

例如：

  events {
      worker_connections  1024;			#每个worker进程支持的最大连接数
      use epoll;				#内核模型，select、poll、epoll
  }

http层配置

http 全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。

例如：

http {
    include       /etc/nginx/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  /var/log/nginx/access.log  main;			#访问日志

    sendfile        on;		#优化静态资源
    #tcp_nopush     on;		#nginx不要缓存数据，而是一段一段发送

    keepalive_timeout  65;	#给客户端分配连接超时时间，服务器会在这个时间过后关闭连接。

    #gzip  on;			#压缩
}

server层配置

提示：通常 Server 配置在独立的/etc/nginx/conf.d/*.conf中，通过引用的方式调用，如下/etc/nginx/conf.d/default.conf：

Server 块也被叫做“虚拟主机”部分，它描述的是一组根据不同 server_name 指令逻辑分割的资源，这些虚拟服务器响应 HTTP 请求，因此都包含在 http 部分。最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或 IP 配置。一个 server 块可以配置多个 location 块，同时一个location也有匹配规则来匹配多个URL。

server {
        listen       80;			        #监听端口，默认80
        server_name  localhost;			#提供服务的域名或主机名

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {				#控制网站访问路径
            root   /usr/share/nginx/html;	        #存放网站的路径
            index  index.html index.htm;	        #默认访问的首页
        }
        #error_page  404              /404.html;	#错误页面

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;	#定义请求错误，指定错误代码
        location = /50x.html {			#错误代码重定向到新的location
            root   html;
        }
    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {					#server段配置
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
    #server {					#server段配置
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;		#SSL证书配置

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}

location（详细）

语法规则

匹配的优先级

location的匹配的优先级与配置文件中的顺序无关。

先将所有匹配前缀分为两类

大致的匹配规则为

“=”匹配 > “^~”匹配（不是用正则，最大前缀匹配） > 正则匹配 > 普通（最大前缀匹配）> 默认（/）

location处理逻辑

1. =前缀的指令严格匹配这个查询。如果找到，停止搜索。
2. 所有剩下的常规字符串，最长的匹配。如果这个匹配使用^〜前缀，搜索停止。
3. 正则表达式，在配置文件中定义的顺序。
4. 如果第3条规则产生匹配的话，结果被使用。否则，使用第2条规则的结果。

如果想要了解更多有关location可以去看：

Nginx网站配置

在默认虚拟机 default.conf 基础上新建虚拟机。

[root@nginx01 ~]# vi /etc/nginx/conf.d/mystie.conf
server {
    server_name  www.ceshi.com;
    
    error_page  404 403 500 502 503 504  /error.html;	#配置错误页
    location / {
        root   /usr/share/nginx/base;
        index  index.html;
    }
}
[root@cainiaojc ~]# mkdir -p /usr/share/nginx/base
[root@cainiaojc ~]# echo '<h1>cainiaojc</h1>' > /usr/share/nginx/base/index.html
[root@cainiaojc ~]# echo '<h1>Error</h1>' > /usr/share/nginx/error.html
[root@cainiaojc ~]# nginx -t -c /etc/nginx/nginx.conf		#检查配置文件
[root@cainiaojc ~]# nginx -s reload				#重载配置文件

查看80端口是否打开

$ firewall-cmd --query-port=80/tcp

如果是yes则可以根据ifconfig查询的ip进行访问

如果没有打开可使用如下命令将80端口打开

$ firewall-cmd --zone=public --add-port=80/tcp --permanent
$ systemctl restart firewalld.service

再次进行查看就应该是打开状态，可进行正常访问。

访问默认页面

随意访问不存在页面

Nginx相关安全策略

禁止访问 htaccess

location ~/\.ht {
     deny all;
}

禁止访问多个目录

 location ~ ^/(picture|move)/ {
      deny all;
      break;
 }

禁止访问 /data 开头的文件

 location ~ ^/data {
      deny all;
  }

禁止访问单个目录

 location /imxhy/images/ {
      deny all;
 }

允许特定 ip 访问

root /usr/share/nginx/rewrite/;
allow 208.97.167.194;
allow 222.33.1.2;
allow 231.152.49.4;
deny all; 

Niginx日志配置

相关配置

access_log：访问日志；
log_format：日志格式；
rewrite_log：重定向日志；
error_log：错误日志；

nginx 具备非常灵活的日志记录模式，每个级别的配置可以有各自独立的访问日志。日志格式通过 log_format 命令来定义。

access_log 配置

语法:

• access_log path [format [buffer=size [flush=time]]];
• access_log path format gzip[=level] [buffer=size] [flush=time];
• access_log syslog:server=address[,parameter=value] [format];
• access_log off; #不记录日志

默认值: access_log logs/access.log combined;
使用默认 combined 格式记录日志：access_log logs/access.log 或 access_log logs/access.log combined;
配置段: http, server, location, if in location, limit_except
参数解释：

• gzip：压缩等级。
• buffer：设置内存缓存区大小。
• flush：保存在缓存区中的最长时间。

log_format配置

语法:log_format name string ……;
默认值: log_format combined “……”;
配置段: http

释义：name 表示格式名称，string 表示等义的格式。log_format 有一个默认的无需设置的 combined 日志格式，相当于 apache 的 combined 日志格式。

示例1：

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

示例2：

       log_format  proxy  '$remote_addr - $remote_user [$time_local] "$request" '
                         '$status $body_bytes_sent "$http_referer" '
                         '"$http_user_agent" "$http_user_agent" ';

配置相关变量释义：

rewrite_log配置

语法: rewrite_log on | off;

默认值：rewrite_log off;

配置段：http，server，location，if

作用：由ngx_http_rewrite_module模块提供的。用来记录重写日志的，对于调试重写规则建议开启。启用时将在error log中记录notice级别的重写日志。

error_log配置

语法：error_log file | stderr | syslog:server=address[,parameter=value] [debug | info | notice | warn | error | crit | alert | emerg];

默认值：error_log logs/error.log error;

配置段：main，http，server，location

作用：配置错误日志。

日志切割脚本（以access.log为例）

目地：每天的0点0分把nginx日志重命名为日期后缀格式，并重新生成新日志文件。

脚本：

#nginx日志切割脚本
#author: http://www.nginx.cn

#!/bin/bash
#日志文件存放目录
logs_path='/usr/local/nginx/logs/'
#pid文件位置
pid_path='/usr/local/nginx/nginx.pid'

#重命名日志文件
mv ${logs_path}access.log ${logs_path}access_$(date -d 'yesterday' +'%Y%m%d').log

#向nginx主进程发信号重新打开日志
kill -USR1 `cat ${pid_path}`

设置corntab定时任务

0 0 * * * bash /usr/local/nginx/nginx_log.sh

参考文档：

Nginx要好好学啊！加油，尽然都看到这了，不如点个赞如何