本文使用带 Chromium 的 RSSHub 镜像与 Redis 部署个人 RSS 服务。配置依据上游 Compose 示例，具体路由的可用性需在自己的网络和账户条件下验证。
RSSHub 把多个网站的数据生成 RSS。它是生成器，阅读、已读状态和分类管理可交给 TTRSS 等阅读器。不同路由依赖不同上游页面、接口与认证，因此“容器启动成功”不等于所有路由都可用。项目仓库
一、一个容易理解的 Compose 方案
安装 Docker Engine 与 Compose 插件后，保存 compose.yaml：
services:
rsshub:
image: diygod/rsshub:chromium-bundled
restart: unless-stopped
ports:
- "127.0.0.1:1200:1200"
environment:
NODE_ENV: production
CACHE_TYPE: redis
REDIS_URL: redis://redis:6379/
depends_on:
- redis
redis:
image: redis:7-alpine
restart: unless-stopped
command: redis-server --save "" --appendonly no
容器通过 Compose 服务名 redis 互相访问。redis://localhost:6379/ 只有在 Redis 与 RSSHub 共享同一个网络命名空间时才成立；普通桥接网络里，RSSHub 的 localhost 指它自己。
Redis 在这里只是可重建的缓存，因此不对宿主机映射 6379，也没有把缓存当业务数据库备份。如果需要缓存持久化，可按 Redis 文档配置卷及持久化策略；个人轻量部署也可以选择 RSSHub 支持的内存缓存，Redis 不是强制依赖。
带 Chromium 的镜像较大，但省去了单独管理 browserless 的步骤。上游当前普通镜像示例使用 PLAYWRIGHT_WS_ENDPOINT=ws://browserless:3000；不要继续把旧 PUPPETEER_WS_ENDPOINT 示例套到所有版本。上游 Compose 配置
docker compose config
docker compose up -d
docker compose logs --tail 100 rsshub
示例使用浮动标签方便阅读。实际长期运行应记录验证过的镜像 digest，升级时先查看变更，备份含 Cookie、Token 的配置，测试自己使用的路由再替换。不要在公开截图或 Compose 文件中贴真实平台 Cookie。
二、访问与反向代理
在服务器本机访问 http://127.0.0.1:1200/。从其他设备访问时，配置自己的 HTTPS 反向代理或 SSH 隧道；回环端口不会自动在公网开放。反向代理在同一台宿主机时可以转发到该地址，运行在容器中则要使用共享网络里的服务地址。
获得某条路由的 URL 后，在 RSS 阅读器中添加它。要确认响应是 XML/RSS 而不是错误页面，并查看文章日期和链接是否正确；有些需要浏览器，有些需要账户，有些路由可能因上游变更失效。
三、常见问题的检查顺序
| 现象 | 优先检查 |
|---|---|
| 连接 Redis 失败 | REDIS_URL 服务名、Redis 启动日志、两者是否同一网络 |
| 路由提示缺少浏览器 | 镜像是否包含 Chromium，或 Playwright 远端是否可连通 |
| 上游返回 401 / 403 | 路由所需认证和权限，不把失败当空 RSS |
| 昨日内容仍在缓存 | 路由与缓存配置，区分上游无更新和缓存未刷新 |
| 阅读器订阅失败 | 阅读器到 RSSHub 的连通性、HTTPS、真实响应格式 |
自建并不保证匿名：RSSHub 服务器仍访问上游，上游能看到其出口地址；需要登录的路由可能使用你的账号。只部署需要的路由和认证，按照上游服务规则使用。
评论区