前阵子群里有人吐槽“现在想盯一个网站的内容更新怎么这么难要么天天手动刷要么开一堆 App 被推送轰炸。”我回了一句“你缺的是一个 RSS 订阅体系。”然后顺手把 RSSHub 加浏览器插件那套东西丢过去。十分钟后他在群里发了一串感叹号说“这个太逆天了”。这事其实一点都不神秘。把“万物皆可 RSS”这句话落到实处靠的是一个插件化设计的开源项目——RSSHub。它的核心思路非常简单任何网站只要能抓到数据就能通过一条“路由规则”变成标准的 RSS 订阅源。再配合浏览器端的自动发现插件、一个自建的阅读器你确实可以在几分钟内把几十个网站、账号、关键词全部收进同一个信息流里。这就是标题里“3分钟订阅整个互联网”的真实含义不是夸张是操作流程本来就快。这篇文章我会把这套东西从底层逻辑到落地实操完整讲一遍。适合谁看信息重度消费者、做行业情报监控的产品经理、自媒体运营、科研人员以及所有不想被算法喂饭、想重新拿回信息主动权的人。哪怕你完全没接触过 RSS跟着步骤走也能跑通。1. 先想明白为什么RSS 这个老技术为什么值得重新捡起来1.1 现在获取信息的几个真实痛点说 RSS 之前先看看我们现在每天是怎么获取信息的。打开今日头条、抖音、小红书算法会告诉你“你可能喜欢”于是你看到的信息越来越窄越来越像你自己。需要跨平台追踪的 UP 主、公众号、微博博主、开源项目、论文作者分散在各处你被迫装了十几个 App。更要命的是平台的推送逻辑是“它想让你看什么”不是“你想看什么”。你明明只关心某个作者的新论文平台却觉得你更该看热门八卦。这种模式最大的问题是你永远在被动接收。你想主动订阅一个特定的人、一个特定的关键词恰恰没有入口。搜索结果页是一次性的过去的就过去了你不会每天去重搜一遍期刊网站你也很难天天刷只能等着邮件提醒。信息越来越丰富获取越来越高效其实是个错觉。效率高的是平台不是你。1.2 RSS 的核心价值订阅粒度与信息主权RSS 是二十多年前的老协议但它的设计思想现在看仍然领先。它把“信息获取”拆成了两件事你决定订阅什么然后由阅读器统一拉取。没有算法没有推荐没有信息流排序。你订阅了某个作者他发的东西就会一条不落地出现在你的阅读器里你没订阅的再热闹也和你无关。这就是订阅粒度的问题。在 RSS 体系里你可以做到非常精细的控制订阅一个具体的 GitHub 仓库的 Release只关注它是否发布新版本订阅某个微博关键词的搜索结果而不是某个博主的所有碎碎念订阅一个学术作者的论文列表他发了新文章你第一时间就能看到。能做到这些靠的不是某个大平台大发慈悲开放接口而是一个插件化的中转服务——RSSHub。它的思路是把“抓取某个网站的特定内容”抽象成一条条可插拔的路由规则社区里已经积累了上千条。你要做的只是找到你要的那条填上参数然后把它丢给阅读器。RSSHub 这个名字起得很贴切它像一个“路由枢纽”你在一边输入目标网站另一边输出标准 RSS。中间发生了什么你不用关心你只需要知道几乎任何有内容、有规律更新的网站都可以通过它变成订阅源。2. 插件化的核心秘密路由机制是怎么把任意网页变成订阅源的2.1 先拆解一下路由到底在干什么在 RSSHub 里每接入一个目标网站就对应一条或多条“路由”。所谓路由本质就是一段配置代码它至少包含三样东西匹配规则URL 里哪段是动态参数比如用户名、仓库名、关键词抓取逻辑请求目标网站的哪个地址是否需要登录、是否需要渲染 JS输出字段把抓到的网页内容映射成 RSS 标准里的标题、链接、摘要、发布时间。如果你用过 Express 这类 Node.js 框架对这个模式不会陌生。RSSHub 自己就是 Node.js 写的路由的模式也很像每条路由就是一个函数。比如 GitHub Release 这条路用户在浏览器里访问的订阅地址可能是/rsshub/github/release/diygod/rsshub翻译成实际行为就是去 GitHub 抓 diygod 这个用户下 rsshub 仓库的 Releases 页面把里面的版本号、更新说明、发布时间解析出来生成一个 RSS XML。同样的规则把用户名和仓库名换成别的就变成了另一个项目的订阅源。这就是“参数化”三个字的含义规则是固定的参数是活的。2.2 为什么要做成插件化架构一次跨领域的类比这里我想用一个看起来完全不相关的领域来帮助你理解——SolidWorks 机械设计里的零件参数化插件。用过 SolidWorks 的朋友都知道做机械设计的时候一个法兰盘、一根轴、一个齿轮建模流程其实是高度重复的选基准面、画草图、标注尺寸、拉伸切除、倒角……如果每个项目都从零开始建模效率极低。参数化插件的做法是把这些重复动作抽象成规则把关键尺寸暴露成参数你改一个直径、改一个厚度模型自动重新生成。RSSHub 的插件化架构和这个如出一辙。RSSHub 的维护者不可能为几千个网站维护一套臃肿的主程序所以把“针对某类网站的信息抓取”抽象成独立路由。主框架只负责三件事请求分发、执行路由规则、把结果输出成 RSS。而每接入一个新的网站只需要新增一个对应的路由插件不动主框架。插件化架构带来的三个直接好处我觉得是这套体系能持续壮大的真正原因社区协作门槛低你不需要理解整个项目只需要会写一条路由就能为某个网站接入支持。RSSHub 的上千条路由就是这样被一点一点填出来的。单点故障可替换某条路由挂了只影响那一个订阅源其他一切照常。你可以等社区修复也可以自己临时改。路由即文档每一条路由的参数说明本身就是使用文档用户不需要看源码只需要知道“填什么参数”。说白了插件化就是把“重复劳动”变成“规则复用”。SolidWorks 插件复用建模步骤RSSHub 插件复用抓取逻辑。跨领域一看设计思想是通用的。2.3 近距离看一条路由的解析过程拿一个典型的路由做示例拆给你看。假设目标是订阅某个视频平台 UP 主的投稿动态路由 URL 可能是https://rsshub.app/bilibili/user/video/22675798这条地址拆开段落作用bilibili目标站点标识决定使用哪套抓取逻辑user/video子路由表示“用户投稿的视频列表”22675798动态参数即 UP 主的 UID当请求到达 RSSHub实际发生的事是RSSHub 用这个 UID 拼接出目标站点对应的页面地址然后发送 HTTP 请求拿到页面 HTML 后根据路由里预设的解析规则提取出每个视频的标题、简介、封面、发布时间最后封装成 RSS 2.0 格式的 XML 返回。这里有一个很多人会忽略的点有些页面内容是通过 JavaScript 异步加载的初始 HTML 里根本没有数据。RSSHub 对这类站点需要在路由层额外启用无头浏览器渲染等 JS 执行完再去拿真实数据。这也是为什么自建实例时官方建议预留一定内存因为一旦大量路由需要走实时渲染资源消耗幕后就拉开了。从“用户填参数”到“服务端抓页面”再到“输出标准 RSS”整套链路实际上就是一个从 URL 到 RSS 的转换器。理解了这条链路后面我们看到任何“没有 RSS 的网站”都不会慌因为你知道剩下的事只是找对路由和参数而已。3. 从零实操Docker 部署 RSSHub 加阅读器3 分钟跑通3.1 先选实例公共实例还是自建如果你只是想快速体验 RSSHub 的能力最简单的办法是直接用官方提供的公共实例。RSSHub 的文档站上列出了大量现成的路由你随便挑一个拼好参数地址直接粘贴到阅读器里就能订阅。我最初就是先这样试了一只“B站 UP 主”订阅源确认输出正常后才开始考虑正经搭建。但公共实例有三个绕不开的问题稳定性看运气公共实例所有人共用流量大偶尔会出现限流甚至短暂不可用部分目标网站对公共云 IP 不友好反爬机制更严格你无法查看日志订阅源失效时很难排查到底是路由坏了还是实例被限了。所以我的建议很直接想认真用就花 10 分钟自建一个。Docker 方案是目前最简单、最省心的选择。3.2 Docker 自建 RSSHub部署、更新、验证先确认机器上已经装了 Docker 和 Docker Compose。没有的话先装上这不是什么高级操作网上教程一大堆。然后随便找个工作目录写一个docker-compose.yml内容大概是这样services: rsshub: image: diygod/rsshub:latest container_name: rsshub restart: always ports: - 1200:1200 environment: - NODE_ENVproduction - CACHE_TYPEmemory - CACHE_EXPIRE600 - LISTEN_INADDR_ANY0 - CORS_ALLOW_ORIGIN* volumes: - ./data:/app/data保存后执行docker compose up -d等服务跑起来访问http://你的服务器IP:1200。能看到 RSSHub 的路由文档页面说明服务已经正常。再顺手测试一条已知路由比如用 GitHub 仓库的 Release 订阅看能不能正常返回 XML能返回就说明链路通了。日常维护几乎为零建议定期更新镜像docker compose pull docker compose up -d这里有两个从实战中得出的提醒。一个是 RSSHub 默认监听 1200 端口建议在前面套一层 Nginx 反代并且强制 HTTPS否则订阅地址里带着 IP 和裸端口在部分网络环境里很容易被拦截。另一个是环境变量里的CACHE_EXPIRE我习惯设为 300 到 600 秒这样即使目标网站短暂抽风你也不会立刻在阅读器里看到一个刷新失败的源。设得太长又会让新内容延迟很久才出现这个值需要平衡。3.3 浏览器端神器RSSHub Radar让订阅源自己“跳”出来自建完 RSSHub先把浏览器插件装上。RSSHub Radar 是官方生态里的一个浏览器扩展作用非常关键当你打开任意一个网页时它会在后台检查这个网站有没有对应的 RSSHub 路由规则如果有扩展图标上会亮起提示点开后直接给出当前订阅地址。这套体验完全改变了“找订阅源”的流程。以前你要先去 RSSHub 文档站翻路由清单再对照参数拼接 URL现在你只要正常浏览网页它自动告诉你“这个页面可以订阅”。以订阅某个 UP 主的视频为例在浏览器里打开他的主页Radar 插件检测到页面匹配 B站的用户路由图标亮起弹出面板里直接显示最终的订阅地址点复制去阅读器里粘贴添加完成。整个过程不到 30 秒。Radar 插件的本质是一个本地路由索引。它内置了 RSSHub 的文档数据库负责匹配“URL 模式”和“路由规则”不涉及任何抓取行为所以非常轻量。3.4 阅读器选哪个FreshRSS 还是 Tiny Tiny RSS订阅源有了需要一个地方统一阅读。这张对比表是我自己的使用感受维度FreshRSSTiny Tiny RSS部署难度简单一个容器搞定略复杂依赖 PostgreSQL 或 MySQL多用户支持不支持适合个人原生支持适合团队共享自定义扩展官方插件与主题较多有社区插件体系界面风格清爽简洁高可定制支持主题化刷新机制依赖 cron 定时任务自带后台任务我的建议很个人化一个人用就上 FreshRSS省心团队几个人共用或者你特别想折腾界面和数据关联再考虑 Tiny Tiny RSS。FreshRSS 的部署同样走 Dockerservices: freshrss: image: freshrss/freshrss:latest container_name: freshrss restart: always ports: - 8080:80 environment: - TZAsia/Shanghai - CRON_MIN*/5 volumes: - ./data:/var/www/FreshRSS/data启动后浏览器访问http://你的服务器IP:8080按安装向导初始化然后在订阅管理里把雷达插件复制过来的地址粘贴进去点添加。做完这一步你的订阅体系已经成立了。3.5 完整流程实测3 分钟复现“订阅整个互联网”下面是完整复现一遍。假设我的目标是订阅五个东西一个 B 站 UP 主、一个 GitHub 仓库的 Release、一个微博关键词、一个行业科技媒体的全文、一个学术作者的论文列表。按顺序操作安装 Docker 并部署 RSSHub约 1 分钟前提是已经安装了 Docker否则会多花几分钟部署 FreshRSS约 1 分钟浏览器装好 RSSHub Radar打开目标网站逐个复制订阅地址1 分钟内完成五个源的添加。这就是“3 分钟”说法的来源。当然如果目标是监控一批特定网站主要工作其实花在前期调研而不是操作本身。这个流程实测下来稳不稳稳。但有几个细节需要处理不然会出问题某些目标网站的路由需要额外的参数或环境变量支持比如那些需要走无头浏览器的站点自建实例时要按路由文档要求打开对应的环境变量RSSHub 的公共实例偶尔抽风如果你要重度使用一定要优先自建FreshRSS 的定时任务是靠 cron 驱动的所以我上面特意设置了CRON_MIN*/5让它每五分钟拉取一次。把这些处理好你得到的是一套完全自主的信息获取系统。没有推荐算法干预没有平台推送噪音只有你真正在乎的内容。4. 科学场景实战用 RSS 精准追踪特定作者的文献更新4.1 科研和行业情报场景下的痛点前面说的都是折腾各种网站实际上 RSS 的价值在科研场景里被严重低估了。做科研的人都有这个体会盯住一个大牛比盯住一本期刊更高效。某个领域出了新论文、新进展真正值得你关注的就是那么几个团队。但学术信息的获取方式至今仍然很原始靠期刊订阅邮件、靠 Google Scholar 提醒、靠人脉互相转发。这些方式要么延迟高要么噪音大。邮件提醒经常被邮箱过滤规则误伤期刊订阅只能监控特定刊物跨库的效果很差。你想实现的目标其实很简单指定一个作者他一旦有新文献上线我第一时间知道且只让我看到这一条。RSS 天然适合干这件事。因为任何“搜索结果页”和“作者公开页面”本质上都是定期更新的内容源。只要有一条路由能把这些页面转换成 XML追踪就成立了。4.2 把作者检索变成可订阅源RSSHub 里有一类路由正是为学术检索服务的。以 Google Scholar 为例Scholar 的搜索结果页背后是一个支持强大检索语法的接口你可以把检索词从“某个关键词”换成“某个作者”。核心参数我建议这样组织https://你的RSSHub地址/google/scholar/author:作者名字Surname具体实现的原理是RSSHub 拿到这个参数后把author:xxx作为检索式发给 Scholar 的搜索接口拿回结果页然后解析出论文标题、作者列表、摘要、引用次数和发布出处输出成 RSS 条目。注意RSSHub 的路由参数在不同版本里可能有调整具体名字以你部署实例的文档页为准。我在这里不写死路径因为项目迭代很快写死了反而容易误导。真正重要的是那套思路找一个支持构建检索式的学术数据库把检索式放进路由参数里出来的 RSS 就是你定制的监控源。同样的逻辑可以延伸到 PubMed。PubMed 的检索式本身是通过http://www.ncbi.nlm.nih.gov/pubmed/?term...传递的RSSHub 的 PubMed 路由支持把完整的检索式作为参数传进去于是你可以订阅“某个关键词 某位作者”这样高度组合化的检索式比单独订阅期刊的范围精确得多。4.3 追踪链路搭建实录我实际搭建过一个追踪三位研究者文献更新的订阅组步骤可以做一次记录打开 Google Scholar按作者名搜索找到目标作者的学术主页确认 URL 里包含该作者的唯一 ID在 RSSHub 文档站里找到 Google Scholar 相关路由把作者的 ID 或检索式填入参数先用浏览器直接访问拼好的订阅 URL看看能否输出 XML以及摘要里是否包含了你关心的字段把这个地址挂进 FreshRSS设置刷新频率为每 30 分钟一次给这个订阅源打上标签“文献追踪”和其他资讯源做区分。实测效果这个订阅组跑了一个多月新论文的发现时间基本能和 Google Scholar 官方提醒持平甚至更快因为 RSS 抓取是分钟级的。最关键的体验是我的邮箱里再也不会混入学术提醒了全部内容都安静地待在自己的信息流里统一处理。这里有一个很实际的避坑经验Google Scholar 的反爬机制比较敏感如果请求频率太高容易返回 403 页面或验证码。所以自建 RSSHub 时请务必把路由对应的缓存时间设大比如一小时。缓存会让同一个订阅地址在短时间内只抓取一次既保证更新速度又不过度打扰目标网站。5. 实战过程中的坑与排查记录5.1 订阅源突然不更新先定位问题在哪一层订阅体系跑久了总会遇到某个源“断更”。别急着怀疑是目标网站没更新按以下顺序排查问题很快能定位先用浏览器直接访问订阅地址看有没有内容输出。有说明问题在阅读器刷新逻辑或网络链路没有问题在 RSSHub 或目标网站。再访问 RSSHub 的日志页面或容器日志。如果在日志里看到 403、429、5xx基本可以断定目标网站拒绝访问或路由抓取逻辑失效。去看目标网站本身有没有改版。如果页面结构变了路由里的解析规则就会失配输出为空或字段丢失这种情况只能等社区修复或者自己改路由。我遇到过最典型的案例是某个新闻类订阅源突然停更排查后发现目标网站启用了新的反爬策略RSSHub 发出的请求被当成爬虫拦截。最终解决方式是给 RSSHub 实例配置了代理出口和合理的 User-Agent 头才恢复正常。5.2 部署层面的几个高频问题部署阶段最容易踩的坑现象原因解决办法访问实例返回 504内存不足Node 进程崩溃给容器预留至少 512MB 内存镜像拉取失败网络问题配置镜像加速源或使用代理部分路由提示需要 Redis缓存类型选的是 memory而已开启 Redis 依赖按路由文档开启REDIS_URL环境变量HTTPS 证书反复报错没有配反代加一层 Nginx 或 Caddy 做终止 TLS另外如果你访问某个路由时提示“需要在环境变量中启用某功能”别硬试先去看这个路由在文档里的说明很多时候是作者特意屏蔽了不稳定的源等真稳定了才放开。5.3 反爬限制目标网站不是你想抓就能抓的真正让 RSSHub 路由失效的头号原因是目标网站的反爬策略。常见的有限制请求频率、检查 User-Agent、校验 Cookie、对数据中心 IP 段进行整体阻断。作为使用者你能做的调整有限但有三个习惯能减少踩雷自建实例的出口 IP 质量很重要别用被滥用的公共 IP 段对访问频率高的订阅源把CACHE_EXPIRE调高让每次抓取之间的间隔更长大部分专业源和学术源对低频请求容忍度很高反而是资讯类、社交媒体类更容易遇到风控。5.4 像 SolidWorks 参数化插件一样自己造一条路由最后说一下扩展。RSSHub 的真正魅力在于你不仅能“用别人写好的路由”还能自己写路由。这就像 SolidWorks 里你不仅是使用现成的参数化插件你还能根据自己的零件改进设计把新的建模流程固化成新插件。自己写路由并没有想象的难。RSSHub 项目的文档里已经给出了路由开发模板一个最简单的路由核心代码大概是这样module.exports { route: /example/:id, parameters: { id: 唯一标识 }, name: 示例源, categories: [其他], async handler(ctx) { const { id } ctx.params; const response await fetch(https://example-site.com/item/${id}); // 解析页面内容映射为 RSS 条目 return { item: [...] }; }, };这段代码的意图很直白接收参数id请求目标页面解析内容返回条目数组。你只要会一点 JavaScript 基础能看懂简单的网页结构就能写出自己的路由。写完放在项目的lib/routes/目录下本地测试通过后可以直接提交 Pull Request 回馈给社区。我自己写的第一条自定义路由是给某个小众设计资源站用的。那个站没有任何 RSS 输出首页也只展示最近十篇文章。按常规思路只能每天手动刷。后来我照着 RSSHub 的代码模板写了一条路由把首页的列表解析成订阅源挂进 FreshRSS 后就再也没手动打开过那个网站。从设计理念上说这和 SolidWorks 参数化插件是相通的把重复的动作抽象成规则把变化的部分暴露成参数主程序保持精简扩展能力全部交给插件。RSSHub 正是因为走了这条路才可能覆盖上千个形态各异的网站。而 CSV 你也能利用这个机会把任何你想要盯住的信息源变成自己的订阅不需要等待哪个平台大发慈悲开放接口。我个人在实际使用过程中最深的一点体会是RSS 这套体系越早搭越划算。刚开始接入了十几个源确实还感觉不到和普通刷网页有多大区别。但当你慢慢积累了上百个精准源之后那种信息完全按你意图流动的秩序感是所有算法推荐都替代不了的。真正值得长期关注的从来不是信息哪里最多而是你能不能在最需要的地方第一时间看到它。