SyncClipboard 官方服务端的 Cloudflare Workers 复刻版 —— SyncClipboardCfServer

发现频道
1

如果你希望可以跨网络同步剪切板，但觉得「自备一台 VPS / Docker / 进程守护」有点重，这里有一个不用改客户端、部署在 Cloudflare 边缘的复刻实现可以看看。

项目地址： GitHub - Leexunhuan743/SyncClipboardCfServer: SyncClipboard 官方同步服务器的 Cloudflare Workers 复刻（TypeScript + D1 + R2 + Durable Objects），协议兼容官方客户端 · GitHub （独立仓库，MIT）

它是什么

用 TypeScript 在 Cloudflare Workers 上完整重写了官方 SyncClipboard.Server.Core，官方客户端零改动，把服务器地址指到你的 Worker 即可使用：

  • 剪贴板实时同步 —— SignalR WebSocket 长连接（WebSockets / SSE / LongPolling 三传输自动降级）
  • WebDAV 兼容端点 —— SyncClipboard.json、file/*、PROPFIND
  • 历史记录 —— 存储、查询、跨设备同步、/api/history/* 全套接口
  • /api/version 返回 3.3.0-beta1，与官方基线一致

关键点：协议行为逐条对照官方源码实现，并用官方发布件做过 A/B 实测；大部分行为「有意偏离」都登记在文档里，且都有理由（多数是更稳、更安全）。

相比官方服务端，多出来的东西

  1. 内置 Web 历史管理界面（官方没有）。部署完成后打开 Worker 地址就自动跳到界面，用同一组用户名密码登录：

    • 浏览 / 搜索 / 筛选 / 排序历史记录
    • 收藏、置顶、批量操作、文本/图片预览、复制、下载
    • 回收站：删除的记录（连同图片/文件数据）在回收站保留 30 天，可一键恢复
    • 在线调整保留策略（条数上限、保留时长），不用重新部署
    • 部署信息面板：直接给出客户端该填的地址

  2. 无服务器、按量计费。个人用量基本落在免费额度内：

    • 免费计划每天 10 万次请求；一台客户端全天在线 ≈ 1.7 万次/天，5 台同时在线 ≈ 8.6 万次/天
    • 数据放 D1（历史）与 R2（附件），免运维、全球边缘

  3. 部署两条路：

    • 命令行：wrangler login → 建 D1 + R2 → 执行 schema.sql → 设 USERNAME/PASSWORD 密钥 → npm run deploy
    • GitHub Actions：Fork 后配 2~3 个 Secret，推送 master 自动建资源、跑完质量门并部署，开箱即用

  4. 国内网络下 workers.dev 有 DNS 污染/不稳定问题 —— 绑定一个自定义域名即可（README 有步骤）。

一些差异，先说清楚（避免踩坑）

方面 官方服务端 本项目
单次上传大小 不限制 默认上限 48 MiB（可调到 64 MiB），超过返回 413
文件夹/大文本 不限制 zip 解压总量 64 MiB、条目 1000、单条目 24 MiB、膨胀比 100:1；单条内联文本 1 MiB
历史清理节奏 过期 10 分钟一轮；回收站/孤儿 12 小时 统一 20 分钟一轮，分多批跑完
访问不存在的地址 直接 404 未带凭据返回 401 并计入失败次数（同一 IP 15 分钟错 10 次会临时封 15 分钟）
数据迁移 历史在本地 history.db 存在 Cloudflare D1（表结构不同），不能直接导入，换服务端后让客户端重新同步即可

这些限制基本来自 Cloudflare 免费档的约束（单请求 100 MiB、isolate 内存 128 MiB）；客户端默认单文件 20 MB，正常使用大多碰不到。

07-ui-v1
07-ui-v11440×900 59.2 KB

说明

这是一个独立的社区实现，与官方项目无关联、未获官方背书；协议行为与哈希算法移植自官方（MIT，版权声明已保留在 LICENSE 中）。界面灵感部分参考了 Python 的 clipserver 项目。

如果你只想「不折腾服务器、白嫖免费额度、还能用浏览器管理剪贴板历史」，值得一试。也欢迎到项目仓库提 Issue / 讨论。