3-nginx的几种配置实例学习--反向代理、负载均衡、动静分离

反向代理

反向代理一

转发localhost的8080端口

反向代理二

根据不同的端口和路径实现不同服务的转发

准备两个tomcat服务 修改其中一个端口围为8081
分别在两个不同的tomcat的webapp中新建 edu/test.html 和 vod/test.html
在nginx中新增服务配置监听9001端口并根据路径匹配转发服务，重载nginx配置然后再浏览器中访问不同的地址查看结果

location匹配顺序

"="前缀指令匹配，如果匹配成功，则停止其他匹配
普通字符串指令匹配，顺序是从长到短，匹配成功的location如果使用^~，则停止其他匹配（正则匹配）
正则表达式指令匹配，按照配置文件里的顺序，成功就停止其他匹配 如果第三步中有匹配成功，则使用该结果，否则使用第二步结果
注意点
匹配的顺序是先匹配普通字符串，然后再匹配正则表达式。另外普通字符串匹配顺序是根据配置中字符长度从长到短，也就是说使用普通字符串配置的location顺序是无关紧要的，反正最后nginx会根据配置的长短来进行匹配，但是需要注意的是正则表达式按照配置文件里的顺序测试。找到第一个比配的正则表达式将停止搜索。
一般情况下，匹配成功了普通字符串location后还会进行正则表达式location匹配。有两种方法改变这种行为，其一就是使用“=”前缀，这时执行的是严格匹配，并且匹配成功后立即停止其他匹配，同时处理这个请求；另外一种就是使用“^~”前缀，如果把这个前缀用于一个常规字符串那么告诉nginx 如果路径匹配那么不测试正则表达式。
匹配模式及顺序
location = /uri 　　　=开头表示精确匹配，只有完全匹配上才能生效。
location ^~ /uri 　　^~ 开头对URL路径进行前缀匹配，并且在正则之前。
location ~ pattern 　~开头表示区分大小写的正则匹配。
location ~* pattern 　~*开头表示不区分大小写的正则匹配。
location /uri 　　　　不带任何修饰符，也表示前缀匹配，但是在正则匹配之后。
location / 　　　　　通用匹配，任何未匹配到其它location的请求都会匹配到，相当于switch中的default。

实验案例

测试"^"和""，nginx配置如下。浏览器输入http://localhost/helloworld/test，返回601。如将#1注释，#2打开，浏览器输入http://localhost/helloworld/test，返回603。注：#1和#2不能同时打开，如同时打开，启动nginx会报nginx: [emerg] duplicate location "/helloworld"...，因为这两个都是普通字符串。

location ^~ /helloworld {      #1
    return 601;
}
        
#location /helloworld {        #2
#    return 602;
#}

location ~ /helloworld {
    return 603;
}

测试普通字符串的长短（普通字符串的匹配与顺序无关，与长短有关）。浏览器输入http://localhost/helloworld/test/a.html，返回601。浏览器输入http://localhost/helloworld/a.html，返回602。

location /helloworld/test/ {        #1
    return 601;
}
        
location /helloworld/ {                #2
    return 602;
}

测试正则表达式的顺序（正则匹配与顺序相关）。浏览器输入http://localhost/helloworld/test/a.html，返回602；将#2和#3调换顺序，浏览器输入http://localhost/helloworld/test/a.html，返回603

location /helloworld/test/ {        #1
    return 601;
}

location ~ /helloworld {            #2
    return 602;
}
        
location ~ /helloworld/test {        #3
    return 603;
}

负载均衡

1、增加upstream 服务池
2、配置转发

Nginx 负载均衡分配策略

nginx 的 upstream 目前支持 4 种方式的分配
1)、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。

2)、weight 指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。

3)、ip_hash 每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。

4)、fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。

5)、url_hash（第三方）

动静分离

通过location指定不同的后缀名实现不同的请求转发。通过expires参数设置，可以设置浏览器缓存过期时间，减少与服务器之前的请求和流量。
具体Expires定义: 是给一个资源设定一个过期时间，也就是说无需去服务端验证，直接通过浏览器自身确认是否过期即可，所以不会产生额外的流量。此种方法非常适合不经常变动的资源。(如果经常更新的文件，不建议使用Expires来缓存)，如果设置3d, 表示在这3天之内访问这个URL, 发送一个请求，比对服务器该文件最后更新时间没有变化，则不会从服务器抓取，返回状态码304,如果有修改，则直接从服务器重新下载，返回状态码200。

2、准备工作
(1) 在liunx系统中准备静态资源，用于进行访问
/data/image 图片文件夹
/data/www html文件夹
3、具体配置
(1) 在nginx配置文件中进行配置

Nginx默认是不允许列出整个目录的。如需此功能，打开nginx.conf文件，在location server 或 http段中加入
autoindex on;
另外两个参数最好也加上去:

autoindex_exact_size off;
默认为on，显示出文件的确切大小，单位是bytes。
改为off后，显示出文件的大概大小，单位是kB或者MB或者GB
autoindex_localtime on;
默认为off，显示的文件时间为GMT时间。
改为on后，显示的文件时间为文件的服务器时间

nginx错误码原因以及解决方案：

1、400 bad request错误的原因和解决办法 配置nginx.conf相关设置如下.

client_header_buffer_size 16k;

large_client_header_buffers 4 64k;

根据具体情况调整，一般适当调整值就可以。

2、Nginx 502 Bad Gateway错误

proxy_next_upstream error timeout invalid_header http_500 http_503;

或者尝试设置:

large_client_header_buffers 4 32k;

3、Nginx出现的413 Request Entity Too Large错误

这个错误一般在上传文件的时候会出现，

编辑Nginx主配置文件Nginx.conf，找到http{}段，添加

client_max_body_size 10m; //设置多大根据自己的需求作调整.

如果运行php的话这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，这样就不会因为提交数据大小不一致出现的错误。

post_max_size = 10M

upload_max_filesize = 2M

4、解决504 Gateway Time-out(nginx)

遇到这个问题是在升级discuz论坛的时候遇到的

一般看来, 这种情况可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的, 这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好, 那么最后就极有可能导致504 Gateway Time-out

现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K。

默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点

在nginx.conf里, 加入： fastcgi_buffers 8 128k

这表示设置fastcgi缓冲区为8×128k

当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点，例如设置成60秒：send_timeout 60;

只是调整了这两个参数, 结果就是没有再显示那个超时, 可以说效果不错, 但是也可能是由于其他的原因, 目前关于nginx的资料不是很多, 很多事情都需要长期的经验累计才有结果.