nginx金丝雀发布本质是按规则将流量分发至不同版本后端，核心策略包括：1.基于upstream权重渐进放量；2.基于cookie/header实现用户级灰度；3.结合k8s ingress或nginxconfig.io声明式配置，并需配套监控告警与秒级回滚机制。

用 Nginx 做金丝雀发布，本质是靠它把请求按规则分发到不同版本的后端服务上，不是简单轮询或随机转发，而是有策略地“试新、控量、可退”。关键不在装多少模块，而在配置怎么写、规则怎么设、出问题怎么切。

基于 upstream 权重的渐进式放量

适合刚起步、想快速验证新版本稳定性的场景。核心是给不同版本的服务组设置权重，让 Nginx 按比例分发请求。

• 定义两个 upstream：一个指向老版本（如 app-stable），一个指向新版本（如 app-canary）
• 在 upstream 块里用 weight 参数控制比例，比如 weight=95 和 weight=5 就是 95% 老版、5% 新版
• 注意：这种方案不保证用户粘性，同一用户可能连续两次请求落到不同版本，导致状态不一致或样式跳变

基于 Cookie 或 Header 的用户级灰度

解决权重法“用户飘移”的问题，让指定用户始终访问新版本，适合功能验证、AB 测试或定向邀请内测。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 用 map 指令提取请求中的 Cookie（如 canary=1）或 Header（如 X-Canary: true）
• 根据提取结果设置变量（如 $backend），再在 proxy_pass 中引用该变量，动态选择 upstream
• 业务侧可主动在登录或埋点时写入灰度标识，运维无需改代码就能控制灰度人群

结合 nginxconfig.io 或 Ingress 的声明式配置

如果你用 Kubernetes，Nginx Ingress Controller 提供了更简洁的声明式支持；如果手动管理 Nginx，nginxconfig.io 这类工具能帮你生成结构清晰、不易出错的配置。

• K8s 场景下，需创建两个 Ingress：一个常规（指向旧版），一个带 nginx.ingress.kubernetes.io/canary: "true" 注解（指向新版）
• 再配合 canary-by-header、canary-by-cookie 或 canary-weight 等注解，实现策略绑定
• nginxconfig.io 则通过可视化表单生成含 upstream、map、split_clients 的完整配置，降低手写门槛

上线后必须做的三件事

配置生效只是开始，真正保障金丝雀效果的是观察和响应机制。

• 监控新版本的关键指标：错误率、延迟 P95、CPU/内存使用率，和老版本做横向对比
• 设置告警阈值，比如新版本 5xx 错误率超过 0.5% 或延迟翻倍，就触发人工介入
• 保留一键回滚能力：要么把新版本 upstream 从配置中临时注释掉并重载，要么把权重调回 0，整个过程秒级完成