关于“信息获取”和“RSS”具体方案的一些疑问（别沉，欧内该

搞七捻三
,
1

先叠个小甲，非代码专业人员，没啥专业基础，目前知识有限，有 理解偏差\错误 还望指出。真诚发问，各位程序员大佬，看到血压高请打它一拳出出气:down_arrow:
monkey_face

佬友们刷信息流上瘾么？有没有只想搜什么东西，或者打开看看关注的up更新，就不知不觉刷起了推荐——刷推荐的时候还总希冀能刷到一些有趣有用的内容，在“浪费时间”和“害怕错过”之间反复受折磨。以上是我的情况 :rofl:

这时候聪明的佬友说了：你可以有策略、有目的的刷，通过互动行为影响算法推荐，让高质量内容多多出现在我的信息流推荐中——本人愚钝，除了穿着清凉的小妹妹，黑箱里再没有其他内容服我管教让推荐趁我心意了。这是另外的话题，暂且按下不表

本贴讨论的是“不刷”的方案——脱离推荐信息流，乃至脱离刷子广告客户端，将需要的信息汇聚一处。聪明的佬友肯定会想到RSS和RSSHub，俺的疑问就源于此。

目前方案：
使用 docker compose 在 vps上部署了RSSHub，主要在手机上使用folo查看
不太满意的地方：

  1. 没有消息推送
  2. 订阅源不稳定：自己配置的源（比如b站知乎非热门博主的投稿）和官方实例（b站小约翰等热门up动态）均会出现不定时的失效。官方示例可能过几天会恢复，自建的不太会排查，经常前一天好好的，突然就不行了，手动更新cookie也只能挽救一部分，仍然有一些动不动就挂了。
  3. RSSHub似乎不支持单个订阅源的精细管理，只能在 docker-compose.yml 文件中定义“缓存时间”这个全局参数，要多订阅不同缓存策略，只能部署多个实例。

所以请教各位佬，有没有 消息推送+统一客户端+信息源稳定可自定义 的解决方案。（要求会不会太高了 :melting_face: 因为纯自用不需要啥规模 所以过反爬+稳定 应该是可以实现的吧？吧？ :innocent:）

期望达到的效果：

  1. 能够为不同的订阅源自定义方案（比如数据存储时间、刷新频率、防封反爬），比如“即时消息”能够主动推送 ；“例行浏览”能够定时更新。
    个人习惯是将信息源分两类：
    a. 和当下任务弱关联or无关联，但感兴趣。比如社交媒体频道
    希望能够定时推送，小时或者日级别，每天早上起来扫一眼
    b. 和当下任务强关联，必须“追新”的领域消息，比如官方消息通知
    希望能够即时推送，分秒级别
  2. 能够汇总到一个客户端，最好兼顾一下阅读时的体验。Reader wise配套的阅读器感觉就很好（但是感觉中文支持不太美丽，比如字符统计是摆设，中文源获取失败等等）。

问问哈基米，得到了一些方案：
1.Cron Job 使用 cron（Linux 的定时任务调度器）为不同的 RSSHub 链接设置不同的访问频率。
——看起来这是解决“定时推送”最简单的方案，不知道有没有佬试过，和RSSHub适配如何。
2.Webhook 通过自动化工具（如 n8n, Huginn, IFTTT, 或者自己写的脚本），监听上游服务的事件。一旦事件发生（例如，Telegram 频道收到新消息），自动化工具就立即调用一个接口或执行一个命令来访问对应的 RSSHub 链接，从而实现“零延迟”的缓存更新。
——涉及到“push”和“轮询”等等专业领域，不是很懂。rss+n8n好像有不少用户，前者获取并处理信源数据，后者负责定时任务推送。还要再维护一套n8n容器系统么？
3.通过其他的TTRSS、FreshRSS这样的自建客户端集中管理。
4.找一些稳定专业的rss服务，哪怕付点钱呢——问题是，有覆盖国内外主流平台并对它们做相应优化的服务存在么？

除了第四条，以上方案均依托RSSHub这个“信息抓取和处理”的引擎，好像不太能解决订阅源时不时失效的问题，

以下就是“异想天开”环节了

B站服务器 → （苹果/谷歌的）推送服务 → 手机系统 → 官方App被唤醒 → App向B站服务器请求完整数据 → App在屏幕上显示内容 → App同时在“通知栏”推送一个本地通知

通过AI得知，数据是通过如上方式被终端的手机获取的.
那么在这条链上，想要绕过反爬，并且稳定、容易下手的地方就是“请求完整数据”以后了——能不能直接拿到输出在手机上的信息？它既有实时的通知，又有处理好的数据；官方客户端和正常用户行为，也不必担心反爬

哎？我正好有一个解了bl锁的xiaomi备用机，能不能通过读缓存或者屏幕内容等方式实时拿到各大APP推送的数据再转发到特定客户端？

比如Brak这种能够推送通知，那能不能连里面的内容一起推呢？

希望抛砖隐玉，神通广大的佬友们有没有处理这类问题的美妙想法捏？（不限于方案本身，只要是有关“高效芜杂的信息获取”，哪怕一点点的方便和优化都好，欧内该）

23 个赞
2

ios 通知的话试试bark，用webhook就可以发送

5 个赞
3

好的谢谢佬 :smiling_face_with_three_hearts:，考虑过这个方案，还没试过。这里的“通知”可以点开查看内容么？比如完整的动态文章

1 个赞
4

bark都是banner样式的通知只有纯文字，可以用 URL Test 实现实现点击跳转

https://bark.example.com/{token}/URL Test?url=https://www.baidu.com

还有可以找找有没有URL Scheme的阅读器，把url scheme填到url里也可以实现点击跳转到应用去，我试了以下 folo:// 可以跳转到folo

1 个赞
5

rsshub本身最好还是家宽部署，
b站,zhihu都是加入了自身的cookie,应对反爬。
你的问题是ttrss+rsshub+客户端即可。

1 个赞
6

N8N几乎不怎么需要维护 就加个Rss Feed Trigger 往那一挂

我不咋喜欢被新闻提醒（有种被骚扰的感觉）
所以都是直接推送到 Discord 有空再看 :blush:

1 个赞
7

我的方案是，RSShub+自己开发的基于python的任务管理项目+Gotify。
数据源方面：RSS订阅，API获取等
数据处理：通过python加工rsshub和api获取的内容。
通知推送：通过部署Gotify服务来推送。

3 个赞
8

不知道 op 找的怎么样了。

folo 订阅稳定问题 该咋解决呢。我现在自建源都认证不过0.0

1 个赞
9

0.o蹲

2 个赞
10

首先感谢各位佬提供的想法和方案，小小汇报一下情况：
手上的服务器是两台1h1g的Oracle免费amd小鸡（问就是arm开不出来 :rofl:
分别部署了 带无头浏览器的RSSHub 和 Miniflux（因为TTRSS有点带不动所以放弃了

已解决问题：
推送，Miniflux集成了ntfy等推送服务，而ntfy有官方直接可用的实例。可直接分订阅源设置新消息推送到手机上的ntfy客户端，还挺即时。自己部署ntfy或者gotify服务器亦可。

待观察问题：
订阅源，暂时依靠 无痕浏览器登入获取的cookie硬撑，先观察几天看看情况。
定时刷新，由于TTRSS性能吃紧，转向Miniflux。发现有“entry_frequency”这样的参数——官方说可以根据源的历史刷新频率来智能规划刷新。亦在观察。

未解决问题：
b站等平台的时效性依然没办法缩短到分钟级：不确定反爬封禁上限不敢测。

cookie失效的问题 RSSHub的github issue （还没仔细看弄明白 就没尝试 :smiling_face_with_tear:

部署过程中的一些情况：
TTRSS Awesome版本目前看来比较主流，但是ntfy的插件作者使用的是其它版本镜像（那位大佬的 相关博文。不知道是不是这个原因，抑或是我配置问题，反正在TTRSS上，启用的ntfy插件无法正常推送；稍微开几个文章过滤，就直接卡死，订阅源爆红。（可能是性能真的绷不住了

Miniflux 官方文档很不戳，各种集成和环境变量参数都写明白了，只是关于“控制订阅源刷新”的几个相关参数略有些绕。最近刚部署，看看效果。（起码暂时没发现卡死

另外
1.有空会把 docker-compose.yml 文件整理一下开个帖子。反代、日志和自动更新粗浅处理了一下，贴上就能跑，便利一下跟我一样的小白。
2.关于如何自制稳定订阅源 发现了Changedetection 和 Huginn 这俩东西。好像有点复杂的样子，还没来得及看，感兴趣的大手子是不是可以出一波实战教程捏 :laughing:搓手手
3.有关folo（原Follow）刚开始收费了。不算新用户了，优点槽点都有，反正我挺疑惑的一点是，不管怎么折腾，我的小米手机都收不到通知；win和mac前一段可以，最近只是提示“测试消息发送成功”，也收不到通知，就，挺难受。

3 个赞
11

抱歉，我也没懂它客户端上所谓的“认证”到底咋回事。可能是和这个图中的有关？

PixPin_2025-11-06_16-49-59
PixPin_2025-11-06_16-49-591450×942 53.4 KB

我切换到其他好心人的实例，在客户端的订阅源还是显示“rsshub://”，也不知道到底抓取请求的发起方到底变了没。
我猜测的是：上传自己的实例，就是在图中页面贡献自己部署的服务，然后认证后可以方便直接在客户端用自己的源订阅，不需要再该前缀拼地址，顺便可以收取一些好看的小“power”（虽然不知道有啥用 :innocent:。

1 个赞
12

别用fo.lo了，吃相有点难看，免费版没法用了，bug也一堆，总是对交互布局进行大更新，越更越不好用。建议自建 freshrss，有其他的需求都可以通过插件解决，我最近还在摸索，打算自建一个使用。

2 个赞
13

是这样的，我觉得它好贵，免费版限制也好多。重点是没有解决订阅源的稳定问题，还是经常爆红。其实我还是挺愿意直接打钱给各大主流订阅源的维护者呢，也不知道订阅费有多少会给到这些开发者 :smiling_face_with_tear:
1H1G的小鸡：啊？我跑FreshRSS，真的假的？ :zany_face:
FreshRSS我的小鸡好像也跑不起来，等到有钱换大鸡把（bushi

反正Miniflux因为没有单个\分类订阅源的刷新时间精细管理，本来是妥协的选择。用了两天发现还可以，起码不卡。先看看情况 :laughing:

2 个赞
14

以前我也用RSSHub，自建了FreshRSS，后面出的Follow内测也用了，其实很多内容也不是我关心的内容，有些内容的时效有限，错过就错过了，还有筛选关键词推送也不好用。

比如说：Steam临时工，XXX上错价格，XXX新史低，突发新闻，这种内容就应该立即推送给我，有些标题内容还写得比较隐晦，还得AI总结一下，更像是监控。我需要这种时间较短的消息的推送。

2 个赞
15

稳定性一直是个弊病，也不知道是rsshub的问题还是它的问题，经常有些订阅莫名其妙就订阅不了，还有不报红但也不更新的源，报红都太日常了。之前也就是凑活在用，听说freshrss很好用，正好打算替换了。

1 个赞
16

认真整理下来，发现真正想看的，影响当下生活的讯息少之又少。但是，却更加重要了，如果还有业务相关，那就依然刚需实时性。听闻 稳定性 和 即时性 本质冲突，可能还要依赖商用IP池或者爬虫。
也本来越觉得个人使用，不商用量也不大，应该很好解决。后来发现想多了，真要实现自用，估计还要上点专业强度。

1 个赞
17

ttrss、miniflux、freshrss都用过，觉得ttrss最接近google reader，但是php的后端有点爱不起来。

自从ttrss不再维护，转移到了freshrss，但是界面不好看。有个兼容的客户端，感觉不好用呀。

1 个赞
18

看有没有好看的主题整上俩？部署ttrss的时候，找到过RSSHub的同款主题，发现css可能有问题，页面显示混乱无比，就没再搞了。

1 个赞
19

类似这两种的混合体，推送真正感兴趣的有时效的内容，AI总结来推送概要，能分类整理打标签更好。

确实最大问题还是源的问题，RSS本身就会慢点，还是应该尝试家里电脑家宽这种内容获取。

1 个赞
20

那个Bzhan的我尝试复刻来着，但是有些B 站视频没有官方字幕。