RSSHub：把散落在网站里的更新变成 RSS

你想持续关注一个 Telegram 频道、一位视频作者或某个论坛板块，却不想每天逐个打开应用检查更新。RSS 阅读器本来适合解决这件事，麻烦在于许多网站没有提供 RSS，或者只提供很有限的订阅内容。

RSSHub 补的是这块缺口。RSSHub 把“去某个来源取什么内容、怎样整理”写成路由；用户把路由路径接在实例域名后，就得到一个可以交给阅读器的 RSS 地址。阅读仍发生在 Folo、Inoreader、FreshRSS 等客户端里，RSSHub 负责把原本不便订阅的内容转换出来。

GitHub 仓库信息

信息	内容
项目标题	RSSHub
项目描述	RSSHub 是一个由社区维护的 RSS 网络，通过路由从各类内容源抓取更新并转换成标准订阅源。
GitHub 仓库	DIYgod/RSSHub
官网地址	RSSHub 文档
主要开发语言	TypeScript 99.6%、JavaScript 0.26%、Nix 0.09%
开源许可证	AGPL-3.0
最近代码更新	2026-09-12（GitHub pushed_at，核对日期：2026-09-13）

路由就是订阅说明书

RSSHub 文档中的每条路由都描述了三件事：支持哪个内容来源、URL 中哪些位置需要替换、该路由是否依赖 Cookie、令牌或浏览器。以 Telegram 频道为例，路由是：

/telegram/channel/:username/:routeParams?

把 :username 换成频道名 awesomeRSSHub，再加上官方实例域名，订阅地址就是：

https://rsshub.app/telegram/channel/awesomeRSSHub

将这个地址添加到 RSS 阅读器，成功信号不是“网页能打开”，而是阅读器识别出 feed 标题并列出频道消息。域名部分可以换成公共实例或自己的实例，路径部分保持不变。固定提交中的 Telegram 路由也把这条地址列为示例，并注明普通公开频道无需浏览器依赖。

RSSHub 不是一个巨大的静态订阅地址目录。路由更像一份带参数的转换规则，同一条规则可以服务许多频道、用户或栏目。找不到目标站点时，应先搜索路由列表，再按照该路由的参数表组装地址。

只看关心的更新

拿到 feed 只是开始。RSSHub 的通用参数可以放在路由末尾，用同一套方式调整许多来源。例如只保留标题或正文中含 release 或“发布”的最近 10 条内容：

https://rsshub.app/telegram/channel/awesomeRSSHub?filter=release%7C%E5%8F%91%E5%B8%83&limit=10

filter 接受正则表达式，因此特殊字符必须完整进行 URL 编码；limit 限制返回条数。还可以用 filterout 排除内容、用 mode=fulltext 尝试提取全文，或用 format=atom、format=json 改变输出格式。全文提取是否有效取决于源站页面，图片和视频也可能因为防盗链而无法在某些阅读器中显示。

RSSHub 还提供一层统一的内容整形入口，不只负责“让没有 RSS 的网站有 RSS”。不过内容整形不会消除上游限制。登录态、反爬、地区限制、页面改版和 API 配额依然可能让单条路由失效。

Radar 省掉手工查路由

如果不想每次先翻文档，可以使用 RSSHub Radar。浏览器扩展会先寻找网页自己声明的 RSS，再根据远程规则匹配可用的 RSSHub 路由；RSSBud 和 RSSAid 则把相近体验带到移动端。Radar 负责“发现地址”，RSSHub 实例负责“生成内容”，阅读器负责“保存和阅读”，三者角色并不相同。

对偶尔添加订阅的人，直接查路由文档已经够用。经常在不同网站间收集信息的人，Radar 能减少从页面 URL 推导路由的工作。

选择公共实例还是自建

选择	适合场景	需要接受的边界
官方或公共实例	先体验、少量订阅、不涉及私人凭据	路由可用性、缓存周期和访问策略由实例维护者决定；不要把自己的 Cookie 或令牌交给陌生实例
自建 RSSHub	需要自己的缓存、代理、访问控制或路由凭据	需要维护 Docker、网络、更新和上游站点变更；单机实例不是高可用服务
网站原生 RSS	网站已经提供完整且稳定的 feed	功能最简单，通常也最可靠，但覆盖范围取决于网站
阅读器内置抓取或邮件订阅	只关心少数站点，且不想维护服务	转换规则通常不可复用，迁移到其他阅读器的成本可能更高

如果只是想知道 RSSHub 是否适合自己，先用官方实例完成一条不含私人凭据的订阅。只有遇到公共实例不稳定、需要受控缓存或必须配置私有凭据时，自建才开始产生实际价值。

用 Compose 建一个自用实例

下面的路径面向单机、自用或放在同机 HTTPS 反向代理后的部署。RSSHub 应用固定到本文源码提交对应的 GHCR 多架构镜像摘要；该镜像索引包含 linux/amd64 和 linux/arm64。Redis 只保存可重建的缓存，基础方案不包含 Chromium，因此标记为“需要浏览器”的路由可能无法工作。

准备一台安装了 Docker Engine 与 Compose 插件的 Linux 主机，确保能访问 GHCR、Docker Hub以及准备订阅的源站。CPU 和内存需求会随路由数量、抓取频率和是否使用浏览器显著变化，官方资料没有给出统一最低值；先从非关键订阅、小规模流量开始观察。

创建配置

新建工作目录并进入：

mkdir -p rsshub && cd rsshub

在该目录创建 .env。把示例值换成由密码管理器生成的随机长字符串，不要提交到 Git：

ACCESS_KEY=replace-with-a-long-random-secret

再创建 compose.yaml：

services:
  rsshub:
    image: ghcr.io/diygod/rsshub@sha256:e5b4bbb8376440a0dbe5757d1cd17a215518fa0857f91eb49f361180fba31adf
    restart: unless-stopped
    ports:
      - "127.0.0.1:1200:1200"
    environment:
      NODE_ENV: production
      CACHE_TYPE: redis
      REDIS_URL: redis://redis:6379/
      ACCESS_KEY: ${ACCESS_KEY:?set ACCESS_KEY in .env}
    healthcheck:
      test: ["CMD-SHELL", "curl -f \"http://localhost:1200/healthz?key=$${ACCESS_KEY}\""]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s
    depends_on:
      redis:
        condition: service_healthy

  redis:
    image: redis:7.4.5-alpine
    restart: unless-stopped
    volumes:
      - rsshub-redis:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  rsshub-redis:

端口只绑定到 127.0.0.1，同机浏览器或反向代理可以访问，公网不能直接连接。Redis 没有发布宿主机端口，只能从 Compose 内部网络访问。ACCESS_KEY 会保护 feed 和健康检查；RSS 阅读器中的订阅地址需要带上 ?key=你的密钥。URL 可能进入阅读器同步、代理和访问日志，面向多人时更适合由反向代理做认证，而不是广泛分发同一个 key。

静态检查并启动

仍在 rsshub 目录执行：

docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps

config --quiet 无输出且退出码为 0，说明 Compose 能解析变量和配置。docker compose ps 中 Redis 与 RSSHub 最终都应为 healthy；若停在 starting 或进入重启循环，先看日志：

docker compose logs --tail=120 rsshub redis

常见原因包括 GHCR 无法访问、1200 端口已被占用、.env 缺少 ACCESS_KEY，或主机无法解析和访问外部内容源。

验收一条真实订阅

Compose 自动读取 .env，但不会把其中的变量导入当前 Shell。下面先在这个可信的工作目录中加载刚刚创建的文件，再检查健康端点和 Telegram feed；命令不会打印密钥：

set -a
. ./.env
set +a

curl --fail --silent --show-error \
  "http://127.0.0.1:1200/healthz?key=${ACCESS_KEY}"

curl --fail --silent --show-error \
  "http://127.0.0.1:1200/telegram/channel/awesomeRSSHub?limit=3&key=${ACCESS_KEY}" \
  | head -n 20

unset ACCESS_KEY

第一条命令应成功返回健康响应，第二条应输出 XML，并包含 feed 标题和条目。随后把第二个 URL 换成反向代理后的 HTTPS 域名，添加到阅读器中，确认阅读器能识别标题和三条以内的内容。若返回 Authentication failed，检查 URL 中的 key 与容器环境是否一致；若返回源站抓取错误，直接打开 https://t.me/s/awesomeRSSHub 检查该来源是否可访问，再查看 RSSHub 日志。

验证缓存与重建边界

连续请求同一路由后，可检查响应头中的 RSSHub-Cache-Status；固定源码会在命中全局缓存时返回 HIT。Redis 卷保存的是可重新抓取的 feed 缓存，不是不可替代的业务数据。需要保留的是 compose.yaml、.env、反向代理配置，以及自行添加的路由专用 Cookie 或令牌。

重建应用容器不会删除 Redis 卷：

docker compose up -d --force-recreate rsshub
docker compose ps

重建后再次请求健康端点和 Telegram feed 即可完成业务验收。即使 Redis 卷丢失，RSSHub 也会重新抓取内容；代价是冷缓存期间增加源站请求和响应时间。因此该卷通常无需作为核心数据备份，但配置与密钥必须进入自己的加密备份。

更新、回退与浏览器路由

RSSHub 没有传统稳定 Release；官方持续发布 latest、日期和提交哈希镜像。更新前先阅读仓库变更和路由文档，记录当前镜像摘要，然后把 Compose 中的 RSSHub 镜像换成已核验的新日期标签或摘要：

docker compose pull rsshub
docker compose config --quiet
docker compose up -d rsshub
docker compose ps

更新后重复健康检查、代表性 feed、访问控制和缓存验收。若新镜像失败，恢复旧摘要并再次 up -d。RSSHub 应用本身没有需要保留的业务数据库，Redis 在这里又只是缓存，因此回退重点是镜像与配置兼容；仍要保留旧配置，避免环境变量变更导致旧版本无法启动。

有些路由必须执行页面脚本。官方提供 chromium-bundled-{YYYY-MM-DD} 镜像，也可以按官方 Compose 接入 browserless。浏览器方案会增加镜像体积、内存消耗和攻击面，应选择与目标日期匹配的标签，并另外验收该路由、容器资源占用和浏览器健康状态。不要因为首页和 Telegram 示例正常，就推断所有依赖浏览器、登录态或代理的路由都能工作。

停止服务使用 docker compose down，该命令会保留 rsshub-redis 卷。docker compose down -v 会删除缓存卷；虽然内容可重建，下一次启动会经历冷缓存。彻底卸载前还需要自行处理工作目录、反向代理配置和备份中的密钥。

公网使用的安全边界

RSSHub 会代表服务器访问外部网站，部分路由还需要 Cookie、API Key 或账号令牌。不要把这些秘密写进公开 Compose、截图或订阅分享链接。公开实例尤其不应启用允许用户指定任意域名的 ALLOW_USER_SUPPLY_UNSAFE_DOMAIN，官方文档明确提示该选项可能带来服务端请求伪造风险。

对公网提供服务时，让 HTTPS 反向代理连接 127.0.0.1:1200，并在代理层增加身份认证、速率限制和日志脱敏。RSSHub 内置 ACCESS_KEY 适合自用门槛，但 key 放在查询参数中，可能被日志、历史记录或同步服务保存。还要遵守被抓取网站的服务条款、访问频率和内容版权要求；RSSHub 的 AGPL-3.0 许可证不等于上游内容可以任意再分发。

一次请求背后发生了什么

Mermaid 流程图

正在准备渲染...

查看源码

flowchart LR
    Reader[RSS 阅读器] -->|路由 URL 与参数| Access[访问控制]
    Access --> Cache{缓存命中?}
    Cache -->|是| Render[格式化输出]
    Cache -->|否| Route[匹配路由处理器]
    Route --> Source[请求内容源或 API]
    Source --> Route
    Route --> CacheStore[写入 Redis 缓存]
    CacheStore --> Render
    Render -->|RSS / Atom / JSON Feed| Reader

固定源码中的 Hono 应用依次挂载访问控制、参数处理、缓存等中间件，再把请求交给路由注册表。路由处理器从源站取回数据并整理成统一结构；模板层按请求的输出格式生成 feed。缓存键包含请求路径、格式和条数限制，同一路由的重复请求可以直接复用结果，减少对源站的压力。

排障可以沿着同一条请求路径进行：认证失败先查 key，404 先查路由和参数，抓取错误查源站可达性或登录配置，内容旧则查缓存，图片缺失再查防盗链与阅读器行为。盲目重启容器通常不会修复已经改版的源站解析规则。

下一步

先挑一个你确实每天会打开、文档中又标为低反爬的来源，完成“生成 URL、加入阅读器、等待一次更新”的闭环。随后再给同一订阅增加 filter 或 limit，观察内容怎样变化。这个小实验比一开始迁移全部订阅更能说明 RSSHub 是否适合你的信息流。

准备长期自建时，再逐条核对所需路由的配置标记，把 Cookie 和 API Key 放进受控的 secrets 管理方式，并为最重要的订阅准备原生 RSS 或其他抓取方案作为替代。RSSHub 路由会随上游网站变化，维护成本来自内容源，而不只是容器本身。

验证边界

本文基于 RSSHub 提交 67305a5 和 RSSHub 文档提交 aaa2d04，核对日期为 2026-09-13。已静态阅读官方文档、Compose、Dockerfile、核心中间件和 Telegram 示例路由，并核验 RSSHub GHCR 镜像摘要及 amd64/arm64 清单；未启动容器，未验证 Redis 镜像、真实 feed、持久化、反向代理、备份恢复或升级。官方文档站与示例 feed 在本次网络环境中超时，文中的命令输出均为读者应完成的验收目标。

参考资料

• RSSHub 官方文档
• 开始使用 RSSHub
• RSSHub 路由列表
• 部署与镜像说明
• 配置与访问控制
• 通用参数