ql-scripts

zhuhjay/ql-scripts

Fork 0

Commit Graph

Author	SHA1	Message	Date
zhuhjay	3ce29ebee2	docs(notify): 诊断补第 5b 节，指向平台侧的转发检查用户实跑结果：sendNotify 加载正常、WEBHOOK 三项前置条件全过、直打平台两次都 204（含换行/中文/emoji 的完整正文也收下了）。但 PUSH_PLUS_TOKEN 未设 —— 青龙根本不发 pushplus，所以收到的那条 pushplus 一定来自平台转发，不是脚本自己发的。补第 5b 节把这条推理写进输出： - 204 只证明平台收下了，收到 ≠ 转发 - 中间还有两道门：事件要匹配到账号、账号下要有 enabled+active 的 pushplus 目标 - 给出两个 curl 判据（/api/notify-targets 与 /api/events?category=notify）以及 deliveries=N 的读法 - 第 5 节在 PUSH_PLUS_TOKEN 未设时不再只是「跳过」，而是说明这条消息必然是平台转发来的	2026-11-05 20:21:02 +08:00
zhuhjay	3a711d0a47	fix(notify): 平台回 204 被误判为失败 + 诊断工具改名 scrip_ 三个改动： 1) sendNotify.js 的 webhook 判据从 statusCode !== 200 改成 2xx 一律成功。平台 /api/hooks/ql 按设计回 204（表示已接收且不写 event_logs），原判据把 204 当失败 → 每轮日志都打「自定义发送通知消息失败！！」，而投递其实成功了。这是纯假警报，也是这次误判的根因。同时把状态码打进日志，真失败时能直接看出是 401/403/400/429。 2) _diag_notify.js → scrip_diag_notify.js。订阅白名单是 scrip_，不带前缀的文件拉不下来，工具等于不存在。加 // cron: 0 0 1 1 * 与 // name:，避免青龙自动建任务时落随机 cron。正文补到六段：sendNotify 加载 / env / webhook 三前置条件与 body+headers 解析复刻 / 直打平台按状态码定位 / pushplus txt-vs-html 模板对比 / 完整 sendNotify 对照。 3) 文档补齐平台侧的两道硬校验：来源 IP 必须 127.0.0.1 或 172.16/12 （走公网域名会变成反代地址 → 403），回环带 XFF 一律 403。给出指向平台的完整 env 写法（WEBHOOK_BODY 必须多行，单行 JSON 会被 parseString 整段吞掉 —— 已实测解析结果为 0 个 key）。验证：node --check（sendNotify + 诊断）/ 5 个 mock 状态码用例（204/401/403/400/429）全部被正确识别 / _probe_meta 四文件 PASS	2026-11-05 09:34:06 +08:00

Author

SHA1

Message

Date

zhuhjay

3ce29ebee2

docs(notify): 诊断补第 5b 节，指向平台侧的转发检查

用户实跑结果：sendNotify 加载正常、WEBHOOK 三项前置条件全过、
直打平台两次都 204（含换行/中文/emoji 的完整正文也收下了）。
但 PUSH_PLUS_TOKEN 未设 —— 青龙根本不发 pushplus，所以收到的那条
pushplus 一定来自平台转发，不是脚本自己发的。

补第 5b 节把这条推理写进输出：
- 204 只证明平台收下了，收到 ≠ 转发
- 中间还有两道门：事件要匹配到账号、账号下要有 enabled+active 的
  pushplus 目标
- 给出两个 curl 判据（/api/notify-targets 与 /api/events?category=notify）
  以及 deliveries=N 的读法
- 第 5 节在 PUSH_PLUS_TOKEN 未设时不再只是「跳过」，而是说明
  这条消息必然是平台转发来的

2026-11-05 20:21:02 +08:00

zhuhjay

3a711d0a47

fix(notify): 平台回 204 被误判为失败 + 诊断工具改名 scrip_

三个改动：

1) sendNotify.js 的 webhook 判据从 statusCode !== 200 改成 2xx 一律成功。
   平台 /api/hooks/ql 按设计回 204（表示已接收且不写 event_logs），
   原判据把 204 当失败 → 每轮日志都打「自定义发送通知消息失败！！」，
   而投递其实成功了。这是纯假警报，也是这次误判的根因。
   同时把状态码打进日志，真失败时能直接看出是 401/403/400/429。

2) _diag_notify.js → scrip_diag_notify.js。
   订阅白名单是 scrip_，不带前缀的文件拉不下来，工具等于不存在。
   加 // cron: 0 0 1 1 * 与 // name:，避免青龙自动建任务时落随机 cron。
   正文补到六段：sendNotify 加载 / env / webhook 三前置条件与 body+headers
   解析复刻 / 直打平台按状态码定位 / pushplus txt-vs-html 模板对比 /
   完整 sendNotify 对照。

3) 文档补齐平台侧的两道硬校验：来源 IP 必须 127.0.0.1 或 172.16/12
   （走公网域名会变成反代地址 → 403），回环带 XFF 一律 403。
   给出指向平台的完整 env 写法（WEBHOOK_BODY 必须多行，单行 JSON
   会被 parseString 整段吞掉 —— 已实测解析结果为 0 个 key）。

验证：node --check（sendNotify + 诊断）/ 5 个 mock 状态码用例
（204/401/403/400/429）全部被正确识别 / _probe_meta 四文件 PASS

2026-11-05 09:34:06 +08:00

2 Commits