Nginx 配置图片反向代理

Nginx 配置图片静态代理

location 语法规则

location [=|~|~*|^~] /uri/ {
        ····· 
}

location 后接的匹配规则含义

=     开头表示精确匹配

^~    开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）

~     开头表示区分大小写的正则匹配

~*    开头表示不区分大小写的正则匹配

!~    区分大小写不匹配的正则

!~*   不区分大小写不匹配的正则

/     通用匹配，任何请求都会匹配到

当我们有多个 location 配置的情况下，其匹配顺序为：

首先匹配 “=”，其次匹配 “^~”, 其次是按文件中顺序的正则匹配，最后是交给 “/” 通用匹配。

当有匹配成功时候，停止匹配，按当前匹配规则处理请求。

比如现在同时存在如下所示匹配规则

location = / {
   #规则A
}
location = /login {
   #规则B
}
location ^~ /static/ {
   #规则C
}
location ~ .(gif|jpg|png|js|css)$ {
   #规则D
}
location ~* .png$ {
   #规则E
}
location !~ .xhtml$ {
   #规则F
}
location !~* .xhtml$ {
   #规则G
}
location / {
   #规则H
}

那么产生的效果如下

访问根目录/   比如 http://localhost/   将匹配规则A

访问 http://localhost/login   将匹配规则B，http://localhost/register 则匹配规则H

访问 http://localhost/static/a.html   将匹配规则C

访问 http://localhost/a.gif, http://localhost/b.jpg   将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用，而 http://localhost/static/c.png 则优先匹配到规则C

访问 http://localhost/a.PNG   则匹配规则E，而不会匹配规则D，因为规则E不区分大小写

访问 http://localhost/a.xhtml   不会匹配规则F和规则G，http://localhost/a.XHTML不会匹配规则G，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到

访问 http://localhost/category/id/1111   则最终匹配到规则H，因为以上规则都不匹配，这个时候应该是nginx转发请求给后端应用服务器，比如FastCGI（php），tomcat（jsp），nginx作为方向代理服务器存在

所以在实际应用中，至少需要有三个匹配规则定义，如下：

# 直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理，官网如是说。
# 这里是直接转发给后端应用服务器了，也可以是一个静态首页
# 第一个必选规则
location = / {
    proxy_pass http://localhost:8080/index
}

# 第二个必选规则是处理静态文件请求，这是 nginx 作为 http 服务器的强项
# 有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用
location ^~ /static/ {
    root /webroot/static/;
}
location ~* .(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}

# 第三个规则就是通用规则，用来转发动态请求到后端应用服务器
# 非静态文件请求就默认是动态请求，自己根据实际把握
# 毕竟目前的一些框架的流行，带 .php, .jsp 后缀的情况很少了
location / {
    proxy_pass http://localhost:8080/
}

业务场景：

假如现在Linux服务器 home/file下有两个目录，一个是img目录另一个是log目录，img目录下有一个名为：a.jpg的图片，现在我们要通过域名/file/img/a.jpg来访问这张图片。

配置方式一：

	#正则匹配图片的url，匹配成功后到指定root的路径下查找
    location ~.*(file).(img|images)*\.(gif|jpg|jpeg|png)$ {
		 root /home/
	     autoindex on;
    } 

配置方式二：

   location ~ /file/img/ {
		 root /home/;
	     autoindex on;
    } 

假设这里直接用服务器的IP访问，IP = 47.100.256.36 ，不绑定域名的情况下。
请求地址为：http://47.100.256.36/file/img/a.jpg，则Nginx 会到服务器的：home/file/img/里去找图片。

注意：

这里最大的坑，就在于，root指的是文件的绝对路径，但是这个绝对路径不是时刻都要写全的，他是和location后面的路径拼接形成一个完成的文件路径。假如配置成：

   location ~ /file/img/ {
		 root /home/file/img/;
	     autoindex on;
    } 

或者：

    location ~.*(file).(img|images)*\.(gif|jpg|jpeg|png)$ {
		 root /home/file/img/;
	     autoindex on;
    } 

直接404，因为访问http://47.100.256.36/file/img/a.jpg的时候，实际上是去/home/file/img/目录下找file目录下的img目录下的文件。不能理解成location后面的路径是用作匹配，url中有这个路径就去root中找文件，要理解成它们描述的是一个包含关系。

有一种情况是可以把root路径写全的，比如默认的正则匹配图片代理：

   location  ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
        root /home/file/img/; #指定图片存放路径
    }

以上这种写法，访问图片必须是：域名或ip/文件名.拓展名的形式。因为你把root写全了！

最重要的是，假如你现在服务器上跑着一个前端项目，前端项目中肯定有很多静态的文件，比如网页中背景图。你没配置图片代理时，你访问你项目目录下的图片不会走代理，访问是正常的。但如果你像上面那样配置了，完犊子，直接404，因为你访问啥图片都能被它匹配上，因为上面那种写法相当于是根据扩展名匹配。不用纠结太多，你只要记住：上面那种root绝对路径写全的，只能用在一个项目中所有图片都在一个root下。真正项目中根本不可能，所有别那么干。哦，你非那么干也行，比如你/home/wwwroot/agriculture.ruanwe.com/static/img/下有一张名为a.jpg的图片，你想通过：域名或ip/static/img/文件名.拓展名的方式访问，再配一个location就行：

   location ~ /static/img/ { 
   root /home/wwwroot/agriculture.ruanwe.com/; 
   autoindex on;
   }

注意：location后面那个小波浪线 ~不能省略，如果省略，就成了普通配置，优先级就低了，就不走这个匹配规则，走上面根据扩展名匹配那个规则了。

或者：

    location  ~ .*(static).(img)*\.(gif|jpg|jpeg|png|bmp|swf)$ {
       root /home/wwwroot/agriculture.ruanwe.com/; 
    }

成了普通配置，优先级就低了，就不走这个匹配规则，走上面根据扩展名匹配那个规则了。

或者：

    location  ~ .*(static).(img)*\.(gif|jpg|jpeg|png|bmp|swf)$ {
       root /home/wwwroot/agriculture.ruanwe.com/; 
    }

它们两个是一个效果。