Nginx 中 Rewrite 规则如何使用 if 条件判断实现复杂的重写逻辑

Nginx的if指令仅支持单条件判断，不可嵌套或使用&&/||，须配合rewrite实现条件重写；推荐优先用map预计算变量或应用层处理，避免隐式location导致proxy_pass失效等风险。

Nginx 的 if 指令可以配合 rewrite 实现带条件的重写，但需特别注意：它只在 server 和 location 上下文中可用，且行为有诸多限制和陷阱。不推荐用 if 做复杂逻辑判断，优先考虑 map 或应用层处理；若必须用，务必理解其执行时机和副作用。

if 的基本语法和可判断变量

if 只支持简单比较（=、!=、~（区分大小写正则）、~*（不区分大小写）、!~、!~*），不能嵌套，也不能用布尔运算符（如 &&、||）。常用判断对象包括：

1. $args：请求参数字符串（如 a=1&b=2）
2. $request_uri：原始 URI（含参数，如 /path?x=1）
3. $uri：解码后的路径部分（不含参数，如 /path）
4. $http_user_agent、$http_referer 等请求头
5. $scheme、$host、$remote_addr 等内置变量

常见 if + rewrite 场景示例

以下写法合法且较常用，但每条 if 都会触发一次配置重解析，影响性能：

1. 强制 HTTPS 跳转：

   if ($scheme = http) { rewrite ^(.*)$ https://$host$1 permanent; }

2. 屏蔽恶意 User-Agent：

   if ($http_user_agent ~* "sqlmap|nikto|wget") { return 403; }

3. 根据参数重写路径：

   if ($args ~* "^id=([0-9]+)$") { rewrite ^/article.php$ /article/$1? last; }

4. 阻止访问特定后缀文件：

   if ($uri ~* .(bak|conf|ini|log|sh)$) { return 404; }

if 的关键限制与危险行为

if 在 location 中执行时，内部会隐式创建一个“伪 location”，导致部分指令（如 root、proxy_pass）失效或行为异常。典型问题包括：

1. rewrite ... last 后，不会重新匹配外层 location，而是进入新生成的内部上下文，可能丢失 proxy_set_header 等设置
2. if 中使用 rewrite + break 时，URI 不再参与后续 location 匹配，容易造成静态资源 404
3. 多个 if 并列时，彼此独立执行，无法组合条件（例如不能写 “当 A 且 B 时”）
4. 正则捕获变量（如 $1）仅在当前 if 块内有效，不能跨 if 使用

更安全的替代方案

对稍复杂的逻辑，应避开 if：

1. 用 map 提前计算结果（支持正则、多条件映射、默认值），再在 server 或 location 中引用变量：

   map $args $new_path { ~*^id=(d+) /article/$1; default /404; }，然后 rewrite ^/old$ $new_path last;

2. 将路由逻辑下沉到后端（如 PHP/Node.js），Nginx 只做基础转发
3. 用 try_files 替代简单存在性判断：

   try_files $uri $uri/ /index.php?$args;

4. 需要多条件组合时，改用 OpenResty 的 Lua 脚本（access_by_lua_block）

if 不是万能开关，它像一把钝刀——能砍，但容易伤手。真正健壮的重写规则，靠的是合理分层：用 map 处理变量映射，用 location 划分资源类型，把业务逻辑交给应用。Nginx 的强项是高效转发，不是流程控制。