ShortPro 域名管理与 PWA 分流方案

版本 v1.0
日期 2026-05-14
状态 设计草案,待评审
适用范围 ShortPro 印尼市场 Web/PWA 端

0. 文档目的

为 ShortPro 印尼业务设计一套抗封锁、可持续运营的域名与 PWA 分发架构。在 Kominfo 周期性封域名的现实下,实现:

• 已安装用户:任意单一域名被封不丢失访问能力
• 新增用户:任意时刻都有可用的安装入口
• 运营团队:对域名健康度有完整可观测性,域名封禁从"事故"变成"KPI 可控的运营动作"

1. 设计原则

1. 三层域名彻底解耦:发现 / 安装 / 数据各自独立,任一层失效不传染至其他层
2. 用户确定性分桶:hash(device_id) % N 把用户均匀分布到多个安装域名,单域被封只影响一个桶(N 分之一用户)
3. 基础设施多样化:注册商、DNS、IP 段、TLS 证书、CDN、Server 指纹全部分散,避免被批量识别封禁
4. 时间换迁移:Service Worker 缓存让被封域名上的 PWA 继续可用数周到数月,用这段时间通过召回机制平滑迁移用户
5. 离线优先:app shell 必须 precache,PWA 启动不依赖任何网络请求
6. 召回机制 Day 1 建好:不能等域名被封了才想怎么联系用户

2. 整体架构

┌─────────────────────────────────────────────────────────────────┐
│  推广渠道:WhatsApp / TikTok / KOL / TG Channel / 短链          │
└────────────────────────────┬────────────────────────────────────┘
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  第一层:分发域名池(Discovery)                                  │
│  spro.id / sp1.app / getshort.app / ...                         │
│  作用:动态告诉用户去哪个安装域名                                 │
│  特性:静态 JS / JSON 配置,几乎无业务逻辑,易替换                 │
└────────────────────────────┬────────────────────────────────────┘
                             ▼
                  hash(device_id) % N
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  第二层:安装域名池(Install)                                    │
│  dramaku-app.com / nontonpro.app / kisahdrama.net / ...         │
│  作用:PWA 真正的安装来源,manifest scope 绑定                    │
│  特性:用户加桌面后图标绑死此域名                                 │
└────────────────────────────┬────────────────────────────────────┘
                             ▼
                Service Worker 接管所有请求
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  第三层:API / 资源域名池                                        │
│  api-1.xxx / api-2.xxx(接口)                                   │
│  cdn-1.xxx / cdn-2.xxx(视频/图片)                              │
│  作用:App 内所有数据请求的目的地                                 │
│  特性:与安装域名解耦,优先级轮询 + 故障自动 fallback             │
└─────────────────────────────────────────────────────────────────┘

3. 域名架构详述

3.1 第一层:分发域名(Discovery Pool)

备份发现路径(防分发域名也被封):

• Telegram Channel bio(@shortpro_id)永远写最新分发域名
• GitHub Gist 公开 JSON(gist.github.com/shortpro/domains.json)
• Pastebin / Hastebin 备份
• bit.ly / lnk.bio 短链指向当前活跃分发域名

这些托管平台属于 Google / Microsoft / Cloudflare 基建,印尼几乎不会单独封禁。

3.2 第二层:安装域名(Install Pool)

命名示例(故意不规律):

dramaku-app.com
nontonpro.app
kisahdrama.net
layardrama.com
ceritamu.app
serial-malam.id
filmwiks.co
tontonan.app

关键约束:

• 每个域名跑的是同一份代码,但 manifest 的 start_url 和 scope 各自指向自己
• PWA 一旦"加到主屏幕",桌面图标和此 origin 绑死(浏览器硬规则,无法绕开)
• 这意味着:用户从 dramaku-app.com 装的 PWA,桌面图标永远打开 dramaku-app.com

3.3 第三层:API / 资源域名(API Pool)

这是整套架构最关键的一层——它决定了"装在桌面上的 App 在安装域名被封后能不能继续用"。

与安装域名彻底解耦的设计要点:

1. PWA 代码里 不写死任何 API URL,基础 URL 从 IndexedDB 读
2. 首次启动:从一个 stable config 端点拉最新 API 池清单(Cloudflare Workers + KV,基本不会被封)
3. SW 内置 fallback 列表,主接口失败自动切到下一个
4. 接口域和视频域分开:接口被封不影响视频播放,反之亦然
5. TLS 指纹 / Server header 错开:别让所有 API 域共用同一证书 fingerprint,防 ISP 按指纹批量识别

4. 用户分桶策略

4.1 分桶算法

bucket = hash(device_id) mod N

其中:
  device_id = 首次访问时生成的 UUID,存 localStorage + IndexedDB(双备份)
  N         = 当前活跃安装域名数
  hash      = FNV-1a 32-bit(轻量、分布均匀,不需要加密强度)

为什么用确定性 hash 而不是随机分配:

• 出事能精确定位影响范围:桶 3 用户集体反馈 → 知道是哪个域名挂了
• 灰度发布可以按桶推
• 域名被封时,只迁移那个桶的用户,其他人完全无感
• 同一设备多次访问,落到同一个桶(避免反复重装)

4.2 分桶持久化

服务端必须存一份映射表,即使 device_id 丢失,登录后仍能恢复:

CREATE TABLE user_install_binding (
  user_id          BIGINT      PRIMARY KEY,
  device_id        VARCHAR(64),
  install_origin   VARCHAR(128) NOT NULL,
  bucket           SMALLINT     NOT NULL,
  assigned_at      TIMESTAMP    DEFAULT NOW(),
  status           VARCHAR(16)  DEFAULT 'active',  -- active/deprecated/migrating
  migrated_to      VARCHAR(128) DEFAULT NULL,
  INDEX idx_origin (install_origin),
  INDEX idx_bucket (bucket)
);

4.3 不同获客渠道的入口策略

5. PWA 安装流程

5.1 时序

用户                分发域名              Dispatch API         安装域名            浏览器
 │                    │                      │                    │                  │
 │─ 点 WA 链接 ──────▶│                      │                    │                  │
 │                    │─ 读/建 device_id     │                    │                  │
 │                    │─ POST /dispatch ────▶│                    │                  │
 │                    │                      │─ hash + 查表       │                  │
 │                    │◀── { install_origin, │                    │                  │
 │                    │      bucket }        │                    │                  │
 │                    │─ 302 跳转 ─────────────────────────────▶│                  │
 │                    │                      │                    │─ 加载 PWA        │
 │                    │                      │                    │─ 注册 SW         │
 │                    │                      │                    │─ Precache shell  │
 │                    │                      │                    │─ 提示加桌面 ────▶│
 │◀────────────────────────────────────── 用户点"加到主屏幕"────────────────────────│
 │                    │                      │                    │─ 写映射表        │

5.2 Dispatch 接口契约

Endpoint POST https://spro.id/dispatch

Request

{
  "device_id": "8f3a-e7b2-...",
  "channel": "whatsapp",
  "referrer": "user_12345",
  "ua": "Mozilla/5.0 ... Chrome/...",
  "lang": "id-ID"
}

Response

{
  "install_origin": "https://dramaku-app.com",
  "bucket": 3,
  "expires_at": 1715731200,
  "fallback_origins": [
    "https://nontonpro.app",
    "https://kisahdrama.net"
  ]
}

fallback_origins 写进客户端 localStorage,万一首选安装域名访问失败,前端可以自己切到 fallback。

6. Service Worker 设计(核心)

6.1 缓存策略总览

6.2 完整 SW 代码模板

// sw.js
const SHELL_VERSION = 'shell-v20260514-01';
const MEDIA_CACHE = 'media-v1';
const SHELL_ASSETS = [
  '/',
  '/index.html',
  '/offline.html',
  '/assets/app.js',
  '/assets/app.css',
  '/assets/fonts/inter.woff2',
  '/assets/icons/icon-192.png',
  '/assets/icons/icon-512.png',
];

// API 池配置(初始,后续从 config 端点动态更新)
const API_POOL_DEFAULT = [
  'https://api-1.shortpro-api.com',
  'https://api-2.shortpro-api.com',
  'https://api-3.shortpro-api.com',
];
const CONFIG_ENDPOINT = 'https://config.shortpro.workers.dev/v1/config';

// ============ 安装阶段:precache app shell ============
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(SHELL_VERSION)
      .then(cache => cache.addAll(SHELL_ASSETS))
      .then(() => self.skipWaiting())
  );
});

// ============ 激活阶段:清理旧版本 ============
self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(
        keys
          .filter(k => k.startsWith('shell-') && k !== SHELL_VERSION)
          .map(k => caches.delete(k))
      )
    ).then(() => self.clients.claim())
  );
});

// ============ 请求拦截 ============
self.addEventListener('fetch', (event) => {
  const req = event.request;
  const url = new URL(req.url);

  // 1. 导航请求 → cache-first,网络失败也无所谓
  if (req.mode === 'navigate') {
    event.respondWith(handleNavigation(req));
    return;
  }

  // 2. API 请求 → 池化路由 + fallback
  if (url.pathname.startsWith('/api/')) {
    event.respondWith(routeToApiPool(req));
    return;
  }

  // 3. 媒体资源 → cache-first
  if (req.destination === 'image') {
    event.respondWith(cacheFirstMedia(req));
    return;
  }

  // 4. 其他静态资源 → cache-first
  event.respondWith(
    caches.match(req).then(r => r || fetch(req))
  );
});

// 导航处理:始终返回 cached shell
async function handleNavigation(req) {
  const cache = await caches.open(SHELL_VERSION);
  const cached = await cache.match('/index.html');
  if (cached) return cached;

  try {
    return await fetch(req);
  } catch {
    return cache.match('/offline.html');
  }
}

// API 池路由:从 IndexedDB 读最新池子,挨个试
async function routeToApiPool(req) {
  const pool = await getApiPool();
  const path = new URL(req.url).pathname + new URL(req.url).search;

  for (const base of pool) {
    try {
      const target = base + path;
      const response = await fetch(target, {
        method: req.method,
        headers: req.headers,
        body: req.method !== 'GET' ? await req.clone().blob() : undefined,
        credentials: 'include',
      });

      if (response.ok || response.status < 500) {
        return response;
      }
    } catch (err) {
      console.warn(`[API Pool] ${base} failed:`, err.message);
      reportApiFailure(base, err.message); // 异步上报,不 await
    }
  }

  // 所有 API 都挂了
  return new Response(
    JSON.stringify({ error: 'all_api_unreachable' }),
    { status: 503, headers: { 'Content-Type': 'application/json' } }
  );
}

// 从 IndexedDB 读 API 池(每次启动刷新一次)
async function getApiPool() {
  const db = await openDB();
  const stored = await db.get('config', 'api_pool');
  return stored?.value || API_POOL_DEFAULT;
}

// 后台静默刷新 config(在 activate 后调用,或定时调用)
async function refreshConfig() {
  try {
    const resp = await fetch(CONFIG_ENDPOINT, { cache: 'no-store' });
    const config = await resp.json();
    const db = await openDB();
    await db.put('config', { key: 'api_pool', value: config.api_pool });

    // 同时检查当前安装域名是否被标记为废弃
    if (config.deprecated_origins?.includes(self.location.origin)) {
      notifyMigration(config.new_install_url);
    }
  } catch (err) {
    console.warn('[Config] refresh failed:', err);
  }
}

// 通知前端弹出迁移引导横幅
function notifyMigration(newUrl) {
  self.clients.matchAll().then(clients => {
    clients.forEach(client => {
      client.postMessage({
        type: 'MIGRATION_REQUIRED',
        newInstallUrl: newUrl,
      });
    });
  });
}

// 媒体缓存(LRU 简化版,实际可用 workbox)
async function cacheFirstMedia(req) {
  const cache = await caches.open(MEDIA_CACHE);
  const cached = await cache.match(req);
  if (cached) return cached;

  const response = await fetch(req);
  if (response.ok) cache.put(req, response.clone());
  return response;
}

// 启动时刷新 config
self.addEventListener('activate', (event) => {
  event.waitUntil(refreshConfig());
});

// 接收前端消息(例如手动触发 config 刷新)
self.addEventListener('message', (event) => {
  if (event.data?.type === 'REFRESH_CONFIG') {
    refreshConfig();
  }
});

6.3 前端迁移引导(配合 SW 的 MIGRATION_REQUIRED 消息)

// app.js 启动逻辑
navigator.serviceWorker.addEventListener('message', (event) => {
  if (event.data?.type === 'MIGRATION_REQUIRED') {
    showMigrationBanner(event.data.newInstallUrl);
  }
});

function showMigrationBanner(newUrl) {
  const banner = document.createElement('div');
  banner.className = 'migration-banner';
  banner.innerHTML = `
    <div class="banner-content">
      <span>🚀 Aplikasi sudah upgrade! Klik untuk pindah ke versi terbaru</span>
      <button onclick="migrateTo('${newUrl}')">Pindah</button>
      <button onclick="this.parentElement.parentElement.remove()">Nanti</button>
    </div>
  `;
  document.body.appendChild(banner);
}

function migrateTo(newUrl) {
  // 携带 device_id 和当前 user token,新域名落地页可以无感登录
  const deviceId = localStorage.getItem('device_id');
  const migrationToken = generateMigrationToken(); // 一次性 token
  window.location.href = `${newUrl}/migrate?d=${deviceId}&t=${migrationToken}`;
}

7. 故障切换机制

7.1 安装域名被封

已安装用户 → 几乎无感: - SW 拦截导航 → cache hit → shell 加载 → API 调用走 API 池 → 正常使用 - 这就是三层架构的核心收益

新增用户: - 服务端把此域名 status 改为 cooling - Dispatch 算法把这个域名从分桶池移除,N 减 1 - 原来分到此桶的新用户重新打散到其他桶 - 此域名进入观察期(7-14 天后若仍不可达,转为 dead)

7.2 API 域名被封

• SW 内置优先级列表,主接口失败自动切下一个
• 启动时拉一次最新 API 清单(从 Cloudflare Workers KV)
• 所有失败异步上报到自有埋点(同样走 API 池,确保自身能上报)
• 失败率超过阈值(比如 5 分钟内 30% 失败)自动从池中移除

7.3 分发域名被封

影响范围最小,只影响新增:

1. 监控告警 → 运营切换推广物料里的链接
2. WhatsApp 群发新链接给现有用户(虽然他们已装,但可能要分享给朋友)
3. Telegram Channel、KOL bio、短链指向同步更新
4. 备份发现路径(Gist / Pastebin)同步更新

8. 用户召回机制(必须 Day 1 建好)

域名被封是必然事件,差别只是何时。用户召回能力直接决定业务能不能扛过封禁周期。

8.1 召回渠道优先级

8.2 FCM 推送细节

• 走 Google 基建,印尼不会封
• 注册 PWA 时主动请求通知权限(印尼用户接受度较高)
• 推送 payload 带 deeplink 到最新分发域名
• 即使原安装域名彻底死,推送通知点击仍可跳转到新域名

8.3 WhatsApp 召回

• 注册流程强制收集 WhatsApp 号(印尼场景非常自然,不会被认为是侵犯隐私)
• 通过 WhatsApp Business API(Twilio / 360dialog / Wati)群发
• 模板示例: Halo {nama}! 🎬 ShortPro pindah ke alamat baru. Klik untuk lanjut nonton drama favoritmu: 👉 {new_url}
• 控制频率,避免被 WA 风控

8.4 离线 fallback 页

每个安装域名的 SW 必须 precache 一个 offline.html,内容包括:

• 当前入口暂不可用的说明
• 备用入口的动态加载(从 Cloudflare Workers JSON)
• WhatsApp 客服联系方式
• Telegram Channel 链接

<!-- offline.html 关键片段 -->
<script>
  fetch('https://config.shortpro.workers.dev/v1/fallback')
    .then(r => r.json())
    .then(data => {
      document.getElementById('new-url').href = data.discovery_url;
      document.getElementById('new-url').textContent = data.discovery_url;
    })
    .catch(() => {
      document.getElementById('new-url').href = 'https://t.me/shortpro_id';
    });
</script>

9. 域名采购与运营节奏

9.1 采购规模

9.2 采购策略

• 注册商分散到 5+ 家:GoDaddy / Namecheap / Porkbun / Cloudflare Registrar / 印尼本地(Niagahoster / IDwebhost)
• TLD 多样化:.com / .app / .id / .co / .net / .io,别全押一种
• 批量错峰:每批不超过 5 个,间隔 2-4 周,避免同一注册时间被批量识别
• WHOIS:开 privacy,但准备好真实联系信息(出问题能申诉)
• 付费 1 年:别一次买 5 年,被封了就是沉没成本

9.3 CDN / 基础设施分散

9.4 轮换节奏

• 每周轮换 1 个:让"老"域名进入冷备休眠 14 天,降低批量老化风险
• 冷备域名定期热身:每月 1 次小流量探活,确保需要时立刻能用
• dead 域名处置:确认彻底封死后,3 个月不续费(避免成本黑洞)

10. 监控与健康检查

10.1 多 ISP 印尼侧探测

部署探测节点(可用低成本 VPS 或者付费 uptime 服务 + 印尼出口):

每 5 分钟从各 ISP 出口 DNS + HTTPS 探测全部活跃域名,失败 3 次连续触发告警。

10.2 Kominfo TrustPositif 监控

• 每天 1 次扫描 https://trustpositif.komdigi.go.id 数据库
• 命中告警 + 自动从 dispatch 池移除
• 内部 wiki 维护"被封域名时间线",积累经验

10.3 客户端埋点

每次启动上报(发送到 API 池):

{
  "event": "app_launch",
  "device_id": "...",
  "install_origin": "https://dramaku-app.com",
  "bucket": 3,
  "api_origin_in_use": "https://api-2.xxx",
  "sw_version": "v20260514-01",
  "shell_cache_hit": true,
  "online": true,
  "ts": 1715731200
}

后台 dashboard 按 install_origin 维度统计:

• DAU / 启动次数(突然为 0 → 被封)
• API 失败率(突然飙升 → 域名劫持)
• SW 缓存命中率(异常低 → 缓存策略问题)

11. 实施计划(6 周)

Week 1 — 域名与基础设施

• [ ] 采购首批 20 个域名(分布在 5+ 注册商)
• [ ] DNS 配置,IP/CDN 分散部署
• [ ] Cloudflare Workers config 端点搭建
• [ ] Service Worker 缓存策略原型代码

Week 2 — 三层架构基础

• [ ] 分发域名静态页 + dispatch 接口
• [ ] 安装域名模板部署(一份代码 N 份部署)
• [ ] API 网关 + 多域名路由
• [ ] 数据库表结构(user_install_binding 等)

Week 3 — 分桶与 SW

• [ ] 分桶算法 + 服务端持久化
• [ ] Service Worker 完整实现(precache / 路由 / fallback)
• [ ] API 池动态配置流程
• [ ] 健康检查接口

Week 4 — 召回机制

• [ ] FCM 集成 + 推送模板
• [ ] WhatsApp Business API 接入
• [ ] 离线 fallback 页 + 迁移引导横幅
• [ ] 邮件召回模板

Week 5 — 监控与运营工具

• [ ] 多 ISP 印尼侧探测节点
• [ ] Kominfo TrustPositif 监控脚本
• [ ] 客户端埋点 + dashboard
• [ ] 运营 SOP 文档(域名被封 → 切换 → 召回的标准动作)

Week 6 — 灰度与压测

• [ ] 内测 100 用户,验证三层切换流程
• [ ] 模拟封禁演练(主动下线 1 个安装域名,观察故障切换)
• [ ] 大盘灰度 10% → 50% → 100%
• [ ] 复盘 + 调优

12. 关键技术坑与对策

13. 成功指标(KPI)

14. 风险与边界

这套方案能做到的:

• 单一域名被封,大多数已安装用户继续可用数周到数月
• 新增用户始终有可用入口
• 域名被封从事故变成可控的运营动作

这套方案做不到的:

• 永久豁免封锁:被封域名上的 PWA 终有一天会失活,只是时间问题
• 100% 召回:再好的机制也会有 10-30% 的长尾用户流失
• 防住国家级深度封锁:如果印尼上 GFW 级别的全栈封锁,任何方案都难

结论:这是一套"延迟战术 + 平滑迁移"的组合拳,目标不是不被封,而是让封禁不影响业务连续性。

附录 A:Config 端点 schema

GET https://config.shortpro.workers.dev/v1/config

{
  "version": "20260514-01",
  "api_pool": [
    "https://api-1.xxx",
    "https://api-2.xxx",
    "https://api-3.xxx"
  ],
  "cdn_pool": [
    "https://cdn-1.xxx",
    "https://cdn-2.xxx"
  ],
  "deprecated_origins": [
    "https://oldsite.com"
  ],
  "new_install_url": "https://spro.id",
  "fallback_discovery": [
    "https://t.me/shortpro_id",
    "https://gist.github.com/shortpro/domains"
  ],
  "min_sw_version": "v20260501-01",
  "ttl": 3600
}

附录 B:常用命令参考

# 多 ISP 探测脚本(从印尼云主机跑)
for domain in $(cat domains.txt); do
  for ns in 8.8.8.8 1.1.1.1 202.134.0.155; do  # 含 Telkomsel DNS
    dig +short @$ns $domain
  done
done

# Kominfo TrustPositif 检查
curl -s "https://trustpositif.komdigi.go.id/api/check?url=$DOMAIN"

# Cloudflare Workers config 更新
wrangler kv:key put --binding=CONFIG "v1" --path=./config.json