基于Vercel自建RSSHub：摆脱信息茧房的部署与调优指南

信息获取这件事，这几年悄悄变了个味。以前我们主动去各个网站“找”内容，现在变成了平台算法“喂”内容，喂什么吃什么，吃着吃着就发现，自己看到的世界越来越窄，同一个观点被反复强化，不同声音越来越难进入视野。这就是大家常说的信息茧房，它不是某个平台的阴谋，而是推荐机制天然的副作用。我自己做内容这些年，越来越警惕这种状态，所以一直在折腾一件事：把信息入口重新握回自己手里。RSS 就是最朴素也最有效的工具，而 RSSHub 则是把那些不提供 RSS 的网站“翻译”成 RSS 的万能适配器。这篇内容要聊的，就是怎么用 Vercel 这个免费托管平台，把 RSSHub 部署成自己的专属信息中转站，从此订阅源自己定、阅读节奏自己控。适合谁看？会一点基础操作、愿意花半小时动手、想摆脱被动投喂的朋友，都能跟着做下来。

1. 先想清楚：为什么要自建 RSSHub 而不是用现成的

1.1 信息茧房的本质是入口被别人攥着

很多人对信息茧房的理解停留在“算法推荐不准”，其实更根本的问题在于入口控制权。你打开某个应用，看到什么、按什么顺序看到、哪些内容被折叠，全由后台决定。你以为是自己在浏览，实际上是在别人铺好的轨道上滑行。RSS 的价值就在于它把“拉取”这个动作还给了用户：你决定订阅谁、多久看一次、用什么工具看，平台不再有中间拦截的机会。

但现实很骨感，大量网站早就砍掉了 RSS 输出，尤其是各类社交平台、视频站点、论坛，它们巴不得你留在自己的应用里。RSSHub 解决的就是这个断层，它用一套路由规则，把网页内容抓取、解析、转换成标准 RSS 格式，让任何支持 RSS 的阅读器都能订阅。换句话说，RSSHub 是那个帮你把“不开放的门”重新撬开的工具。

那为什么不直接用公共的 RSSHub 实例？原因有三个，我按重要性排一下：

• 稳定性不可控：公共实例用户量大，经常限流、超时，热门路由动不动就 503，你正看到关键处突然刷不出来，体验很差。
• 隐私与数据：你的订阅列表、阅读偏好都经过别人的服务器，虽然多数实例不做记录，但数据经过第三方这件事本身就不太舒服。
• 路由可用性：公共实例为了控制负载，往往只开放部分路由，一些冷门但对你很重要的源可能根本用不了。

自建之后，这些顾虑基本消失。服务器是你自己的（虽然是免费的），路由想开哪个开哪个，访问量只有你自己，稳定性反而更好。

1.2 Vercel 免费额度够不够用，算一笔账

选 Vercel 的核心原因是免费且省心。它提供 Serverless 函数托管，不需要你维护服务器、不用管系统更新、不用配反向代理，代码推上去就能跑。对个人使用来说，免费额度到底够不够？我拿自己的实际用量算一下。

Vercel 免费版（Hobby 计划）的额度大致是这样：每月 100GB 带宽、函数执行时间有一定限制、部署次数不限。RSSHub 单次请求返回的内容通常几十 KB 到几百 KB，假设你订阅 50 个源，每小时刷新一次，一天就是 1200 次请求，按平均 100KB 算，一天流量约 120MB，一个月 3.6GB 左右。这个量级离 100GB 的带宽上限还有很大距离，个人使用完全够。

真正需要注意的是函数执行时长和冷启动。Serverless 函数每次被调用都要经历一次启动过程，如果某个路由抓取的目标网站响应慢，函数执行时间就会拉长，极端情况下可能超时。所以自建 RSSHub 时，路由的选择和缓存策略比公共实例更重要，这一点后面会详细讲。

提示：免费额度是给个人合理使用的，别拿它跑高频率轮询或者对外提供公共服务，那样既不稳定也容易触发平台限制。

1.3 部署方案的整体思路

整个方案其实就三层：代码层是 RSSHub 本体，从官方仓库拉取；托管层是 Vercel，负责运行和对外提供访问；使用层是你的 RSS 阅读器，订阅部署好的地址。三层之间通过环境变量和路由配置连接起来。

我选择直接 fork 官方仓库再改配置，而不是从零搭一个精简版，原因是官方仓库的路由最全、更新最勤，后续想加新源直接同步上游就行，省得自己维护。代价是仓库体积大一些，首次部署稍慢，但这是一次性成本，值得。

2. 动手前的准备：账号、环境与仓库

2.1 账号与工具的清单

动手之前，把这几样东西备齐，能省掉中途卡壳的麻烦：

• 一个代码托管平台账号：用来 fork RSSHub 仓库，主流平台都行，操作逻辑类似。
• 一个 Vercel 账号：直接用代码托管账号授权登录最方便，省去单独注册。
• 本地环境：装好 Git 和 Node.js（建议 18 以上版本），用于本地调试和推送代码。如果你只想在网页上操作，本地环境可以跳过，但调试时会不方便。
• 一个 RSS 阅读器：网页版、客户端都行，用来验证部署结果。

Node.js 版本这块要留意，RSSHub 对 Node 版本有要求，太老的版本跑不起来。我建议直接装当前 LTS 版本，别用太新的实验版，兼容性更稳。

2.2 Fork 仓库时的几个细节

打开 RSSHub 的官方仓库，点 fork，这一步没什么难度。但有几个细节值得说：

第一，fork 之后建议改个仓库名，比如加上自己的标识，方便区分。第二，注意分支选择，官方主分支更新频繁，如果你追求稳定，可以 fork 后切一个固定 tag 的分支，避免上游大改导致你的部署突然挂掉。我自己是跟主分支，但会在部署前看一眼最近的提交记录，有大的破坏性变更就缓一缓。

第三，fork 完成后，把仓库克隆到本地。命令很基础：

git clone https://你的代码托管地址/你的用户名/rsshub.git cd rsshub

克隆下来之后先别急着改，跑一下npm install装依赖。这一步耗时取决于网络，耐心等它跑完。装完之后可以本地启动试试：

npm run dev

默认会在本地某个端口起服务，浏览器打开能看到 RSSHub 的欢迎页，说明环境没问题。这一步的意义在于，把问题暴露在本地而不是部署之后，本地能跑通，部署成功率会高很多。

2.3 环境变量的规划

RSSHub 支持大量环境变量，但自用部署不需要全配，挑几个关键的就行。我整理了一个常用清单：

具体变量名以官方文档为准，我这里强调的是配置思路：缓存要开、超时要合理、访问要控制。缓存能大幅减少对目标网站的请求，既保护对方也提升自己的响应速度；超时设置要平衡，抓取慢的源给足时间，但不能无限等；访问控制是自用实例的保险，万一地址泄露，有个口令挡一下。

注意：环境变量在 Vercel 后台配置，改完需要重新部署才生效，别改完就以为立刻起作用了。

3. 部署到 Vercel：从导入到跑通

3.1 导入项目与构建设置

登录 Vercel 后台，选择新建项目，关联你的代码托管账号，找到 fork 的 RSSHub 仓库导入。导入后进入配置页，这里有几个关键项：

框架预设一般能自动识别，识别不准就手动选 Node 相关预设。构建命令和输出目录保持默认即可，RSSHub 官方仓库已经配好了。环境变量在这一步就可以填，把上一节规划的几个变量加进去。

有一个容易忽略的点：Node 版本。Vercel 项目设置里可以指定 Node 版本，建议选和本地一致的 LTS 版本，避免本地能跑、线上报错这种尴尬。我踩过一次坑，本地是较新版本，线上默认版本偏旧，某个依赖直接报语法错误，排查了半天才发现是版本不一致。

3.2 首次部署与验证

点部署，等构建完成。首次构建时间会比较长，因为依赖多，几分钟到十几分钟都正常，别以为卡死了。构建成功后 Vercel 会给你一个域名，形如你的项目名.vercel.app。

验证分三步走：

1. 访问根路径，能看到 RSSHub 的欢迎页面，说明服务起来了。
2. 访问一个简单路由，比如某个常见站点的订阅路径，看能否返回 XML。浏览器直接打开会显示一坨 XML 文本，这是正常的，说明路由工作。
3. 丢进阅读器订阅，看能否正常解析出条目。这一步才是真正的验收，因为有些路由返回的 XML 格式有细微问题，浏览器看着正常，阅读器却解析失败。

我第一次部署时就遇到过路由返回内容但阅读器报错的情况，后来发现是某个字段编码问题，换了个路由就好了。所以验证一定要用真实阅读器，别只看浏览器。

3.3 自定义域名与访问控制

Vercel 分配的默认域名能用，但不太好记，而且某些网络环境下访问体验一般。如果你有自己的域名，可以在项目设置里绑定，按提示配置解析记录即可。绑定后记得等证书签发完成，通常很快。

访问控制这块，自用实例建议加一层。RSSHub 本身支持简单的访问校验，配合环境变量设置一个口令，阅读器订阅时把口令带上。这样即使地址被别人知道，没有口令也拿不到内容。设置方法参考官方文档的访问控制章节，核心就是配一个密钥变量，然后在请求里带上对应参数。

提示：加了访问控制后，阅读器里的订阅地址要相应调整，别忘了这一步，否则会一直提示无权限。

4. 路由配置与缓存调优：让实例真正好用

4.1 路由的取舍原则

RSSHub 的路由成百上千，但不是每个都适合在你的实例上跑。我的取舍原则是按需启用、优先稳定。具体来说：

• 只留自己真正订阅的源，用不到的路由不用管，它们不会主动消耗资源，但了解哪些路由对目标网站压力大，有助于避开雷区。
• 避开高频抓取类路由，有些路由每次请求都要抓大量页面，在 Serverless 环境下容易超时，能不用就不用。
• 关注路由的维护状态，官方仓库里有些路由因为目标网站改版已经失效，订阅前先看文档标注。

我自己的做法是维护一个订阅清单，每个源标注抓取频率和稳定性，隔一段时间回顾一次，失效的及时替换。这个习惯坚持下来，信息流的质量会明显提升。

4.2 缓存策略的实际调整

缓存是自建实例和公共实例体验差距最大的地方。公共实例为了公平，缓存时间往往设得保守；自用实例可以按源定制。思路是这样：

• 更新频率低的源（比如周更的博客），缓存时间可以设长，几小时甚至一天都行，减少无谓请求。
• 更新频繁的源（比如新闻类），缓存时间设短一些，保证时效，但也别短到每次刷新都回源。
• 抓取成本高的源（需要多页解析的），缓存时间必须设长，否则既慢又容易失败。

RSSHub 的缓存通过环境变量控制，可以设全局默认值，也可以针对特定路由覆盖。我一般先设一个全局的适中值，然后对几个重点源单独调。调整后观察一段时间，看阅读器里的更新是否及时、请求是否稳定，再微调。

4.3 冷启动与响应速度的优化

Serverless 的冷启动是绕不开的话题。函数一段时间没被调用，下次请求要重新初始化，第一次响应会慢几秒。对 RSS 阅读来说，这个延迟通常可以接受，因为阅读器是后台定时拉取，不是你在前台干等。

但如果你的阅读器设置的是打开即刷新，冷启动的延迟就会感知到。缓解办法有两个：一是适当提高阅读器的刷新间隔，让请求分散；二是利用缓存，缓存命中时不需要重新执行抓取逻辑，响应会快很多。这两个办法配合起来，日常使用基本感觉不到冷启动的存在。

5. 常见问题排查与实战避坑

5.1 部署后访问 404 或 500

这是最常见的问题，原因通常分几类。404多半是路由路径写错，或者该路由在你的版本里不存在，对照官方文档核对路径。500则是函数执行出错，去 Vercel 后台看函数日志，日志里会写明错误类型。

我遇到过的 500 有几种：依赖缺失（构建时没装全）、环境变量名写错（读不到配置）、目标网站反爬（抓取被拒）。排查顺序建议是先看日志、再本地复现、最后查路由文档。本地能复现的问题最好解决，改完推上去重新部署即可。

5.2 路由能返回但阅读器解析失败

这种问题最迷惑，浏览器打开有内容，阅读器就是不认。原因通常是 XML 格式细节问题，比如字段缺失、编码不规范、日期格式不对。排查方法是把返回的 XML 复制出来，用在线 XML 校验工具过一遍，看有没有格式错误。

另一个常见原因是阅读器对某些字段要求严格，比如缺少发布时间就拒绝解析。这种情况可以换个阅读器验证，确认是路由问题还是阅读器问题。如果是路由问题，看看官方仓库有没有相关 issue，或者自己改一下路由代码。

5.3 抓取频繁被目标网站限制

自建实例虽然请求量小，但如果某个源你设的刷新频率太高，照样会被目标网站限制。表现是间歇性失败、返回空内容或者验证页面。解决办法很直接：降低刷新频率、拉长缓存时间。RSS 的本质是聚合更新，不是实时监控，大多数源一小时甚至几小时刷新一次完全够用。

还有一个技巧是错峰抓取，如果你的阅读器支持为不同源设置不同刷新时间，把几个重点源错开，避免同一时刻集中请求。这个细节对稳定性帮助不小。

5.4 常见问题速查表

这张表我建议存下来，出问题时按行对照，能快速缩小范围。实际排查中，大部分问题都落在前四行里。

6. 我踩过的坑和几条实在建议

6.1 别一上来就订阅几十个源

新手最容易犯的错是部署完兴奋，一口气把能想到的源全加上，结果阅读器里信息爆炸，反而更焦虑。我的建议是从五到十个核心源开始，跑一两周，确认稳定、内容质量符合预期，再逐步增加。RSS 的意义是精准获取，不是越多越好，源太多和算法投喂没本质区别，只是换了个方式淹没自己。

6.2 定期维护比一次性部署更重要

自建实例不是部署完就一劳永逸。目标网站会改版、路由会失效、依赖会更新，隔一段时间要回顾一次。我一般每个月花十几分钟，检查订阅源是否正常、有没有该更新的依赖、日志里有没有异常。这点维护成本换来的是长期稳定，很划算。

6.3 把阅读节奏也设计进去

工具解决了“获取”，但“怎么读”还是自己的事。我自己的习惯是固定时段集中看，而不是随时刷新。RSS 阅读器最大的好处就是没有推送打扰，你可以决定什么时候打开。如果把它用成又一个随时响的应用，那就白折腾了。

6.4 关于免费额度的心态

免费额度是给合理使用的，个人订阅完全够，但别想着拿它做对外服务或者高频抓取。真到了不够用的程度，说明你的使用场景已经超出个人范畴，那时候再考虑升级或换方案也不迟。现阶段，把精力放在选好源、调好缓存上，比纠结额度更有价值。

最后分享一个我一直在用的小习惯：给订阅源分个组，核心源和拓展源分开，每天只看核心组，拓展组周末扫一眼。这个简单的分类，让信息获取从“被动接收”变成了“主动安排”，茧房也就慢慢被撬开了。