ngx_http_random_index_module仅用于单台Nginx本地目录中随机选HTML作索引页，不支持上游选择、模板集或版本化页面；实现多模板随机展示应采用upstream随机分发、路径rewrite或header注入等架构。
ngx_http_random_index_module 本身并不适用于负载均衡层的多套模板随机展示，它只是一个在单台 Nginx 服务器上、针对一个 location 中的静态目录，自动从其子文件中随机选取一个作为索引页（如 index.html）返回的模块。它不参与上游选择、不感知后端服务、也不支持“模板集”或“版本化页面”的语义。
该模块的真实用途和限制
这个模块仅在以下场景生效：
- 配置了 root 指令指向一个本地文件系统目录；
- 该目录下存在多个 HTML 文件（如
v1.html、v2.html、test.html）； - location 启用了 random_index on，且未指定具体 index 文件；
- 用户访问该 location 根路径（如
/）时，Nginx 随机选一个 HTML 返回——仅此而已。
它不会转发请求、不调用 upstream、不读取后端响应、也不支持 JS/CSS 资源的路径重写或模板上下文隔离。因此，它不能替代 A/B 测试网关、灰度路由或真正的前端模板分发逻辑。
想实现“多套模板随机展示”，应采用的合理架构
真正可行的方案是将“模板选择”逻辑前置到负载均衡层（如 Nginx），通过变量 + upstream + rewrite 或 subrequest 实现，而非依赖 random_index。常见做法包括：
-
基于 upstream 的随机分发：定义多个 backend server（每套模板部署在独立服务或路径），用
upstream { hash $remote_addr consistent; }或least_conn等策略间接实现近似随机；更直接的是用 Lua（OpenResty）或第三方模块（如nginx-upstream-random）做随机 upstream 选择； -
URL 路径映射 + rewrite：在入口 location 中生成随机数（需 Lua 或 map + $time_iso8601 等伪随机变量），再根据结果 rewrite 到不同模板路径（如
/template/v1/、/template/v2/），各路径对应不同 root 或 proxy_pass； -
Header 注入 + 后端识别：Nginx 在请求头中添加
X-Template-Version: v1（值由 map 或 Lua 随机生成），后端服务读取该 header 渲染对应模板；这种方式解耦更强，适合 SSR 或微前端场景。
如果坚持用纯 Nginx（无 Lua），一个轻量折中方案
可结合 map 和时间变量模拟随机性（非密码学安全，但对灰度/AB 场景够用）：
map $msec $tpl_ver {
~^[0-3] "v1";
~^[4-7] "v2";
default "v3";
}
server {
location / {
root /usr/share/nginx/html/$tpl_ver;
index index.html;
try_files $uri $uri/ =404;
}
}
这里利用毫秒级时间戳的首位数字分布近似均匀的特点，将请求按时间片分流到不同模板目录。虽非真随机，但在流量较大时效果接近，且无需额外模块。
为什么不推荐强行套用 random_index？
因为它的设计目标与需求错位：
- 它只处理 文件名列表，无法区分“模板逻辑”（如共用 API 但不同 UI）；
- 所有模板必须放在同一目录，易造成资源冲突（同名 CSS/JS 被覆盖）；
- 无法控制模板间的数据上下文、埋点标识或 CDN 缓存键；
- 一旦启用，所有子请求（如
/assets/main.js）仍走统一 root，无法按模板隔离静态资源。
真正需要多模板能力时，应把“模板”视为独立服务实例或明确的路由维度，而非文件系统的随机挑选。
