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 就能稳稳跑起灰度。
