ntfy vs Gotify：自托管通知与手机告警怎么选？

详细比较

先看通知要送到哪些设备

同时使用 Android、iPhone 和桌面浏览器，或希望多个接收端按主题订阅消息，可以先评估 ntfy。主要用 Android 接收自有脚本和服务通知，希望围绕用户及应用管理消息，可以先评估 Gotify。两者都能自托管，也都提供 HTTP 发布路径；真正影响选择的是接收设备、权限组织和离线后的处理方式。先列出备份、监控、自动化这些发送来源，再列出哪些人需要看到哪类消息。不要只比较第一条通知能否发出，因为设备休眠、网络变化和权限撤销才是长期使用经常遇到的条件。

依据：官方资料；选择条件为编辑分析。

当前版本让旧教程需要重新核对

截至二〇二六年十月十一日，官方最新发布标记为 ntfy 2.29.0 与 Gotify 3.1.1。本文依据当前官方文档分析，没有进行同机延迟、电量或吞吐测试。尤其要注意 Gotify 三代的迁移变化：旧的配置文件格式不再直接适用，已有令牌的读取方式也发生变化。网上能找到的两代教程，不一定适用于当前部署。选择 Gotify 并不意味着必须马上升级现有服务；应先核对客户端、脚本和备份恢复兼容，再安排隔离验证。新版本号本身也不是稳定性排名。

依据：官方资料、官方资料、官方资料；选择条件为编辑分析。

主题订阅与用户应用是不同组织方式

ntfy 围绕主题发布和订阅，适合把备份、网站状态和日常自动化分成不同消息流；多个接收端订阅同一主题前，应确认各自有合适权限。Gotify 则围绕用户、应用和客户端组织通知，官方说明用户管理自己创建的对象及消息。对一个人管理几项脚本，应用列表可能更直观；需要多人分别订阅消息时，应先画出授权关系。这里比较的是默认组织模型，不是断言其中一个无法扩展。采用前试着把一个发送源交给另一位维护者，看权限和交接步骤是否清楚。

依据：官方资料、官方资料；选择条件为编辑分析。

发送接口简单不代表凭据可以共用

ntfy 可通过 HTTP PUT 或 POST 发布消息，Gotify 的常见做法是创建应用，再用应用令牌向消息接口发送。两者都容易接入能发 HTTP 请求的脚本，但现成集成是否接受自定义地址、标题和认证头仍要核对。编辑建议每个发送来源使用可单独撤销的凭据，并避免把管理员身份复制进全部自动化。Gotify 三代令牌仅在创建或轮换时显示，依赖日后从接口重新读取令牌的旧流程需要调整。试选时应包括轮换一次凭据，并确认旧脚本不能继续发送。

依据：官方资料；选择条件为编辑分析。

Android连接方式要在休眠后验证

Gotify 官方提供 Android 客户端，使用连接状态的前台通知维持接收工作；ntfy 也提供 Android 应用，并区分不同接收与即时送达路径。是否能及时显示，仍会受设备的后台限制、网络连接和通知权限影响。本文没有电量测试，不能据此宣布某一方案更省电或永不漏报。编辑建议用实际手机检查锁屏一段时间后的通知、切换网络后的恢复，以及系统省电设置变化后的表现。如果维护者不愿处理持续连接与系统限制，应把这一成本写进选择，而不只看服务器安装步骤。

依据：官方资料；选择条件为编辑分析。

iPhone需求通常更倾向ntfy但有条件

ntfy 官方提供 iOS 应用；自托管服务器要实现即时通知，需要配置上游轮询请求转发，通常通过 ntfy.sh 接入 Firebase 与 APNs。官方说明转发的是原消息标识及主题地址的摘要，手机再向自有服务器获取正文。这与把正文直接发送到上游不同，但仍涉及外部推送链路，不能描述为完全独立离线接收。Gotify 官方主要提供服务器、网页与 Android 客户端，iOS 路径需另行核对第三方方案及维护责任。若 iPhone 是主要接收设备，先把后台送达和上游依赖验证清楚。

依据：官方资料、官方资料；选择条件为编辑分析。

浏览器关闭后是否通知要单独确认

ntfy 的网页应用可以安装成 PWA；自托管时需要配置 Web Push，才能使用相关后台通知能力。具体在标签页、网页应用或浏览器关闭后能否接收，还取决于平台支持、权限及浏览器推送服务。Gotify 提供网页界面和 WebSocket 接收路径，不能因为网页上看得到消息，就推断关闭浏览器以后仍有同样行为。编辑建议把桌面和手机浏览器分别测试，记录标签页打开、关闭与系统通知权限被撤销的结果。主要在桌面值守的人，与只靠手机后台通知的人，可能得到不同选择。

依据：官方资料；选择条件为编辑分析。

私有主题必须落实访问控制

ntfy 的主题名称不是天然的身份验证。当前官方配置说明默认回退权限为可读写，私有实例应配置认证、访问规则和默认拒绝，再分别给发送端与接收端所需权限。Gotify 的用户与应用归属也需要正确落实，不能把所有人放进一个共用账户后仍声称已经隔离。编辑建议以无凭据、只有发送权限、只有读取权限三种身份检查真实结果。消息内容避免放入密码、完整客户资料或后台密钥；自托管提供部署控制权，不能自动证明已经实现端到端加密或独立安全审计。

依据：官方资料；选择条件为编辑分析。

消息表现能力应服务后续处理

ntfy 提供优先级、标签和通知动作等发布选项，Gotify 通过优先级及 extras 表达显示和点击行为，客户端支持范围需要逐项核对。选型时可以试一条备份失败通知：标题应指出对象，正文给出失败阶段，点击后进入受权限保护的详情页。不要把危险管理动作直接塞进通知按钮，以免误触或凭据暴露。Gotify 官方还提示 Markdown 远程图片可能带来信息泄露，对脚本或外部输入可优先用纯文本。丰富显示只有在接收者能正确理解和处理时才有价值。

依据：官方资料、官方资料；选择条件为编辑分析。

离线补看与故障确认需要分别设计

ntfy 在服务端配置缓存后，可通过订阅接口的 since 参数获取仍在缓存内的消息；缓存期限和回放限制决定断网后能补看多少内容。Gotify 保存消息并提供管理与查询路径，也应核对实际数据库和客户端重新连接后的行为。两者的通知记录都不等于负责人已经看见，更不等于故障已经解决。编辑建议给重要告警加入事件标识，并由监控或工单系统承担确认、升级和关闭状态。短时断网可恢复多少条消息，应通过实际配置验证，不能把通知服务当成无限期审计档案。

依据：官方资料；选择条件为编辑分析。

代理连接与持久化也是选型成本

自托管需要维护 HTTPS、反向代理、持续连接、数据库及相关配置。Gotify 官方的代理文档强调 WebSocket 接入要求，代理超时或连接转发不合适时，网页能打开也可能无法正常接收。ntfy 使用的缓存、认证和 Web Push 状态同样需要按实际启用功能维护。编辑建议备份配置与持久化数据，并在隔离环境验证恢复后可以重新发送和订阅。这里没有资源对比实测，不能用镜像大小推断长期内存开销。主机容量、连接规模和维护人员能力应进入完整成本计算。

依据：官方资料；选择条件为编辑分析。

免费自托管与托管服务要分开算

两者都提供开源自托管路径，软件可用不意味着主机、域名、备份及运维时间没有成本。ntfy 另有官方托管服务，托管套餐、保留与附件额度不应直接套用到自有实例；需要购买时应再次核对当时的套餐页。Gotify 的自托管范围也不自动包含你需要的第三方移动端服务。编辑建议先写出每月需维护的主机与依赖，再判断是否愿意承担升级和故障处理。本文不引用未当次核验的订阅报价，不把免费标签转化为总成本排名。

依据：官方资料；选择条件为编辑分析。

用五个真实场景完成选择

准备同一组非敏感测试通知，依次检查正常发送、设备休眠、短时断网、凭据撤销，以及一次隔离恢复。Android 为主、用户与应用归属容易管理，可以优先试 Gotify；跨 Android、iOS 和浏览器订阅，且接受相应推送依赖，可以优先试 ntfy。再观察一条重复故障通知是否会造成刷屏，并确认发送失败时脚本能记录错误。现有方案已经满足设备覆盖、权限和恢复要求时，继续使用也合理。最终依据实际接收与交接结果选择，不依据未经测量的速度或安全分数制造统一赢家。

依据：官方资料；选择条件为编辑分析。