Nginx中应避免在location内用if+proxy_pass实现条件转发，因其为伪指令且作用域受限；正确做法是优先用map提前生成变量，再在location中安全调用proxy_pass或rewrite，仅允许if内使用rewrite、set、return、break等安全指令。
在 Nginx 中，rewrite 本身不支持嵌套或复杂逻辑判断，但可以结合 if 指令实现带条件的重写与转发。不过要注意：if 在 location 块中行为受限，且有隐式限制（如不能嵌套、部分变量不可用），需谨慎设计逻辑顺序和作用域。
理解 if + rewrite 的基本协作机制
if 是一个“上下文敏感”的指令，只在 server 和 location 块中有效；它内部可执行 rewrite、set、return 等有限指令。
关键点是：if 块中的 rewrite 默认为内部重写（无跳转），除非加 flag 如 redirect 或 permanent。若要实现“条件转发”，通常需配合 proxy_pass，而 rewrite 只负责路径改写 —— 真正的转发由后续的 proxy_pass 完成。
常见条件转发场景及写法
以下为典型实用模式（假设后端服务基于路径区分）：
-
按请求参数转发：如
/api?service=auth→ 转到 auth 服务
location /api {
if ($args ~* "service=auth") {
rewrite ^/api(.*)$ /$1 break;
proxy_pass http://auth_backend;
}
if ($args ~* "service=user") {
rewrite ^/api(.*)$ /$1 break;
proxy_pass http://user_backend;
}
} -
按请求头或 Cookie 分流：如灰度发布时识别特定 Cookie
if ($http_x_forwarded_for ~* "192\.168\.10\.5") {
proxy_pass http://new_backend;
break;
}
if ($cookie_version = "v2") {
proxy_pass http://new_backend;
break;
}
proxy_pass http://old_backend;（注意：多个 if 并列时，按顺序匹配，第一个满足即执行并跳出） -
组合条件（用变量中转）：if 不支持 and/or，可用 set 预判
set $upstream "";
if ($host ~* "^beta\.example\.com$") { set $upstream "beta"; }
if ($request_uri ~* "^/admin/") { set $upstream "${upstream}admin"; }
if ($upstream = "betaadmin") {
proxy_pass http://beta_admin;
break;
}
必须避开的坑
if 是“伪指令”，不是编程语言的 if” —— 它在配置加载阶段编译为检查序列，不支持逻辑运算符、嵌套、多条件连写（如 if (A && B) 无效）。常见误用包括：
- 在 if 中使用
proxy_pass后还写 rewrite：proxy_pass 会忽略后续 rewrite，且 location 匹配已结束 - 依赖未初始化变量（如 $arg_xxx 在非 querystring 请求中为空，但 if 判空不一定如预期）
- 用 if 控制 cache 或 header：应优先用 map 指令替代，更高效安全
- rewrite 后没加
break导致循环重写（尤其在 root 或 alias 下）
更健壮的替代方案推荐
对真正复杂的路由逻辑，建议降级使用：
• map 指令预定义变量：适合基于 host、uri、header 的单维度映射，性能高、语法清晰
• 多个 location + 正则匹配：Nginx 原生支持 PCRE，比 if 更可靠（如 location ~ ^/v2/(.*)$ { proxy_pass http://v2/$1; }）
• OpenResty + Lua：需要动态逻辑时，Lua 可完整控制转发流程，但增加运维成本
