Gist 是一款采用 Next.js 构建的现代 RSS 阅读器应用程序。

最近我的 FreshRSS 阅读器出了一个怪现象：用来实现智能刷新订阅源的 AutoTTL 扩展在这个月初突然“罢工”了。具体表现为，我手动点击刷新后，它能按调整后的 TTL 时间更一次，之后就彻底“躺平”。所有订阅源的「下次更新时间」都卡在 pending，关掉 AutoTTL 反而能恢复正常自动刷新。

这问题有点意思，像是某个环节的状态机卡住了。作为一个喜欢刨根问底的人，我花了点时间深入排查，最终发现问题的根源竟是一个看似不相关的数据库警告。记录一下这次排查的全过程，给遇到类似问题的博友一个排故参考。

[toc]

FreshRSS 自动更新问题描述

FreshRSS 部署情况

• 运行环境：FreshRSS 与 PostgreSQL 均部署在 Docker 容器中。
• 软件版本：FreshRSS：V 1.27.1；PostgreSQL：V 15.15；AutoTTL： V 0.5.9。

FreshRSS 诡异现象

1. 在 FreshRSS 管理页面点击“手动更新”，所有订阅源能正常刷新。
2. AutoTTL 插件会在设定的 TTL 时间到达后，成功执行一次自动更新，刷新全部订阅源（其实并不，只是当时我以为是全刷新了）
3. 但在此之后，所有订阅源的“下次更新时间”全部显示为 pending，AutoTTL 的自动调度机制似乎完全停止工作。
4. 关键线索：关闭 AutoTTL 扩展后，FreshRSS 基础的计划任务反而能正常定时刷新。

FreshRSS 自动更新问题初步判断

问题的核心矛盾点很明确：

• 手动刷新有效：说明 FreshRSS 的核心更新脚本 actualize_script.php 和网络连接本身没问题。
• AutoTTL 自动调度失效：说明负责定时触发更新的“闹钟”——也就是 Cron 服务，或者 AutoTTL 扩展自身出了问题。
• 关闭 AutoTTL 后正常：这几乎将矛头直接指向了 AutoTTL 扩展。我第一感觉是插件冲突或者插件本身 Bug 了。

FreshRSS 自动更新问题排查

最讨厌这种“时灵时不灵”的问题，因为手动刷新后，AutoTTL 扩展居然还能正常工作一次（其实并不是正常工作，只是当时我没发现而已。其实这次会在更新到一半时卡住，但因为会更新一部分订阅源所以我当时一直以为订源被全部更新了）

第一步：先确保自己是在用最新版的软件

首先重新拉取一次镜像，并检查AutoTTL 扩展的实际版本，确保他们都是最新版，以防这个 bug 其实早就被修复了，只是我没更新，或者是两者某一方更新后，另一方没更新导致的兼容性问题。
经过检查，确认目前，FreshRSS、PostgreSQL、AutoTTL都是他们各自的最新版本了。

第二步：看眼前端日志

看眼日志里都有点啥问题，是不是某个订阅源有问题，导致卡死在它上边了
虽然日志中有很多类似报错

cURL error 28: Operation timed out
HTTP 503 Service Unavailable!
HTML+XPath Web scraping failed for 
Error fetching content: HTTP code 0: Could not resolve host:

但这基本都是订阅源本身的问题，比如触发了源的抓取频率限制，源站服务器卡了。并没有发现会引起订阅源无法更新的故障。于是这时我感觉肯定是扩展的锅，于是就跑去 github 给 AutoTTL 发了个 issues。
扩展作者mgnsk的回复提醒了我“How often does your cron run? A pending status means that the time for updating the feed has arrived but cron has not run yet.（cron 每隔多久运行一次？挂起状态意味着更新 feed 的时间已到，但 cron 尚未运行。）”

第三步：检查 Docker 内的 Cron 服务

FreshRSS 的自动更新依赖于容器内的 Cron 服务定时执行任务，既然自动更新卡住，那就先检查 cron 是不是正常工作。

1. 这里为了行文方便，先假定一些配置

   FreshRSS本体容器名：freshrss-app
   PostgreSQL数据库容器名：freshrss-db
   PostgreSQL数据库用户名：freshrss
   PostgreSQL数据库密码：freshrss
   

2. 进入容器：首先得进到容器内部看看。

   docker exec -it freshrss-app /bin/bash
   

3. 检查 Cron 状态：看下是不是 cron 服务宕了
   输入 service cron status，结果显示 cron is running.。嗯，系统级的 cron 在正常走，没问题。

4. 查看定时任务：看看具体定时任务是什么

   执行 crontab -l，看到了关键配置：

   */21 * * * * . /var/www/FreshRSS/Docker/env.txt; su www-data -s /bin/sh -c 'php /var/www/FreshRSS/app/actualize_script.php' 2>> /proc/1/fd/2 > /tmp/FreshRSS.log
   

这个配置设计得很周到：先加载环境变量文件，然后切换到 www-data 用户执行更新脚本，还把日志重定向了。

5. 手动执行定时任务：
   先不带参数执行一下试试
   • 直接键入 php /var/www/FreshRSS/app/actualize_script.php ：结果直接罢工了，好吧看来环境变量是必须的。
   • 那就带上参数试试. /var/www/FreshRSS/Docker/env.txt; su www-data -s /bin/sh -c 'php /var/www/FreshRSS/app/actualize_script.php' 结果订阅源正确刷新了！ 这说明Docker内，cron设置的更新命令本身和权限设置都是正确的，所以如果不使用 AutoTTL 时能正常更新是理所应当的。

第四步 研究下 AutoTTL 是如何工作的

AutoTTL 的工作原理，其实就是
1. 先根据每个订阅源历史上的平均更新间隔，最短更新间隔，计算出每个不同的订阅源，最合适的刷新间隔。
2. 拦截系统的cron，让他不是刷新所有订阅源，而是改为触发 AutoTTL，由 AutoTTL 去判断本次 cron 应该去刷新哪些订阅源。
3. 就在这时，我注意到了一个事情：AutoTTL 会往数据库里写数据并计算排序他们 既然刚才手动执行系统级 Cron 任务能成功，为什么自动运行时 AutoTTL 就不行呢？差别就在于“手动”和“自动”之间的环境差异。我意识到，刚才的输出信息我还没仔细看。

第五步：回头再看一眼刚才被忽略的警告日志

再次手动执行 Cron 任务，但这次我紧紧盯着终端输出。果然，在一堆刷新成功的提示信息之间，发现了一条 WARNING：

WARNING: database "freshrss" has a collation version mismatch
DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE freshrss REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

这个警告来自于 PostgreSQL 数据库。大意是：数据库的排序规则版本和操作系统提供的版本不匹配。通常是因为系统底层库升级了，但数据库对象还用的是旧规则。
我想起来，月初时服务器宕机了一次，被我顺势维护了一番，当属将所有能更新的 docker 都手动更新了一次，而日常docker 的自动更新是由 Watchtower 做的，为了稳定性，我并不允许 Watchtower 去更新 docker 中的数据库版本，这次我看 PostgreSQL 只是一个小版本升级（ 15.14 → 15.15 ）更新日志中没改啥东西，就顺手也给升级了。

第六步：修复数据库排序规则

根据警告信息的提示，我们需要对 PostgreSQL 数据库进行操作。

1. 连接至 PostgreSQL 数据库：

   # 进入 PostgreSQL 的容器，使用 psql 客户端连接
   docker exec -it freshrss-db psql -U freshrss -d freshrss
   

2. 重建数据库索引（重要）：
   在数据库连接中，执行以下 SQL 命令。执行以下命令，重建所有使用默认排序规则的数据库对象（主要是索引）以确保其与新版本的规则兼容。

   REINDEX DATABASE freshrss;
   

   这个过程可能会花费一些时间，取决于你数据库大小。

3. 刷新数据库的排序规则版本：
   重建完成后，重建完成后，执行 WARNING 提示中的命令，更新数据库的系统目录版本：

   ALTER DATABASE freshrss REFRESH COLLATION VERSION;
   

4. 在freshrss中手动刷新一次订阅源，耐心等待了下一个 Cron 周期…………好了 AutoTTL 正常工作了，订阅源能够按照 Adjusted TTL 定期自动更新，完成故障修复。

FreshRSS 自动更新，为什么因为“警告”就会导致故障？

我推测是这样的机制

1. 系统级 Cron 按时启动，AutoTTL拦截 Cron。
2. AutoTTL 开始工作，首先它会连接数据库，准备获取需要更新的订阅源列表。
3. AutoTTL 连接数据库执行初始查询，排序订阅源列表，确定现在哪些订阅源需要更新。
4. PostgreSQL 输出了这个排序规则不匹配的警告。这个警告信息可能被 AutoTTL 的错误处理机制捕获，导致脚本的执行流程被意外中断或挂起，但又没有抛出致命的错误，所以 FreshRSS 的日志中也不会有记录。
5. 于是，AutoTTL “静默”失败了。对 AutoTTL 插件来说，它感知到的状态就是“上一次更新任务启动后没正确结束”，所以它不敢再调度新的任务，所有状态便卡在了 pending。
6. 当我手动刷新时，绕过了 AutoTTL 的排序步骤， AutoTTL 只记录订阅源的最后刷新时刻，所以更新能成功。

总结与教训

1. 不要忽视任何警告（Warning）：尤其是数据库、系统底层的警告。它们可能不会立即导致服务崩溃，但会像“慢性病”一样，在特定条件下引发诡异的行为。
2. 日志是救命的黄金：不要感觉如果能跑 WARNING 日志就不需要，而只记录 ERROR 日志。这次如果放过日志中的 WARNING ，我可能还在插件代码里兜圈子。
3. 数据库升级需谨慎：在这之前我只锁死大版本，谁能想到这次小版本升级都能出事，Docker 官方实打实的给我上了一课。
4. Docker跑数据库需指定精确的版本号：数据库的 docker 镜像一定要写死版本，绝对不要使用 latest 标签，务必使用精确的版本号，以确保部署的一致性。最好连 Debian 版本号也指定上，也就是 17.6-bookworm 这样的版本号。为什么？比如这次的小版本更新中实际 隐含着一次 Linux 操作系统大版本升级。 你以为自己只是从 PostgreSQL 15.14 升级到 PostgreSQL 15.15 只是数据库的一次小版本号升级，但实际上 Docker 官方提供的 PostgreSQL 镜像，这次把运行 PostgreSQL 的操作系统从 Debian 12 升级到了 13 。这就导致 C 函数库 (glibc) 版本出现了跃迁 —— glibc 版本从 Debian 12 的 2.36 升级到了 Debian 13 的 2.41，而在这两个 glibc 版本中，排序规则发生了变化，这也就是本次故障产生的核心原因所在。

希望这篇记录能帮到遇到类似问题的朋友。如果你的 FreshRSS 或者其他使用了 PostgreSQL 的Docker 也出现了什么灵异现象，不妨先去检查一下数据库日志，说不定会有惊喜（或者说惊吓）。

具体这次 Docker 官方在 PostgreSQL 升级时做了什么，可以参考这篇文章《原地报废：不要在生产环境用Docker跑PostgreSQL！》

The post FreshRSS 自动更新订阅源失效排查：AutoTTL 扩展失效竟是 Docker 官方埋下的坑 appeared first on 秋风于渭水.

Glean（拾灵）是一款自托管的 RSS 阅读器和个人知识管理工具，帮助重度信息消费者通过智能 RSS 聚合高效管理阅读。

WordPress 如何让 RSS feed 输出全文？ WordPress RSS 设置全文输出教程 教你让 WordPress 的 RSS 订阅显示全文 WordPress：让 RSS 订阅源输出完整内容的三种方法 修改 WordPress /feed 输出全文的完整指南 RSS 只显示摘要？教你改成全文（WordPress 设置/代码/插件） WordPress RSS 全文输出配置：设置、代码与插件方案 如何强制 WordPress RSS 显示完整内容（含 functions.php 方法） 提升订阅体验：WordPress RSS 输出全文的解决方案 WordPress RSS 订阅优化：开启全文输出的最佳实践

通过 WordPress 设置修改

1. 进入 WordPress 管理后台 → 设置 → 阅读。
2. 查找 “For each article in a feed, show”（每篇文章在订阅源中显示）。
3. 你会看到两个选项：Full text（完整内容）和 Summary（摘要）。
4. 选择 Full text 以确保 /feed 输出文章的完整内容。
5. 点击 保存更改（Save Changes）。

通过主题修改（当设置被覆盖时）

• 打开你主题的 functions.php 文件。
• 添加以下 PHP 代码：

// 强制 RSS 订阅源显示完整内容
function my_full_feed_content($content) {
    return get_the_content();
}

add_filter('the_excerpt_rss', 'my_full_feed_content');
add_filter('the_content_feed', 'my_full_feed_content');

通过插件修改

最近偷窥大佬【似水流年】的友链RSS聚合页，在流年兄的大力指导和支持下终于完美上线。 展示：朋友的圈 – 品味苏州 (pwsz.com) 导航简称（友圈）。 此页面聚合了本站友链中经常更新的朋友们的rss数据，终于不用再每次一个个点击网站查...

Source

最近我发现原本的 RSS（/rss、/feed）没有按时更新。 [caption id="attachment_5288" align="alignnone" width="351"] rss[/caption] 进一步检查后发现这些地址都被 301 重定向到了 FeedBurner（https://feeds.feedburner.com/zhihua-xblog），而 FeedBurner 已经久未维护，偶有抓取失败或延迟，导致读者无法及时收到新文章。 造成这次重定向的原因是我们使用的第三方主题/插件（mytheme）里曾经内置了将站点 feed 转发到 FeedBurner 的功能。 当时之所以做 301 转向，是为了节省服务器带宽并统一订阅链接。 但现在服务器已经升级，带宽与性能不再是主要问题，因此不再需要通过 FeedBurner 做中转。 更糟糕的是，外部订阅器或旧配置在访问 /feed 时被持续重定向到 FeedBurner，如果 FeedBurner 自身抓取不到最新源，就会出现更新停滞或重复重定向的风险，极端情况下甚至可能出现重定向环（redirect loop）。 为了避免订阅丢失或链接异常，我们决定弃用 FeedBurner，并将本站的官方 RSS 源迁回自有域名。 请所有读者、RSS 订阅器和外部引用尽快把订阅地址改为： https://justyy.com/feed 如果你在使用 Feedly、Inoreader、邮件订阅或其他 RSS 客户端，请把原来的 FeedBurner 地址替换为上面的新地址，以确保你能及时收到更新。 如果你在网站或第三方平台上嵌入了本站的 RSS 链接，也请尽早更新为 https://justyy.com/feed，以免未来出现不可预期的中断。

用 FeedBurner 的好处

• 统一和美化 RSS 输出：让各平台的 RSS 格式一致，订阅链接固定。
• 订阅统计：可以看到每日订阅人数、来源与点击数。
• 邮件推送功能：自动将新文章通过邮件发送给订阅者。
• 广告功能：早期支持 AdSense for Feeds，在 RSS 中插广告获利。
• 节省带宽：FeedBurner 缓存内容，订阅者访问时不会直接访问原站。

用 FeedBurner 的坏处

• 功能残缺：订阅统计、邮件推送等功能已被停用或不稳定。
• 数据不准确：订阅数与阅读数常年不更新。
• 影响 SEO 与品牌归属：订阅链接属于 FeedBurner，而不是你自己的域名。
• 更新延迟：FeedBurner 抓取源可能延迟几小时，无法实时同步。
• 潜在风险：如果未来 FeedBurner 服务终止，订阅者将全部丢失。

总结与迁移建议

本想着RSS阅读器——FreshRSS 就留在1.24.3版本养老的，因为更高的版本需要PHP 8.1及以上的版本，而我用的则是PHP 7.4.3，不想安装新版本的PHP了。

奈何手痒，点了升级，突如其来的报错让我懵了。报错如下：

Parse error: syntax error, unexpected '|', expecting '{' in /www/wwwroot/网站文件夹/lib/lib_rss.php on line 140

这下不装也得装了。

先尝试8.1不行，又升到8.4，还是不行，这已经是目前最新的PHP版本了，如果还不行，那说明程序有问题了。

于是找到报错文件对应的行数，看代码是什么。

搜索到这是PHP不同版本的间语法问题，照着说明改了几处，问题依旧。尝试用Google Gemini，改进代码依然无效。使用PHP在线监测工具，代码没问题。

求救朋友，微信群，朋友圈，要么忘了，要么无回复，要么就是开玩笑。

后来突然想起来，何不用最新的代码覆盖？覆盖问题依旧，那么用原来的覆盖呢？

这下有变化了，变成新的报错了：FreshRSS error: FreshRSS requires PHP 8.1.0+!

而我就是用的 8.4.1啊，尝试重启PHP，问题依旧。那如果重启整个服务器呢？

我去！

果然重启大法好。

重启之后再次升级成功。

FreshRSS升级成功

最近因为Follow的爆火，RSS的内容也跟着一起火了一把。笔者最近也优化了一下自己博客的RSS输出，在这里写一下博客如何更加 优雅的输出RSS，以及在订阅RSS的时候如何更好的发现RSS源。

RSS2.0 与 ATOM

RSS是一种消息来源格式，用于方便的将一个站点的内容以一个指定的格式输出，方便订阅者聚合多个站点的内容。

目前RSS的版本为2.0，而我们大家在使用博客输出RSS文件的时候，除了常用的RSS2.0格式，目前还有一个ATOM格式，其目前的版本为1.0。Atom发展的动机为了解决RSS2.0的问题，它解决了如下问题（来源WikiPedia）：

• RSS 2.0可能包含文本或经过编码的HTML内容，同时却没有提供明确的区分办法；相比之下，Atom则提供了明确的标签（也就是typed）。
• RSS 2.0的description标签可以包含全文或摘要（尽管该标签的英文含义为描述或摘要）。Atom则分别提供了summary和content标签，用以区分摘要和内容，同时Atom允许在summary中添加非文本内容。
• RSS 2.0存在多种非标准形式的应用，而Atom具有统一的标准，这便于内容的聚合和发现。
• Atom有符合XML标准的命名空间，RSS 2.0却没有。
• Atom通过XML内置的xml:base标签来指示相对地址URI，RSS2.0则无相应的机制区分相对地址和绝对地址。
• Atom通过XML内置的xml:lang，而RSS采用自己的language标签。
• Atom强制为每个条目设定唯一的ID，这将便于内容的跟踪和更新。
• Atom 1.0允许条目单独成为文档，RSS 2.0则只支持完整的种子文档，这可能产生不必要的复杂性和带宽消耗。
• Atom按照RFC3339标准表示时间 ，而RSS2.0中没有指定统一的时间格式。
• Atom 1.0具有在IANA注册了的MIME类型，而RSS 2.0所使用的application/rss+xml并未注册。
• Atom 1.0标准包括一个XML schema，RSS 2.0却没有。
• Atom是IETF组织标准化程序下的一个开放的发展中标准，RSS 2.0则不属于任何标准化组织，而且它不是开放版权的。

相比之下ATOM协议是有更多的有点，如果你RSS生成程序已经支持了Atom那肯定是优先使用Atom。不过现在基本上99%以上的Rss订阅器或者工具对于两者都有很好的支持，因此如果你现在已经使用了RSS2.0也没必要替换成Atom了。

RSS的自动发现

对于提供Rss订阅的网站，最好的方式是提供相应的连接或者使用Rss图标，告诉访客当前网站的Rss地址。

除了这样之外，我们还应该在网站的源码中添加RSS地址，这样对于一些浏览器插件或者订阅软件可以通过我们的网站页面自动发现RSS订阅地址。

对于RSS2.0的订阅地址可以添加如下代码：

1

<link rel="alternate" type="application/rss+xml" href="/feed.xml" />

对于ATOM的订阅地址可以添加如下代码：

1

<link rel="alternate" type="application/atom+xml" href="atom.xml" title="Site title" />

如果你同时提供了ATOM和RSS2.0两种订阅文件，可以上面两行代码都添加。当然现在一些博客程序的模板文件中已经添加了上面的代码，检查一下即可。

RSS输出的优化

因为我的博客是以RSS2.0格式输出的订阅文件，因此这里我就按照我的优化内容来介绍一下输出相关的优化，对于ATtom可以参考其规范文档。

首先区分介绍和全文的输出。对于只输出描述的网站只需要设置描述部分即可，对于输出了全部的博客，还是建议同时输出描述和全文的。 而RSS2.0不支持输出全文，我们可以用一下的标记来输出全文：

1

<content:encoded>全文内容</content:encoded>

其中的文章html，最好做一下转码。 （以上代码加的有问题，有的RSS识别失败，暂时回退了，有时间换Atom）

其次可以补充一下网站的内容的元数据，比如作者的信息，网站的标题简介等等。

对于文章，也可以在输出的时候输出相关的元数据，如标题，作者，标签等。标签支持设置多个，可以用如下的标记：

1

<category domain="{{ .Permalink }}">{{ .LinkTitle }}</category>

另外在我设置的过程，发现rss是提供了一个comments标记的，设置这个标记后，如果RSS阅读器对此支持，理论上可以直接从RSS阅读器点击跳转到文章的评论页面。

最后，我们可能想要检测要多少通过RSS点击跳转到我们博客的访问量，这个时候可以在输出的链接上面加上特定的参数，这样在我们的统计平台上面就可以看到有多少用户从这里打开页面的，我所加的参数如下：

?utm_source=rss

订阅RSS

目前最流行的订阅RSS的方式要属于Follow了，这里也推荐使用。

除了Follow之外，我还自建了一个FreshRss来订阅一些内容，这个的使用要更早于Follow的出现。现在还不能抛弃它的原因是Follow目前不支持移动端，我使用Android的手机，在移动推荐使用FeedMe来浏览FreshRss的订阅内容。

另外，我们在浏览一些内容或者博客的时候，也需要一个工具来帮助我们方便的查看和订阅RSS源，这个时候就要推荐一下DIYgod大佬开发的浏览器插件RSSHub-Radar，对于我们的博客，如果已经加了我前面说的html代码，它可以自己发现订阅地址，如下图所示：

它还支持配置规则，则一些拥有RSSHub订阅的站点，比如b站，微博，小红书等，可以嗅探到RSShub的订阅地址，如下图所示：

另外，看上面弹出的窗口中是可以直接去预览对应的RSS内的，还可以直接跳转到Follow、FreshRss等订阅源去添加这个订阅源，这些可以在插件的设置中进行设置，如下图所示：

除了上面的设置，这个插件还支持一些其他的设置，读者朋友可以自行探索。

总结

以上就是关于网站配置和rss订阅方面我的一些建议，而本文的标题也有一些标题党了，欢迎吐槽。

资料

如果读者需要查阅ATOM和RSS的维基百科，请查看英文版本，中文版本内容比较简略，很多发展相关的内容都没有。

• ATOM 规范：https://datatracker.ietf.org/doc/html/rfc4287
• RSS2.0 协议：https://www.rssboard.org/rss-specification
• RSSHub-Radar: https://github.com/DIYgod/RSSHub-Radar

看完评论一下吧

捣鼓订阅了几个常用博客聚合平台，期待发现更多有趣站长！

经常关注不到学校的一些通知之类的，而学校网站又没有 RSS 订阅。

使用 Feed43 创建订阅源，需要的同学可以订阅。