嘿，朋友们！今天咱们不聊Nginx那些老生常谈的反代、负载均衡。那些都是基本功，是个人都会配两下。今天，咱们要玩点硬的，聊点能让隔壁运维老哥对你刮目相看的东西——在Nginx模块里，把变量当成瑞士军刀，玩出各种骚操作。
你是不是一直觉得，Nginx变量不就是$host、$remote_addr这些玩意儿？在location里用set设置一下，顶天了做个字符串拼接？如果你这么想，那你可就把Nginx想简单了。它就像一个低调的武林高手，表面上只会几招广播体操，实则内功深厚，身怀绝世秘籍。
今天，我就带你扒掉Nginx的“伪装”，直击它最核心、最灵活，也最能体现你配置功力的地方：模块中的复杂变量使用。
第一章：热身运动——变量，不只是你想的那个“变量”
首先，咱们得统一思想。在Nginx的语境里，变量是啥？
你可以把它理解成一个标签，或者一个占位符。当Nginx处理请求时，它会动态地把这个标签替换成具体的值。比如$host代表客户端请求的主机名，$uri代表当前请求的URI。
这很简单，对吧？但“复杂”在哪呢？
- 变量有“内置”和“自定义”之分：内置变量是Nginx自带的“黑话”，比如
$args（请求参数）、$content_length。自定义变量则是你用set指令创造的“暗号”。 - 变量的值是“求值”出来的：它不是一成不变的。一个变量可能由其他变量计算、组合而来，这个过程可能发生在请求处理的不同阶段。
- 有些变量是“惰性”的：它很“拖延”，不到真正用它的时候，它绝不计算。这个特性是后面很多骚操作的基础。
来，看个入门级“复杂”例子，让你感受一下：
server {
listen 80;
server_name localhost;
location / {
set $name "Nginx大侠";
set $greeting "Hello, $name!"; # 变量里套变量
set $full_request "$request from $remote_addr"; # 拼接内置变量
add_header X-My-Greeting $greeting;
add_header X-Full-Request $full_request;
return 200 "看响应头哦！\n";
}
}
你用curl -I访问一下，就会在响应头里看到：
X-My-Greeting: Hello, Nginx大侠!
X-Full-Request: GET / HTTP/1.1 from 127.0.0.1
看，这已经不是简单的变量引用了，这是变量的初级魔法：插值与拼接。
第二章：潜入核心——模块是舞台，变量是演员
现在，舞台搭好了。Nginx的各个模块（如ngx_http_rewrite_module, ngx_http_map_module, ngx_http_core_module等）就是这个舞台。变量作为演员，在不同的模块指令下，表演着不同的戏法。
重头戏一：map 模块——打造你的“变量翻译官”
map指令绝对是复杂变量界的“万金油”。它允许你创建一个键值对映射。语法是：
map $源变量 $目标变量 { ... }
它就像一个翻译官，你告诉它一个词（源变量），它帮你查字典，返回对应的翻译（目标变量）。
高级玩法示例：根据User-Agent智能分配上游服务
假设你的网站有PC版和Mobile版，由不同的后端服务处理。你可以在http块里定义一个map：
http {
# 定义map，$http_user_agent是内置变量，代表客户端的User-Agent
map $http_user_agent $backend_site {
default "pc-backend"; # 默认值
~*mobile "mobile-backend"; # 如果User-Agent包含"mobile"（不区分大小写）
~*(android|iphone) "mobile-backend"; # 或者包含android/iphone
}
upstream pc-backend {
server 10.0.0.1:8080;
}
upstream mobile-backend {
server 10.0.0.2:8080;
}
server {
listen 80;
location / {
# 神奇的事情发生了！$backend_site变量会根据User-Agent自动变成"pc-backend"或"mobile-backend"
proxy_pass http://$backend_site;
}
}
}
看到了吗？我们没有写任何if判断，仅仅通过map定义了一个复杂的变量$backend_site，就在proxy_pass中实现了智能路由。这比写一堆if语句优雅、高效得多！
重头戏二：if语境下的“危险”舞步
if是实现条件逻辑的利器，但在Nginx里它也是个“著名的坏家伙”。因为它的行为有时很反直觉，而且在某些阶段下使用会有性能问题甚至bug。
不过，在变量赋值和判断上，它依然有其一席之地。我们只要清楚它的“雷区”即可。
示例：实现一个简单的访问开关
location /admin {
set $maintenance_mode "0"; # 默认不开维护模式
# 假设我们有一个特定的请求头来触发维护模式
if ($http_x_enable_maintenance = "secret123") {
set $maintenance_mode "1";
}
# 如果处于维护模式，返回503
if ($maintenance_mode = "1") {
return 503 "Service Under Maintenance, Please try again later.";
}
# 正常情况下的代理
proxy_pass http://backend;
}
这里，我们创建了一个自定义变量$maintenance_mode，并在if语境下修改它。这展示了如何通过变量在请求处理流程中传递状态信息。
警告：if最坑的地方在于它有时会发起一个内部子请求，尤其是在try_files和rewrite的上下文中。所以，除非你很清楚后果，否则不要在location里随意使用if做复杂的重写。
第三章：究极进化——完整示例：打造一个“智能动态代理”
理论说再多都是纸上谈兵，现在我们来搞个真家伙。我们的目标是：一个能根据请求参数、路径和IP，动态决定代理目标和改写URI的Nginx配置。
需求场景：
- 请求
/api/v1/user/<user_id>/profile，代理到user-service:8080，并将URI重写为/user/<user_id>。 - 请求
/api/v1/order/<order_id>，且来源IP是内网（10.0.0.0/8），代理到order-service-internal:8081。 - 请求
/api/v1/order/<order_id>，且来源IP是外网，代理到order-service-external:8082，并且URI需要加上/public前缀。 - 其他
/api/v1/开头的请求，默认代理到default-backend:8080。
这需求，够复杂了吧？用传统配置得写吐。但用我们今天学的复杂变量，可以轻松搞定！
完整配置代码：
http {
# 定义内网IP判断的map
map $remote_addr $is_internal {
default 0;
~^10\. 1; # 简单匹配10.x.x.x
# 可以继续添加其他内网网段...
}
# 定义一级路径路由的map
map $uri $api_service {
default "default-backend";
~^/api/v1/user/ "user-service";
~^/api/v1/order/ "order-service"; # 先匹配到order，具体内外网逻辑后面再细拆
~^/api/v1/product/ "product-service";
}
upstream user-service {
server user-service:8080;
}
upstream order-service-internal {
server order-service-internal:8081;
}
upstream order-service-external {
server order-service-external:8082;
}
upstream default-backend {
server default-backend:8080;
}
upstream product-service {
server product-service:8080;
}
server {
listen 80;
server_name api.myawesome.com;
location /api/v1/ {
# 1. 根据一级路径，先确定一个大方向的服务
set $target_upstream $api_service;
# 2. 特殊处理order服务：根据内外网IP进行细分
if ($api_service = "order-service") {
# 利用之前map定义的$is_internal变量
if ($is_internal) {
set $target_upstream "order-service-internal";
}
if (!$is_internal) {
set $target_upstream "order-service-external";
}
}
# 3. 动态URI重写逻辑
# 先初始化一个变量，保持原始URI
set $rewritten_uri $uri;
# 处理user服务的URI重写： /api/v1/user/123/profile -> /user/123
if ($api_service = "user-service") {
# 使用正则表达式捕获组，并赋值给变量
# 这个重写操作发生在if语境中，需要小心
if ($uri ~ "^/api/v1/user/([0-9]+)/profile$") {
set $user_id $1; # $1是前面正则捕获到的user_id
set $rewritten_uri /user/$user_id;
}
}
# 处理外网order服务的URI重写： /api/v1/order/456 -> /public/order/456
if ($target_upstream = "order-service-external") {
set $rewritten_uri /public$uri;
}
# 4. 最终代理传递
proxy_pass http://$target_upstream$rewritten_uri;
# 为了方便调试，可以加一些响应头看看变量的值
add_header X-Debug-Upstream $target_upstream always;
add_header X-Debug-Rewritten-Uri $rewritten_uri always;
add_header X-Debug-Internal $is_internal always;
}
}
}
让我们来拆解这个“魔法”：
- 第一层过滤（
map $uri $api_service）：我们用map对请求URI进行初步分类，生成$api_service变量。这步像是一个粗筛子，把请求分到几个大篮子里。 - 第二层细化（
if判断）：对于order-service这个篮子，我们觉得还不够细，于是用if结合$is_internal变量（它本身也是另一个map的产物！），把篮子里的东西再分成“内网订单”和“外网订单”。 - 动态URI构建（
set $rewritten_uri）：这是最秀的部分！我们创建了一个$rewritten_uri变量，并根据不同的服务类型，动态地修改它。
-
- 对于
user-service，我们用正则捕获了user_id，然后拼装出了全新的URI。 - 对于外网的
order-service，我们只是在原URI前加了个/public前缀。
- 对于
- 最终汇合（
proxy_pass）：最后，我们把计算好的$target_upstream和$rewritten_uri变量，拼接到proxy_pass指令中。http://$target_upstream$rewritten_uri这个字符串，在最终执行的时刻，才被“求值”成真正的代理地址。
整个过程，就像是在编写一个微型的、专属于Nginx的脚本程序。变量在其中充当了数据载体和逻辑纽带的角色。
第四章：心法与避坑——从“会用”到“精通”
玩转了上面的示例，你已经是个高手了。但高手更要懂得“避坑”。这里送你几条心法：
- 变量的作用域：在
server块里set的变量，在整个server内都有效。在location里set的，通常只在这个location及其嵌套的location中有效。 - 求值的时机与惰性：牢记Nginx变量的“惰性求值”。
set $a $b;只是记录了“$a的值等于$b的值”这个关系，并不会立即计算。只有当$a被用在proxy_pass，add_header等指令中时，才会去查询$b当时的值。这解释了为什么变量能如此动态。 - 性能考量：
map定义的变量虽然好用，但它的匹配是在运行时进行的。如果一个map有非常非常多的键值对，可能会对性能有细微影响。通常不用担心，但对于极致性能场景，要心中有数。 - 少用
if：重申一遍，除了我们演示的这种简单的变量设置和判断，尽量不要在location里用if做复杂的重写，那是rewrite ... last指令的战场。
结语：你的Nginx，从此不一样
好了，旅程到此结束。现在回头看看，是不是觉得Nginx变量不再是那个傻白甜了？它是一套藏在配置文件下的、灵活而强大的编程模型。
从简单的字符串拼接，到map实现的智能路由，再到融合了多种变量和条件判断的动态代理，你手中的Nginx已经完成了一次进化。它不再是一个冰冷的、只能按部就班的流量转发器，而是一个能理解你业务逻辑、能根据复杂条件做出决策的智能网关。
下次当你的产品经理又提出“这个功能能不能在Nginx层帮我们判断一下……”的时候，你可以自信地推一推并不存在的眼镜，嘴角露出一丝微笑：
“没问题，给我几个变量，还你一个奇迹。”
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
