Release 下载Sublink Worker · GitHub Release 历史版本 · 三路反代镜像
最新正式版v2.4.2本区块同步 Sublink Worker 的官方 GitHub Release，并为最近版本生成 三路反代镜像加速下载通道。 默认展开最新正式版；如果项目只有预发布版，会在版本旁单独标注。下载按钮直接指向官方直链或镜像链接，便于复制真实 URL 做校验。
Sublink Worker v2.4.2 不是下载后双击运行的客户端。它是一个要部署在 Cloudflare Workers、Docker 或 Node.js 上的订阅转换服务。2026 年 4 月 27 日的 GitHub Release 没有附加二进制资产，只给了部署命令和源码归档。想少管服务器，选 Cloudflare Workers；想保留短链并掌握回滚，默认选 Docker Compose + Redis；已有 Linux 服务守护、反向代理和监控，再考虑 Node.js。
这里没有把真实订阅接入任何实例。下面的版本事实、命令入口和 API 行为来自官方仓库、Release 与文档；验证样例只使用 example.invalid 保留域名，不含真实订阅 token。
v2.4.2 修了什么，哪些旧问题值得重验？
官方更新日志给 v2.4.2 列了四项修复。第一项是自定义规则的出站成员：生成 Clash、Sing-Box、Surge 配置时，自定义规则现在应包含「节点选择」「自动选择」、手动切换分组和节点列表。旧行为会让规则存在，却没有可切换的成员。
第二项改了远程订阅解码顺序。转换器先识别明文 Clash YAML、Sing-Box JSON、Surge INI 和协议链接，只有内容确实像 Base64 时才解码。这一项要防的是明文被强行解码后出现乱码或空配置。
第三项针对空 Clash 代理组。url-test 或 fallback 没有成员时，v2.4.2 会抛出 InvalidConfigError，不再静默产出无效配置。第四项让 Auto Provider 的名称在重复构建间保持稳定，避免每次重建都换一个 provider 引用。
这四项都是「输出正确性」变化，不是首页样式变化。升级验收只打开 Web UI，会漏掉真正需要看的地方。
Cloudflare Workers、Docker、Node.js 怎么选？
三者运行同一套项目代码，差异集中在存储、进程责任和回滚。下面这张表用于选默认部署，不比较没有官方数据支撑的速度。
| 部署方式 | 默认存储口径 | 你要负责什么 | 回滚抓手 | 更合适的情况 |
|---|---|---|---|---|
| Cloudflare Workers | SUBLINK_KV；也可按文档接外部存储 | Worker、KV 绑定、域名与边缘访问规则 | 回退 Worker 部署版本或 Git tag | 个人轻量使用，不想维护 Linux 进程 |
| Docker Compose | 官方 Compose 同时启动 Redis 7，写入 redis-data 卷 | 镜像 tag、Redis 卷、端口和宿主机备份 | 把镜像变量改回旧 tag，再重建 Worker | 长期保存短链、希望一次管住应用与存储 |
| Node.js | 未配 Redis/Upstash 时会落到内存 KV | Node.js 18+、进程守护、反向代理、存储与日志 | 切回旧源码目录或旧构建产物 | 已有 systemd/PM2、Redis 和发布流水线 |
项目 package.json 声明 Node.js 版本为 >=18。Docker 官方镜像提供 amd64 与 arm64；官方 Compose 已写入 Redis 主机、端口、key 前缀和 30 天的 CONFIG_TTL_SECONDS=2592000。这不等于短链一定 30 天失效：运行文档把基础配置 TTL 与短链 TTL 分开，短链默认是不过期。
Cloudflare Workers 怎样部署并确认 KV 已绑定？
从 tag 部署时，先把源码固定到 v2.4.2。Release 给出的入口是 npm install && npm run deploy；仓库里的 deploy 脚本会先执行 setup-kv，再调用 Wrangler。
git clone https://github.com/7Sageer/sublink-worker.git
cd sublink-worker
git checkout v2.4.2
npm install
node -p "require('./package.json').version"
npm run deploy版本输出应为：
2.4.2仓库的 wrangler.toml 把 Worker 入口设为 src/worker.jsx，同时声明 SUBLINK_KV。部署后不要把「页面能开」当成 KV 验收。创建一条只指向 https://example.invalid/sample 的临时短链，再读取返回的 /s/<code>；重新部署后仍能得到重定向，才证明写入没有只落在进程内存。
官方 API 把 /shorten 和 /config 都列为写操作。公开域名至少要在 Cloudflare 外层给这两个路径加访问控制或速率限制。不要把管理员令牌写进仓库变量文件，也不要把完整请求 URL 贴进工单。
Docker 怎样固定版本并检查 Redis 持久化？
官方快速开始直接给出 docker compose up -d，但生产升级不该一直追 latest。官方 Compose 支持 SUBLINK_WORKER_IMAGE 覆盖镜像，用 tag 固定到 v2.4.2：
git clone https://github.com/7Sageer/sublink-worker.git
cd sublink-worker
git checkout v2.4.2
SUBLINK_WORKER_IMAGE=ghcr.io/7sageer/sublink-worker:v2.4.2 \
docker compose up -d
docker compose ps
docker compose logs --tail=80 worker预期不是日志里出现某句固定文案，而是 worker 与 redis 都处于运行状态，http://127.0.0.1:8787/ 能返回页面。日志命令可能打印请求路径；如果请求里已经带真实订阅 URL，先在日志采集器里关闭 query string，再让团队成员读取。
Redis 是否在落盘，要看 Redis 自己。官方 Compose 把 redis-data 挂到 /data，并载入仓库的 redis.conf。可读取持久化状态，不要用 MONITOR 在繁忙生产实例里长时间抓全部命令：
docker compose exec redis redis-cli INFO persistence \
| grep -E '^(rdb_last_bgsave_status|aof_enabled|loading):'
docker volume ls | grep redis-data升级前把 Compose 文件、镜像 tag 与 Redis 卷备份策略放在一起。只备份容器列表没有意义；容器可以重建，短链与 configId 对应的数据在存储层。
Node.js 怎样运行，为什么不该裸跑？
官方 Node.js 路径会把 src/platforms/node-server.js 打包到 dist/node-server.cjs。开发机可按文档直接启动：
git clone https://github.com/7Sageer/sublink-worker.git
cd sublink-worker
git checkout v2.4.2
npm install
npm run build:node
node dist/node-server.cjs这条命令退出终端就会停止。官方文档建议 Node.js 使用 PM2 等进程管理工具；在已有 Linux 服务体系里，systemd 也可以承担重启和开机启动，但服务文件、用户权限和环境变量保管要由你自己完成。
存储更容易被忽略。运行时按 Redis、Upstash/Vercel KV、内存 KV 的顺序选择后端。Node.js 没有配置前两者时会启用内存 fallback。想让缺少持久化直接暴露为配置错误，可设置：
DISABLE_MEMORY_KV=true
REDIS_URL=redis://sublink:<REDACTED>@127.0.0.1:6379/0
REDIS_KEY_PREFIX=sublink
CONFIG_TTL_SECONDS=2592000这只是字段示例，<REDACTED> 不能原样用于生产。真正的 REDIS_URL 应交给 systemd credential、容器 secret 或你的密钥管理系统，不要提交到 Git。完成配置后，重启 Node.js 进程并重复短链重启测试；进程重启后记录仍在，才算持久化接通。
订阅 URL 会在哪几层泄露？
Sublink Worker 能自托管，不代表输入天然不会留下痕迹。官方 API 的 /clash、/singbox、/surge 与 /xray 都通过 GET 接收 config；/shorten 也通过 GET 接收 url。源订阅 URL、分享 URI 或 URL 编码后的节点参数因此可能出现在浏览器历史、边缘请求日志、反向代理 access log 和运维截图里。具体哪一层保存多久，取决于你的平台和日志配置，项目文档没有给出统一承诺。
| 信息位置 | 可能暴露的内容 | 最小化动作 |
|---|---|---|
| GET 查询串 | 源订阅 URL、分享 URI、规则选择 | 不用真实数据做公开演示；日志不保存 query string |
/shorten 存储 | 原始目标 URL 与短码映射 | 限制写接口；不用可猜短码承载敏感链接 |
/config 存储 | Clash YAML、Sing-Box JSON 或 Surge 配置 | 限制写接口；设置合适 TTL；删除不用的配置 |
| 运行环境变量 | Redis 密码、Upstash 的 KV_REST_API_TOKEN | 用平台 secret；限制部署日志和主机读取权限 |
| 客户端分享 | 转换后的完整订阅地址 | 不发群聊、不贴 Issue；泄露后轮换源端凭据 |
/shorten 只是把长链接换成短码，不是加密。知道短码并能访问实例的人，仍可触发到原始 URL 的重定向。Cloudflare KV、Redis 或 Upstash 也只是存储后端，不会自动替你设计访问权限。
如果还不清楚转换端会接触哪些字段，先看订阅转换的四类信息风险。需要比较不同转换路径，可接着看订阅格式转换方案；若团队已有传统后端，再用subconverter 工具页核对它与 Sublink Worker 的 API 和部署责任差异。
从旧版升级到 v2.4.2 怎么验？
先保留旧实例，不要原地覆盖后才找差异。Cloudflare 可先发 Preview，Docker 可在另一个本机端口启动新 tag，Node.js 可用独立目录和端口。两边只喂同一份脱敏输入，输入必须排除真实域名、UUID、密码和订阅 token。
下面的 ss:// 使用保留域名 example.invalid 和测试密码，只用于检查解析与输出结构：
SUBLINK_TEST_BASE="http://127.0.0.1:8787"
curl -fsS --get \
--data-urlencode 'config=ss://[email protected]:8388#upgrade-check' \
"${SUBLINK_TEST_BASE}/clash" \
-o /tmp/sublink-v242-clash.yaml
node --input-type=module -e \
'import fs from "node:fs"; import yaml from "js-yaml"; yaml.load(fs.readFileSync("/tmp/sublink-v242-clash.yaml","utf8")); console.log("YAML parse OK")'
grep -E '^(proxies|proxy-groups|rules):' /tmp/sublink-v242-clash.yaml看到 YAML parse OK 只说明 YAML 语法可解析。还要按 v2.4.2 的修复项看内容：
| 回归项 | 该怎么构造 | 通过信号 | 失败后先看哪里 |
|---|---|---|---|
| 明文订阅解码 | 输入一份脱敏 Clash YAML、Sing-Box JSON 或协议 URI | 输出不是空文件，也没有 Base64 乱码 | 响应状态、原始 Content-Type、Worker 日志 |
| 自定义规则成员 | 用 /clash 或 /singbox 加一条脱敏 customRules | 对应规则组含节点选择、自动选择或预期手动组 | 请求中的 JSON 编码、输出组成员 |
| 空代理组 | 构造没有成员的 url-test 或 fallback | 返回明确 InvalidConfigError，而非可下载的坏配置 | HTTP 状态与错误响应正文 |
| Provider 稳定性 | 同一输入连续生成两次 | 两次输出里的自动 provider 名称一致 | diff 中的 provider key 与引用 |
| 存储恢复 | 创建临时短链或 configId 后重启实例 | 重启后仍可读取；删除测试数据后失效 | Redis/KV 绑定、TTL、内存 fallback |
对输出做 diff 时，先删除会自然变化的时间戳或请求标识，再比较结构。若新版只在一个回归项失败，保留旧版本提供服务，并把该项的脱敏输入、HTTP 状态、响应片段和准确 Git tag 放进 Issue；不要上传原始订阅。
哪些结论不能从 Release 推出来？
Release 能证明版本号、发布日期、提交和官方部署入口，不能证明你的 Worker 域名、Linux 主机或 Redis 配置已经安全。它也没有为 v2.4.2 提供 Windows、macOS 或 Linux 可执行资产；源码归档不是二进制安装包。
本文没有连接真实订阅，也没有验证具体客户端对所有协议字段的接受程度。Sublink Worker 官方列出的输出包括 Clash、Sing-Box、Surge 与 Xray，但「成功生成文本」不等于目标客户端一定接受每个字段。最终上线前仍要在隔离的测试客户端导入脱敏配置，查看解析错误和策略组成员。
最后一个边界是日志。官方 API 文档建议给 /shorten、/config 等写操作增加访问令牌或速率限制，却没有承诺任何部署方式默认隐藏查询串。先完成访问控制、密钥保管和日志脱敏，再换入真实数据；否则自托管只是把泄露面从第三方转换站移到了自己的基础设施。