apache需通过mod_proxy、mod_proxy_http和mod_rewrite组合实现灰度发布：先识别请求特征（header/cookie/uid），再显式代理至对应后端；必须启用三模块，配置中rewrite规则须在proxypass前，支持基于header、cookie及uid哈希的分流策略。
apache 本身不内置灰度发布引擎，但用 mod_proxy + mod_rewrite 组合就能实现轻量、可靠、热更新的灰度流量分发。核心逻辑是：先识别请求特征（如 header、cookie、uid），再显式代理到对应后端，而不是依赖 balancer 自动轮询。
必须启用的核心模块
缺一不可，否则规则不生效或代理失败：
- mod_proxy：提供反向代理基础能力
- mod_proxy_http：支持 HTTP 协议后端转发
- mod_rewrite：用于提取请求头、匹配条件、触发代理
检查方式：httpd -M | grep -E "(proxy|rewrite)"。若缺失，需在配置中补全加载语句，例如：
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule rewrite_module modules/mod_rewrite.so
基于请求头的灰度路由（最常用）
适合人工触发、环境标识驱动的场景，比如测试人员加 X-Release-Stage: canary 头即可走灰度服务：
- 规则必须写在
ProxyPass之前，否则会被默认代理覆盖 -
[NC]忽略大小写，兼容canary/Canary/CANARY -
[P]表示交由 mod_proxy 处理，[L]终止后续规则
示例配置：
RewriteEngine On
RewriteCond %{HTTP:X-Release-Stage} ^canary$ [NC]
RewriteRule ^/(.*)$ http://canary-backend:8080/ [P,L]
ProxyPass / http://stable-backend:8080/
ProxyPassReverse / http://stable-backend:8080/
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
基于 Cookie 的用户级灰度
适合 AB 测试或白名单控制，要求前端已写入如 gray=v2 这类标识：
- 不能用
[CO]标志写 Cookie 来做判断，得用%{HTTP_COOKIE}提取已有值 - 用
[E=GRAY_VERSION:%1]将匹配结果存入环境变量，供后续规则复用 - 避免重复解析，提升性能和可读性
示例片段：
RewriteCond %{HTTP_COOKIE} (?:^|;\s*)gray=(v2|canary)(?:;|$)
RewriteRule ^ - [E=GRAY_VERSION:%1]
RewriteCond %{ENV:GRAY_VERSION} =v2
RewriteRule ^/api/(.*)$ http://v2-backend:8080/api/$1 [P,L]
用 UID 哈希做固定比例分流
确保同一用户始终走同一版本，适合需要会话一致性的灰度验证：
- 从 Header 或 Cookie 提取 UID，例如：
RewriteCond %{HTTP:X-User-ID} ^(\d+)$ - 用
SetEnvIf或 Apache 2.4.13+ 的expr取末两位作为槽位：UID_SLOT=${substr($1,-2)} - 用
<if></if>判断范围，比如<if></if>实现 10% 分流
未匹配请求自然走默认 ProxyPass，无需额外 fallback 配置。
