Nginx参数详解+Rewrite规则

Nginx参数详解

Nginx常用配置参数有upstream,主要用于均衡后端多个实例:

Nginx 的upstream目前支持5种算法分配方式:

轮询(默认rr round robin)

每个请求按时间顺序逐一分配到后端不同的服务器,如果后端某台服务器down掉,自动剔除,待恢复自动添加上。

Weight权重

指定轮询权重,权重越高,处理的请求就越多,weight和访问比率成正比,用于后端服务器性能不均的情况。

ip_hash

每个请求根据访问的IP的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题,一般用于登录会话。

fair(第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配。

url_hash(第三方)

upstream的 fail_timeout和max_fails参数是用来判断负载均衡upstream中的某个server是否失效。

在fail_timeout的时间内,nignx与upstream中某个server的连接尝试失败了max_fails次,则nginx会认为该server已经失效。在接下来的 fail_timeout时间内,nginx不再将请求分发给失效的server。

例如在nginx.conf里面配置如下的test_app均衡:

upstream test_app {
    server 192.168.8.2:8080 weight=1 max_fails=2 fail_timeout=30s;
    server 192.168.8.3:8080 weight=1 max_fails=2 fail_timeout=30s;
}

test_app均衡两台后端JAVA服务,在30秒内nginx会与后端的某个server通信检测,如果检测连接失败2次,则Nginx会认为该server已经失效,然后踢出转发列表,然后在接下来的30s内,nginx不再讲请求转发给失效的server。

另外,fail_timeout设置的时间对响应时间没影响,这个响应时间是用proxy_connect_timeout和proxy_read_timeout来控制的。

proxy_connect_timeout : Nginx与后端服务器连接的超时时间,发起握手等候响应超时时间。

proxy_read_timeout:连接成功后_等候后端服务器响应时间,其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间)。

proxy_send_timeout :后端服务器数据回传时间,在规定时间之内后端服务器必须传完所有的数据。

keepalive_timout:一个http产生的tcp连接在传送完最后一个响应后,还需要等待多少秒后,才关闭这个连接。

Rewrite规则

Rewrite规则含义就是某个URL重写成特定的URL,从某种意义上说为了美观或者对搜索引擎友好,提高收录量及排名等。

Rewrite规则的最后一项参数为flag标记,支持的flag标记主要有以下几种:

last :相当于Apache里德(L)标记,表示完成rewrite;

break;本条规则匹配完成后,终止匹配,不再匹配后面的规则

redirect:返回302临时重定向,浏览器地址会显示跳转后的URL地址

permanent:返回301永久重定向,浏览器地址栏会显示跳转后的URL地址

last和break用来实现URL重写,浏览器地址栏URL地址不变。

例如用户访问www.test.com,想直接跳转到网站下面的某个页面,www.test.com/new.index.html如何来实现呢?

我们可以使用Nginx Rewrite 来实现这个需求,具体如下:

在server中加入如下语句即可:

rewrite ^/$ http://www.test.com/index01.html permanent;

*代表前面0或更多个字符

+代表前面1或更多个字符

?代表前面0或1个字符

^代表字符串的开始位置

$代表字符串结束的位置

。为通配符,代表任何字符

例如多个域名跳转到同一个域名,nginx rewrite规则写法如下:

server {
    listen 80;
    server_name www.yangxz.com yangxz.com;
    if ( $host != 'www.yangxz.com' ) {
    rewrite ^/(.*)$ http://www.yangxz.com/$1 permanent;
   }
}

当访问的文件和目录不存在时,重定向到某个php文件

if( !-e $request_filename ) {
    rewrite ^/(.*)$ index.php last;
}

目录对换 /xxxx/123456 ---/xxxx?id=123456

rewrite ^/(.+)/(/d+) /$2?id=$1 last;

浏览器请求头跳转

if( $http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /ie/$1 break;
}

禁止访问以.sh,.flv,.mp3为文件后缀名的文件

location ~ .*/.(sh|flv|mp3|xml|rar|zip)$ {
    return 403;
}

将yangxingzhen.com跳转到nuoyo.cn

if ($host = 'yangxingzhen.com' ) {
    rewrite ^/(.*)$ http://nuoyo.cn/$1 permanent;
}

匹配用户浏览器代理信息:

if ( $http_user_agent ~* "(Android)|(iPhone)|(Mobile)|(WAP)|(UCWEB)" ) {
    rewrite ^/$  http://m.jfedu.net/ permanent;
}
Nginx-BBS论坛rewrite规则配置
rewrite ^([^/.]*)/group-([0-9]+)-([0-9]+)/.html$ $1/forum.php?mod=group&fid=$2&page=$3 last;

Nginx location规则匹配

1、"= ",字面精确匹配, 如果匹配,则跳出匹配过程。(不再进行正则匹配)

2、"^~ ",最大前缀匹配,如果匹配,则跳出匹配过程。(不再进行正则匹配)

3、/ 不带任何前缀:最大前缀匹配,举例如下:

location / 代表以"/"开头的搜索匹配, 在没有正则表达式匹配的情况下才进行这个匹配(优先级最低)

4、"~ ",大小写相关的正则匹配

5、"~* " , 大小写无关的正则匹配

6、"@", Named location 不是普通的location匹配,而是用于location内部重定向的变量。

Location @apache

其中: 1、2、3 三种情况属于 location using literal string, 即使用普通字符串的location匹配;

4、5二种情况属于 location using regular expresstion,即使用正则表达式的location匹配;

location 匹配的优先级(与location在配置文件中的顺序无关)

= 精确匹配会第一个被处理。如果发现精确匹配,nginx停止搜索其他匹配。

普通字符匹配,正则表达式规则和长的块规则将被优先和查询匹配,也就是说如果该项匹配还需去看有没有正则表达式匹配和更长的匹配。

^~ 则只匹配该规则,nginx停止搜索其他匹配,否则nginx会继续处理其他location指令。

最后匹配理带有"~"和"~*"的指令,如果找到相应的匹配,则nginx停止搜索其他匹配;当没有正则表达式或者没有正则表达式被匹配的情况下,那么匹配程度最高的逐字匹配指令会被使用。

location  = / {
  # 只匹配"/".
  [ configuration A ] 
}
location  / {
  # 匹配任何请求,因为所有请求都是以"/"开始
  # 但是更长字符匹配或者正则表达式匹配会优先匹配
  [ configuration B ] 
}
location = /images/ {
  # 匹配任何以 /images/ 开始的请求,并停止匹配 其它location
  [ configuration C ] 
  root  /tmp/;
}
location ~* /.(gif|jpg|jpeg)$ {
  # 匹配以 gif, jpg, or jpeg结尾的请求. 
  # 但是所有 /images/ 目录的请求将由 [Configuration C]处理.   
  [ configuration D ] 
  Root /var/www/html/
}

请求URI例子:

/ -> 符合configuration A

/documents/document.html -> 符合configuration B

/images/1.gif -> 符合configuration C

/documents/1.jpg ->符合 configuration D

正常的优先级别为:

(location =) > (location 完整路径 >) >(location ^~ 路径) >(location ~* 正则) >(location 路径)

给TA打赏
共{{data.count}}人
人已打赏
运维

Linux文件权限解析

2023-11-21 16:25:46

运维

Jumpserver开源堡垒机管理

2023-11-21 16:27:40

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索