RSSHub 最容易让人产生错觉的时刻，是 Docker 显示 Up 的那一刻。服务启动了，首页也能打开，似乎以后只管阅读就行。真正用上几周，才会碰到另一组问题：某条源不再更新，磁盘慢慢变满，更新镜像后多了一个报错，换服务器时想不起密钥放在哪儿。
这些问题不需要很复杂的平台才能处理。一套个人使用的 RSSHub，通常把配置、缓存、入口和更新流程理顺，就能少掉不少临时救火。这篇围绕 VPS 上的长期运行展开，既给出可落地的部署文件，也讲清楚什么值得备份、更新前该留什么、遇到故障如何回退。
把这套服务拆成四件事
RSSHub 读取上游内容并生成 Feed；Redis 缓存请求结果；Caddy 为阅读器提供 HTTPS 入口；阅读器保存你怎么读、读到哪儿。这四件事不能互相替代。
尤其要分清缓存和归档。Redis 数据没了，RSSHub 通常可以重新抓取；阅读器里的已读状态、收藏和历史文章没了，则要看阅读器自己的备份机制。只备份 RSSHub 的 Redis 卷，无法保证恢复你完整的阅读历史。
还有一种常见误会：服务器在线，就等于所有订阅都正常。实际上，健康接口可能一直返回成功，而某个网站刚好改了页面、收紧了匿名 API 或要求登录。维护时要留一个基础健康检查，再选几条真正重要的路由做内容检查。
先部署一份自己能维护的 Compose
下面适合宿主机已有 Caddy、Docker Engine 与 Compose 插件的 Linux VPS。RSSHub 只监听本机 1200 端口，Redis 留在 Compose 网络里。没有 Caddy 也可以先在 SSH 会话中完成本机测试，之后再接入口。
mkdir -p ~/services/rsshub
cd ~/services/rsshub
umask 077
printf 'RSSHUB_ACCESS_KEY=%s\n' "$(openssl rand -hex 32)" > .env
chmod 600 .env
新建 .env 的命令只执行一次；已有配置时先备份，不要覆盖。创建 compose.yaml：
name: rsshub
services:
rsshub:
image: ${RSSHUB_IMAGE:-diygod/rsshub:latest}
restart: unless-stopped
ports:
- "127.0.0.1:1200:1200"
environment:
NODE_ENV: production
CACHE_TYPE: redis
REDIS_URL: redis://redis:6379/
CACHE_EXPIRE: "900"
ACCESS_KEY: ${RSSHUB_ACCESS_KEY:?Set RSSHUB_ACCESS_KEY in .env}
depends_on:
redis:
condition: service_healthy
healthcheck:
test: ["CMD-SHELL", "curl -fsS --get --data-urlencode key=\"$$ACCESS_KEY\" http://127.0.0.1:1200/healthz >/dev/null"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
redis:
image: redis:7-alpine
restart: unless-stopped
volumes:
- redis-data:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 3s
retries: 3
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
volumes:
redis-data:
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
本文选择 900 秒路由缓存，是为个人订阅留出一个保守的起点，不代表所有源都应使用相同刷新节奏。镜像先用 latest 便于首次拉取，稳定后再固定摘要。浏览器组件没有默认加入，后面需要时再扩展。
宿主机 Caddy 增加独立站点块：
rss.example.com {
reverse_proxy 127.0.0.1:1200
}
把域名换成自己的，先完成 DNS 解析与入口放行，再验证、重载 Caddy。已有站点块应保留；Caddy 在容器中时，回环地址属于它自己，必须按容器网络调整上游地址。
一台合适的小机器，比一堆用不到的配置省心
长期运行时，最先困扰个人用户的往往不是 CPU 跑分，而是网络偶尔不通、磁盘没人看、续费突然变贵，以及浏览器路由挤占内存。选 VPS 要把这些事情放到一起考虑。
只跑少量非浏览器路由，可以从 1—2 GB 内存作为试用起点；同机还跑博客、数据库和其他服务，就要把它们的峰值一起算进去。这个容量建议没有承诺路由数量，实际需求取决于目标网站、内容体积和并发。
如果想单独放一台机器承载订阅服务，可以看看 雨云当前的云服务器方案。比较时不妨把“首期多少钱”往后放一点，先看续费、流量、重装系统和升级规格是否符合自己的计划。RSSHub 并不需要特定服务商；有现成机器，也完全可以先复用。
真正决定是否合适的，是从这台 VPS 请求你常看的那些网站。用得到的三条源能稳定更新，比产品页上更高的理论带宽有意义。
密钥、访问码和日志，要放在一起考虑
开启 ACCESS_KEY 后，健康检查同样需要带密钥。本文 Compose 已经处理了这一点：$$ACCESS_KEY 让变量在容器内展开，避免被 Compose 提前替换。检查状态时可以执行：
docker compose exec -T rsshub sh -c \
'curl -fsS --get --data-urlencode "key=$ACCESS_KEY" http://127.0.0.1:1200/healthz'
把主密钥塞进所有订阅地址最方便，但也会让它出现在阅读器账户、浏览器历史，甚至反向代理日志里。按路径生成 code 能减少主密钥的直接分发，不过它仍是可用的访问凭据，并且没有单独的过期时间。
如果你启用了 Caddy 访问日志，检查日志是否保存完整查询串，按实际需求处理敏感参数。不要为“留足排障信息”把含密钥的 URL 同步进公共日志平台。截图和求助时同时遮住 key、code 与第三方平台令牌，而不是只遮住服务器 IP。
更换主密钥之前，先列出受影响的阅读器与订阅地址。一次轮换会让旧主密钥和由它生成的路径码一起失效；如果先改服务端、几天后才想起客户端，就会出现“服务没坏，所有订阅却都不更新”的情况。
备份什么，决定了迁移时能恢复什么
建议单独保存一份运维说明，记录域名、部署目录、端口、正在使用的镜像摘要，以及哪些路由依赖额外环境变量。令牌本体留在受保护的环境文件里，不要抄进公开笔记。
备份至少包含 compose.yaml、.env、Caddy 对应配置和必要的自定义文件。下面假设 Caddy 配置路径为 /etc/caddy/Caddyfile，命令在部署目录执行：
umask 077
backup_dir="$HOME/rsshub-backups/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
cp compose.yaml .env "$backup_dir/"
sudo cat /etc/caddy/Caddyfile > "$backup_dir/Caddyfile"
docker compose images > "$backup_dir/images.txt"
docker inspect "$(docker compose ps -q rsshub)" \
--format '{{.Image}}' > "$backup_dir/image-id.txt"
这份备份包含密钥，目录和文件权限应受限，复制到其他位置时也一样。保存在同一块磁盘上只能应付误改配置；要应付整机丢失，还需要一份受保护的异地副本。恢复时不要直接覆盖整份 Caddyfile，先确认里面有没有其他业务站点。
Redis 若只承担本文的缓存职责，可以把缓存重建列为恢复方案。确实需要保留 Redis 数据时，应另外设计停写、快照与恢复流程，不能在写入期间随手复制几份文件就宣称备份可用。更不要把 RSSHub 的缓存备份当成阅读器历史备份。
更新前，先记下旧镜像
维护流程示意。回退是否可用，取决于你有没有保留明确的旧版本与配置。
docker compose pull 只下载镜像，docker compose up -d 才会按变化重建容器。更新前先记录当前容器真正使用的镜像，而不是仅凭 latest 这个名字判断版本：
old_id=$(docker inspect "$(docker compose ps -q rsshub)" --format '{{.Image}}')
docker image inspect "$old_id" --format '{{json .RepoDigests}}'
把输出中的可拉取摘要保存好，格式通常是 仓库名@sha256:...。若当前镜像没有仓库摘要，还应保存本地镜像或记录对应的构建来源，不能只留一个今后找不回来的本地 ID。
为方便回退，本文 Compose 用 RSSHUB_IMAGE 控制镜像。稳定运行后，可以在 .env 中添加一行，把完整摘要写进去。后续升级时先选定并验证新的镜像，修改这一个值，再拉取、重建：
docker compose pull rsshub
docker compose up -d rsshub
docker compose ps
docker compose logs --since=10m rsshub
如果 .env 已固定旧摘要，只运行 pull 不会自动升级，这是固定版本本来就要达到的效果。不要一边要求版本可复现，一边又期待同一摘要自动变成最新版。
更新后依次检查本机健康接口、域名访问、常用路由、阅读器新条目。发现回归时，恢复备份中的旧摘要和相关配置，再执行 up -d rsshub，重复同样的检查。先保留旧镜像和备份，等观察结束后再清理。无差别运行 docker system prune -a --volumes 会波及其他业务，也可能删掉你正需要的回退材料。
“15 分钟缓存”为什么不等于“15 分钟看到更新”
一次内容更新要经过几段时间：上游网站先发布，RSSHub 在请求到来时抓取或返回缓存，阅读器再按自己的计划拉取，最后才显示在客户端。任何一段延迟，都会影响最终看到的时间。
因此，某篇文章晚出现，不能只盯着 CACHE_EXPIRE。先比较源站发布时间、RSS 输出中的条目时间、阅读器最后一次抓取时间。读者一天只打开两次的博客，没必要每分钟检查；更新密集的通知源，也不能靠不断缩短间隔突破上游限额。
Redis 的作用是减少重复请求和计算，不是替你绕过目标网站的频率限制。多台实例共用一个上游账号或同一个出口 IP 时，也可能共享限制。遇到明确限流先退让请求频率，再看令牌权限与平台额度。
浏览器路由单独算账
有些路由需要执行网页脚本，才用得上浏览器。RSSHub 官方 Compose 示例提供了独立 Browserless 服务的思路，也可以使用带 Chromium 的镜像。但浏览器不是给所有路由加上的加速器；它会带来额外的内存、进程和故障点。
增加之前先确认具体路由声明，按所选浏览器镜像的版本核对连接地址、认证与资源配置。独立 Browserless 只供 RSSHub 容器访问时，不需要把它的管理端口开放到公网。更改后用那条需要浏览器的路由验证，不能拿一个普通 API 路由成功就算验收。
如果机器已经同时跑了数据库与博客，先看内存峰值再决定是否同机部署。交换空间可以缓解某些瞬时压力，却不能把严重内存不足变成稳定的浏览器服务。
留一张很短的巡检清单
个人服务没必要为了监控再搭一整套复杂系统。每次更新后，以及发现订阅异常时，先看这几个输出：
docker compose ps
docker stats --no-stream
df -h
docker system df
docker compose logs --since=30m --tail=150 rsshub
重点看变化：重启次数是否增加，磁盘余量是否持续下降，是否只有某个路由重复报错。本文限制了 Docker 日志文件大小，但并未限制 Redis 缓存体积、镜像数量和其他服务日志，磁盘仍然要看。
一条重要订阅还可以留下简单的人工验收记录：什么时候检查、最新条目标题是什么、源站有无更新。比起只盯着绿色在线图标，这种记录更容易发现“服务在线，内容已经停了”的问题。
换 VPS 时，让域名替你省事
迁移前在新机器恢复配置，先使用本机地址验证，确保主密钥、路由参数和必要令牌一致。域名尚未切过去时，不要因为新机器暂时拿不到正式证书就贸然改掉旧入口；可以用临时测试域名做完整 HTTPS 验证。
确认新环境后再调整正式 DNS。旧机器保留一段合理的观察时间，考虑 DNS 缓存与阅读器刷新周期，确认请求已经转移后再下线。若保留同一主密钥和路径，原有路径访问码也可以继续使用；换了主密钥则需要同步更新客户端。
域名不变，阅读器里那一串订阅地址就不用跟着改。自建 RSSHub 的长期价值，往往就在这些不起眼的地方：配置找得到，出错能定位，更新有退路，搬家不费劲。
参考资料
本文的基础 Compose 已在本机隔离 Docker 环境验证：RSSHub 与 Redis 健康检查通过；带密钥的健康请求返回 200，无密钥返回 403；GitHub Issues 示例及路径访问码返回了可解析的 RSS。这不等于所有机房、路由或第三方登录都经过实测。
技术配置核对日期：2026 年 9 月 30 日。
- RSSHub 官方仓库与 部署文档。
- 官方 Compose 文件：缓存与浏览器服务配置。
- RSSHub 配置实现：环境变量与缓存配置。
- 访问控制源码：健康接口和密钥行为。
- Docker Compose 启动依赖与 Docker 日志轮转选项：健康依赖、日志大小限制。