server块rewrite规则优先执行，作用于完整URI路径，语法为rewrite regex replacement [flag]；支持permanent、redirect、last、break等标志位，决定重定向或内部重匹配行为。
server 块里的 rewrite 规则会在请求进入该 server 时第一时间执行，优先级高于 location 匹配。它不依赖路径前缀，而是直接作用于整个请求 URI（不含协议和域名，但含查询参数前的路径部分），适合做全局性重写或跳转。
rewrite 在 server 块中的基本写法
语法固定为：rewrite regex replacement [flag];
-
regex 是 PCRE 正则，匹配的是请求 URI 路径（例如
/user/123中的/user/123，不含?id=1） -
replacement 可以是新路径、完整 URL（如
http://new.com/$1），支持用$1、$2引用捕获组 -
flag 决定后续行为：常用
permanent（301）、redirect（302）、last、break
server 块 rewrite 的执行时机与流程
它属于 Nginx 请求处理的第一阶段：
- 客户端请求到达后，先匹配 server（通过
server_name和端口） - 一旦命中，立即执行该 server 块中定义的所有 rewrite 指令（按书写顺序）
- 若 URI 被重写，且 flag 是
last或未指定，则 Nginx 会**重新发起一次内部请求**，再次走 server → location 匹配流程 - 若 flag 是
break，则重写后停止 rewrite 执行，也不触发重匹配，直接进入 location 处理 - 若 flag 是
permanent或redirect，则直接向客户端返回 301/302 响应，不进 location
常见实用场景与配置示例
适合在 server 层统一处理的逻辑：
-
强制 HTTPS 跳转：
rewrite ^(.*)$ https://$host$1 permanent;（配合listen 80使用） -
根路径重定向：
rewrite ^/$ /index.html last;，把访问/改为服务/index.html -
移除多余斜杠：
rewrite ^/(.*)//+(.*)$ /$1/$2 permanent;，避免重复// -
统一入口路由：
rewrite ^/api/(.*)$ /backend/$1 break;，再配合 location /backend 作反向代理
注意事项与易错点
server 块 rewrite 看似简单，但几个细节常导致预期外行为：
- 正则默认不匹配查询参数（
?key=val），需用$args或$request_uri显式处理 -
last和break都会终止当前 rewrite 指令链，但last触发重匹配，break不触发——这点直接影响静态文件能否被正确 serve - 多个 rewrite 连续写时，前一条改写的 URI 会作为下一条的输入，注意捕获组编号和路径变化
- 如果 server 块里同时有 if + rewrite，优先级低于纯 rewrite；且 if 块内 rewrite 的 flag 行为可能受限（不推荐嵌套 if 做重写）
