NAS 和服务器上跑的服务越来越多，通知也成了一个绕不开的问题。应用分别跑在 VPS、NAS 和小主机上，平时看着没什么，但一旦某个容器挂了、任务报错了，或者服务掉线了，如果没有一个统一的消息入口，很多时候就只能等到自己手动检查时才发现。

市面上的消息推送服务很多，但几乎都有各自的限制。

比如 TG 很好用，但需要网络环境支持；企业微信、钉钉、飞书 更偏向企业内部使用；微信服务号 又有不少模板和规则限制。后来也出现了像 pushplus、wxpusher 这类方案，推送方式更多，也更灵活。

但这些服务本质上还是第三方平台。一旦中转服务宕机、接口调整，甚至停止维护，已经接入的服务、脚本和令牌都得跟着修改，维护起来并不轻松。

服务少的时候，一对一推送当然够用；但服务一多，通知链路就会越来越乱。这时候，如果有一个属于自己的推送服务，统一接收各类服务消息，再按需转发到 TG、pushplus、wxpusher、企业微信、Webhook 等不同渠道，整个通知体系就会清晰很多。

所以，真正值得考虑的，是给自己搭一个统一的消息转发中枢。而这次要分享的 MagicPush，正好就是用来解决这个问题的。

服务介绍（摘自项目）

完整项目名：magiccode1412/magicpush，可于GitHub搜索。

一个支持多种消息渠道的推送服务管理平台，用户可以通过标准化的REST API接口将消息推送到多种通知渠道。

消息渠道支持基本覆盖市面上的所有：企业微信机器人、TG Bot、PushPlus、WxPusher、飞书机器人、钉钉机器人、微信公众号 (模板消息推送，支持测试号)、Server酱 (微信推送服务)、Webhook (通用 HTTP 推送，支持自定义 URL/Headers/Body)、SMTP邮件 (支持QQ邮箱、163邮箱、Gmail等)。

核心功能（摘自项目）

• 多渠道消息同时推送
• 标准化REST API
• 双令牌JWT认证机制 (access/refresh token)
• 用户注册/登录
• 渠道绑定与配置管理
• 推送接口管理（多接口/多令牌）
• 推送历史记录与状态追踪
• 响应式Web管理界面
• 深浅色主题切换

部署流程

以威联通NAS为例，通过Docker Compose的方式进行部署。

部署代码如下：

services:
  magicpush:
    image: magiccode1412/magicpush:latest # 国外用这个
    #image: docker.cnb.cool/magiccode1412/magicpush:latest # 国内用这个
    ports:
      - "3099:3000" # 自行修改
    # environment:
      # - JWT_SECRET=your-secret-key # 可选，不设置则自动生成安全密钥
    volumes:
      - /share/Container/magicpush/data:/app/server/data # 自行修改
    container_name: magicpush
    restart: always

打开威联通的Container Station，创建新的应用程序。

使用展示

部署完毕后，浏览器输入NAS_IP:3099即可访问服务。第一次访问需要注册管理员账户。

首先要到「渠道管理」中，绑定消息推送渠道。最近OpenClaw火热，各种渠道绑定大家想必都非常熟悉了。选择你较为常用的那个进行绑定。

接着是「接口管理」，新建一个推送接口，是支持多渠道接入的。

可在「渠道管理」或是「接口调试」中进行测试。

再例如 Uptime Kuma ，监控网站健康情况、证书之类的，配置一下，点击测试也OK。

最后

总的来说，MagicPush 更适合拿来做一套属于自己的统一通知中枢。把分散在不同设备、不同服务里的消息集中起来，再按需转发到各个渠道，管理和维护都会轻松很多。对于手上服务比较多的人来说，还是很值得折腾一下的。

感谢观看，本文完。