把域名放进一个数组、用随机函数取一个下标、再通过前端 location.href 或后端 302 响应把用户送走。代码本身十分钟能写完，真正决定成败的是你对场景的判断分流、防封、A/B 测试,这三种需求对应的实现方式完全不同。
先弄清楚：随机跳转的三种真实场景
随机跳转不是炫技，它背后总有一个具体问题要解决，想清楚属于哪一类,代码才不会写歪。
多镜像站分流，降低单点压力
当站点部署了多个镜像域名，与其让用户手动挑选，不如在前端入口做一次随机分发，核心诉求是把流量摊平,让每个域名的带宽和并发都落在安全区间内。
电商活动页的多域名轮换防封
做投放的朋友最怕活动页被拦截，多准备几个备用域名，让脚本随机选一个落地，是相当一部分团队在用的兜底手段，这里要注意：轮换频率不能太高，否则用户收藏的链接会频繁失效,体验反而更差。
A/B 测试与灰度发布
把新老版本挂在不同域名上，随机把用户导向其中一组，这种做法比单纯在同一个域名下切流量更容易隔离数据,统计也更干净。
前端 JS 随机跳转域名的代码怎么写？可直接复制的三步实现
前端方案最轻，不需要服务器配合,一段脚本贴进页面就能跑。
基础版：数组加 Math.random
const pool = [ 'https://a.example.com', 'https://b.example.com', 'https://c.example.com' ]; const target = pool[Math.floor(Math.random() pool.length)]; window.location.replace(target);
用 replace 而不是 href，好处是不往浏览器历史里塞垃圾记录,用户按返回键不会又跳回来。
加权版：让主域名承接更多流量
均匀随机会把主站流量也稀释掉，多数情况下，你希望主域名拿五成、备用域名各拿两成半。
const pool = [
{ url: 'https://main.example.com', weight: 5 },
{ url: 'https://a.example.com', weight: 3 },
{ url: 'https://b.example.com', weight: 2 }
];
const total = pool.reduce((sum, item) => sum + item.weight, 0);
let r = Math.random() total;
for (const item of pool) {
r -= item.weight;
if (r <= 0) {
window.location.replace(item.url);
break;
}
}
权重调整只需要改数字，不用动逻辑,后续运维成本很低。
加一层存活探测，避免把用户送到挂掉的域名
随机最大的问题是不可控，如果池子里有个域名已经挂了，照样有概率把用户送过去,稳妥的做法是跳转前先探测一次。
function ping(url) {
return new Promise((resolve, reject) => {
const img = new Image();
const timer = setTimeout(() => reject(), 1500);
img.onload = () => { clearTimeout(timer); resolve(url); };
img.onerror = () => { clearTimeout(timer); reject(); };
img.src = url + '/favicon.ico?_=' + Date.now();
});
}
注意 fetch 配 no-cors 拿不到状态码，只能判断请求是否发出，所以用图片或 favicon 做探测更实在，这个细节不少教程会略过,实际用起来会踩坑。
服务端 302 随机重定向和前端跳转的对比：哪种更适合你的站点
这是被问得最多的一个问题，两种方式都能实现跳转,但代价不一样。
| 对比维度 | 前端 JS 跳转 | 服务端 302 重定向 |
|---|---|---|
| 首屏速度 | 多一次执行，略慢 | 浏览器直接收响应，更快 |
| 搜索引擎处理 | 部分爬虫不执行 JS | 标准 HTTP 语义，可识别 |
| 用户禁用 JS | 直接失效 | 不受影响 |
| 日志与统计 | 依赖前端埋点 | 服务端日志完整 |
| 缓存风险 | 较低 | 302 可能被中间层缓存 |
| 实现成本 | 几乎为零 | 需要服务器或边缘计算 |
行业共识认为，面向搜索引擎的站点优先用服务端 302，因为按照搜索引擎公开的站长指南，302 属于临时跳转，权重仍归原地址，语义清晰，而纯活动页、内部工具页面用前端 JS 更灵活。
从 Nginx 到 Cloudflare Worker：几种服务端随机跳转的落地方式
Nginx 加 Lua 模块，按权重随机跳转
location /jump {
content_by_lua_block {
local pool = {
"https://main.example.com",
"https://a.example.com",
"https://b.example.com"
}
math.randomseed(ngx.now() 1000 + ngx.worker.pid())
local idx = math.random(1, #pool)
return ngx.redirect(pool[idx], 302)
}
}
关键在 math.randomseed，不重置种子的话，多个 worker 进程会产出相同的随机序列,跳转看起来就不随机了。
Cloudflare Worker 配置随机域名跳转的完整步骤
登录控制台，进入 Workers & Pages，创建新 Worker,粘贴以下代码并绑定路由：
export default {
async fetch(request) {
const pool = [
'https://a.example.com',
'https://b.example.com',
'https://c.example.com'
];
const url = new URL(request.url);
const target = pool[Math.floor(Math.random() pool.length)];
return Response.redirect(target + url.pathname + url.search, 302);
}
}
记得把 pathname 和 search 一起带过去，否则用户进入内页会直接掉回首页,这是新手最常见的一处疏漏。
PHP 和 Node.js 的两行写法
<?php
$pool = ['https://a.example.com', 'https://b.example.com'];
header('Location: ' . $pool[array_rand($pool)], true, 302);
exit;
app.get('/go', (req, res) => {
const pool = ['https://a.example.com', 'https://b.example.com'];
res.redirect(302, pool[Math.floor(Math.random() pool.length)]);
});
面向海外用户时，节点放在香港还是新加坡
跨境业务的团队常纠结这个，判断标准很简单：看你的目标用户在哪里，面向东南亚选新加坡，面向日韩和港澳台选香港，纯看物理距离和网络绕行情况，用 Cloudflare 这类边缘网络时节点会自动就近，但国内访问速度仍受回国线路影响,需要实测。
至于服务器成本，纯前端方案几乎不花钱；走服务端的话，Cloudflare 免费额度对中小流量足够，国内云厂商的轻量应用服务器一般在一年几百到一千多元区间，具体取决于带宽和配置,近年来价格波动不大。
踩坑清单与合规红线
代码跑起来只是开始,这些问题不处理迟早会出状况。
- 跨域登录态丢失：随机跳转到不同域名，Cookie 不共享，用户会莫名其妙退出登录，要么统一走主域名的 SSO,要么把登录态放在顶级域。
- HTTPS 证书：池子里任何一个域名证书过期，跳过去就是一片红,证书到期监控必须做。
- 302 被缓存：部分 CDN 和代理会缓存 302，导致用户永远落在同一个域名，响应头加上
Cache-Control: no-store。 - 随机种子固定：Lua、Python 等语言默认种子可能不变,务必用时间戳初始化。
- 合规底线：随机跳转本身是中性技术，但用于跳转劫持、诱导下载、规避监管就属于违规，据工信部相关通报，域名跳转劫持一直是整治重点，务必确保跳转目标全部可追溯、内容合法。
围绕如何实现跳转到随机域名的代码，几个高频疑问
随机跳转会被搜索引擎判成作弊吗？
取决于跳转目标和跳转方式，如果所有域名内容一致、只是镜像分流，用 302 是合规做法；如果跳转到内容完全不同的站点，尤其是低质页面，就容易被判定为作弊，搜索引擎关注的是跳转前后的内容相关性,不是跳转动作本身。
跳转后用户登录状态丢了怎么办？
本质是 Cookie 的作用域问题，方案有三个：把登录态写在顶级域名的 Cookie 上，让子域共享；用统一的认证中心做 SSO 跳转；或者把 token 放在 URL 参数里传递后立即写入本地存储，第二种最稳,代价是需要改造认证流程。
这套东西自己写还是买现成的服务划算？
看规模和频率，日跳转量在几千次以内，自己写几十行代码完全够用，成本接近零；量级上来以后要考虑可用性探测、权重调度、实时日志，这时候现成的流量调度服务反而更省心，据业内经验，大多数中小站点在前端方案阶段就够用了,不需要提前上复杂架构。
随机跳转域名的代码短小，但真正决定效果的是域名池的维护、存活探测和跳转语义的选择。先把场景想清楚，再决定用前端还是 302,比急着复制代码更重要。