nginx的virtual host(server块)本身不直接实现灰度,而是作为灰度策略执行入口,通过map+proxy_pass、if+set、upstream权重或子域名分流等方式,在同一server内动态调度流量至不同后端,实现精准、可控、无侵入的灰度发布。

Nginx 中的 Virtual Host(即 server 块)本身不直接“做灰度”,但它可以作为灰度策略的执行入口——把灰度逻辑(如权重分流、Cookie/Header 匹配、IP 过滤等)写在 server 块内或其上游,就能让这个虚拟主机具备灰度能力。关键不是 Virtual Host 多少个,而是它如何调度流量到不同后端。
下面说几种在 server 块中落地灰度发布的常用方式,清晰实用:
1. 在 server 中用 map + proxy_pass 实现请求特征分流
适合按 Cookie、Header 或用户标识精准控制灰度人群。
- 必须把 map 写在 http 块顶层(不能嵌套在 server 里),例如识别灰度用户:
map $http_cookie $backend_group {
~*is_gray=1 "canary";
~*version=v2 "canary";
default "stable";
}
- 然后在 server 块中引用:
server {
listen 80;
server_name example.com;
<pre class="brush:php;toolbar:false;">location / {
proxy_pass http://$backend_group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}}
- 对应 upstream 要提前定义好:
upstream stable {
server 10.0.1.10:8080;
}
upstream canary {
server 10.0.1.20:8080;
}
2. 在 server 中用 if + set 控制简单规则(慎用,仅限基础场景)
比如只对某个测试 IP 开放新版本,或根据请求头临时切流。
- 示例:只让内网测试机走灰度后端
server {
listen 80;
server_name example.com;
<pre class="brush:php;toolbar:false;">set $backend "stable";
if ($remote_addr = "192.168.10.5") {
set $backend "canary";
}
location / {
proxy_pass http://$backend;
}}
- 注意:
if在 location 外可用,但避免复杂嵌套;Nginx 官方建议优先用 map 替代 if 做路由判断。
3. 在 server 中结合 upstream 权重做比例灰度
最轻量、无需用户标识,适合初期小流量验证。
- 直接在 upstream 里配权重,server 块只需 proxy_pass 到该 upstream:
upstream backend {
server v1.example.com weight=95; # 老版本占 95%
server v2.example.com weight=5; # 新版本占 5%
}
<p>server {
listen 80;
server_name example.com;</p><pre class="brush:php;toolbar:false;">location / {
proxy_pass http://backend;
}}
- 上线后可热 reload 配置,逐步调高新版本 weight(如 5→20→50→100),全程无感知。
4. 多 Virtual Host 分流(不推荐主流灰度,但有特定用途)
比如用不同子域名隔离灰度环境(gray.example.com → canary,www.example.com → stable),本质是 DNS 或前端控制,不是真正的“灰度发布”——它没实现同一入口下用户分层。
- 仅适用于内部试用、运营侧快速验证,不适合 A/B 测试或渐进式放量。
- 配置上就是两个独立 server 块,各自 proxy_pass 到不同 upstream,不共享流量池。
真正可靠的灰度,核心是 同一个 server 块 + 动态路由决策 + 可观测验证。Virtual Host 是载体,不是策略本身。只要逻辑写对、reload 生效、监控跟上,一个 server 就能稳稳跑起灰度。











