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