perf(cdn): 放宽源站限流并新增 OSS 源站同步以加速预热

预热需每个边缘节点各拉一份完整文件，回源总量=节点数x172MB，而 ECS 出网
仅约 6Mbps，导致预热耗时几十分钟至数小时且打满带宽影响 API。

A. nginx /downloads/ 移除 limit_rate、并发 8/24 放宽至 32/64：
   接入 CDN 后该路径只服务 CDN 回源与少量直连兜底，原限流已只剩副作用，
   多节点并发回源易撞上限被拒 503 而使预热失败或极慢
B. release.yml 新增 OSS 上传（CDN 源站）：OSS 出网带宽极大，可使预热降至
   分钟级且完全不占用 ECS。路径与 ECS 一致（downloads/ 前缀），故无需改
   DOWNLOAD_BASE_URL、前端与 electron-updater 配置；ECS 同步保留作兜底
   与存量客户端更新源。未配置 OSS_BUCKET 时该步骤跳过

文档修正先前判断：原结论'CDN 回源 ECS 即可，不需要 OSS'漏算了预热回源量，
已改为推荐 CDN + OSS 源站并附回源量估算表。

Author: Aparencia

.github/workflows/release.yml

@@ -148,6 +148,45 @@ jobs:
           target: /opt/Entropydecrease/downloads
           strip_components: 1
 
+      # ---------------------------------------------------------------
+      # 同步至 OSS（CDN 源站）
+      # 为何需要 OSS：ECS 出网仅约 6Mbps，而 CDN 预热需**每个边缘节点各
+      # 拉一份完整文件**，回源总量 = 节点数 x 172MB，以 ECS 为源站时
+      # 预热耗时达几十分钟至数小时且会打满带宽影响 API。
+      # OSS 出网带宽极大，可使预热降至分钟级且完全不占用 ECS。
+      #
+      # 路径与 ECS 保持一致（downloads/ 前缀），因此无需改变
+      # DOWNLOAD_BASE_URL，也无需改前端与 electron-updater 配置。
+      # ECS 同步仍保留：存量客户端的更新源仍指向 ECS，且作为兜底。
+      # ---------------------------------------------------------------
+      - name: Upload to OSS (CDN origin)
+        if: ${{ secrets.OSS_BUCKET != '' && secrets.ALIYUN_ACCESS_KEY_ID != '' }}
+        env:
+          AK_ID: ${{ secrets.ALIYUN_ACCESS_KEY_ID }}
+          AK_SECRET: ${{ secrets.ALIYUN_ACCESS_KEY_SECRET }}
+          OSS_BUCKET: ${{ secrets.OSS_BUCKET }}
+          # 未配置时默认杭州（与 ECS 同地域）
+          OSS_ENDPOINT: ${{ secrets.OSS_ENDPOINT || 'oss-cn-hangzhou.aliyuncs.com' }}
+          FILE_NAME: ${{ steps.meta.outputs.file }}
+        run: |
+          set -eo pipefail
+          curl -sL https://aliyuncli.alicdn.com/aliyun-cli-linux-latest-amd64.tgz -o /tmp/aliyun.tgz
+          tar -xzf /tmp/aliyun.tgz -C /tmp
+
+          oss_cp() {
+            /tmp/aliyun oss cp "$1" "oss://$OSS_BUCKET/downloads/$2" \
+              --force -e "$OSS_ENDPOINT" -i "$AK_ID" -k "$AK_SECRET"
+          }
+
+          cd release-windows-latest
+          # 同 ECS 的顺序约定：先二进制后元数据，避免 latest.yml 率先就位
+          # 而指向尚未上传完成的安装包
+          oss_cp "$FILE_NAME" "$FILE_NAME"
+          oss_cp "$FILE_NAME.blockmap" "$FILE_NAME.blockmap"
+          oss_cp latest.yml latest.yml
+          oss_cp latest.json latest.json
+          echo "OSS sync done: oss://$OSS_BUCKET/downloads/"
+
       # 保留策略：仅保留最近 3 个版本的安装包，防止磁盘增长
       - name: Prune old versions (keep last 3)
         uses: appleboy/ssh-action@v1

docs/knowledge/solutions/2026-07-installer-cdn-distribution.md

@@ -30,17 +30,29 @@
 
 ## 方案描述
 
-### 架构选择：CDN 回源 ECS（推荐）vs CDN + OSS 源站
+### 架构选择：CDN + OSS 源站（推荐）vs CDN 回源 ECS
+
+> ⚠️ **本节结论已根据实测修正**。最初判断为“安装包是固定文件、缓存命中率高、回源次数少，故 CDN 回源 ECS 即可”，**该判断漏了预热这一环**：预热需要**每个边缘节点各拉一份完整文件**，回源总量 = 节点数 × 文件大小，在小带宽源站上代价极大。
 
 | 维度 | CDN 回源 ECS | CDN + OSS 源站 |
 |------|-------------|---------------|
-| 新增组件 | 仅 CDN | CDN + OSS |
-| CI 改造 | **无需改动**（沿用现有 scp 同步） | 需新增 OSS 上传步骤 |
-| 缓存命中率 | 接近 100%（安装包为固定文件） | 同 |
-| ECS 负担 | 仅回源（每版本每节点一次） | 无 |
-| 源站可用性 | ECS 故障时无法回源（但已缓存内容仍可服务） | 更高 |
+| 源站出网带宽 | 实测约 **6 Mbps（瓶颈）** | 极大（共享大带宽） |
+| 预热耗时（172MB） | 几十分钟～数小时 | **通常分钟级** |
+| 预热是否影响 API | 会打满 ECS 带宽 | **完全不影响** |
+| 存储成本 | 0 | 约 **0.06 元/月**（0.5GB） |
+| CI 改造 | 无 | 需一步 OSS 上传 |
+
+**预热回源量估算（ECS 为源站时）**：
+
+| 预热节点数 | 回源总量 | 耗时（@770KB/s） |
+|-----------|---------|------------------|
+| 5 | 860 MB | 约 19 分钟 |
+| 10 | 1.7 GB | 约 37 分钟 |
+| 30 | 5.2 GB | 近 2 小时 |
+
+且每次发版文件名变更均需重新预热，故以小带宽 ECS 作源站不可持续。
 
-安装包是**内容不变的静态文件**，CDN 缓存命中率接近 100%，回源仅在新版本发布后每节点首次发生。因此 **CDN 回源 ECS 即可解决绝大部分带宽问题**，且改造量最小。OSS 方案可作为后续演进（追求源站高可用时）。
+**OSS 路径约定**：上传至 `oss://<bucket>/downloads/`，与 ECS 保持一致，因此切换源站时**无需改变 `DOWNLOAD_BASE_URL`、前端与 electron-updater 配置**。ECS 同步仍保留（存量客户端更新源仍指向 ECS，兼作兜底）。
 
 ### 下载源可切换设计
 

server/nginx/nginx.conf

@@ -222,14 +222,14 @@ http {
         location ^~ /downloads/ {
             root /usr/share/nginx;
             autoindex off;
-            # 实测（RTT 仅 21ms，已排除延迟因素）：单流约 140KB/s 且启用 BBR 前后无
-            # 差异，单流受限原因未明；但多流可叠加：4 并发 500KB/s、8 并发 764KB/s。
-            # 故单 IP 并发放宽至 8：既兼容多线程下载器（限 4 会使超出连接被拒 503），
-            # 也实测提升总吞吐。limit_rate 2m 远高于实际速率，仅作异常保护上限。
-            # 注：浏览器默认单连接，因此普通用户仍只能得到 ~140KB/s，根治需 CDN。
-            limit_rate 2m;
-            limit_conn dl_conn 8;
-            limit_conn dl_total 24;
+            # 接入 CDN 后本路径主要服务 CDN 回源（少量、可信）与少量直连兜底，
+            # 不再承载大量用户直接下载，故原限流已只剩副作用：
+            # CDN 预热时多个边缘节点并发回源，易撞上并发上限而被拒（503），
+            # 导致预热失败或极慢（预热需每节点各拉一份完整文件）。
+            # 故移除 limit_rate（回源越快预热越快）并大幅放宽并发；
+            # 仍保留上限以防异常爬取耗尽连接。
+            limit_conn dl_conn 32;
+            limit_conn dl_total 64;
 
             # 更新元数据（latest.yml / latest.json）禁止缓存，
             # 否则客户端会长期读到旧版本信息；允许 www 子域跨域读取