用海外云服务器自建 ntfy 推送通知服务完整教程：Docker 部署、访问控制与把脚本/告警/智能家居事件推到自己手机（2026 最新版）

Meta Description: 2026 最新 ntfy 自建教程：用海外云服务器 Docker 部署私有推送通知服务，覆盖 Nginx 反代 + HTTPS、访问控制 ACL 与访问令牌、Web Push、附件、iOS/Android 客户端与限流运维，附价格表与 10 条问答。

关键词：ntfy 搭建教程、自建 ntfy 推送服务器、ntfy Docker 部署、自建 Push 推送通知、ntfy 访问控制 ACL、ntfy 手机客户端、ntfy 服务器告警推送、ntfy 和 Uptime Kuma 区别、UnifiedPush 自建推送、海外云服务器自建推送服务

前言

结论先行：如果你要的是「让服务器、脚本、定时任务、智能家居里的任意一件事，主动把一条消息推到我自己的手机上，而且这条链路完全归自己、不经过 Telegram／钉钉／Server 酱这类第三方中转」，那么你要的既不是监控系统，也不是聊天工具，而是 ntfy——一个常驻内存只有几十 MB、一条 Docker 命令就能跑起来的自建推送通知服务。装好之后，任何能发 HTTP 请求的东西都能给你推消息：curl 一下就是一条通知，手机上的 ntfy App 秒收。

ntfy 的关键价值在于它是「一根你自己拥有的消息管道」：它不判断该不该通知，也不采集任何指标，只负责把一条消息从「产生它的地方」送到「订阅它的设备」。正因为它如此纯粹，它才能被塞进你现有的一切系统里——把服务器告警、脚本执行结果、备份完成、智能门磁触发、CI 构建失败，统统汇聚到一处。本文给出一份可直接复制执行的完整教程：从服务器选型、Docker 部署、Nginx + HTTPS 反代（含 WebSocket），到访问控制 ACL、访问令牌、发消息与收消息的所有姿势、附件与 Web Push、iOS 推送的特殊约束、限流安全加固，最后附一份配置价格对比表和 10 条常见问题解答。

🚀 需要一台海外云服务器来跑 ntfy？通过 5.chengzicloud.cloud 购买阿里云国际版 / 腾讯云国际版 / AWS，享专属折扣。

一、先搞清楚：ntfy 到底解决什么问题（与站内方案的分工）

一句话概括：ntfy 是一个「发布／订阅（pub-sub）」式的推送通知服务器。你向它的一个「话题（topic）」发布（publish）一条消息——用普通的 HTTP PUT/POST，或者命令行——任何订阅（subscribe）了该话题的设备都会立刻收到，包括手机 App、浏览器 PWA、命令行、以及另一个程序。它就干这一件事：把消息从发布者送达订阅者。截至 2026 年 10 月，官方最新版本为 v2.30.0，官方 Docker 镜像 binwiederhier/ntfy 覆盖 amd64 / armv6 / armv7 / arm64。

关键边界先说清：ntfy 不监控任何东西。它不知道你的服务是不是挂了，不采集指标，也不做日志聚合——它只是一根「送达管道」。判断「有没有出问题、该不该告警」是监控系统的职责；ntfy 只负责把已经决定好的消息发出去。这一点决定了它和站内若干既有文章的清晰分工：

顺便回答一个常见疑问：为什么不用 Telegram Bot / Server 酱 / Bark 这类现成推送，而要自建？ 因为它们本质上都是第三方中转——消息必须经过别人的服务器，可用性、隐私与长期政策都不由你控制；在国内访问 Telegram 还常常需要额外的网络条件。自建 ntfy 的价值，正是把这条链路收回自己手里：服务器是你的、域名是你的、消息不经他人服务器，内网环境里也能直达。代价当然也有——你要自己维护一台小服务器和一张证书。

两条反向边界务必先认清，否则容易用错工具：

• ① 它不判断「该不该通知」。 何时告警、阈值多少、要不要合并通知，是监控系统的职责。把「检测服务是否存活」的逻辑塞进 ntfy 是错位用法——那样你还得再写一套探测轮询，不如直接用 Uptime Kuma。
• ② 它不是即时通讯（IM）。 ntfy 是单向的「事件→通知」广播：没有会话、没有已读回执、没有群成员管理。需要双向聊天请用 Rocket.Chat，需要社群长帖讨论请用 Discourse。

一句话选型：要「判断服务好没好」用 Uptime Kuma，要「采集指标看趋势」用 Prometheus+Grafana，要「把任何系统里的任意事件送到自己设备」才轮到 ntfy。

二、部署前的硬性前置条件（三个先想清楚的点）

ntfy 本身部署极简，但有三件事必须先行确认，否则后面会返工：

1. 一个域名（或子域）。 浏览器 Web Push、手机 App 的 API 调用都要求 HTTPS + 有效证书；用一个子域如 ntfy.example.com 挂到你的域名下最省事。另外请记住：自建服务器若要用 iOS 客户端推送，必须保留 upstream-base-url 指向官方 ntfy.sh（详见第八节，这是整个方案里唯一一段无法完全自持的环节）。
2. HTTPS 证书。 ntfy 面向浏览器和手机 App，必须在 TLS 之后。用 Nginx 反向代理 + Let's Encrypt 即可，流程与站内《Nginx 反向代理 + SSL 证书配置完整指南》一致。
3. 一台能跑 Docker 的机器 + 放行端口的防火墙。 1 核 1G 起步即可（ntfy 极轻）；防火墙只放行 22 / 80 / 443，且反代必须把 /（包含 /v1/... API 路径与 WebSocket 升级）整体转发给 ntfy，不能只转某个子路径。

三、第一步：Docker 部署 ntfy 服务端

先建好目录与配置文件。注意官方 Docker 镜像里不带 server.yml，必须手动创建一份再挂载进去。在宿主机新建 /etc/ntfy/server.yml：

base-url: "https://ntfy.example.com"
listen-http: ":80"
cache-file: "/var/cache/ntfy/cache.db"
cache-duration: "12h"
behind-proxy: true
auth-file: "/var/lib/ntfy/user.db"
auth-default-access: "deny-all"

逐项说明（这几项是安全与可用性的关键）：

• base-url：实例对外的完整地址，配置错误会导致 Web Push 与点击链接失效，必须和你的域名完全一致；
• listen-http: ":80"：容器内监听 80 端口（这是 ntfy 的默认值），我们只把 80 映射到宿主机、由 Nginx 反代接管 TLS；
• cache-file + cache-duration: "12h"：把消息落盘缓存，默认缓存 12 小时——这样订阅端断线重连后还能补收这段时间内的消息；
• behind-proxy: true：告诉 ntfy「我在反向代理后面」，让它按 X-Forwarded-For 取真实客户端 IP（否则限流会把所有请求当成同一个 IP）；
• auth-file + auth-default-access: "deny-all"：把匿名访问全部关掉，任何人默认既不能读也不能写——这是把「公开服务器」变成「私有服务器」的核心开关（详见第五节）。

接着写 docker-compose.yml（与官方 compose 示例一致，去掉了注释以免 YAML 解析问题）：

services:
  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    command:
      - serve
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - /var/cache/ntfy:/var/cache/ntfy
      - /etc/ntfy:/etc/ntfy
      - /var/lib/ntfy:/var/lib/ntfy
    ports:
      - 80:80
    restart: unless-stopped
    init: true

启动与自检：

// 拉镜像并后台启动
docker compose up -d

// 健康检查，返回 {"healthy":true} 即为正常
curl -s http://127.0.0.1/v1/health

两个容易踩的坑：其一，若以非 root 用户（compose 里的 user:）运行，必须把 server.yml、user.db、cache.db 和附件目录 chown 成同一个 uid/gid，否则容器内写入会失败；其二，/var/lib/ntfy 必须持久化挂载——你的用户与访问令牌数据库 user.db 就在里面，不挂载则每次重建容器都会丢失所有账号。

四、第二步：Nginx 反向代理 + HTTPS（别忘了 WebSocket）

ntfy 的订阅端（手机 App、浏览器）会建立长连接，WebSocket 与长轮询都靠它。反代除了常规的 Host 与 X-Forwarded-* 头，还必须转发 Upgrade / Connection 并把读超时调大，否则通知会频繁掉线重连。下面是一份可直接用的 Nginx 配置（证书路径按你的实际替换）：

server {
    listen 80;
    server_name ntfy.example.com;

    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 1d;
    }
}

三个必须记住的点：① server.yml 里要同步设 behind-proxy: true，否则真实 IP 会被代理吞掉，限流和日志都会失真；② proxy_read_timeout 要放长（示例给 1 天）——订阅连接是「挂住等消息」的长连接，超时太短会导致手机端反复断线重连；③ 如果要发大消息或上传附件，记得调大 client_max_body_size：Nginx 默认 1M，而 ntfy 单条消息上限默认 4K（超出请改用附件），附件单文件默认上限 15M。配好证书后用 certbot --nginx 之类的工具签发 Let's Encrypt 证书即可。

五、第三步：访问控制——把「公开话题」变成「私有」

这一步绝不能省。 ntfy 默认是一台「任何人对任何话题都能读写」的公开服务器——如果不做访问控制就暴露到公网，等于免费给全网当推送网关，还会被人拿去做垃圾通知。私有化的做法是配置里已经写好的 auth-default-access: "deny-all"（匿名一律拒绝），再用内置的用户与权限系统逐个授权：

// 新增一个管理员用户（会提示设置密码）
docker exec -it ntfy ntfy user add --role=admin alice

// 给 alice 授予话题 mytopic 的读写权限（rw = read-write）
docker exec -it ntfy ntfy access alice mytopic rw

// 生成一枚访问令牌，供脚本、设备免密调用
docker exec -it ntfy ntfy token add alice

权限模型要点：每个用户对每个话题可单独设为 deny-all、read-only、write-only、read-write；也支持用通配符把整类话题授权给某个用户。发布端推荐用访问令牌而非账号密码——在请求头里带上 Authorization: Bearer 你的令牌 即可；订阅端（手机 App）则在 App 里填服务器地址、用户名和密码。这样「能发消息的脚本」和「能收消息的手机」可以各用各的凭据，某个令牌泄露只需单独吊销，不影响其它设备。

六、发消息：HTTP API、命令行与 JSON 三种姿势

ntfy 的发布接口就是一个普通 URL：向 https://你的域名/话题名 发 POST/PUT 请求，请求体就是消息正文。最简形式：

// 命令行最简发布（正文即消息）
curl -d "备份已完成" https://ntfy.example.com/mytopic

// 带标题、优先级、标签与点击跳转
curl \
  -H "Title: 数据库备份完成" \
  -H "Priority: default" \
  -H "Tags: white_check_mark,floppy_disk" \
  -H "Click: https://ntfy.example.com/backup-log" \
  -d "今日 03:00 备份成功，共 1.2 GB" \
  https://ntfy.example.com/mytopic

要一次带上多个字段，用 JSON 发布更清爽（把 topic 放进请求体，POST 到根路径即可）：

curl \
  -H "Content-Type: application/json" \
  -d '{"topic":"mytopic","title":"磁盘告警","message":"/data 使用率 92%","priority":4,"tags":["warning","rotating_light"],"click":"https://grafana.example.com"}' \
  https://ntfy.example.com/

常用请求头一览（记不住也没关系，官方文档有完整表格）：

优先级从低到高为 min / low / default / high / max（也写作 1–5）；Tags 里的词会自动映射成 emoji 徽标；Delay 让消息到点才送达，适合「会议提醒」这类定时场景（默认延迟上限 3 天）。

七、收消息：手机 App、浏览器、命令行与 API 订阅

ntfy 的「客户端」覆盖非常全，按你的设备挑即可：

• 安卓：Google Play、F-Droid 或 GitHub Releases 上的 APK 都能装。用官方 Play 版（内置 Firebase/FCM 通道）后台可即时到达；F-Droid 版不带 Firebase，后台即时到达需配合 UnifiedPush 分发器或常驻 WebSocket，会更费电，介意的话用 Play 版或自行安装带 FCM 的构建。
• iOS：App Store 安装即可；自建服务器的 iOS 推送会经官方 ntfy.sh 转发（前提是配置项 upstream-base-url 保持指向它），这是自建 iOS 推送绕不开的一环，见第八节。
• 浏览器 / PWA：直接打开 https://ntfy.example.com，网页版就能订阅话题；也可「添加到主屏幕」当 PWA 用，配合 Web Push 一样能收系统通知。
• 命令行：ntfy subscribe https://ntfy.example.com/mytopic 会把新消息实时打印出来，非常适合在服务器上调试。
• 程序订阅（API）：订阅同一个话题有四种流式端点——/mytopic/json（每行一条 JSON）、/mytopic/sse（Server-Sent Events）、/mytopic/raw（只输出正文）、/mytopic/ws（WebSocket）；带上 ?poll=1&since=... 可按时间补收缓存里的历史消息，since=all 取全部。

补充两点常见疑问：多设备能否订阅同一话题？ 可以——同一话题可被无限多台设备同时订阅，一台手机、一台平板、一个桌面浏览器能同时收到，互不影响。自建服务器如何保证订阅端安全？ 把话题设为需要权限（见第五节），订阅端用账号密码或令牌登录；公开话题任何人都能读，只适合本来就想公开展示的状态播报。

八、进阶能力：附件、Web Push、iOS 与延迟/邮件/动作

把基础链路跑通后，这些能力能让它更像「生产级」：

• 附件：用 Attach 头带一个 URL，或用客户端上传本地文件。默认限制为单文件 15M、单个访客累计 100M、全局总量 5G，附件 3 小时后过期；网络受限时也可把附件存到 S3 兼容对象存储（可参考站内《MinIO 对象存储搭建教程》）。
• Web Push（浏览器）：先用 ntfy webpush keys 生成一对密钥，再把 web-push-public-key / web-push-private-key / web-push-email-address 写进 server.yml。浏览器订阅的密钥有效期默认 60 天，到期前会提醒重新订阅。
• iOS 与 upstream：自建服务器要让 iOS 客户端收到推送，必须设 upstream-base-url: "https://ntfy.sh"——iOS 的系统推送通道由苹果与官方服务器协作，这一环无法完全自持。如果你不接受「消息经过上游」，那 iOS 端就只能靠 App 在前台时通过 WebSocket 接收，无法后台即时到达——这是自建 ntfy 唯一需要权衡的取舍点。
• 延迟投递与邮件：Delay 头支持 10m、tomorrow, 9am 这种写法；配好 smtp-server 等一整套 SMTP 参数后，用 Email 头可让同一条消息「既推送又发邮件」，适合重要告警双通道留痕。
• 动作按钮：Actions 支持在通知上放按钮，点击「查看」跳链接、「广播」再推一条、「HTTP 请求」调某个接口——足以做「一键确认」之类的轻交互。

九、安全加固与限流：别让服务器变成「别人的推送网关」

公开的 ntfy 实例是滥用重灾区，务必按下面清单加固：

1. 关闭匿名与自注册：auth-default-access: "deny-all"，并保持 enable-signup: false / enable-login: false / enable-reservations: false 的默认值（默认就是关的，别去打开）。
2. 内置限流：ntfy 自带防滥用限流——默认每个访客短时间内最多突发 60 次请求、之后每 5 秒回填 1 次；单访客订阅话题数上限 30；全局话题总数上限 15,000，另有全局订阅数与附件总量上限。这些默认值对个人/小团队足够，公开实例可按需调整。
3. 反代必须设 behind-proxy: true：否则限流按代理 IP 计数，真实用户会被误伤、滥用者反而绕过（同时用防火墙禁止直连容器 80 端口，只留 Nginx 入口）。
4. 最小权限：发布端一律用「只对该话题有写权限」的令牌；不要给脚本 admin 令牌。
5. 及时升级：新版本会带安全修复，定期 docker compose pull && docker compose up -d。
6. 端口收敛：防火墙只放行 22 / 80 / 443，其余一律关闭（可参考站内《网站安全加固指南：端口、权限与防爆破》）。

十、海外云服务器配置推荐与价格对比

ntfy 是一个极轻的 Go 服务，个人实例 1 核 1G 就绰绰有余，内存与 CPU 都不是瓶颈；真正要留意的只有两件事——消息缓存 cache.db 与附件的磁盘占用，以及你愿不愿意为「随时可达」多留一点余量。下表价格为当日直读官方定价页的档位-规格映射（DigitalOcean Droplet 与 AWS Lightsail）；阿里云国际版 / 腾讯云国际版为区间参考，实际以控制台为准（价格随地域、套餐调整，这里只做量级参考）。带 * 的 vCPU 为突发型（burstable）。

选型口诀：1 核 1G 是舒适起步，2 核 2G 更从容，只有做公开大实例才需要往上加。 个人自用，DO 或 Lightsail 的 $6 / $7 档（1 核 1G）就是最优解；要跑小团队共享、并保留较多消息缓存与附件，上个 2 核 2G（$12–$18）即可。

声明：本文价格数据采集于 2026 年 10 月，仅为公开官网参考区间，实际以各家官网实时价格为准，金额单位均为美元（USD）。

十一、把 ntfy 接进现有系统：几个可直接照抄的示例

ntfy 最好用的地方在于「谁都能调」：凡是能发 HTTP 请求、或能配 Webhook 的系统，都能把消息汇进来。下面给四类最常见的接入方式。

11.1 脚本与定时任务（cron / shell）

最通用的方式就是一条 curl，在任何脚本末尾加上它，就把「脚本的成败」变成了手机上的即时通知：

// 备份脚本成功后推送一条通知
curl \
  -H "Title: 数据库备份完成" \
  -H "Priority: default" \
  -H "Tags: white_check_mark" \
  -d "今日 03:00 备份成功" \
  https://ntfy.example.com/backup

把它放进 crontab 或 systemd timer，即可实现「定时任务结果自动推送到手机」。

11.2 Uptime Kuma（可用性监控 → 经 ntfy 下发）

Uptime Kuma 的通知类型里直接支持 ntfy：在「通知」中新增一条、类型选 ntfy、填入自建服务器地址、话题名与访问令牌，再挂到对应监控项上即可。这样 Uptime Kuma 负责「探测发现问题」，ntfy 负责「送达」，职责清晰（对应站内《Uptime Kuma 自建服务监控与状态页教程》）。

11.3 Home Assistant（智能家居事件推送）

Home Assistant 内置了官方 ntfy 集成：在「设置 → 设备与服务 → 添加集成」中搜索 ntfy，填入服务器地址与令牌即可。此后自动化里就能用通知动作推送「门磁被打开」「温湿度超阈值」这类事件（对应站内《Home Assistant 智能家居中枢教程》）。

11.4 告警系统与工作流（Grafana / Alertmanager / n8n）

• Grafana 告警：其原生联系点是通用 Webhook，社区有 grafana-to-ntfy 之类的桥接把 Grafana 告警格式转成 ntfy 消息；
• Prometheus Alertmanager：需要一个极小的中继（如 alertmanager-ntfy）来转换格式——因为 Alertmanager 只发它自己结构的 JSON，直接打给 ntfy 会被当成一整段纯文本；
• n8n：用「HTTP Request」节点向 https://你的域名/话题 发 POST 即可，社区也有现成的 n8n-ntfy 节点。

一句话总结：能发 HTTP 请求或配 Webhook 的系统都能汇入 ntfy，差别只在于对方发的是纯文本还是自带 JSON 结构——前者直连，后者加一步格式转换。

推荐方案

综合成本与体验，给两套可以直接照抄的组合：

方案 A：个人自用（预算优先）

• 香港 / 新加坡节点，1 核 1G、25–50 GB SSD（DO / Lightsail 约 $6–$7）；
• 按本文第三、四节用 Docker Compose 部署，server.yml 设好 base-url 与 behind-proxy: true；
• 第五节配 auth-default-access: "deny-all"，给脚本发一枚只写令牌、手机端用账号订阅；
• Nginx + Let's Encrypt 提供 HTTPS，防火墙只放行 22/80/443；手机装 ntfy App 订阅即可。

方案 B：团队共享（体验优先）

• 2 核 2G、60 GB SSD 以上、3 TB 月流量；
• 为每人建独立用户与令牌，按话题授予最小权限；
• 开启附件（必要时接对象存储），按需调大缓存时长与限流上限；
• 把 Uptime Kuma、Prometheus Alertmanager、Home Assistant、n8n 的告警统一接到 ntfy 的一个话题上，做「聚合推送入口」。

部署后的日常维护：定期备份 /etc/ntfy/server.yml 与 /var/lib/ntfy/user.db（账号与令牌全在这里，丢了要重建）；cache.db 属可再生的缓存，可视情况纳入备份；用 docker compose pull 跟进版本更新；随时用 docker stats 观察内存与磁盘占用，确认缓存与附件没有异常膨胀。

🚀 需要海外云服务器来部署 ntfy？通过 5.chengzicloud.cloud 购买阿里云国际版 / 腾讯云国际版 / AWS，享专属折扣。