Nginx的if指令仅支持单条件判断，不可嵌套或使用&&/||，须配合rewrite实现条件重写；推荐优先用map预计算变量或应用层处理，避免隐式location导致proxy_pass失效等风险。
Nginx 的 if 指令可以配合 rewrite 实现带条件的重写，但需特别注意：它只在 server 和 location 上下文中可用，且行为有诸多限制和陷阱。不推荐用 if 做复杂逻辑判断，优先考虑 map 或应用层处理；若必须用，务必理解其执行时机和副作用。
if 的基本语法和可判断变量
if 只支持简单比较（=、!=、~（区分大小写正则）、~*（不区分大小写）、!~、!~*），不能嵌套，也不能用布尔运算符（如 &&、||）。常用判断对象包括：
-
$args：请求参数字符串（如a=1&b=2） -
$request_uri：原始 URI（含参数，如/path?x=1） -
$uri：解码后的路径部分（不含参数，如/path） -
$http_user_agent、$http_referer等请求头 -
$scheme、$host、$remote_addr等内置变量
常见 if + rewrite 场景示例
以下写法合法且较常用，但每条 if 都会触发一次配置重解析，影响性能：
- 强制 HTTPS 跳转：
if ($scheme = http) { rewrite ^(.*)$ https://$host$1 permanent; } - 屏蔽恶意 User-Agent：
if ($http_user_agent ~* "sqlmap|nikto|wget") { return 403; } - 根据参数重写路径：
if ($args ~* "^id=([0-9]+)$") { rewrite ^/article\.php$ /article/$1? last; } - 阻止访问特定后缀文件：
if ($uri ~* \.(bak|conf|ini|log|sh)$) { return 404; }
if 的关键限制与危险行为
if 在 location 中执行时，内部会隐式创建一个“伪 location”，导致部分指令（如 root、proxy_pass）失效或行为异常。典型问题包括：
-
rewrite ... last后，不会重新匹配外层 location，而是进入新生成的内部上下文，可能丢失proxy_set_header等设置 -
if中使用rewrite+break时，URI 不再参与后续 location 匹配，容易造成静态资源 404 - 多个
if并列时，彼此独立执行，无法组合条件（例如不能写 “当 A 且 B 时”） - 正则捕获变量（如
$1）仅在当前if块内有效，不能跨 if 使用
更安全的替代方案
对稍复杂的逻辑，应避开 if：
- 用
map提前计算结果（支持正则、多条件映射、默认值），再在server或location中引用变量：map $args $new_path { ~*^id=(\d+) /article/$1; default /404; }，然后rewrite ^/old$ $new_path last; - 将路由逻辑下沉到后端（如 PHP/Node.js），Nginx 只做基础转发
- 用
try_files替代简单存在性判断：try_files $uri $uri/ /index.php?$args; - 需要多条件组合时，改用 OpenResty 的 Lua 脚本（
access_by_lua_block）
if 不是万能开关，它像一把钝刀——能砍，但容易伤手。真正健壮的重写规则，靠的是合理分层：用 map 处理变量映射，用 location 划分资源类型，把业务逻辑交给应用。Nginx 的强项是高效转发，不是流程控制。
