路由–Location的使用
语法规则: location [=|~|~*|^~] /uri/ {… }
首先匹配 =,其次匹配^~,其次是按文件中顺序的正则匹配,最后是交给 /通用匹配。当有匹配成功时候,停止匹配,按当前匹配规则处理请求。
- =精准匹配命中时,停止 location 动作,直接走精准匹配,
- 一般匹配(含非正则)命中时,先收集所有的普通匹配,最后对比出最长的那一条
- 如果最长的那一条普通匹配声明为非正则,直接此条匹配,停止 location
- 如果最长的那一条普通匹配不是非正则,继续往下走正则 location
- 按代码顺序执行正则匹配,当第一条正则 location 命中时,停止 location
path匹配过程
假设 http 请求路径为
,匹配过程如下:
rewrite 使用
rewrite regex replacement [flag];
flag= 【break/last/redirect/permanent 】
regex 是正则表达式
replacement 是替换值,新值
flag — 后续处理标识
flag=break
发生 nginx 内部重定向,path 值被更新,rewrite 层面的命令会中断。原控制流程逻辑不变往下走
flag=last
发生 nginx 内部重定向,path 值被更新,rewrite 层面的命令会中断。控制流程刷新,重新进行整个 location 层的逻辑流程。
flag= redirect/permanent
发生页面重定向(301 永久重定向/302 临时重定向),nginx 流程结束,返回 http 响应到浏览器,页面 url 更新
flag 为空
发生 nginx 内部重定向,path 值被更新,rewrite 层面的命令继续。最后一个 rewrite 完毕,刷新控制流程,重新进行 location 重匹配
Nginx 处理请求的 11 个阶段
Nginx 处理请求的全过程一共划分为 11 个阶段(如图),按阶段由上到下依次执行 (上
一阶段的所有指令执行完毕,才进入下一阶段)
各阶段的含义如下:
post-read: 接收到完整的 http 头部后处理的阶段,在 uri 重写之前。一般跳过
server-rewrite: location 匹配前,修改 uri 的阶段,用于重定向,location 块外的重写指令
( 多次执行)
find-config: uri 寻找匹配的 location 块配置项( 多次执行)
rewrite: 找到 location 块后再修改 uri,location 级别的 uri 重写阶段( 多次执行)
post-rewrite: 防死循环,跳转到对应阶段
preaccess: 权限预处理
access: 判断是否允许这个请求进入
post-access: 向用户发送拒绝服务的错误码,用来响应上一阶段的拒绝
try-files: 访问静态文件资源
content : 内容生成阶段,该阶段产生响应,并发送到客户端
log: 记录访问日志