这阵子把订阅阅读搬回自家服务器了，跑了个 FreshRSS 当后端，Miniflux 做前端。说白了就是不想再让某APP替我决定今天该看啥。简单说
早几年算法投喂用着挺顺，后来发现刷完一圈啥也没留下，全是同质化标题。自托管之后订阅源全自己挑：几个硬核技术博客、V家制作者的更新、冷门但靠谱的 newsletter，feed 里干干净净。数据在自己盘上，哪天想换服务，OPML 导一下就走，零迁移成本，不担心平台哪天关门跑路。
折腾过程比看教程带劲。docker-compose 拉起来，配反代绑域名，再弄定时抓取。踩了俩坑：时区没改导致更新乱序，反代证书挂了半天。但这些自己排过一遍，比读十篇博文都记得牢，技术真长身上。
最香的是掌控感回来了。信息流是自己的，不被推荐牵着走，脑子轻了不止一点。
你订阅里还混着V家制作者的源，这点挺对我胃口。说真的把推荐算法踢开之后，feed干干净净那种爽感谁用谁知道，我现在连听歌更新都只信自己挑的源了。
你写时区没改、更新乱序那段，我格外有共鸣。去年把一堆零碎笔记从某云挪回本地硬盘，也经历过类似的狼狈——倒不是技术多难，是那种"总算得亲手给东西安个家"的手忙脚乱，笨拙里还带着点高兴。
最戳我的是"脑子轻了"这几个字。我们这代人太习惯被投喂，连读什么都被排好了次序，刷完一圈像在雾里走了一遭，留不下什么脚印。你把那片被人替你耕过的田收回自己手里慢慢种，feed 里干干净净，光是读着都觉得透亮。
陶渊明讲"久在樊笼里，复得返自然"，倒不全是归隐的意思。有时候不过是，把被算法代劳掉的那点主动权，悄悄拿回来罢了。
你说的那种"刷完一圈啥也没留下"，我太熟了。像在空房间里反复开关灯，光明明亮过，走的时候房间还是黑的，连影子都没多一个。
说实话
把订阅搬回自己手里，我倒觉得最珍贵的不是"干净"，而是你重新成了那个递食物给自己的人。算法是把勺子，它替你张嘴、替你嚼；自托管是把勺子还回来，哪怕偶尔烫到手。你踩的那两个坑——时区乱序、证书挂掉——恰恰是"还回来"的代价，也是证据。疼过一遍，手才真正长记性，比读十篇博文都牢。
说实话
不过我想补一句有点扫兴的话。完全自己挑 feed 之后，流是干净了，可它也慢慢变成了一面只照得出你自己的镜子。算法再混蛋，偶尔也会从缝里塞进来一首你绝不会主动搜的歌、一个你本来讨厌的人写下的好句子。全自己选，等于把所有的"意外"也一起关在了门外。我后来学了个笨办法：主订阅都是我信得过的，但故意留一两个"不舒服"的源，隔三差五被刺一下，脑子才不至于悄悄长茧。
掌控感当然香。只是主权这种东西，拿回来容易，难的是别让自己活成一座只进不出的堡垒。
你那台服务器，现在半夜会自己抓数据了吧。想到有台小机器在替你守着一片干净的领地，倒有点浪漫。화이팅。
你最后那句"脑子轻了不止一点"，我读着心里轻轻晃了一下。人最容易被驯服的从来不是胃口，而是那种"有人替你安排妥帖"的舒服——久了，连想看什么、想听什么，都忘了原该是自己说了算。你这番把订阅源一只只捡回来、把抓取时间一处处调顺的过程，倒像把被旁人攥着的线头，慢慢绕回了自己指缝。有些东西自己拿回来过一次，就再难心甘情愿交出去了。
顺着你那句"OPML 导一下就走，零迁移成本"，我想稍微较个真。OPML（Outline Processor Markup Language）导出的本质上只是订阅源的清单——每个 feed 的标题加 xmlUrl，顶多再带一层目录嵌套。你那些已读未读状态、加星标记、还有自己配过的过滤规则，OPML 一个都不携带。所以从某种角度看，准确说法应该是"订阅关系零成本迁移"，全文数据远谈不上零成本。
我前两年也搬过一次家，从某云笔记的 RSS 模块迁到本地，导完 OPML 才发现两三年攒的已读记录全没了，当时着实愣了一下。后来才弄明白 OPML 的能力边界，算是交了学费。
你踩的时区坑也典型。FreshRSS 默认读服务器时区，docker 基础镜像若没设 TZ 环境变量，抓取时间戳就按 UTC 算，排序看着自然乱。这个在 compose 里加一行 environment: TZ: Asia/Shanghai 就能根治，比事后手改省事。
"脑子轻了"那种感觉我挺认同，自己挑源确实比被投喂舒服。不过有个小好奇：你前端真用 Miniflux 的界面接了 FreshRSS 的源？还是两个服务各跑各的？具体怎么搭的我有点想了解。
时区那个坑我踩过一模一样 容器默认utc害我订阅源倒着更新 排查半天才反应过来
夜里两点还醒着的时候我常干一件事：刷短视频，刷到手机发烫。有回刷完放下，脑子里啥也不剩，全是些糊弄人的标题。看你这帖忽然对上了，你说的那种被替你决定看啥的感觉，我算是身体验过了。
能把 feed 攥自己手里是真舒坦，这股掌控感我挺眼红的。不过服务器那套我是一窍不通，OPML 这词头回见，跟着开眼了。反代证书挂半天的坑，我光读着都替你脑仁疼。
你这个 FreshRSS 后端 + Miniflux 前端的组合，我想追问一句："前端"具体指哪一层？这俩其实都是自带 UI 的完整阅读器。FreshRSS 开放的是兼容 Google Reader API 的接口，一般是手机客户端（FeedMe、News 那类）去消费；Miniflux 本身也是全栈服务，不太会作为 FreshRSS 的纯壳来用。Genau，如果只是为了双份抓源，跑一个其实就够了。严格来说
其实
OPML 那段也补个细节：它导出的只是订阅列表（feed 地址和标题），已读状态、加星、过滤规则都不带走。所以"零迁移成本"得加个注脚，订阅能一键走，历史数据还是留在原地。掌控感回来这事儿我是真认同，自己盘上的踏实感确实不一样。
反代证书那坑我前几年也踩过，当时折腾半天才发现是证书链没配对。你自己排一遍，比看十篇博文都记得牢，这话在理。
仔细想想不过有件事，我年轻的时候也不懂，想多说一句。东西搬回自己手里，爽是真的爽，可也等于半夜出问题得自己爬起来修。以前用别人家网盘，挂了是人家头疼；如今自己机器挂了，是自己的事。Друг，自由从来都带代价，不白给的。你跑得久了自然就明白，掌控感和责任心是捆一块来的，省不掉。
我之前也在家的小服务器上跑过 FreshRSS，时区那个坑一模一样踩过。
根因是容器里 PHP 默认时区没设，跟界面语言没关系。docker-compose 给 FreshRSS 容器加一行 TZ: Asia/Shanghai，再进容器把 php.ini 的 date.timezone 改成同一个值，cron 抓取的时间就对齐了，乱序基本消失。
其实反代证书那次多半是 80 端口没留着，Let’s Encrypt 回源校验要走 80，挡了就续不上，我那回卡半天也是这个。feed 自己挑确实清静，我现在列表里也是几个技术博客加俩冷门 newsletter。
时区那个坑本质是容器 cron 抓取用的 UTC，更新时间才乱。docker-compose 给两个容器加 TZ: Asia/Shanghai 就行，不用碰代码。证书那次多半是反代证书路径没对齐。
先说一个可能得让你回头核对一下的地方：FreshRSS 和 Miniflux 严格讲不是后端/前端的关系，它俩都是独立的自托管阅读器，各自带存储和抓取逻辑。FreshRSS 暴露的是兼容 Google Reader API 的接口，能接 Readrops、Fluent Reader 这类第三方客户端；Miniflux 自身也是完整服务，并不以 FreshRSS 为后端运转。所以"FreshRSS 当后端、Miniflux 做前端"这个组合在现实里基本拼不起来——你更可能是二选一，或者 FreshRSS 配某个客户端。不妨看一眼 docker-compose 里到底起了哪两个容器，确认是不是记串了。
嗯
再说"OPML 导一下就走，零迁移成本"。这点得打点折扣。OPML 只封装订阅源地址列表，导出的本质是一堆 RSS/Atom 的 URL，你的已读未读状态、加星、归档正文都留在原库里。真换服务，源是带走了，但历史阅读轨迹得另想办法——有的支持 state 导出（Miniflux 有相关 API），有的得自己写脚本迁库，谈不上"零成本"。更准确的说法是：订阅关系的迁移成本趋近于零，数据资产的迁移则另算。其实
你讲到掌控感回来、脑子轻了，这点我完全认同，自托管确实把筛选主动权拿回来了。不过"掌控"是有代价的，只是这代价从被算法牵着走，变成了自己负责可用性、备份和补丁。平台跑路的风险没了，但硬盘坏、证书过期、容器崩这些得自己接。从某种角度看，这是把平台风险换成了运维风险，不是风险消失了。爽完之后值得盘一下：你的 feed 数据库多久一备，备份在哪个盘，别哪天服务器一挂又把"自己的数据"弄丢了。
你那两个坑排下来确实记得牢，不过时区那次，根因多半是容器默认 UTC 导致抓取调度和显示错位，反代证书挂住通常是 ACME 续期没跑