简介这是一款基于 Go 语言开发的轻量级推送通知工具 ntfy面向需要向手机或桌面实时推送消息的开发者和运维人员。它通过简洁的 PUT/POST 请求即可触发通知适用于服务报警、脚本执行提醒、定时任务状态推送、IoT 事件通知等场景省去自行搭建消息通道的麻烦。资源包共包含 415 个文件压缩后约 12.89MB主要涵盖 106 个 Go 源码文件、前端界面常用的 js/jsx/css、png/svg/ico 图标与图片素材以及 Dockerfile、配置文件、说明文档等目录结构清晰便于按需查阅与二次开发。目前已有 1658 人学习下载受到较多开发者关注。对自建通知服务或研究 Go 工程实践的读者而言这份资源提供了可运行的服务端源码、Web 管理界面、容器化部署方案和移动端接入示例覆盖从部署到调用的完整链路既能直接用于生产环境也可作为项目学习参考。1. 为什么我弃了一堆商业推送最后留下了 ntfy做运维和自托管这行久了通知推送这个事儿绕不过去。服务器报警要通知脚本跑完要通知下载任务结束要通知CI/CD 构建结果也要通知。前前后后我试过 Telegram Bot、Server酱、Pushover、Bark 这些方案各有各的问题。第三方服务要么有消息频率限制要么依赖外部网络状况要么就是客户端体验不够顺手。直到我用上了 ntfy才觉得这个事儿终于清爽了。ntfy读作 notify是一个开源的、基于 HTTP 的推送通知服务核心思路特别朴素你往一个 URL 发一条 HTTP 请求订阅了这个主题的设备就能立刻收到推送。它支持手机 App、桌面浏览器、命令行工具等多种订阅方式可以自己部署也可以用官方公共实例 ntfy.sh。对我来说最吸引人的是两件事一是自托管之后数据完全在自己手里二是对接方式极其简单curl 一条命令就能发通知比什么 SDK、API 封装都来得直接。这篇文章写给谁如果你有服务器、NAS、树莓派或者你平时写脚本跑自动化任务想找一种“一旦有事能立刻叫醒你”的通知方式那 ntfy 很适合你。就算你是零基础用户只想来个简单的手机推送照着文章里最简单的方式也能搞定。我尽量把部署、配置、避坑这些实操细节都讲透都是自己踩过之后沉淀下来的经验。1.1 一次需求变化让我重新审视推送工具最初我用的是某商业推送服务绑定 App 之后往里发请求就行。一开始还挺满意后来有次服务器凌晨宕机报警消息因为对方服务限流被丢了第二天一早我才发现网站挂了几个小时。那次之后我就决定通知链路必须自建不能把命脉掐在别人手里。选型时我列了这几个硬性要求部署足够简单最好一个容器搞定API 足够通用任何语言都能调客户端体验要好推送延迟要低最好还支持权限控制不至于裸奔在公网上。逐个筛下来ntfy 几乎完全命中。它服务端是 Go 写的单二进制文件部署几乎没有依赖数据库用的是 SQLite缓存消息也不需要额外装 Redis。客户端覆盖 Android、iOS、Web、桌面还支持命令行订阅一条命令就能在终端里收消息。1.2 HTTP Topic 的思路到底精妙在哪ntfy 最核心的抽象是“主题”Topic你可以把它理解成一个微信群聊的群名。发布者往这个主题发消息订阅者就会收到。它的 API 就是普通 HTTP比如curl -d 服务器磁盘空间不足 ntfy.sh/myserver-alerts就这么一行任何能发 HTTP 请求的工具都成了你的通知发送器。没有 SDK 的繁琐不用引入依赖也不限制编程语言。我的脚本里直接curl、python requests、Node fetch都试过全部畅通。这套设计的新颖之处在于它把推送这个“应用层能力”降维成了“HTTP 请求”让任何终端都能轻松对接。1.3 和其他方案的直观对比我顺手整理了一个对比表方便你判断自己的需求落在哪儿方案部署方式接入成本客户端体验适合场景ntfy自托管单容器极低curl即可Android/iOS/Web/桌面全支持自托管爱好者、开发者Telegram Bot官方服务较低需要外网访问官方App体验好能接受依赖第三方服务Server酱官方服务极低微信接收依赖微信国内快速接入Bark自托管或公共实例较低iOS专用仅iOS苹果生态用户如果你追求可控性和通用性ntfy 的优势非常明显。如果你的需求是一次性接个微信提醒那 Server酱也许更省事。工具没有绝对好坏合适才最重要。2. 自建 ntfy 服务部署与基础配置我用 Docker 部署这是目前为止最省心的方式。以下是我的实际部署过程包含配置细节和一些容易忽略的坑。2.1 Docker 快速部署先创建一个数据目录用于持久化配置和缓存mkdir -p /opt/ntfy/data mkdir -p /opt/ntfy/etc然后写一个简单的docker-compose.ymlversion: 3 services: ntfy: image: binwiederhier/ntfy:latest container_name: ntfy command: - serve environment: - TZAsia/Shanghai volumes: - /opt/ntfy/data:/var/lib/ntfy - /opt/ntfy/etc:/etc/ntfy ports: - 8080:80 restart: unless-stopped启动docker compose up -d注意几点。第一镜像里的默认端口是 80我映射到宿主机的 8080避免和已有服务冲突。第二/var/lib/ntfy是数据目录消息缓存和用户数据库都存在这里必须持久化否则容器重建消息全丢。第三环境变量里我设置了时区以后消息时间显示会正常。服务起来后浏览器访问http://你的服务器IP:8080能看到 ntfy 的 Web 界面就说明成功了。2.2 关键配置项解析与踩坑点ntfy 的配置主要写在/etc/ntfy/server.yml里。先给几个我实际用到的配置项# 外部访问的基础URL务必改成你的实际域名或IP base-url: http://your-domain.com # 监听地址默认监听所有网卡 listen-http: :80 # 消息缓存文件 cache-file: /var/lib/ntfy/cache.db # 缓存消息条数 cache-messages: 5000 # 消息在没有订阅者时是否缓存等订阅者上线再推 cache-duration: 12h # 是否开启用户注册功能 auth-default-access: deny-all enable-signup: false这里我踩过一个坑base-url如果配错手机 App 扫码后连接会失败提示地址不对但服务端日志里一切正常。这个问题很隐蔽排查了我半小时。提醒你配置修改后要重启容器生效docker compose restart2.3 添加访问控制和用户体系服务部署完了最重要的事就是加权限。初始状态下 ntfy 是允许所有人读写的就像群里所有人都能发消息这在公网上等于裸奔。好在 ntfy 天然支持基于用户和 Access Control ListACL的权限控制。先创建一个管理员用户docker exec -it ntfy ntfy user add --roleadmin myadmin然后设置密码按提示输入两次即可。接着创建普通用户每个用户对应一组主题权限docker exec -it ntfy ntfy user add alert-user docker exec -it ntfy ntfy access allow alert-user write-only server-alerts上面这条命令的意思是alert-user只能向server-alerts主题写消息不能读取。这个场景对应你的监控系统它只需要发不需要收。同理你自己作为个人用户可能需要某个主题既能读又能写docker exec -it ntfy ntfy access allow myuser read-write my-notes配置好之后往受保护的主题发消息就需要认证了格式为https://ntfy.example.com/主题名请求头加上curl -H Authorization: Bearer tk_你的访问令牌 -d hello https://ntfy.example.com/server-alerts访问令牌可以通过 Web 界面生成也可以在命令行里用ntfy token add命令创建。这种方式比直接用密码更安全适合脚本环境因为令牌可以单独撤销不用改密码。3. 手机和桌面的接入与日常玩法部署好了服务端接下来就是各种端上的接入。这一部分是普通用户最容易卡住的地方我详细拆开讲。3.1 手机端 App 安装配置Android 端在 F-Droid 或者 Google Play 搜 ntfy 就能装。iOS 端在 App Store 搜索 ntfy 即可。安装后打开 App点击右上角的设置图标进入“设置”页面找到“服务器地址”一栏填写你自建服务的地址比如https://ntfy.example.com。然后回到主界面点击“添加订阅”输入主题名称比如server-alerts。如果你在服务端配置了权限还需要在“用户名/密码”或者“访问令牌”里填上对应的凭证。一切正常的话App 会显示“已连接”之后对应的推送就都能收到了。这里有一个 Android 特有的坑部分国产手机系统为了省电会自动杀掉后台 App导致推送延迟甚至完全收不到。你需要把 ntfy 加入电池优化的白名单并在系统设置里允许它自启动。iOS 端因为是走 APNs后台问题少很多但也要保证 App 的通知权限是开启的。3.2 桌面端与浏览器的接入方式桌面端其实不用装什么重量级客户端。ntfy 提供了一个 Web 界面你直接在浏览器里打开服务器地址登录后能看到所有订阅的主题也能在网页上发消息。这个方案对我这种经常在不同电脑之间切换的人来说最舒服浏览器开着就能收不用装软件。如果你在终端里办公多ntfy 还有命令行客户端。安装方式curl -sSL https://github.com/binwiederhier/ntfy/releases/latest/download/ntfy_linux_amd64.tar.gz | tar -xz sudo mv ntfy /usr/local/bin/之后订阅主题ntfy subscribe --usermyuser:pass https://ntfy.example.com/server-alerts命令行订阅主要用于调试或配合 tmux 在后台常驻接收消息。3.3 实用玩法从监控告警到自动化提醒服务跑起来、客户端接好了玩法就多了。我这里列几个我自己常用的场景你可以参考着改造。第一服务器监控告警。配合 Uptime Kuma 或 Zabbix把 webhook 地址填成https://ntfy.example.com/server-alerts在请求头里加上认证令牌。我自己的服务器 CPU 过载、磁盘不足、服务宕机都是通过这个链路第一时间收到推送。第二脚本执行结果通知。比如每天凌晨的数据库备份任务备份成功、失败都发一条到backup-status主题我早上起床一翻手机就知道昨晚备份有没有问题。脚本里一行 curl 就够了curl -H Authorization: Bearer tk_xxx \ -H Title: 数据库备份 \ -H Priority: default \ -d 备份成功耗时 3 分 20 秒 \ https://ntfy.example.com/backup-status第三下载任务完成通知。我用的是 qBittorrent 的 Webhook 功能下载完成后往downloads主题发一条消息带上文件名和保存路径省得每天刷客户端看进度。第四智能家居联动。如果你用 Home Assistant直接在自动化里调用 REST API 就能往 ntfy 发消息比如“门锁已打开”“烟雾报警器触发”比折腾各种专用推送组件省事得多。4. 常见问题与排查技巧实录实践多了总会遇到各种问题我把我遇到过的、以及朋友踩过的一些坑整理成速查表希望能帮你少走弯路。问题现象可能原因解决方案手机收不到消息但 Web 界面正常系统后台优化杀掉 App加入电池白名单允许自启动收不到消息服务端日志没有请求防火墙没放行端口检查 80/8080 端口是否开放App 订阅时提示连接失败base-url配置错误或 HTTPS 证书问题检查 server.yml 的 base-url访问域名是否 HTTPS发消息提示 401权限配置有问题或令牌无效检查用户权限和令牌是否对应消息延迟严重网络问题或 App 被省电策略限制检查网络调整系统电池策略重启容器后历史消息丢失数据目录没有挂载持久化确认 volumes 配置正确4.1 收不到消息的排查顺序遇到收不到消息我一般按这个顺序排查先看服务端日志docker logs ntfy有没有请求记录再看客户端能否正常连接服务器接着看是不是走了代理或 HTTPS 证书有问题最后查手机系统设置。大部分问题都出在最后两步尤其是国产手机的系统省电策略这属于“非技术性”问题但也是最容易让人崩溃的。4.2 公网暴露的防护建议如果你打算把 ntfy 暴露到公网我强烈建议加一层反向代理并用 HTTPS 加密传输。我自己是用 Caddy 简单配置的Caddy 会自动申请和续期证书ntfy.example.com { reverse_proxy 127.0.0.1:8080 }这样外部访问就是https://ntfy.example.com证书自动搞定。另外别忘了在防火墙层面仅放行 80、443 端口ntfy 的 8080 只允许本机访问避免绕过代理直接裸奔。还有一点如果你用的是默认配置且开了注册功能公网上任何人都能注册用户既浪费资源又有安全隐患。建议像我一样把enable-signup设为false用户全部用命令行创建权限按需分配。4.3 消息延迟与缓存机制ntfy 默认会缓存一段时间的消息好处是如果手机暂时离线等它上线后能收到缓存期间错过的消息。缓存时长和条数都可以在 server.yml 里调整。我设置的是 12 小时、5000 条对日常使用完全够用。注意缓存不是永久存储如果你需要消息长期留存建议同时对接一个日志系统比如直接把消息写入文件或数据库。延迟方面我用自建服务实测下来手机推送延迟基本在 1 秒内有时候甚至感觉是即时到达。这点比某些“定时轮询”的方案体验好很多也是我一直用它作为主力通知工具的重要原因。4.4 一个小经验先跑通最小链路最后分享一个我在接入任何新工具时都会用的经验先跑通最小链路再扩展功能。所谓最小链路就是服务端部署好之后先在终端用 curl 发一条消息到某个主题同时手机 App 订阅这个主题确认能收到。这一步通了说明基础设施没问题。之后再逐步添加权限、反向代理、HTTPS、多用户、自动化脚本每加一块就测试一块定位置永远是最小的问题域排查效率高很多。我最初就是从 curl 发消息、手机收消息这一步开始的整个过程前后不到 10 分钟。后来才慢慢加上 HTTPS、权限控制、监控告警和各类自动化脚本。到现在ntfy 已经成了我日常运维里最离不开的基础设施之一。按这个思路走你也能快速搭起一套自己的推送中枢。本文还有配套的精品资源点击获取