Ntfyxnotify x to me

使用说明

第一条 Ntfyx HTTPS 通知：从 hello 到服务检查

按步骤发送 hello，区分请求受理、收件验证与系统提醒，再设置合适的服务健康规则。附有日期和平台范围的 Android 模拟器实测及排查方法。

更新于

2026 年 10 月 17 日实际检查了什么

#

先验证一条容易辨认的消息：MyNotify 中的 hello。收发成功后，再定义服务怎样才算正常。HTTPS 与监控参考页介绍完整选项；本例围绕首次测试，以及结果不符时该如何判断。

检查实际观察测试环境
第一条 HTTPS 消息App 显示和复制同一条短 key 链接，通过发送测试按钮提交，并验证对应 MyNotify / hello 消息；观察到匹配的 FCM 回调、成功解密和系统通知记录。Ntfyx 1.5.2，Android 10 / API29 GMS 模拟器，连接真实 staging 服务。
响应丢失后的重试同一个持久化测试在故意丢失响应、重启及暂停/恢复期间进行了 4 次 GET，最终仍只有 1 条消息，经过验签、接收端解密和同步确认。iOS NtfyxCore 1.5.2 的 PhoneClient 在 macOS 运行，连接真实 staging 服务。
监控设置Android 验证了预览、新建、独立系统 Topic、暂停和删除；iOS 核心检查还覆盖文本/JSON 预览、私网地址拒绝及监控管理。真实 staging 请求；没有自然等待每小时异常与恢复。

1. 先在 App 发送 hello

#

简短 HTTPS 发送链接需要 App 1.5.2 或更高版本。本例从新收件箱和默认 MyNotify 开始；已有收件箱应使用自己链接中的 Topic 别名。如果之前的测试仍在等待，先检查原消息，再决定是否发送新测试。

  1. 打开该 Topic 的 HTTPS 推送页，确认发送链接已准备好。
  2. 点击“发送”（图示 1.5.2 为“发送测试通知”），保持 App 联网，等待对应通知。
  3. 在本例的新收件箱打开 MyNotify，核对标题和正文分别为 MyNotify、hello；再单独确认是否出现系统提醒。
Ntfyx Android HTTPS 推送页，显示 MyNotify、hello 的 Example 占位链接，以及发送测试和复制链接按钮。
Android 1.5.2 英文 Example 界面。图中 key 是占位内容，用于说明操作位置，并非实网 staging 送达过程截图。

2. 看清结果，再决定是否重发

#

请求被受理、收件箱验证了消息、系统显示提醒，是三个不同的判断。只收到 API 响应，还没有完成整条测试。

看到的状态说明了什么下一步
已受理／等待中服务已接受请求，App 尚未确认收到匹配消息。先让 App 同步；如果出现“检查投递”，先检查原消息，再决定是否发送新测试。
MyNotify 中对应的 helloApp 已收到并验证这条消息。收件链路已工作。没有横幅时，检查通知权限、Topic 静音时段和网络；Android 推送需要 Google Play 服务。
系统通知操作系统为这条消息发布了提醒。点击可进入会话；提醒送达不代表你本人已经看过或采取行动。

3. 复制链接，发送下一条自己的消息

#

从 App 复制完整链接。更换正文时，只替换最后的消息段，并按 UTF-8 百分号编码，例如 backup%20finished。保留 key 和 Topic 段。下面是 Example 占位链接，不能发送。

终端
https://api.ntfyx.me/v1/send/sk_EXAMPLE_KEY_123456789A/MyNotify/hello

4. 为自己的服务添加健康检查

#

第一条消息成功后，打开“发现 → 我的监控”。选择你了解预期响应的公开 HTTP 或 HTTPS 健康地址。图中的 example.com 地址仅作示意，操作时应填写自己的公开服务。

  1. 选择添加监控，填写地址，并取一个容易辨认的名称。
  2. 只关心成功状态时选择 HTTP 2xx；纯文本响应可选择“包含文本”。App 1.5.3 先获取响应预览，再填入大小写准确的预期内容，例如 ok。
  3. 点击“检查地址”，阅读返回状态和规则结果。结果不符时，先修正规则或服务。
  4. 结果符合预期后点击“启用监控”。后续每小时检查，不是连续可用性探测。
Ntfyx Android 添加监控页，使用 Example 健康地址、包含 ok 的文本规则和每小时检查频率。
Android 1.5.2 英文 Example 监控表单。该图不会创建监控，也不证明已观察到一次自然小时故障。

让规则真正区分正常与异常

#

文本规则按大小写匹配子串。如果 JSON 服务可能返回 status: not ok，搜索 ok 仍会匹配。这种服务应选择“JSON 字段”，字段填 status，预期值为字符串 ok。所有规则还要求最终 HTTP 状态为 2xx。下表是规则示例，不是实际故障日志。

响应示例文本包含 okJSON status 等于字符串 ok
HTTP 200 · {"status":"ok"}匹配匹配
HTTP 200 · {"status":"degraded"}不匹配不匹配
HTTP 200 · {"status":"not ok"}仍匹配，因为包含该子串不匹配
HTTP 503 · {"status":"ok"}HTTP 状态不符合要求HTTP 状态不符合要求

异常确认与恢复怎样工作

#

尚未进入故障事件时，首次检查失败会在 60 秒后复查；复查仍失败才发送一条异常提醒。持续失败会在后续每小时检查时继续记录并提醒。当前服务会记录每轮最终结果，包括持续失败和后续恢复。App 1.5.3 默认仅失败时推送，正常和恢复静默留在会话；关闭此选项则每轮都推送。每项监控在系统 My Monitor Topic 中保留独立 Session，让原因与恢复留在一起。