nginx常用配置(nginx配置多个server)

原地址：如何配置NGINX

Nginx是一款轻量级、高性能的web服务器，专为高并发性而设计。

Nginx的一个显著特点是可以高效处理HTML等媒体文件。Nginx采用异步事件驱动模型，在高负载下提供可预测的性能。

动态内容通过Nginx传输到CGI、FastCGI或Apache等其他web服务器，然后返回到Nginx分发给客户端。本文将让您熟悉基本的Nginx参数配置和规定。

00-1010所有的Nginx配置文件都位于/etc/nginx目录下，最基本最重要的配置文件是/etc /etc/nginx/nginx.conf

Nginx的配置项也叫指令。集合是人们常说的块或上下文，两者是相同的。

以字符#开头的行是注释行，不会被Nginx解析。命令行必须是分号；结束，否则Nginx无法正确加载配置文件并抛出错误。

以下内容摘自nginx安装时附带的配置文件/etc/nginx/nginx.conf。文件开头有四个指令：用户、worker _ processes、error _ log、PID。它们不包含在任何指令块中，所以我们称它们存在于主指令块中。事件和http指令块是附加的指令配置块，也存在于主指令块中。

您可以参考官方nginx配置文件，了解这些指令和主指令块中其他配置参数的含义。

指令(Directives)块(Blocks)上下文(Contexts) http配置块包含处理web通信的指令，这些指令通常称为通用指令，因为这些指令作用于所有nginx代理的站点服务。对于http配置块中的所有说明，您可以参考官方nginx配置文件。

00-1010上面的http配置块包含一个include指令，用来告诉nginx站点的配置文件的位置。

如果您使用官方nginx软件包安装，它将包括/etc/NGINX/conf.d/*。如上所述。nginx所代表的每个站点都应该在/etc/nginx/conf.d目录中有自己的配置文件，并使用example.com.conf形式的统一命名约定非nginx所代表的站点的配置文件应该命名为example.com.conf.disabled如果从Debian或Ubuntu源码安装nginx，这个指令会像/etc/nginx/sites-enabled/*；站点启用文件夹包含指向站点配置文件的链接，这些文件存储在/etc/nginx/sites-available/文件中。您可以通过删除链接来禁用站点代理。根据您的安装来源，您可以在/etc/nginx/conf.d/default.conf或etc/nginx/sites-enabled/default的路径中找到默认Nginx配置示例。无论什么安装源，每个站点的配置文件都会包含一个服务器配置块，比如3360。

http配置块侦听指令告诉nginx它应该侦听的http链接的主机名///IP//端口号。default_server参数意味着端口80上不满足其他特定侦听语句的请求也将由该虚拟主机处理。第二条监听指令基于IPv6，其行为与之前的IPv4一致。

00-1010 server _ name指令，允许一个IP地址代理多个域名。nginx代理服务器将根据收到的请求头决定将请求转发到哪个域名。

您应该为代理的每个域名创建一个单独的配置文件。下面是一些相应的例子：

1.处理来自example.com和www.example.com的请求

s="pgc-img-caption">

2.server_name指令的值也可以是通配符*， *.example.com和.example.com这两个指令都是指示nginx处理来自二级域名example.com下的所有请求

3.处理所有以example开头的域名下的请求

Nginx还允许server_name的值是自定义的、无效的域名，它只管根据HTTP请求头中的域名来响应请求，不会去关注该域名是否是有效的。

这种特性在局域网中是非常有用的，或者是你已经知道所有的可能发起请求的客户端。比如，前端常用的，在hosts文件中配置的ip-域名对，nginx都可以监听、处理。

Location路由配置块

Location配置的是，Nginx如何响应请求的资源。该指令把请求抽象为特定的文件或文件夹，就像server_name指令指示Nginx如何处理代理域名下的请求一样， 比如http://example.com/blog/， 下面是一些例子:

上述是路由字符串匹配，匹配的目标是，http请求中域名之后的所有路径：

请求: Http://example.com/

响应: 假设已经配置了主机 server_name example.com, location /该指令将决定该请求的响应是什么。

Nginx总是会用最精确的路由匹配来处理请求:

请求: 例如有这两个请求http://example.com/planet/blog/ &http://example.com/planet/blog/about/

响应: 在上面的路由匹配中，最终会使用location /planet/blog/ { }路由下的配置处理，即使location /planet/ { }该路由也是匹配的，但是因为前者是更精确的，所以会使用前者而不是后者。

当location指令后面紧跟着一个波浪号～， 表示该路由匹配是正则匹配，并且是区分大小写的。 因此IndexPage.php是能够符合上述的第一个例子的，但是indexpage.php是不行的。在第二个例子中，正则表达式^/BlogPlanet(/|index\.php)$会匹配，诸如/BlogPlanet/和/BlogPlanet/index.php这样的请求，但是不会匹配到/BlogPlanet, /blogplanet/或者 /blogplanet/index.php这样的请求，因为大小写不符合。

Nginx的正则匹配规则是遵循PCRE（Perl Compatible Regular Expression）的。

如果你想使匹配规则对大小写不敏感，那么在~后面添加一个*. 上述的例子是指定nginx如何处理以文件扩展名结尾的请求。 在第一个例子中，所有以.pl, .PL, .cgi, .CGI, .perl, .Perl, .prl, 和.PrL结尾的文件请求，都是满足匹配规则的.

location指令后面跟着 ^~组合，意味着，如果匹配到特定的字符串，就直接停止寻找更精确的路由匹配项，直接使用当前的路由配置。除此之外，与字符串匹配规则一样。如果一个请求符合该指令，那么不论后面是否有更精确的匹配项，直接使用此处的配置规则。关于匹配的顺序以及优先级，后文会有更详细的介绍。

最后，如果你在location后面添加了一个等号=, 意味着这是一个精准的匹配，请求路径必须严格等于路由项，才会停止匹配查询。举个栗子：最后的例子会匹配到http://example.com/, 而不会匹配http://example.com/index.html, 使用精准匹配可以轻微的提升响应速度，在某个请求需要频繁的被调用的场景下是非常有用的。

该指令的处理顺序如下：

精准匹配路由是最先被处理的，如果发现符合条件的，Nginx会停止匹配搜索，直接处理请求字符串匹配是第二优先处理的，如果遇到^~匹配项，nginx会停止匹配，直接处理。否则，会持续匹配搜索直到找到最合适的匹配项正则匹配项（~和~*）是第三优先处理的，如果遇到符合条件的，停止搜索，处理请求如果前三步都没有匹配到，那么将会使用最通配的字符串匹配

确保代理域名下的每个文件、文件夹至少能够匹配一个location指令

注意：

不建议也不支持嵌套的location配置块

路由的根路径和入口文件

location也是一个块指令，里面可以配置相关的指令

一旦Nginx匹配到了一个请求的最佳匹配路由，该请求的响应就会被相关location内的指令处理。例如：

本例中，文件的根路径会被定位在html/目录下，在默认的nginx配置文件中，例子中的完整文件路径是/etc/nginx/html/

请求: http://example.com/blog/includes/style.css

响应: nginx会尝试在/etc/nginx/html/blog/includes/style.css路径下寻找目标文件

注意：

如果需要的话，root的值也可以使用绝对路径

index指令是告诉nginx，如果没有在目标路径找到目标文件，那么使用index指令的值代表的文件作为返回值。 例如：

请求: http://example.com

响应: nginx没有找到合适的匹配项，就会返回/etc/nginx/html/index.html文件

如果index指令的值有多个，nginx会按顺序寻找文件，直到发现第一个存在的，以此作为响应。如果在相关的文件夹下index.html不存在，会寻找index.htm, 如果依然不存在，就会返回404.

下面是一个稍微复杂的例子，展示了一个代理example.com域名的服务上的一系列location配置

在这个例子中，所有获取以.pl为扩展名的资源的请求，都会被第二个location块处理, 在该指令块里定义了一个fastcgi回调来处理所有的请求。其他的请求则是由第一个指令块处理。 资源的请求被分发在文件系统中的/srv/www/example.com/public_html/路径下，如果请求的目标文件不存在，nginx会寻找index.html或index.htm代替，如果这两个文件也不存在，就会返回404.

我们来分析一下下面的几个例子:

请求: http://example.com

响应: 该请求会被第一个location匹配

/srv/www/example.com/public_html/index.html 路径下的文件，有的话直接返回，没有走第二步/srv/www/example.com/public_html/index.htm路径下的文件，有的话返回，没有的话走第三步返回404错误

请求: http://example.com/blog/

响应: 该请求会被第一个location匹配，请求路径里面有指出资源路径，因此拼接root路径

/srv/www/example.com/public_html/blog/index.html 路径下的文件，有的话直接返回，没有走第二步/srv/www/example.com/public_html/blog/index.htm路径下的文件，有的话返回，没有的话走第三步返回404错误

请求: http://example.com/tasks.pl

响应: 请求的资源是以.pl结尾的，会被第二个location匹配，资源名称是tasks.pl，拼接上root路径 nginx会寻找/srv/www/example.com/public_html/tasks.pl 路径下的文件，然后用指定的FASTCGI回调处理该文件，然后把结果作为响应返回

请求: http://example.com/username/roster.pl

响应: 请求的资源是以.pl结尾的，会被第二个location匹配，资源名称是roster.pl，路径是username, 拼接上root路径 nginx会寻找/srv/www/example.com/public_html/username/roster.pl路径下的文件，然后用指定的FASTCGI回调处理该文件，然后把结果作为响应返回

总结(译者)nginx location 指令是取请求uri，与location指令后面紧跟的字符串或正则表达式做比较，选择匹配度最高的location块，用其中定义的指令处理请求。root指令调整了资源的寻址路径，nginx会按照root + uri的路径来寻找请求资源如果uri没有明确指定资源名（具体的文件名），那么nginx会读取index指令的值作为默认返回值, 如果没有的话返回404

作者：Goldbeener

来源：掘金