事件中心与通知
这页解决什么问题
事件中心 负责回答两类问题：
- 系统最近到底发生了什么
- 哪些事情值得自动推送通知
如果你已经不满足于“出了问题再自己进后台看”，这页就是新版文档里最值得补上的能力之一。
页面结构怎么理解
路径：
事件中心
这里分成两层：
事件通知
而 通知 下面又分成：
提供商规则投递记录
可以把它理解成：
事件：看系统发生了什么提供商：决定消息发到哪里规则：决定什么情况下要发投递记录：看发没发出去、为什么失败
事件页能做什么
事件 页主要负责：
- 按事件类型、级别、来源筛选
- 搜索关键字
- 打开单条事件详情
- 删除不再需要的历史事件
事件详情里会按类型展示很多有助于排错的字段，例如：
- 登录 IP、IP 归属地、User-Agent
- 关联的 TOTP / Passkey 名称
- DDNS 更新范围、IP 来源、执行结果
- 隧道类型、连接状态、进程 PID
- SSH 登录用户、认证方式、失败次数、封锁原因
- CPU / 内存告警阈值与恢复阈值
目前能看到哪些系统事件
常见事件至少包括：
- 登录成功
- 退出登录
- 登录失败
- 会话 IP 漂移
- 扫描器拦截
- DDNS 更新
- 网关节流封锁
- 应用更新提示
- CPU 告警 / 恢复
- 内存告警 / 恢复
- FRP 已连上 / 已断开
- Cloudflared 已连上 / 已断开
- SSH 登录成功
- SSH 登录失败
- SSH IP 被封锁
这意味着你现在已经可以把“认证、网络入口、SSH 防护、系统运行态、更新提示”放到同一个地方看。
通知支持哪些提供商
通知提供商已经内置：
- Webhook
- WxPusher
- ServerChan
- PushPlus
- 企业微信
- 钉钉
- 飞书
- PushDeer
- Bark
- Telegram
建议第一次配置时，优先选你最熟的一种。
对大多数个人用户来说，常见顺序通常是：
Webhook企业微信 / 飞书 / 钉钉PushPlus / ServerChan / Bark / TelegramEmail
推荐的最小配置顺序
建议按这个顺序来，不容易乱：
- 先新增一个通知提供商
- 先执行一次“测试发送”
- 测试成功后，再去新增通知规则
- 最后去
投递记录看真实发送结果
这样做的好处是：
- 能先排除“连接目标配置错了”
- 不会把“规则没匹配”和“消息根本发不出去”混成一件事
通知规则里的 5 个关键字段
时间窗口
表示在多长时间内统计同类事件。
例如：
60 秒
通常就表示：
- 最近 60 秒内
触发次数
表示在这个窗口里至少出现多少次，才真正触发通知。
例如：
60 秒内 3 次登录失败
聚合维度
表示这些事件应该按什么粒度合并。
支持：
全局IP会话主题对象主机名提供商
最直观的理解是：
- 登录失败更适合按
IP - 会话 IP 漂移更适合按
会话 - DDNS 更新更适合按
提供商 - 隧道连上 / 断开更适合按
主题对象
冷却时间
表示一条规则刚触发完之后，要过多久才允许再次触发。
它的主要作用是：
- 防止同一类问题在短时间里疯狂刷屏
通知目标
表示这条规则最终要发到哪些提供商。
一条规则可以绑定多个通知目标。
第一批最值得开的规则
如果你不想一上来就把所有事件都接通知，推荐先开这几类：
1. 登录失败
推荐思路：
- 时间窗口：
60 秒 - 触发次数：
3 - 聚合维度：
IP - 冷却时间：
300 秒
适合发现：
- 撞库
- 扫描
- 登录口被频繁试探
2. 会话 IP 漂移
推荐思路：
- 时间窗口：
60 秒 - 触发次数：
1 - 聚合维度：
会话
适合发现：
- 网络环境变化
- 代理环境变化
- 可疑的会话漂移
3. SSH 登录失败或封锁
推荐思路：
- 时间窗口：
60 秒 - 触发次数：
1到3 - 聚合维度：
IP - 冷却时间：
300 秒
适合发现：
- SSH 入口被撞密码
- 某个来源持续尝试不存在的用户
- SSH 安全已经自动封锁了可疑来源
4. DDNS 更新
推荐思路：
- 时间窗口：
300 秒 - 触发次数：
1 - 聚合维度：
提供商
适合发现：
- 家宽 IP 变化后是否成功写回
- 某个 DDNS 提供商是否持续异常
5. 隧道断开
推荐思路：
- 时间窗口：
60 秒 - 触发次数：
1 - 聚合维度：
主题对象
适合发现：
- FRP 断开
- Cloudflared 断开
6. 应用更新提示
推荐思路：
- 时间窗口：
3600 秒 - 触发次数：
1 - 聚合维度：
主题对象
适合发现：
- 有新版本可升级
投递记录怎么看
投递记录 负责回答的是：
- 哪条规则触发了
- 发给了哪个提供商
- 当前状态是成功、失败、重试中还是放弃
- 失败原因是什么
你还能直接看到：
- 消息标题与摘要
- 请求摘要
- 响应摘要
- 尝试次数
- 下次重试时间
所以当你遇到“规则明明触发了，但手机没收到消息”时，优先看这里，而不是先怀疑规则本身。
两个很实用的使用建议
先少量规则跑稳，再逐步扩
通知系统最怕的不是“少”，而是“一上来全开，然后每天被刷爆”。
推荐先只开：
- 登录失败
- SSH 登录失败或封锁
- 隧道断开
- DDNS 更新
跑稳后，再慢慢补：
- CPU / 内存告警
- 网关节流
- 更新提示
先让通知对你有用，再追求完整
如果一条通知不能帮助你立刻做判断，它大概率就不值得先开。
好的第一批通知，应该满足：
- 你收到后会立刻采取动作
- 频率不会高到让你麻木
- 能明显缩短排障时间