yetone/alma-relay

Alma Relay 是 Alma 远程访问功能的自建中继服务。桌面版 Alma 主动向中继建立一条出站 WebSocket 长连接；手机上的 Alma App 通过 HTTPS/WSS 访问同一中继，中继再把 HTTP、流式 SSE 和 WebSocket 请求沿桌面已有的连接转发下去。适用场景是：你希望桌面远程控制走自己掌控的基础设施、选择更近的区域，或不依赖官方托管的 relay.alma.now（README）。

部署方式及各自前提

项目给出三种运行同一中继的路径，前提各不相同：

• Cloudflare Workers，作者称免费、无需服务器，使用 SQLite 后端的 Durable Objects 和 WebSocket 休眠机制，请求体上限固定为 24 MB。自带 TLS 和 *.workers.dev 域名；用自己的域名需要修改 routes（README）。
• Docker + 自动 HTTPS，需要一台开放 80、443 端口且 DNS 指向它的 VPS，证书由 Caddy 自动申请和续期（README）。
• 放在自己的反向代理后面，可用发布的容器镜像，或用 Node ≥ 20 直接运行。代理必须允许 WebSocket 且不能缓冲响应；README 给了 nginx 和 Caddy 配置示例以及 /healthz 检查方式（README）。

所有配置都通过环境变量完成，且均为可选项。其中两个影响谁能使用中继：不设密钥时，任何知道地址的人都能在中继上开隧道（但要连到你的桌面仍需 256 位连接码）；RELAY_REGISTRATION_KEY 用共享密钥限制注册；RELAY_TOKEN_SECRET 则改为签发按用户区分的 JWT，适合团队共用一台中继，轮换密钥即可让所有令牌失效（README）。

安全模型与限制

开启端到端加密时（新配对默认开启），手机与桌面会做带认证的 ECDH 握手并派生 AES-256-GCM 会话，连接码参与密钥派生。中继运营方只能看到密文，连接码、令牌和流量都不会写入磁盘或日志（README）。这一保证依赖客户端版本：需要 Alma 0.4.329 或更新版本，因为更早的桌面端仍会响应中继自己发出的明文请求。README 仍建议始终使用 HTTPS，因为 TLS 还能隐藏路由元数据，而内容本身已有端到端加密保护（README）。

有两个功能还有额外限制。手机通知走 Apple Push，而 Apple 只接受签名该 App 的团队密钥，因此自建中继无法向官方 Alma iOS App 推送通知，其余功能不受影响；自行构建的 iOS App 可以提供自己的 APNs 密钥（README）。桌面浏览器的实时画面走 WebRTC，多数网络需要 TURN 服务器：Docker 方案已包含 coturn 及相关端口配置，Cloudflare 用户则需在别处运行 coturn 并配置凭据（README）。

实用说明

切换中继前已配对的手机需要重新扫描配对二维码，因为配对链接里带的就是中继地址（README）。项目采用 MIT 许可证（LICENSE）。仓库还提供了协议文档，可用于自己实现中继或 agent，并附有覆盖两种版本的端到端测试套件（README）。