如何通过Apache mod_rewrite的Cookie标志位实现灰度发布配置的详细步骤？

本文共计999个文字，预计阅读时间需要4分钟。

很多人误以为给请求添加一个+Cookie+就能依赖它做灰度分流，但实际上它只负责在响应头中设置+Set-Cookie+，并不读取、验证或参与后续规则匹配。灰度发布真正依赖的是基于已有+Cookie+做条件判断，而不是写一个新的+Cookie+就完事。

典型错误是这样写：

RewriteRule ^/api/.*$ /api-v2/ [CO=gray:1:example.com:86400:/]

这只会每次响应都塞一个 gray=1，但完全没用——因为下一次请求是否走 v2，得看有没有这个 Cookie，而这里没配 RewriteCond 去检查它。

如何用 RewriteCond + %{HTTP_COOKIE} 识别灰度用户

灰度逻辑必须从「读取 Cookie」开始，再结合正则匹配值，最后决定重写目标。关键不是写 Cookie，而是读它、信它、用它。

• RewriteCond %{HTTP_COOKIE} gray=1：匹配任意位置含 gray=1 的 Cookie 字符串（注意：不区分字段边界，gray=123 也会命中）
• 更安全的写法：RewriteCond %{HTTP_COOKIE} (?:^|;\s*)gray=1(?:;|$)，用非捕获组和边界断言避免子串误匹配
• 若需多值支持（如 gray=v2 或 gray=canary），正则改用 gray=(v2|canary)，并在 RewriteRule 中用 %1 引用分组
• Cookie 值建议由前端或登录服务统一注入，Apache 不生成也不验证签名，所以务必确保上游可信

如何组合 [E] 和 %{ENV:...} 实现跨规则复用灰度状态

单条 RewriteRule 无法把 Cookie 判断结果“传递”到后续规则中；如果多个路径都要根据同一灰度状态路由，重复写 RewriteCond 易出错且难维护。这时该用环境变量中转。

示例：把灰度标识存入环境变量，后续所有规则都可直接引用

RewriteCond %{HTTP_COOKIE} (?:^|;\s*)gray=(v2|canary)(?:;|$) RewriteRule ^ - [E=GRAY_VERSION:%1] <p>RewriteCond %{ENV:GRAY_VERSION} =v2 RewriteRule ^/api/(.*)$ /api-v2/$1 [L]</p><p>RewriteCond %{ENV:GRAY_VERSION} =canary RewriteRule ^/api/(.*)$ /api-canary/$1 [L]

注意：[E] 必须配合 ^ -（即空替换）才能只设变量不改 URL；[L] 防止后续规则干扰；=v2 是字符串精确匹配语法，比正则更高效。

Cookie 域名、路径与 HTTPS 安全标志的实际影响

灰度 Cookie 若配置不当，会导致浏览器不携带、Apache 读不到，整个链路就断了。这不是规则写错，而是部署细节失效。

• [CO] 设置 Cookie 时，域名必须匹配请求 Host，否则浏览器拒绝存储；例如请求是 app.example.com，却设 CO=gray:1:example.com，多数现代浏览器会忽略
• 路径参数（第 4 个）要覆盖所有需灰度的入口，比如设为 / 而非 /api/，否则静态资源请求带不上 Cookie
• 生产环境必须加 Secure 和 HttpOnly 标志，对应 [CO] 的第 5、6 位：如 [CO=gray:v2:app.example.com:86400:/:Secure:HttpOnly]
• 若后端服务依赖 Cookie 值做鉴权或埋点，HttpOnly 会阻止 JS 读取——这反而是好事，避免前端篡改灰度标识

灰度发布最易被忽略的，其实是 Cookie 的生命周期管理：没有自动过期机制，也没有服务端校验逻辑，一旦用户长期不清理 Cookie，就会永远卡在旧版本里。上线灰度策略前，得先想好怎么退、怎么清、谁来触发。