常见问题

隐私、部署模型、多设备多空间、数据与升级 —— 一次说清。

下面的回答按主题分组，尽量每条用一句话给结论，再补理由。如果你正在排查具体故障，请直接看故障排查。

隐私与安全

我的剪贴会上传到哪里？谁能看到？

只在你 已配对设备 之间传，且全程端到端加密。

应用层用 XChaCha20-Poly1305 加密，密钥由空间 MasterKey 派生，与传输层独立。流量可能直连，也可能经过加密中继 —— 中继看到的只有源 / 目的 node ID 与密文，看不到内容。

UniClipboard 自己有服务器吗？

只有发现层（rendezvous）和加密中继。它们都不解密、也不持久化你的内容：

rendezvous 帮设备根据 node ID 找到地址，记录的是签名过的地址条目，跟"DNS for peers"一个性质。
中继只在 P2P 打洞失败时短暂转发加密数据包。

你的剪贴历史不会出现在我们的任何服务器上。没有"账户云"、没有云端备份。

诊断数据与使用情况分析走独立通道，用于崩溃排查和产品可靠性分析，不承载剪贴内容。完整字段范围见隐私与数据收集。

UniClipboard 会收集哪些诊断或使用情况数据？

默认会收集两类可关闭的数据：诊断数据（崩溃、错误、匿名日志、性能 trace、前端诊断）和使用情况分析（首次启动、配对漏斗、同步可靠性事件）。它们不包含剪贴板内容、文件内容、口令或密钥。详见隐私与数据收集。

口令忘了能找回吗？

不能。 口令通过 Argon2id 派生 KEK，KEK 又封装空间 MasterKey。整条链路上没有任何能用第二把钥匙打开的副本 —— 这是设计目标，也是不留后门的代价。

如果还有一台设备能登录这个空间：在那台机器上吊销丢失设备、必要时重建空间即可。如果所有设备都丢了口令，本地历史只能放弃，重新 init 一个新空间。

锁屏页提供了 「忘记口令？重置并重新开始」 入口，可以在 GUI 里直接完成上述操作：它会清掉本机磁盘上的 keyslot 与 KEK，然后把你送回 setup 页面，让你重新 init 一个新空间或从另一台设备 join。点击后需要手动输入 RESET 确认 —— 一旦执行，本机历史无法找回。

中继被攻陷了怎么办？

中继被攻陷只能影响 性能与可达性，不影响机密性。攻击者拿到的是 QUIC 之上的密文与端到端加密信封，没有 MasterKey 的话什么也看不到。详见配对与同步 — 中继看到的 vs. 对端看到的。

本地磁盘上是不是明文？

不是。本地剪贴数据库与全文搜索索引在磁盘上都是加密的，密钥保存在系统密钥环（macOS Keychain / Windows Credential Manager / Linux Secret Service）。详见同步内容 — 本地存储。

我能完全禁用中继吗？

可以。设置 → 网络 → 仅局域网模式（LAN-only mode） 会关掉加密中继 fallback（底层即 allow_relay_fallback = false）。打开后稳态同步只走 mDNS 局域网发现 + 直连（LAN / IPv6）路径：

不再连任何 iroh relay 节点（RelayMode::Disabled）；
不再向 n0 公共 DNS（dns.iroh.link）发布或解析 NodeId（清掉 pkarr publisher + DNS lookup）；
即使对端在配对时存过 relay url，本端 dial 时也会剥掉，不会经对方的 relay 中转。

效果：只能在同子网且 mDNS 可达时找到对端；跨网段已配对设备会变得不可达 —— 这是 LAN-only 的设计意图。

此开关变更需要重启 daemon 生效，托盘图标也会反映 LAN-only 状态。

注意：首次配对仍走公网 rendezvous（rendezvous.uniclipboard.app）交换 NodeId，请先在默认模式完成配对，再开 LAN-only。

如果只想让 当下这次 走直连，把两台设备放到能互通的同一网络（同 Wi-Fi、IPv6 全程可达、或共享 VPN），不用动全局开关。

部署与账号

一定要联网吗？

只在配对、跨网络发现、跨网络同步时需要。同 Wi-Fi 下的同步是 P2P 直连，外网完全断掉也能跑。

一定要邮箱 / 账号吗？

没有账号系统。 信任边界是空间 + 口令，不存在第三方身份提供方。详见配对与同步 — 信任。

能自托管 rendezvous / 中继吗？

UniClipboard 现在在 设置 → 网络 → 自定义中继节点 暴露自定义 iroh relay URL。留空时继续使用 iroh 默认中继；每行填一个 relay URL 后，重启 daemon 即可只使用这些自定义中继节点。从零搭一台中继的完整流程见自建 iroh relay。

自定义 rendezvous discovery 仍未暴露。首次配对仍会使用 UniClipboard 的 rendezvous 服务；跨网络 NodeId 发现仍走当前 iroh discovery 路径，除非你开启了仅局域网模式。

多设备与多空间

"空间"和"设备"是什么关系？

空间（Space） = 加密单位 + 共享历史 + 一组配对设备。
设备（Device） = 一个 iroh node ID，加入一个或多个空间。

加入空间后，该设备就拥有空间内的全部内容密钥，也会被空间内其他设备视为可信对端。

一台设备能加入多个空间吗？

可以，但 同一时刻只激活一个。带上另一个 sponsor 的邀请码运行 uniclip join --switch（或用 GUI 的设备页）切换时，本地历史会先用新空间的 MasterKey 重新加密再切，没有明文窗口。

典型用法：把"个人"和"工作"两套设备分到两个空间，机敏度不同。

怎么把一台设备从空间里移除？

在另一台还在线的设备上吊销它（GUI 的设备页 / 后续会有 CLI 子命令）。吊销后空间内其他设备会拒绝来自该 node ID 的传输请求。

仅在被移除设备本机删数据 不算吊销 —— 只有空间内的可信清单才能撤销信任。

添加第 N 台设备和加第二台一样吗？

完全一样。每加一台都生成一张一次性邀请码、在新设备上输入，没有"主设备"概念。详见快速开始 — 添加第二台设备。

数据与历史

历史保留多久？

默认按本地保留策略管理（条目数 + 大小阈值），超出会自动 GC。每台设备各自维护，不跨设备同步删除。

按设备粒度的更细控制（按内容类型、单独清空某台）见同步内容 — 按设备粒度的同步开关。

新加入的设备会拿到我之前的历史吗？

不会。配对不回填历史。从加入那一刻起新产生的剪贴会同步过去，之前的内容仍然只在原设备上。这是刻意为之 —— 让"加入"是一个明确的时间锚，便于审计也避免一台设备被加入就把整个空间历史拷走。

卸载后数据会被清干净吗？

卸载安装包不会自动清理数据目录与系统密钥环条目。这是为了避免误卸装造成数据丢失。如果确实想抹干净，参考故障排查 — 紧急重置。

升级会不会丢历史？

补丁版与小版本升级保留历史。0.6 网络栈重写 是一次破坏性升级 —— 旧的配对状态失效，本地历史保留但需要重新走一次配对流程。后续大版本如果再出现这种情况，会在 release notes 里显式标注。

可以。GUI 在 设置 → 存储 → 配置备份 / 迁移 提供 导出配置，把当前设备的历史、设置、身份、密钥材料打包成一个加密的 .ucbundle 文件（由你的 Space 口令保护，无需另设口令）；在另一台机器上 导入配置 即可恢复，连配对关系都保留、不用重新配对。导入会替换目标机当前的配置，所以无论目标机是全新安装还是正在使用都可以（会被覆盖）。完整步骤和「搬家语义」见导出与导入配置。

底层仍可以用隐藏命令 uniclip dev dump-clipboard --limit N（开发用途，未来可能变化）。直接拷贝数据目录做镜像备份是 不可靠 的：数据库是加密的、密钥的存放方式跨安装形态不一致，复制文件无法带走身份，跨机器恢复请用上面的导出 / 导入。

平台与版本

有移动端吗？

iOS 侧 UniClipboard iOS App 已开启 TestFlight beta 公测，邀请链接： testflight.apple.com/join/nyNQ8dQe —— 在 App Store 装好 TestFlight，再点这个链接接受邀请并安装即可（详细步骤与代理梯子相关的常见坑见移动端同步 — 配对一台 iPhone）。

Android 侧装 UniClipboard Android 客户端： github.com/UniClipboard/UniClip， APK 在 releases 页下载侧载（暂不发布到 Google Play）。其他任意 SyncClipboard 协议兼容客户端也可以填入相同的 base URL + 凭据接入。

不论用哪个客户端，移动端同步都走「HTTP 伴侣（companion）」模式：桌面守护进程暴露一个 SyncClipboard 兼容的 HTTP 服务，客户端用 base URL + Basic Auth 与之读写。原内置的 iOS 快捷指令仍然作为备选保留。

"伴侣"的含义在使用上是：

双向工作。 桌面 → 移动端和移动端 → 桌面都可以。
不走 P2P。 移动端同步走的是普通 HTTP —— 不走 iroh P2P、不做 NAT 打洞、也不会回落到加密中继。同一 LAN 下开箱即用；需要跨网络时，自建无头 server 节点（公网 HTTPS 端点）或走 Tailscale / VPN overlay。
移动端不是真正的对端。 移动设备不会加入空间的信任网络，也不会在移动设备之间互相同步；它们只与配对的那一台桌面互通剪贴。

端到端配置流程见移动端同步指南，协议细节见移动端 LAN API，配对界面见配对与同步 — 移动端伴侣。

iOS App 为什么不能像桌面那样在后台静默同步剪贴板？

这是 iOS 系统层的限制，不是我们可以绕开的实现问题。 iOS 没有给第三方 App 一个"系统剪贴板变化时唤起后台读取"的通用钩子： UIPasteboard 只在 App 处于前台时能稳定读到，挂起态的 App 不会被系统按剪贴板变化拉起；如果尝试常驻后台轮询，会被调度器杀掉，而且每次读取还会触发系统级的"已从 XX 粘贴"横幅提示。

落到 UniClipboard iOS App 上的具体表现是：

接收路径只在前台工作。 桌面端的新内容只有在你把 App 调到前台时（或者命中我们下发的通知再点开时）才会落到剪贴板，做不到桌面那种持续静默同步。
发送也需要用户主动操作。 在其他 iOS App 里复制的内容不会自动外发 —— 需要你切回 UniClipboard（或调用我们提供的 iOS 快捷指令）把当前剪贴板推出去。
大厂也撞同样的墙。 微信输入法之所以可以同步剪贴板，也只是在键盘被调起的那一刻读取，不是真正的后台静默同步。这是 iOS 的沙箱约束，跟厂商规模无关。

未来可能的方向是做一个 输入法 / 面板形态的伴侣 —— 切到 UniClipboard 的输入面板时，iOS 给到一个合法的读写窗口，可以推拉一次剪贴板。这件事我们在评估，但不承诺；即便做出来，也不会变成"永远在后台静默同步"，因为底层系统约束并没有变。

如果你确实需要永远在线的剪贴板同步，请把桌面端（macOS / Windows / Linux）作为常驻对端，iOS App 更合适的定位是"按需触发的伴侣客户端"。