nginx配置笔记

1. 前言

1.1. 配置文件位置

对于许多发行版，该文件将位于/etc/nginx/nginx.conf。如果它不存在，也可能在 /usr/local/nginx/conf/nginx.conf或 /usr/local/etc/nginx/nginx.conf

1.2. 上下文

……它似乎是以树状结构组织的，由几组括号（看起来像{和}）定义的。用Nginx的术语来说，这些括号定义的区域被称为 “上下文（Context）”

2. The Core Contexts

2.1. The Main Context

The most general context is the “main” or “global” context. It is the only context that is not contained within the typical context blocks that look like this

1
2
3
4
5
6
7
8
9
# The main context is here, outside any other contexts

. . .

context {

    . . .

}

Some common details that are configured in the main context are the user and group to run the worker processes as, the number of workers, and the file to save the main process’s PID

2.2. The Events Context

It is used to set global options that affect how Nginx handles connections at a general level.

There can only be a single events context defined within the Nginx configuration.

1
2
3
4
5
6
7
8
# main context

events {

    # events context
    . . .

}

Nginx uses an event-based connection processing model, so the directives defined within this context determine how worker processes should handle connections.

Nginx使用了一个基于事件的连接处理模型，所以在这个上下文中定义的指令决定了worker进程应该如何处理连接。

2.3. The HTTP Context

When configuring Nginx as a web server or reverse proxy, the “http” context will hold the majority of the configuration. This context will contain all of the directives and other contexts necessary to define how the program will handle HTTP or HTTPS connections.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# main context

events {
    # events context

    . . .

}

http {
    # http context

    . . .

}
  • encounter control the default locations for access and error logs (access_log and error_log)
  • configure asynchronous I/O for file operations (aio, sendfile, and directio)
  • configure the server’s statuses when errors occur (error_page)
  • configure compression (gzip and gzip_disable)
  • fine-tune the TCP keep alive settings (keepalive_disable, keepalive_requests, and keepalive_timeout),
  • configure the rules that Nginx will follow to try to optimize packets and system calls (sendfile, tcp_nodelay, and tcp_nopush).
  • configure an application-level document root and index files (root and index)
  • set up the various hash tables that are used to store different types of data (*_hash_bucket_size and *_hash_max_size for server_names, types, and variables).

2.4. The Server Context

  • within the “http” context
    • nested, bracketed contexts
  • allows for multiple declarations
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# main context

http {

    # http context

    server {

        # first server context

    }

    server {

        # second server context

    }

}

每个实例都定义了一个特定的虚拟服务器来处理客户端请求

The directives which decide if a server block will be used to answer a request are:

  • listen: The ip address / port combination that this server block is designed to respond to. If a request is made by a client that matches these values, this block will potentially be selected to handle the connection.
  • server_name: This directive is the other component used to select a server block for processing. If there are multiple server blocks with listen directives of the same specificity that can handle the request, Nginx will parse the “Host” header of the request and match it against this directive.

2.5. The Location Context

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
location match_modifier location_match {

    . . .

}



# main context

server {

    # server context

    location /match/criteria {

        # first location context

    }

    location /other/criteria {

        # second location context

        location nested_match {

            # first nested location

        }

        location other_nested {

            # second nested location

        }

    }

}
  • Location blocks live within server contexts
  • can be nested inside one another

While server contexts are selected based on the requested IP address/port combination and the host name in the “Host” header, location blocks further divide up the request handling within a server block by looking at the request URI. The request URI is the portion of the request that comes after the domain name or IP address/port combination.

服务器上下文是根据请求的IP地址/端口组合和 “Host “头中的主机名来选择的，而位置块则通过查看请求URI来进一步划分服务器块内的请求处理。请求URI是指请求中域名或IP地址/端口组合之后的部分

3. Other Contexts

3.1. The Upstream Context

The upstream context is used to define and configure “upstream” servers.

基本上，这个上下文定义了一个命名的服务器池，Nginx可以代理请求。当你配置各种类型的代理时，可能会用到这个上下文。

Upstream Context可以在Server或Location block中通过名称引用，将特定类型的请求传递给已定义的服务器池。然后，Upstream将使用算法（默认为round-robin）来决定将请求交给哪个特定的服务器。这个上下文让我们的Nginx在代理请求时，可以做一些负载均衡。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# main context

http {

    # http context

    upstream upstream_name {

        # upstream context

        server proxy_server1;
        server proxy_server2;

        . . .

    }

    server {

        # server context

    }

}

3.2. The If Context

“if “上下文可以建立对其中定义的指令进行条件处理。就像传统编程中的if语句一样，Nginx中的if指令将在给定的测试返回 “true “时执行包含的指令。

Nginx中的if上下文是由rewrite模块提供的，这是该上下文的主要用途。由于Nginx会用许多其他目的指令来测试请求的条件，所以if不应该用于大多数形式的条件执行。这是一个非常重要的注意点，以至于Nginx社区创建了一个名为if is evil的页面。

这个问题基本上是Nginx的处理顺序经常会导致意外的结果，似乎颠覆了if块的意义。在这些上下文里面，唯一被认为是可靠安全的指令是返回和重写指令（这个上下文就是为这个上下文创建的）。在使用if上下文时，需要注意的另一件事是，它会使同一上下文中的try_files指令失去作用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# main context

http {

    # http context

    server {

        # server context

        location location_match {

            # location context

            if (test_condition) {

                # if context

            }

        }

    }

}

3.3. The Limit_except Context

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
. . .

# server or location context

location /restricted-write {

    # location context

    limit_except GET HEAD {

        # limit_except context

        allow 192.168.1.1/24;
        deny all;
    }
}

The limit_except context is used to restrict the use of certain HTTP methods within a location context.

例如，如果只有某些客户端应该能够访问POST内容，但每个人都应该能够读取内容，你可以使用limit_except块来定义这个要求。

4. inheritance model

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
http {
    server {
        location / {
            root /var/www/html;

            . . .

        }

        location /another {
            root /var/www/html;

            . . .

        }

    }
}

http {
    root /var/www/html;
    server {
        location / {

            . . .

        }

        location /another {

            . . .

        }
    }
}

5. rewrite

指令语法：rewrite regex replacement[flag];

默认值：none

应用位置：server、location、if

rewrite是实现URL重定向的重要指令，他根据regex(正则表达式)来匹配内容跳转到replacement，结尾是flag标记

标记符号说明
last本条规则匹配完成后继续向下匹配新的location URI规则
break本条规则匹配完成后终止，不在匹配任何规则
redirect返回302临时重定向
permanent返回301永久重定向

6. 补充

6.1. worker vs master

1
2
3
4
[root@server1 ~]# ps -ef |grep nginx |grep -v grep
root      2120     1  0 10:03 ?        00:00:00 nginx: master process nginx
nobody    2173  2120  0 10:30 ?        00:00:00 nginx: worker process
[root@server1 ~]#

当你启动nginx以后，使用ps命令查看nginx进程， 会发现nginx进程不只有一个，默认情况下， 你会看到至少两个nginx进程

一个master进程，一个worker进程，这两个nginx进程都有各自的作用，见名知意, “worker”进程天生就是来”干活”的，真正负责处理请求的进程就是你看到的”worker”进程，那么”master”进程有什么用呢? “master”进程其实是负责管理”worker”进程的，除了管理” worker”进程，master”进程还负责读取配置文件、判断配置文件语法的工作，“master进程”也叫”主进程”，在nginx中，”master”进程只能有一个,而”worker”进程可以有多个

默认的nginx.conf配置文件中有这样一条配置

1
worker_ processes 1;

上述配置的意思就是启动nginx后只有1个worker进程，你想要多少个worker进程，将worker_ processe指令的值设置成多少就好了,非常简单, worker_ processes指令只能在main区域中使用,通常情况下,
worker_ processes的值通常不会大于服务器中cpu的核心数量

当worker_ processes的值为auto时，nginx会自动检测当前主机的cpu核心数,并启动对应数量的worker进程，比如，nginx检测到当前主机一共有4个cpu核心，那么nginx就会启动4个worker进程

7. nginx php

8. 参考