用 FreshRSS 追踪技术更新：Docker 部署、订阅导入与自动刷新检查

技术文档、博客和项目发布信息散在不同网站里，每天逐个打开很费时间。FreshRSS 可以把 RSS 与 Atom 订阅放进自己的阅读器，按分类浏览、保留未读和收藏。它适合跟踪已经提供订阅的网站，不需要先抓取整个互联网，也不负责保证原站文章永远可访问。

第一次只导入经常阅读的十几项订阅，观察标题、摘要、发布时间和刷新结果。把几年收藏的所有网址一口气导入，可能得到很多不支持订阅或已经失效的条目，反而更难整理。

部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。

OPML 保存订阅，完整数据保存阅读状态

OPML 适合从旧阅读器搬入订阅，或把订阅带到别的工具。已读、收藏、历史文章、账号和设置不应默认全部包含在 OPML 中。完整实例恢复需要另外保存应用数据，使用扩展时也保留相关目录和版本。

FreshRSS 官方订阅列表与阅读界面示例

项目仓库保留的历史截图展示分类和文章列表；当前版本的主题与按钮可能已有调整。实际订阅提供全文还是摘要，由来源和设置决定；有些文章仍需回原站阅读，不能把阅读器的收藏状态当作已经保存了一份完整原文。

订阅内容也可能包含私人信息，例如带令牌的内部 RSS 地址。导出 OPML、备份或截图前检查这些地址，不把自己的私人订阅列表直接发给别人作为推荐清单。

从官方镜像和本地数据目录开始

本文使用默认 Debian 系列官方镜像，持久数据路径为 /var/www/FreshRSS/data，扩展路径为 /var/www/FreshRSS/extensions。不套用其他镜像的 PUID/PGID 参数，不因看到同名软件就认为目录和用户都相同。

mkdir -p ~/services/freshrss/data ~/services/freshrss/extensions
cd ~/services/freshrss

保存 compose.yaml：

services:
  freshrss:
    image: freshrss/freshrss:latest
    environment:
      TZ: Asia/Shanghai
      CRON_MIN: "13,43"
    ports:
      - "127.0.0.1:8084:80"
    volumes:
      - ./data:/var/www/FreshRSS/data
      - ./extensions:/var/www/FreshRSS/extensions
    restart: unless-stopped

CRON_MIN 设置每小时对应分钟刷新，示例每小时两次。未设置或留空时，镜像内的自动刷新任务会被禁用，因此仅看到网页正常不能证明订阅会自动更新。已有外部定时任务时，不再同时启用两套相同刷新机制。

docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 freshrss

默认发行标签用于初次部署，验收后固定对应版本或镜像摘要。扩展有独立维护状态，升级应用之前核对兼容性，不把所有扩展同时更新后才发现无法判断是哪一项出了问题。

首次安装使用 SQLite 验证

ssh -L 18084:127.0.0.1:8084 user@your-server

本机打开 http://127.0.0.1:18084，按安装界面检查环境、选择数据库和创建用户。小实例可以从 SQLite 开始，不为了一个人的阅读器就先增加外部数据库的维护。如果选择了 PostgreSQL 或 MySQL，后面的目录备份也要补上相应数据库恢复材料。

安装后的认证方式要明确。私人实例不要使用无需认证的公开入口，先退出登录，确认访问订阅或账户时的实际行为。需要多个用户时分别创建账号，各自管理阅读状态，不共用一个管理员。

正式域名启用 HTTPS 后，反向代理接到宿主机 8084，并核对应用的外部地址和代理设置。实际测试登录、添加订阅和 OPML 导入，不只检查首页标题。反向代理、认证和应用设置都可能影响提交操作。

FreshRSS 订阅抓取、阅读状态与导出关系示意

抓取任务把更新放进数据目录，读者操作产生阅读状态。OPML 主要携带订阅关系，完整副本用于恢复两者及账号设置。

准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。

导入后检查代表性订阅

导入一个小 OPML，核对分类、中文名称和 URL。选一项普通博客、一项项目发布订阅和一个自己维护的测试源，观察文章数量、日期和摘要是否符合预期。重复订阅和失效地址先处理，再继续导入。

文章更新和新文章的规则可能因来源而异。原站修改旧条目、不提供稳定标识或重新生成订阅，会影响阅读器判断；出现重复不一定是数据库损坏。查看来源与抓取结果，再决定如何整理，不直接清空历史重新开始。

长期不读的订阅可以单独分类或取消。分类围绕自己的阅读目的，例如项目更新、服务器维护和个人文章；不需要每个网站都建一层目录。阅读入口越简单，越容易每天实际使用。

自动刷新要用真实更新验证

观察日志及订阅的最后更新时间。最好使用自己能修改的测试订阅，新增一条文章后等待定时任务，确认它进入列表。手动点击刷新成功只能证明抓取可用，不能证明 Cron 已按时间执行。

遇到错误，区分 URL 不存在、格式解析、证书、网络或来源限流。先验证服务器是否能访问该源，再调整应用设置。不要因为自己浏览器能打开原站，就认为服务器端的抓取一定会成功。

每半小时抓一次适合不少普通订阅，但来源可能有自己的访问规则。大量订阅同时刷新时，观察耗时和资源占用，再安排合理频率。没有必要为了“及时”把所有来源都改成每分钟访问。

需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。

客户端 API 不与网页密码混用

手机阅读器若支持 FreshRSS API，需要按当前版本的账户和 API 设置启用相应功能。客户端支持的协议、端点与认证方式不同，照它自己的文档填写，不把一个客户端的 URL 直接复制给所有应用。

API 凭据也需要保护。丢失手机、停用客户端或更换账号后，撤销旧凭据，再检查网页账号和其他设备是否正常。使用 API 不代表所有阅读功能都完全一致，拿一条已读和一条收藏实际验证同步效果。

内网或带私人令牌的订阅不宜随意共享。默认限制的内部主机访问，不因为某条订阅失败就直接全局放开；确需访问自己的内网来源时，按当前官方配置精确允许目标。

备份先保住自己整理过的内容

停止应用后保存本地数据、扩展及 Compose：

mkdir -p backups
docker compose stop freshrss
tar -czf "backups/freshrss-$(date +%F-%H%M%S).tar.gz" data extensions compose.yaml
docker compose start freshrss

把副本转移到外部存储，限制访问。另做一份 OPML 导出，便于未来迁移订阅；两者都保存，但不要把它们说成同一种备份。外部数据库部署必须增加数据库导出，本例目录副本只覆盖本地方案。

恢复测试采用独立目录与回环端口，使用备份对应的镜像及扩展版本。检查账号、分类、历史文章、已读与收藏，然后让测试订阅产生一次新条目，确认恢复后的刷新也能继续运行。升级后如果数据迁移已经发生，回退使用升级前副本，而不是仅换回旧镜像。