ntfy 自托管推送服务器

解决什么问题

凌晨三点，backup.sh 静默失败；CI 流水线红掉的时候，值班同事正在睡觉；cron 任务跑完了，没人知道它是成功还是沉默。传统方案要么依赖邮件（没人看），要么接入 iOS/Android 推送（要账号、要审核、要凭证），对脚本和机器来说太重。

ntfy 把这件事压成一次 HTTP 请求：任何能发 PUT 或 POST 的进程——shell 脚本、CI step、定时任务、容器、IoT 网关——都能把一条消息推给订阅了同一主题的人，手机、桌面浏览器、桌面客户端都能收到。

它如何工作

• 发布/订阅模型：主题名由发送方随意指定（如 server-down、nightly-backup），订阅方通过 Web 页面、Android/iOS 客户端或原始 HTTP 长连接订阅同名主题，两者无需事先认识，也无需注册账号。
• 发送一条通知：向 http(s)://<host>/<topic> 发一个 PUT/POST，请求体就是通知正文，一行命令就能完成，没有 SDK、没有配置文件。
• 行为由 HTTP 头控制：X-Priority 设定紧急程度（视觉样式与声音），X-Tags/X-Icon 指定图标和 Emoji 标记，Action 增加可点击按钮，Deliver-By 实现延迟投递，Click 让点击后跳转指定地址。
• 自托管要点：单二进制或容器部署，用 YAML 配置 listen 监听地址、base-url 对外访问域名（不配会导致客户端订阅地址错误）、磁盘缓存路径，以及可选的认证用户与访问令牌。
• 访问控制：可开启用户名/密码、Bearer token、限制谁能创建主题，适合多团队共享同一实例时按主题隔离。

适用边界

• 不是短信或邮件网关，也不保证送达率——推送依赖客户端在线并保持连接，离线期间的消息在客户端重新连上后才收到（受缓存时间限制）。
• 移动端后台推送仍走系统通道，自托管实例无法替代 APNs/FCM 的系统级投递能力。
• 单机内存/磁盘缓存的容量有限，海量主题或高并发分发需要横向拆分或限制主题数量。
• 默认不带 TLS，暴露在公网请在前面挂反代终止 HTTPS，否则订阅链接可能被中间人改写。
• 适合告警、构建结果、任务完成提醒这类低延迟、短生命周期的消息，不适合做持久化消息队列或聊天系统。