RSSHub 运维 Skill

部署

本机 RSSHub: ~/projects/diygod/RSSHub/，systemd user service rsshub，端口 1200。

# 启停
systemctl --user start rsshub
systemctl --user restart rsshub
systemctl --user is-active rsshub

# 重建
cd ~/projects/diygod/RSSHub && pnpm build && systemctl --user restart rsshub

GitHub 搜索路由修复（v1.0 bug）

问题: v1.0 的 lib/routes/github/search.ts 使用 response.payload.results.map()，GitHub 更改 API 后返回空响应，报 TypeError: Cannot read properties of undefined (reading 'map')。

修复: 改用 GitHub Search API /search/repositories + token 认证。

// 核心改动: host 从 github.com 改为 api.github.com
const host = 'https://api.github.com';
const suffix = `search/repositories?q=${encodeURIComponent(query)}&sort=${sort}&order=${order}`;
const headers = { accept: 'application/vnd.github.v3+json', 'User-Agent': 'RSSHub' };
if (config.github?.token) {
    headers['Authorization'] = `token ${config.github.token}`;
}
const response = await ofetch(link, { headers });
const out = response.items.map((item) => ({
    title: item.full_name,
    author: item.owner.login,
    link: item.html_url,
    description: item.description || '',
}));

GitHub token: Obsidian ~/mc/牧尘/claw/key.md 中 github_pat_ 开头，写入 ~/projects/diygod/RSSHub/.env 和 ~/.hermes/.env。

重建步骤: 改代码 → pnpm build → systemctl --user restart rsshub → curl http://127.0.0.1:1200/github/search/ai 验证。

织忆对接

脚本: ~/.hermes/scripts/rsshub-zhiyi-fetch.py

订阅 6 个 GitHub AI 搜索源
去重状态文件: ~/.hermes/data/rsshub_ai_seen.json（最多 500 条）
有新增 → 写入织忆 /api/v1/commit；无新增 → 静默退出
Cron: 6457e26da8c3 每天 8:00/20:00
源间延时: RSSHUB_SOURCE_DELAY 环境变量可配，默认 15s

2026-09-04 限流事故（403→503 误报）

症状: cron 报 "HTTP Error 503"，但 RSSHub 本身 active，curl 单测也 200。

真相: RSSHub 把上游 403 转成 503。lib/routes/github/search.ts 无缓存、每次实时打 GitHub Search API，6 源串行连发（间隔<1s）触发 GitHub secondary rate limit（403），冷却 30-60s；RSSHub 内置 ofetch retry（3s/6s backoff）覆盖不了 → 3 次重试全挂。日志特征: Request https://api.github.com/search/repositories ... with error 403 + --> GET /github/search/XXX 503。

修复: 脚本源间加 15s 延时（无论成败都等），单次 cycle 从 ~6s 拉长到 ~75s，请求节奏远低于限流阈值。dry-run 不再写 seen 状态文件（旧版无条件 save_seen，dry-run 会把真新条目标 seen 导致漏抓）。

验证: time python3 rsshub-zhiyi-fetch.py --dry-run 应 exit 0 且无 ⚠️ 输出；journalctl --user -u rsshub 应见源间 15s 间隔的连续 200。

Pitfalls

git pull 超时: gh-proxy.com 镜像偶尔慢，用 git fetch --depth 1 浅克隆
pnpm build 警告: TOLERATED_TRANSFORM 和 EVAL 警告可忽略
状态文件污染: 测试时 --dry-run 不写状态文件；但旧版本有 bug 会写
GitHub API 限流: 无 token 时 60 次/h，有 token 5000 次/h
503 复发快速判定（2026-09-04 20:01 实例）: cron 报"部分失败: GitHub LLM/深度学习 503"时，先 for p in /github/search/LLM ...; do curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:1200$p; done 实测——全 200 = 瞬时限流已自愈，无需处置。失败源不标记 seen（fetch 异常 continue，条目不写状态文件）→ 下轮自动补抓，无数据丢失；且 6 源按 link 跨源去重，LLM/deep+learning 漏抓的条目通常已被 ai/machine+learning 等重叠源写入（补跑返回空=证实）。
补跑验证法: 收到部分失败告警后手动 python3 rsshub-zhiyi-fetch.py 补一轮——输出空（0 新增 0 报错）说明漏源条目已被重叠源覆盖；有新增则正常补写。

4.2 KiB Raw Blame History Unescape Escape

RSSHub 运维 Skill

部署

GitHub 搜索路由修复（v1.0 bug）

织忆对接

2026-09-04 限流事故（403→503 误报）

Pitfalls

4.2 KiB

Raw Blame History