nginx检测配置文件

『壹』 nginx在做负载均衡时如何配置

1、下面的架构就是我们今天的演示结构，后端有两台服务器，分别是node1和node2，前端是一台web服务器，然后在web服务器上做负载均衡，将前端的访问流量导到后端的两个节点服务器上。三个服务器的IP地址分别是：web：192.168.1.210node1：192.168.1.211node2：192.168.1.212
2、按照这样的架构，在后端的node1和node2节点上分配配置好需要访问的网站，然后为了方便测试，我们将两个网站的主页分别改成下面的内容。便于区分访问的节点。
3、后端两个节点配置好以后，我们再来配置web服务器里的负载均衡配置，首先使用默认配置，先打开/etc/nginx/nginx.conf配置文件，在http区块里添加upstream块内容，及配置了两个后端服务器，后端负载均衡集群的名称是backend，记下这个名称。
4、然后再打开/etc/nginx/conf.d/default.conf这个配置文件，在server区块里，把location里面的内容改成图中所示内容。即将所有访问192.168.1.210的流量代理到后端的backend集群里。
5、配置文件配置好以后，使用nginx-t命令测试一下配置文件，保证配置文件是ok状态，然后执行nginx命令启动nginx服务器。
6、启动后在浏览器上输入前端web服务器的ip地址192.168.1.210，然后可以看到第一次是node1响应的，然后刷新一下以后，又变成了node2响应的。就这样实现了负载均衡的效果。由两个服务器分别响应，是因为默认的负载均衡算法是轮询算法，即两个节点轮流来。
7、然后我们还可以尝试一下加权轮询算法，即给不同的节点配置不同的权重，权重高一点的服务器，响应的多一些，权重第一点的响应少一些。加权轮询算法配置，在后端服务器后面加上权重值weight即可。配置好以后，执行nginx-t命令检测配置文件，确认无误后，执行nginx-sreload命令重新加载配置文件。
8、通过加权轮询的方式，我们无法通过手动一次次点击，最后来统计次数。但是我们可以使用自动化工具来统计。使用的工具是一款叫做httpd-tools的软件，安装好以后，提供了一个ab命令
9、然后我们来执行ab命令进行测试，常用的格式是：ab-n1000-c50http://localhost这个命令是在210服务器上执行的。表示一共执行1000次访问，每次发送50个请求。
10、然后我们登录到后端的node1服务器上，打开nginx的访问日志，从中可以看到ab命令测试的访问信息里，访问来源都是ApacheBench，因此可以通过可以来源来统计nginx响应的次数。命令是：grepApacheBenchaccess.log|wcnode1和node2节点上的统计结果分别是714和286，如下面图中所示，虽然没有达到5:2的权重比例，但是也非常接近了。说明这个配置生效了。

『贰』 Nginx配置文件详解

说到该指令 ，首先得阐述一下什么是所谓的 “惊群问题”，可以参考 WIKI网络的解释。就Nginx的场景来解释的话大致的意思就是：当一个新网络连接来到时，多个worker进程会被同时唤醒，但仅仅只有一个进程可以真正获得连接并处理之。如果每次唤醒的进程数目过多的话，其实是会影响一部分性能的。

所以在这里，如果accept_mutex on，那么多个worker将是以串行方式来处理，其中有一个worker会被唤醒；反之若accept_mutex off，那么所有的worker都会被唤醒，不过只有一个worker能获取新连接，其它的worker会重新进入休眠状态。

用rewrite转发的话，url会发生变化的，那就用proxy_pass吧，于是添加了如下的配置：

在现有环境的nginx里添加这段配置之后，访问却始终转不过去，查看nginx日志也只能看到是404信息，并没有更多定位问题的信息。检查了许久也没找到原因，于是重新装了一台新nginx，里面只加上面这段配置，结果nginx是能够转发成功的，这说明单独来看这条location的配置是没有问题的，很有可能是现有环境nginx里的某些配置影响到了这个转发。

为了定位问题原因，我将aaa.example.com虚拟主机下的其他配置注意注释掉来调试，最后发现当注释掉proxy_set_header Host $http_host ;这条配置之后，就能成功转发了。这才注意到是反向代理配置的问题。现有环境中原有的配置也不能随便删掉，上网查了下原因，找到下面这种解决方案：

即，在location里面添加一条proxy_set_header Host http_host时，则不改变请求头的值，所以当要转发到bbb.example.com的时候，请求头还是aaa.example.com的Host信息，就会有问题；当Host设置为$proxy_host时，则会重新设置请求头为bbb.example.com的Host信息。

另外，关于proxy_pass转发url的参数，可以通过在location中用rewrite来做，所以完善后的配置如下：

在location用rewrite改变了URI之后，proxy_pass将使用改变后的URI。上面例子(.*)是将所有参数传给 1会拼接在 http://bbb.example.com 后面。

先来看下proxy_set_header的语法

允许重新定义或者添加发往后端服务器的请求头。value可以包含文本、变量或者它们的组合。 当且仅当当前配置级别中没有定义proxy_set_header指令时，会从上面的级别继承配置。 默认情况下，只有两个请求头会被重新定义：

当匹配到/customer/straightcustomer/download时，使用crmtest处理，到upstream就匹配到crmtest.aty.sohuno.com，这里直接转换成IP进行转发了。假如crmtest.aty.sohuno.com是在另一台nginx下配置的，ip为10.22.10.116，则$proxy_host则对应为10.22.10.116。此时相当于设置了Host为10.22.10.116。如果想让Host是crmtest.aty.sohuno.com，则进行如下设置：

如果不想改变请求头“Host”的值，可以这样来设置：

但是，如果客户端请求头中没有携带这个头部，那么传递到后端服务器的请求也不含这个头部。 这种情况下，更好的方式是使用$host变量——它的值在请求包含“Host”请求头时为“Host”字段的值，在请求未携带“Host”请求头时为虚拟主机的主域名：

此外，服务器名可以和后端服务器的端口一起传送：

如果某个请求头的值为空，那么这个请求头将不会传送给后端服务器：

nginx配置项，里面的配置项有代理https，http，代理静态文件，H5分发，代理TCP连接，能满足大多数搭建测试环境所要用的nginx的情况，大家碰到要使用nginx的时候可以参考下

『叁』 windows下nginx怎么检查配置文件

从今开始，学nginx #安装pcre [root@svr3 ~]# tar -xjf pcre-8 10/ Opera/9.80 (Windows NT 5.1; U; zh-cn) Presto/2.9.168 Version/11.50 ===>如何启动nginx? <假定nginx安装在/usr/local/nginx中> 方法1、执行/usr/local/nginx/sbin/nginx -t 检查配置文件是否有误！或是直接执行/usr/local/nginx/sbin/nginx 如果有多个配置文件可以使用指定的配置文件启动： #/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf ===> nginx的信号控制： TERM,INT 快速关闭 QUIT 从容关闭 HUP 重启，重新加载配置文件 USR1 重启打开日志，在切割日志时用途大 USR2 平滑升级可执行程序 WINCH 从容关闭进程 本文出自 潜入技术的海洋 博客

『肆』 nginx前端常用配置

nginx现在几乎是众多大型网站的必用技术，大多数情况下，我们不需要亲自去配置它，但是了解它在应用程序中所担任的角色，以及如何解决这些问题是非常必要的。

下面我将从nginx在企业中的真实应用来解释nginx在应用程序中起到的作用。

为了便于理解，首先先来了解一下一些基础知识， nginx是一个高性能的反向代理服务器 那么什么是反向代理呢？

代理 是在服务器和客户端之间假设的一层服务器， 代理 将接收客户端的请求并将它转发给服务器，然后将服务端的响应转发给客户端。

不管是正向代理还是反向代理，实现的都是上面的功能。

正向代理 是为我们服务的，即为客户端服务的，客户端可以根据正向代理访问到它本身无法访问到的服务器资源。

正向代理 对我们是透明的，对服务端是非透明的，即服务端并不知道自己收到的是来自代理的访问还是来自真实客户端的访问。

反向代理 是为服务端服务的，反向代理可以帮助服务器接收来自客户端的请求，帮助服务器做请求转发，负载均衡等。

反向代理 对服务端是透明的，对我们是非透明的，即我们并不知道自己访问的是代理服务器，而服务器知道反向代理在为他服务。

下面是一个nginx配置文件的基本结构：

下面是 nginx 一些配置中常用的内置全局变量，你可以在配置的任何位置使用它们。

| 变量名 | 功能 | | ------ | ------ | | $host | 请求信息中的 Host ，如果请求中没有 Host 行，则等于设置的服务器名 | | $request_method | 客户端请求类型，如 GET 、 POST | $remote_addr | 客户端的 IP 地址 | | $args | 请求中的参数 | | $content_length | 请求头中的 Content-length 字段 | | $http_user_agent | 客户端agent信息 | | $http_cookie | 客户端cookie信息 | | $remote_addr | 客户端的IP地址 | | $remote_port | 客户端的端口 | | $server_protocol | 请求使用的协议，如 HTTP/1.0 、·HTTP/1.1 | | server_name | 服务器名称| | $server_port`|服务器的端口号|

先追本溯源以下，跨域究竟是怎么回事。

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。通常不允许不同源间的读操作。

如果两个页面的协议，端口（如果有指定）和域名都相同，则两个页面具有相同的源。

例如：

现在我在 fe.server.com 对 dev.server.com 发起请求一定会出现跨域。

现在我们只需要启动一个nginx服务器，将 server_name 设置为 fe.server.com ,然后设置相应的location以拦截前端需要跨域的请求，最后将请求代理回 dev.server.com 。如下面的配置：

这样可以完美绕过浏览器的同源策略： fe.server.com 访问 nginx 的 fe.server.com 属于同源访问，而 nginx 对服务端转发的请求不会触发浏览器的同源策略。

根据状态码过滤

根据URL名称过滤，精准匹配URL，不匹配的URL全部重定向到主页。

根据请求类型过滤。

GZIP 是规定的三种标准HTTP压缩格式之一。目前绝大多数的网站都在使用 GZIP 传输 HTML 、 CSS 、 JavaScript 等资源文件。

对于文本文件， GZip 的效果非常明显，开启后传输所需流量大约会降至 1/4 ~ 1/3 。

并不是每个浏览器都支持 gzip 的，如何知道客户端是否支持 gzip 呢，请求头中的 Accept-Encoding 来标识对压缩的支持。

启用 gzip 同时需要客户端和服务端的支持，如果客户端支持 gzip 的解析，那么只要服务端能够返回 gzip 的文件就可以启用 gzip 了,我们可以通过 nginx 的配置来让服务端支持 gzip 。下面的 respone 中 content-encoding:gzip ，指服务端开启了 gzip 的压缩方式。

这里为什么默认版本不是 1.0 呢？

HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性。

启用持久连接情况下，服务器发出响应后让 TCP 连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。

为了尽可能的提高 HTTP 性能，使用持久连接就显得尤为重要了。

HTTP/1.1 默认支持 TCP 持久连接， HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。对于 TCP 持久连接上的 HTTP 报文，客户端需要一种机制来准确判断结束位置，而在 HTTP/1.0 中，这种机制只有 Content-Length 。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。

nginx 同样有着配置 chunked的 属性 chunked_transfer_encoding ，这个属性是默认开启的。

Nginx 在启用了 GZip 的情况下，不会等文件 GZip 完成再返回响应，而是边压缩边响应，这样可以显著提高 TTFB ( Time To First Byte ，首字节时间，WEB 性能优化重要指标)。这样唯一的问题是， Nginx 开始返回响应时，它无法知道将要传输的文件最终有多大，也就是无法给出 Content-Length 这个响应头部。

所以，在 HTTP1.0 中如果利用 Nginx 启用了 GZip ，是无法获得 Content-Length 的，这导致HTTP1.0中开启持久链接和使用 GZip 只能二选一，所以在这里 gzip_http_version 默认设置为 1.1 。

如上面的图，前面是众多的服务窗口，下面有很多用户需要服务，我们需要一个工具或策略来帮助我们将如此多的用户分配到每个窗口，来达到资源的充分利用以及更少的排队时间。

把前面的服务窗口想像成我们的后端服务器，而后面终端的人则是无数个客户端正在发起请求。负载均衡就是用来帮助我们将众多的客户端请求合理的分配到各个服务器，以达到服务端资源的充分利用和更少的请求时间。

Upstream指定后端服务器地址列表

在server中拦截响应请求，并将请求转发到Upstream中配置的服务器列表。

上面的配置只是指定了nginx需要转发的服务端列表，并没有指定分配策略。

轮询策略

默认情况下采用的策略，将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的，但是如果其中某一台服务器压力太大，出现延迟，会影响所有分配在这台服务器下的用户。

最小连接数策略

将请求优先分配给压力较小的服务器，它可以平衡每个队列的长度，并避免向压力大的服务器添加更多的请求。

最快响应时间策略

依赖于NGINX Plus，优先分配给响应时间最短的服务器。

客户端ip绑定

来自同一个ip的请求永远只分配一台服务器，有效解决了动态网页存在的session共享问题。

匹配以 png|gif|jpg|jpeg 为结尾的请求，并将请求转发到本地路径， root 中指定的路径即nginx本地路径。同时也可以进行一些缓存的设置。

nginx的功能非常强大，还有很多需要探索，上面的一些配置都是公司配置的真实应用（精简过了），如果您有什么意见或者建议，欢迎在下方留言...

『伍』 nginx 如何检测配置文件的正确性

用参数-t
nginx -t
如果返回ok,用 -s reload 重新加载配置文件

『陆』 nginx 配置详解是什么

Nginx配置文件详解：

Nginx的主配置文件是nginx.conf，这个配置文件一共由三部分组成，分别为全局块、events块和http块。在http块中，又包含http全局块、多个server块。

每个server块中，可以包含server全局块和多个location块。在同一配置块中嵌套的配置块，各个之间不存在次序关系。

配置文件支持大量可配置的指令，绝大多数指令不是特定属于某一个块的。同一个指令放在不同层级的块中，其作用域也不同，一般情况下，高一级块中的指令可以作用于自身所在的块和此块包含的所有低层级块。

如果某个指令在两个不同层级的块中同时出现，则采用“就近原则”，即以较低层级块中的配置为准。比如，某指令同时出现在http全局块中和server块中，并且配置不同，则应该以server块中的配置为准。

全局块：

全局块是默认配置文件从开始到events块之间的一部分内容，主要设置一些影响Nginx服务器整体运行的配置指令，因此，这些指令的作用域是Nginx服务器全局。

通常包括配置运行Nginx服务器的用户（组）、允许生成的worker process数、Nginx进程PID存放路径、日志的存放路径和类型以及配置文件引入等。

『柒』 nginx配置解读

Nginx是俄罗斯人Igor Sysoev(塞索耶夫)编写的一款高性能的 HTTP 和反向代理服务器。也是一个IMAP/POP3/SMTP代理服务器，也就是说，Nginx本身就可以托管网站，进行HTTP服务处理，也可以作为反向代理服务器使用。

Nginx功能丰富，可作为HTTP服务器，也可作为反向代理服务器，邮件服务器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。并且支持很多第三方的模块扩展。

总之，非常牛的一款反向代理服务，牛逼吹的差不多啦，下面进入正题[得意]

Nginx配置文件nginx.conf详解

『捌』 如何验证Nginx配置文件是否准确

检测nginx配置文件是否正确

/usr/local/nginx/sbin/nginx -t -c nginx.conf  
-c 配置文件路径  
-g Set global directives. (version >=0.7.4)  
-t 检测文件是否正确不执行  
-v Print version.  
-V Print nginx version, compiler version and configure 
parameters. 
编译时如果使用了–with-debug编译,还可以使用error_log file [ debug_core| debug_http | debug_event …] 来获得debug信息

通过信号对 Nginx配置文件 进行控制

『玖』 nginx 配置详解是什么

Nginx是lgor Sysoev为俄罗斯访问量第二的rambler.ru站点设计开发的。从2004年发布至今，凭借开源的力量，已经接近成熟与完善。

Nginx功能丰富，可作为HTTP服务器，也可作为反向代理服务器，邮件服务器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。并且支持很多第三方的模块扩展。

Nginx的稳定性、功能集、示例配置文件和低系统资源的消耗让他后来居上，在全球活跃的网站中有12.18%的使用比率，大约为2220万个网站。

1、全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。

2、events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。

3、http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。

4、server块：配置虚拟主机的相关参数，一个http中可以有多个server。

5、location块：配置请求的路由，以及各种页面的处理情况。

Nginx常用功能。

1、Http代理，反向代理：作为web服务器最常用的功能之一，尤其是反向代理。

Nginx在做反向代理时，提供性能稳定，并且能够提供配置灵活的转发功能。Nginx可以根据不同的正则匹配，采取不同的转发策略，比如图片文件结尾的走文件服务器，动态页面走web服务器，只要你正则写的没问题，又有相对应的服务器解决方案。

。并且Nginx对返回结果进行错误页跳转，异常判断等。如果被分发的服务器存在异常，他可以将请求重新转发给另外一台服务器，然后自动去除异常服务器。

2、负载均衡

Nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为轮询，加权轮询，Ip hash。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他一一找出来做下实现。

『拾』 初识Nginx配置文件以及基本命令

配置文件名为 nginx.conf ，Linux放在目录： /usr/local/nginx/conf 、 /etc/nginx , 或 /usr/local/etc/nginx 中；Windows放在 安装目录conf 中。 依据实际安装情况决定

nginx由配置文件中指定的指令控制模块组成。 指令分为 简单指令 和 块指令 ：
简单指令 由空格分隔的名称和参数组成，并以分号 ; 结尾；
块指令 具有与简单指令相同的结构，但是是以大括号 { 和 } 包围的一组附加指令。 如果块指令在大括号内部有其他指令，则称为上下文(例如： events ， http ， server 和 location )；
配置文件中放置在任何上下文之外的伪指令都被认为是主上下文。 events 和 http 指令驻留在主上下文中， server 在 http 中的，而 location 在 server 块中。一个配置文件一个 http ，一个及以上个 server ，一个 server 运行一个工作进程并代表一个虚拟服务器；
# 号所在的一行被视为注释；
几个顶级指令将适用于不同流量类型的指令组合在一起：

对于大多数指令，在子上下文中定义的上下文将继承父级中包含的伪指令的值，要覆盖从父进程继承的值，子上下文中需要包含该指令（即子上下文要显式声明）。

打开配置文件(如 /usr/local/nginx/conf/nginx.conf )，默认的配置文件已经包含了服务器块的几个示例，大部分是注释掉的。 现在注释掉所有这样的块，并启动一个新的服务器块：

每个 server 上下文都可以指定要监听的端口、server_name，当nginx决定哪个服务器处理请求后，它会根据服务器块内部定义的location指令的参数测试请求头中指定的URI， 比如如下配置，系统中创建 /data 目录及其子目录 /www ：

第一个 location 块指定与请求中的URI比较 / 前缀。 对于匹配请求，URI将被添加到 root 指令中指定的路径(即 /data/www )，形成本地文件系统中的请求文件路径。 如果有几个匹配的location块，nginx将选择具有最长前缀来匹配location块。 上面第一个 location 块提供最短的前缀长度为1，因此只有当所有其他location块不能提供匹配时，才会使用该块。第二个 location ,将是以 /images/ 的请求来匹配，位置 / 也匹配这样的请求，但具有较短前缀，也就是 /images/ 比 / 长。

这已经是一个在标准端口 80 上侦听并且可以在本地机器上访问的服务器 http://localhost/ 的工作配置， 端口 80 和 server_name localhost 可以省略，它们为默认值 。 响应以/images/开头的URI的请求，服务器将从 /data/images 目录发送文件。 例如，响应 http://localhost/images/logo.png 请求，nginx将发送服务上的 /data/images/logo.png 文件。 如果文件不存在，nginx将发送一个指示 404 错误的响应。 不以 /images/ 开头的URI的请求将映射到 /data/www 目录。 例如，响应 http://localhost/about/example.html 请求时，nginx将发送 /data/www/about/example.html 文件。

反向代理应该是Nginx做的最多的一件事了，反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。
通过向nginx配置文件添加一个server块来定义代理服务器，其中包含以下内容：

这将是一个监听端口 8080 的简单服务器，并将所有请求映射到本地文件系统上的 /data/up1 目录。 请注意，root指令位于server块上下文中，当选择用于服务请求的 location 块不包含自己的 root 指令时，将使用此root指令。创建 /data/up1 目录然后可以将一个静态网页比如 index.html 文件放入其中，然后访问 http://localhost:8080/ 即可访问该文件。
目前为止，还是配置的静态资源访问，并不是代理服务器，然后增加或修改现有 location 上下文，改为如下：

当用户访问 http://localhost:8080/ 时，会返回 http://localhost:8181 服务器的的资源。
location 上下文后面的参数，可以是正则表达式，如果是正则表达式，前面要加 ~ ，比如：

以上配置表示，nginx接收到所有以.gif，.jpg或.png结尾的URI，相应的请求将映射到/data/images目录。当nginx选择一个location块来提供请求时，它首先检查指定前缀的location指令，记住具有最长前缀的location，然后检查正则表达式。 如果与正则表达式匹配，nginx会选择此location，否则选择之前记住的那一个。

要找到最符合URI的位置，NGINX首先将URI与前缀字符串的位置进行比较。然后用正则表达式搜索位置。除非使用^~修饰符对正则表达式给予更高的优先级。在前缀字符串中，NGINX选择最具体的字符串(也就是最长和最完整的字符串)。 下面给出了选择处理请求的位置的确切逻辑：

测试所有URI的前缀字符串。 = (等号)修饰符定义了URI和前缀字符串完全匹配。如果找到完全匹配，则搜索停止。如果 ^~ (插入符号)修饰符预先添加最长匹配前缀字符串，则不会检查正则表达式。存储最长匹配的前缀字符串。根据正则表达式测试URI。断开第一个匹配的正则表达式并使用相应的位置。如果没有正则表达式匹配，则使用与存储的前缀字符串相对应的位置。

= 修饰符的典型用例是 / (正斜杠)的请求。 如果请求/是频繁的，则指定 = / 作为location指令的参数加速处理，因为搜索匹配在第一次比较之后停止。

要启动nginx，请运行可执行文件。 当nginx启动后，可以通过使用-s参数调用可执行文件来控制它。 使用以下语法：

信号(signal)的值可能是以下之一：

当主进程收到要重新加载配置的信号，它将检查新配置文件的语法有效性，并尝试应用其中提供的配置。 如果这是成功的，主进程将启动新的工作进程，并向旧的工作进程发送消息，请求它们关闭。 否则，主进程回滚更改，并继续使用旧配置。 老工作进程，接收关闭命令，停止接受新连接，并继续维护当前请求，直到所有这些请求得到维护。 之后，旧的工作进程退出。

两者在 location 中，指定一个路径，其中使用 alias 做如下配置：

若按照上述配置的话，则访问/img/目录里面的文件时，ningx会自动去/var/www/image/目录找文件

若按照这种配置的话，则访问/img/目录下的文件时，nginx会去/var/www/image/img/目录下找文件。alias是一个目录别名的定义，root则是最上层目录的定义，指的是 /var/www/image/img/ 。还有一个重要的区别是alias后面必须要 / 结束，否则会找不到文件，而root则可有可无。

另外对于index，含义如下

这样，当用户请求 / 地址时，Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和 index.html 这两个文件。如果 index.htm 文件存在，则直接发起“内部跳转”到 /index.htm 这个新的地址；而如果 index.htm 文件不存在，则继续检查 index.html 是否存在。如果存在，同样发起“内部跳转”到 /index.html ；如果 index.html 文件仍然不存在，则放弃处理权给 content 阶段的下一个模块。

参考地址1
参考地址2:B站