区块链中文技术社区

ntfy 推送通知工具指南

ntfy 推送通知工具指南

一、工具简介

ntfy 是一款开源的 HTTP 推送通知服务,使用 Go 编写,单二进制发布,采用 Apache-2.0 协议。

核心目标: 解决脚本、训练、爬虫等长时间任务完成后,无法及时获知结果的问题。

核心特点:

  • 一行 curl 命令即可发送通知
  • 公共服务器 ntfy.sh 免费使用,无需注册、无需 API Key
  • 手机端 App(Android / iOS,均开源)订阅同一 Topic 即可接收
  • Topic 名称即权限凭证,务必使用足够复杂、难以猜测的名称

二、基础用法示例

发送简单文本通知

curl -d "备份完成了" ntfy.sh/mytopic-secret123

带标题、优先级、标签的通知

curl -H "Title: 构建失败" \
     -H "Priority: urgent" \
     -H "Tags: warning,skull" \
     -d "第 3 步测试挂了" \
     ntfy.sh/mytopic-secret123

推送文件(如日志、截图)

curl -T error.log \
     -H "Filename: error.log" \
     ntfy.sh/mytopic-secret123

三、适用人群与注意事项

推荐使用

  • 经常写脚本做自动化任务的开发者
  • 需要轻量级运维报警的运维人员
  • 自托管玩家,希望自建私有推送通道

谨慎使用

  • 仅需简单 IM 转发的轻度用户(微信群发可能更顺手)
  • 介意数据经过第三方服务器、又不愿自建服务的用户

重要提醒

  • iOS 用户注意: 使用公共服务器时,后台推送可能存在延迟;如需稳定推送,建议自建服务并配置推送证书(比 Android 复杂)。
  • Android 用户体验更顺畅,推荐优先使用。

四、快速上手步骤

方式一:零安装体验(5 分钟)

  1. 构思一个复杂难猜的 Topic 名称

  2. 终端执行:

    curl -d "hello from terminal" ntfy.sh/你的topic名
  3. 手机安装 ntfy App 并订阅相同 Topic

方式二:完整体验(20–30 分钟)

  1. Android: Google Play / F-Droid 搜索 ntfy
  2. iOS: App Store 搜索 ntfy
  3. 打开 App → 订阅 → 输入 Topic 名称

方式三:自托管(可选)

适合对数据隐私有要求的用户:

docker run -p 80:80 -it binwiederhier/ntfy serve

详细文档:https://docs.ntfy.sh/install/


五、项目信息

项目字段 内容
项目名称 ntfy
GitHub https://github.com/binwiederhier/ntfy
官网 https://ntfy.sh
Star 数 ~3.2 万(截至 2026-07-14)
开源协议 Apache-2.0

六、一句话评价

ntfy 将「被通知」从 IM 中解耦,封装成可编程的 HTTP 接口,是自动化工具链中极其轻量、实用的一块拼图。

一款用于分析任何网站的一体化开源情报工具

官网:https://web-check.xyz/
github: https://github.com/lissy93/web-check

目前仪表盘将显示:IP 信息、SSL 证书链、DNS 记录、Cookie、标头、域名信息、搜索抓取规则、页面地图、服务器位置、重定向记录、开放端口、路由追踪、DNS 安全扩展、网站性能、跟踪器、关联主机名、碳足迹。

你还在使用 WebSocket 实现实时消息推送吗?

一、写作背景与核心主题

本文针对服务端主动向客户端推送数据的常见业务场景(数据大屏实时刷新、消息中心未读提醒、在线聊天等),对比分析了三类主流实现方案的优劣,重点介绍了 SSE(Server-Sent Events,服务端推送事件) 的使用场景、核心API与落地实践,帮助开发者根据业务需求选择更合适的推送方案。


二、三类实时推送方案全面对比

方案 核心原理 优点 缺点 适用场景
轮询 客户端定时/不间断向服务端发起HTTP请求,模拟“推送”效果 实现简单,兼容所有浏览器 1. 每次请求都要经历HTTP建连/断连流程,资源浪费严重
2. 长期占用浏览器并发名额(Chrome同域名并发限制为6)
3. 轮询间隔短则耗资源,间隔长则实时性差
仅作为浏览器完全不支持WebSocket和SSE的兜底方案,不推荐常规使用
WebSocket 基于ws/wss协议的全双工双向通信,客户端和服务端可随时互相发送数据 1. 双向通信能力强
2. 实时性极高
3. 现代浏览器兼容性良好
1. 是独立于HTTP的新协议,需要服务端额外适配支持
2. 协议复杂度高,相对“重量级”
3. 断线重连需要自行实现
需要双向交互的场景:在线聊天、多人协作编辑、实时游戏等
SSE 基于HTTP/1.1的单向长连接,仅支持服务端主动向客户端推送数据 1. 轻量,协议复杂度远低于WebSocket
2. 完全复用现有HTTP服务端生态,无需额外适配
3. 默认支持断线重连
4. 客户端资源消耗低
5. 支持自定义数据类型
1. 仅支持单向通信(服务端→客户端)
2. IE浏览器、小程序不支持
仅需服务端单向推送的场景:数据大屏实时数据、消息中心通知、系统公告、日志实时输出等

三、SSE核心知识点详解

1. 连接状态(readyState

通过EventSource实例的readyState属性可获取当前连接状态:

  • 0(对应常量EventSource.CONNECTING):连接未建立,或连接已断线正在重试
  • 1(对应常量EventSource.OPEN):连接已建立,可正常接收数据
  • 2(对应常量EventSource.CLOSED):连接已断开,且不会重连

2. 核心事件监听

事件名 触发时机 典型用途
open 连接成功建立时触发 初始化页面状态、打印连接成功日志
message 收到服务端推送的数据时触发 解析数据并更新页面UI
error 发生通信错误、连接中断时触发 提示用户连接异常、记录错误日志

3. 服务端响应规范

SSE要求服务端返回特定的HTTP响应头和数据格式:

Content-Type: text/event-stream  # 声明SSE流式数据格式
Cache-Control: no-cache         # 禁止缓存,保证数据实时性
Connection: keep-alive          # 声明长连接

数据体格式必须以data:开头,两个换行符\n\n结束:

data: {"message": "Current time is 10:30:00"}\n\n

四、SSE实战Demo说明

文章提供了原生HTML前端 + Node.js Express后端的完整可运行示例,无需任何框架即可验证SSE效果:

1. 前端实现逻辑

  • 首先检测浏览器是否支持window.EventSource,不支持则抛出错误
  • 通过new EventSource('http://localhost:8088/sse/')建立SSE连接
  • 监听open/message/error事件,收到数据后动态创建<li>元素插入页面
<script>
if (!!window.EventSource) {
  const source = new EventSource('http://localhost:8088/sse/');

  source.onopen = () => console.log("SSE连接已建立");

  source.onmessage = (event) => {
    const data = JSON.parse(event.data);
    const li = document.createElement("li");
    li.innerHTML = data.message;
    document.getElementById("ul").appendChild(li);
  };

  source.onerror = () => console.log("SSE连接中断");
} else {
  throw new Error("当前浏览器不支持SSE");
}
</script>

2. 后端实现逻辑(Node.js Express)

  • 配置跨域支持,允许前端页面访问
  • 设置SSE要求的响应头
  • 通过setInterval每秒向客户端推送一次当前时间
const express = require('express');
const app = express();
const port = 8088;

// 跨域配置
app.all("*", (req, res, next) => {
  res.header("Access-Control-Allow-Origin", "*");
  res.header("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Requested-With");
  res.header("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS");
  req.method === 'OPTIONS' ? res.sendStatus(200) : next();
});

// SSE接口
app.get("/sse", (req, res) => {
  res.set({
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive'
  });

  setInterval(() => {
    const data = { message: `Current time is ${new Date().toLocaleTimeString()}` };
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  }, 1000);
});

app.listen(port, () => console.log(`服务启动成功:http://localhost:${port}`));

五、关键结论与注意事项

  1. 选型优先级:能用SSE解决的单向推送需求,不要用更复杂的WebSocket;需要双向通信再选WebSocket;轮询仅作为兜底方案。
  2. 兼容性提醒
    • SSE和WebSocket现代浏览器兼容性均较好
    • ❌ IE浏览器不支持SSE
    • ❌ 微信小程序不支持SSE
  3. 开发小技巧:轮询虽然不推荐用于生产环境,但开发调试时实现成本极低,适合快速验证逻辑。

Gatus 介绍:Go 语言编写的主动式健康监控状态页

Gatus 介绍:Go 语言编写的主动式健康监控状态页

核心定位

Gatus 是一款用 Go 开发的主动式健康状态监控面板(GitHub 10k+ Star),用于填补传统监控工具的盲区:

  • 传统监控(如 Prometheus Alertmanager)依赖流量触发告警,若服务无访问则无法发现故障。
  • Gatus 采用主动探测逻辑,按预设间隔主动检查端点,在用户感知问题前发出预警。
  • 核心公式:主动健康检查 + 可视化状态页 + 多通道告警
  • 支持 HTTP、ICMP、TCP、DNS、gRPC、WebSocket 等十余种协议,单 Docker 命令即可启动。

核心特性

特性 说明
灵活条件语法 不止校验状态码,可基于响应体(支持 JSONPath)、响应耗时、SSL 证书/域名过期时间等配置规则,支持数组长度、多值匹配、正则等函数,也可用于简易 UAT 测试。
Suite 端到端监控 支持串联多步请求,前序请求的返回结果可作为后续请求参数,实现「创建-更新-校验-删除」等完整业务流的可用性监控。
外部端点推送 内网服务无需暴露端口,可通过 Agent 主动推送健康状态,支持心跳检测,超时未上报即触发告警。
40+ 告警通道 覆盖协作工具(Slack/Discord/企业微信)、PagerDuty、短信、邮件、主流云厂商平台,支持自定义 Webhook;可配置「连续失败 N 次才告警」「恢复自动通知」。
SSH 隧道 可通过跳板机监控 Kubernetes 集群内或私有云内网服务。
生态兼容 暴露 Prometheus 指标,可对接现有监控体系;生成 SVG 状态徽章,可直接嵌入 GitHub README、文档站点。
低资源与安全 Go 实现,生产环境内存占用仅几十 MB,支持配置热加载、断网防误报,支持 Basic Auth/OIDC/mTLS 等安全特性。

部署与存储

部署方式

支持 Docker、Kubernetes Helm、Terraform、单二进制直接运行;配置文件支持多 YAML 文件拆分合并,便于多团队协作管理。

存储方案

存储类型 适用场景
Memory 快速体验,重启后数据丢失
SQLite 轻量单机部署、小团队/个人项目
PostgreSQL 生产环境、高可用需求

生产环境推荐 PostgreSQL + 写穿缓存,提升仪表盘加载速度。

同类工具对比

特性 Gatus Uptime Kuma Healthchecks.io
开发语言 Go Node.js Python
协议支持 极广(含 gRPC/SSH 等) 中等 较少
条件规则 灵活(支持 JSONPath/函数) 简单 简单
工作流监控 支持 不支持 不支持
SSH 隧道 支持 不支持 不支持
资源占用 极低 中等 中等

Gatus 更适合需要深度定制、监控复杂业务场景的技术团队。

适用场景

  1. 个人/小团队:快速搭建轻量监控,SQLite + 常用告警即可满足需求。
  2. 中大型团队:统一管理数百个微服务的健康状态,对接现有 Prometheus 监控体系。
  3. SaaS 产品:对外提供用户可见的服务状态页,搭配徽章展示历史可用性。
  4. DevOps 运维:补位传统监控盲区,实现无流量场景下的故障前置发现。

项目地址

GitHub:https://github.com/TwiN/gatus