ngx_http_random_index_module仅随机选取目录下文件作索引页，不支持请求头/参数匹配、upstream分流、cache_key差异化或反向代理逻辑，故无法用于灰度测试或多套缓存模板路由。
ngx_http_random_index_module 并不适用于灰度测试，也不能实现“多套缓存模板”的路由或分流逻辑。
这个模块的功能非常单一：在 location 中启用后，它会在指定目录下**随机选取一个文件作为索引页**（类似 index index.html; 的增强版），仅用于静态文件服务场景，比如随机展示某个 HTML 欢迎页。它不参与请求转发、不读取请求头/参数、不支持条件判断、不涉及缓存控制，更无法与网关层的灰度策略（如按用户 ID、Header、Cookie、权重等分流）产生任何关联。
为什么不能用于灰度测试？
灰度发布/测试的核心是「可控分流」，而该模块完全不具备以下能力：
- 无法根据 HTTP 请求头（如
X-Canary: true）、Cookie 或查询参数做匹配 - 不支持 upstream 分组、proxy_pass 动态选择或缓存键（cache_key）差异化生成
- 不介入反向代理流程，只影响
index文件的本地路径解析 - 与 Nginx 的缓存机制（
proxy_cache）无集成，更谈不上“多套缓存模板”
真正适合网关层灰度的 Nginx 方案
若需在 Nginx 网关实现基于缓存模板的灰度（例如：新旧两套渲染逻辑，对应不同缓存策略和内容），应组合使用以下标准模块：
-
map 指令：提取灰度标识（如
$http_x_version或$arg_v），映射为缓存分区名或 upstream 名 -
proxy_cache_key：在 key 中加入灰度维度（如
$cache_key_$version），使不同版本走不同缓存槽位 - upstream + proxy_pass：按 map 结果将请求分发到不同后端集群（v1-api / v2-api）
- （可选）split_clients：实现按用户 ID 哈希的百分比灰度，适合无标识流量
示例片段：
map $http_x_canary $cache_version {
"v2" "v2";
default "v1";
}
proxy_cache_key "$scheme$request_method$host$request_uri$cache_version";
upstream backend_v1 { server 10.0.1.10:8080; }
upstream backend_v2 { server 10.0.1.20:8080; }
map $http_x_canary $upstream_backend {
"v2" backend_v2;
default backend_v1;
}
location / {
proxy_pass http://$upstream_backend;
proxy_cache my_cache;
}
如果目标是“多套静态模板缓存”，该怎么做？
假设你有一组预渲染的 HTML 页面（/templates/v1/, /templates/v2/），想按灰度规则返回不同版本：
- 用
map判断灰度标识，设置root路径变量（如$template_root） - 用
try_files或alias结合变量定位文件（Nginx 1.19+ 支持变量在root中） - 配合
add_header X-Cache-Version $cache_version;便于前端或监控识别
注意：这仍是静态内容分发，不是动态模板渲染；真正的“缓存模板”通常属于应用层（如 SSR 框架）或 CDN 配置范畴，Nginx 层只负责路由与缓存隔离。
