Ntfy：服务器出事了，让手机立刻响一声
推送这件事看起来简单，实际有三个坑：第三方服务要收费、手机厂商的推送通道不可控、以及「怎么在不暴露服务器的情况下发通知」。
一、它的设计：一条 HTTP 请求就是一条通知
curl -d "备份失败：/data 空间不足" ntfy.sh/我的私密主题没有 SDK、没有密钥交换、没有复杂配置。任何能发 HTTP 请求的东西都能发通知——脚本、cron、容器健康检查、甚至是路由器的告警。
这个极简设计的好处是在所有环境里都能用：老旧设备、受限网络、没有外网权限的脚本，只要能发一个 POST 就行。
二、自建部署
services:
ntfy:
image: binwiederhier/ntfy
restart: unless-stopped
command: serve
ports: ["8089:80"]
volumes:
- ./cache:/var/cache/ntfy
- ./ntfy.yml:/etc/ntfy/server.yml
environment:
- TZ=Asia/Shanghai配置文件里至少要设两项：
base-url: "https://ntfy.你的域名"
cache-file: "/var/cache/ntfy/cache.db"不设 base-url，手机端订阅后会拿不到消息（回连地址错）。这条是自建版最常见的「装好了但收不到」的原因。
三、安全：一定要加访问控制
公开的推送服务意味着任何人都能往你的主题发消息——垃圾通知还是小事，钓鱼链接才麻烦。
三种做法，从简到严：
- 主题名足够随机（长随机串），等于「知道地址才能发」；
- 开启访问令牌，发送时带
Authorization: Bearer； - 整个服务加一层登录（反向代理 + 统一认证），适合内部使用。
个人用第二种就够：令牌存在脚本的环境变量里，泄露风险很低。
四、和监控串起来
真正有用的不是「能发通知」，是「该发的时候才发」。几个实际配置：
| 场景 | 触发方式 | 备注 |
|---|---|---|
| 备份失败 | 脚本末尾判断退出码 | 只在失败时发，成功不发 |
| 磁盘快满 | 定时检查 df 使用率 > 85% | 每小时一次，带渐进的优先级 |
| 服务挂了 | 监控工具的告警钩子 | 恢复时也发一条，否则不知道什么时候好的 |
| 长任务完成 | 任务收尾调用 | 比盯着终端省事 |
优先级字段（Priority）要用起来：普通通知静默，紧急通知响铃。全部按最高优先级发，人会很快学会忽略所有通知。
五、和手机厂商推送的关系
自建推送在安卓上要靠常驻连接（后台服务），iOS 上则依赖其官方推送中转——这一点无法绕开。所以「完全自建、不依赖任何第三方」在移动端是不成立的，能自建的只是「消息的源头」。
知道这个前提，就不会在「为什么 iPhone 收不到」上浪费时间：检查应用是否允许后台通知、是否被省电策略杀掉。
六、什么时候不需要它
如果你只有一条要通知的事（比如网站挂了），直接用监控工具自带的邮件通知就够，不必为此再维护一个服务。它的价值在「多个来源、多种级别、统一的接收端」。
监控工具的部署见 Uptime Kuma；指标可视化见 Grafana + Prometheus。
相关阅读
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论