自己部署 RSSHub 之后，有一类问题几乎绕不开：部分路由需要登录态才能正常使用，例如知乎、微博等。但 Cookie 过期是不定时的，且不会收到通知。每每发现 Cookie 过期的时候，订阅已经很长时间没有更新了，于是再翻文档、从浏览器里找 Cookie、登录服务器、修改 Compose、重建容器。整个流程尽管不难，但可以说相当浪费时间。更麻烦的是，“订阅一段时间没有新内容”并不能证明 Cookie 已经失效。作者可能只是没有更新，上游也可能正在限流或短暂故障。如果仅凭 RSS 是否更新来判断，很容易在不该动的时候替换 Cookie。为了解决这个问题，我写了 RSSHub Cookie Sync。它会把 Microsoft Edge 中已经登录的知乎、微博 Cookie 送到自己的 RSSHub 服务器，先验证候选登录态，再在确有需要时完成切换；如果必须重新登录，则通过 Bark 提醒。整个过程不修改 RSSHub 源码，也不依赖 CookieCloud。它解决的不是“复制 Cookie”，而是后续维护单次复制 Cookie 很简单，真正麻烦的是长期运行时的一整套判断：浏览器里有没有可用的新登录态；服务器正在使用的 Cookie 是否真的失效；眼前的失败是认证问题，还是限流、超时、上游故障；替换之后 RSSHub 是否仍然健康；切换失败时能否自动回到原来的状态；什么时候应该安静重试，什么时候必须叫人回来登录。所以这个项目没有把浏览器 Cookie 直接覆盖到 RSSHub，而是把新 Cookie 当作“候选”。服务器会验证候选，并独立监控 live Cookie。只有验证和切换条件都满足，候选才会被提升；否则继续保留原来的 live 值。四段式链路Edge 扩展负责最靠近浏览器的一段。它使用 Manifest V3，只申请 Cookie、定时任务、Native Messaging 和本地状态所需的权限；知乎、微博的 host 权限还是可选权限，需要用户主动授权。自动同步会在 Edge 启动、每 15 分钟以及目标 Cookie 变化后触发，Cookie 变化还会先合并一小段时间，避免短时间内反复上传。Native Host是浏览器扩展与本机系统能力之间的桥。扩展不会直接接触 SSH 私钥，也不会把服务器连接信息硬编码进扩展包。Host 只接受经过约束的服务器地址、端口和 ~/.ssh/ 下的一层密钥文件名，再调用系统 OpenSSH。SSH 受限账号固定为 rsshub-sync。它没有普通 shell，也不在 Docker 组里；服务端通过 forced command 把它限制在同步协议内。Cookie 通过 SSH 标准输入传递，不出现在命令参数中。服务端负责所有会影响 RSSHub 的决定：校验输入、验证上游、保存候选、更新 live env、检查 Compose、重建目标服务、等待健康检查，以及在失败时回滚。systemd timer 则让这些检查在 Mac 休眠或 Edge 关闭时仍能继续。为什么不会一失败就换 Cookie判断登录态时，项目直接探测知乎、微博的登录接口和 RSSHub 健康状态，而不是观察“有没有新文章”。服务端把结果分成认证失败、临时故障和健康状态：明确的认证失败会累计确认；403、429、432、超时和 5xx 则按临时上游故障处理，不会立刻轮换 Cookie。这一区分很重要。限流时盲目换 Cookie，不仅解决不了问题，还可能把一份可用登录态替换掉。只有 live Cookie 被确认失效、且服务器手里已有验证通过的候选时，自动修复才有意义；没有可用候选时，Bark 会提醒我回到 Edge 重新登录，持续的临时故障和后续恢复也会按策略告警。知乎和微博的状态彼此独立。一个服务出现问题，不会清空或阻断另一个服务的有效登录态。更新 RSSHub 时，把失败当作正常分支首次接入时，安装器会把目标 RSSHub service 中的 ZHIHU_COOKIES、WEIBO_COOKIES 和 TWITTER_AUTH_TOKEN 从 Compose 的 environment 迁移到 Compose 文件旁的 secrets/rsshub.env，并使用 env_file 的 raw 格式加载。这样 Cookie 中的 $、# 等字符不会被 Compose 再解释，secret 文件也会收紧为仅 root 可读。此后的切换不是“写文件然后祈祷”。服务端会持锁执行事务，原子写入新 env，先检查 Compose 配置，只重建目标 RSSHub service，再轮询健康状态。任何一步失败，都会恢复旧 env 并重新建立原来的运行状态。它不会执行 docker compose down，不会重建 Redis 或 browserless，不会拉取镜像，也不会删除 volume。这部分比“如何获得 Cookie”更值得写：自动化最危险的地方，往往不是它做不到，而是它在只完成一半时留下一个模糊状态。这里的安装、迁移、切换和卸载都把中断恢复、边界检查与幂等性当成正常路径。凭据放在哪里Cookie 本质上就是登录凭证。项目尽量缩短它的暴露路径：扩展按目标请求地址筛选 Cookie，live 值不写入扩展持久化状态；传输阶段的 Cookie 只在一次调用的内存和 SSH 标准输入中短暂存在，不放进本机命令参数、环境变量或日志；最终只按 RSSHub 的要求进入服务器 root-only env 文件和容器环境；Native Host 只返回固定的脱敏状态，不把服务端任意错误文本带回扩展；本机默认使用项目专用的 Ed25519 密钥，不会悄悄回退到通用的 id_ed25519；SSH 开启严格主机密钥校验，未知主机不会被自动接受；服务端的 live env、候选、状态与 Bark 配置均限制为 root 可读。这些措施不能消除宿主机本身的信任边界。拥有 Mac 当前用户权限的程序，仍可能攻击浏览器或读取该用户可读的 SSH 文件；拥有服务器 root 或 Docker 管理权限的人，也能读取 RSSHub 容器中的 Cookie。项目保护的是同步链路，不是对已经失守的操作系统做沙箱逃生。安装流程普通安装分三端进行。首先在 Mac 当前用户下安装 Native Host，并复制安装器最后输出的项目公钥：Shell复制curl -fsSL https://github.com/Jaaayden/rsshub-cookie-sync/releases/latest/download/install-macos.sh | sh然后用普通 SSH 首次连接服务器，核对并接受主机指纹。在同一个 root 会话里运行服务端安装器，按提示选择 RSSHub Compose 并粘贴刚才的公钥：Shell复制curl -fsSL https://github.com/Jaaayden/rsshub-cookie-sync/releases/latest/download/install-server.sh | sh最后从 GitHub Releases 下载扩展 ZIP，在 edge://extensions 中以“加载解压缩的扩展”安装。进入扩展的连接设置，确认 Native Host 可读，填写服务器地址和 SSH 端口，选择 rsshub-cookie-sync 专用密钥，再授权知乎、微博站点权限并执行第一次同步。Warning不要把 Cookie、Bark Device Key、SSH 私钥、真实服务器地址或未经脱敏的 Compose 输出贴到 Issue、聊天或截图里。Release 同时提供 SHA256SUMS，正式安装前可以校验下载文件。适用范围与取舍目前项目面向 macOS、Microsoft Edge Chromium 的 Default Profile，以及使用 Linux、systemd、Docker Engine 和 Docker Compose v2.30+ 的自托管 RSSHub。支持的 provider 是知乎与微博，运行时服务端只依赖 Python 3.9+ 标准库；Node.js 仅用于扩展测试。它不会自动输入密码，不会绕过验证码或 MFA，也不会凭空延长已经失效的会话。需要人工登录时，正确的动作仍然是回到浏览器完成登录；这个项目负责的是把“什么时候该回来”判断清楚，并把其余机械步骤可靠地完成。截至本文撰写时，最新版本为 v1.1.3。仓库包含 Edge 扩展、macOS Native Host、Linux 服务端、安装与卸载脚本，以及覆盖协议校验、密钥迁移、事务回滚、Compose 迁移和监控策略的自动化测试。项目地址代码、安装文档、故障排查和安全策略都在 GitHub：Jaaayden/rsshub-cookie-sync。项目采用 MIT License。如果你也在自托管 RSSHub，并且经常被登录态过期打断，它也许能省掉一段重复而容易出错的维护工作。
自己部署 RSSHub 之后，有一类问题几乎绕不开：部分路由需要登录态才能正常使用，例如知乎、微博等。
但 Cookie 过期是不定时的，且不会收到通知。每每发现 Cookie 过期的时候，订阅已经很长时间没有更新了，于是再翻文档、从浏览器里找 Cookie、登录服务器、修改 Compose、重建容器。整个流程尽管不难，但可以说相当浪费时间。
更麻烦的是，“订阅一段时间没有新内容”并不能证明 Cookie 已经失效。作者可能只是没有更新，上游也可能正在限流或短暂故障。如果仅凭 RSS 是否更新来判断，很容易在不该动的时候替换 Cookie。
为了解决这个问题，我写了 RSSHub Cookie Sync。它会把 Microsoft Edge 中已经登录的知乎、微博 Cookie 送到自己的 RSSHub 服务器，先验证候选登录态，再在确有需要时完成切换；如果必须重新登录，则通过 Bark 提醒。整个过程不修改 RSSHub 源码，也不依赖 CookieCloud。
它解决的不是“复制 Cookie”，而是后续维护
单次复制 Cookie 很简单，真正麻烦的是长期运行时的一整套判断：
所以这个项目没有把浏览器 Cookie 直接覆盖到 RSSHub，而是把新 Cookie 当作“候选”。服务器会验证候选，并独立监控 live Cookie。只有验证和切换条件都满足，候选才会被提升；否则继续保留原来的 live 值。
四段式链路
Edge 扩展负责最靠近浏览器的一段。它使用 Manifest V3，只申请 Cookie、定时任务、Native Messaging 和本地状态所需的权限；知乎、微博的 host 权限还是可选权限，需要用户主动授权。自动同步会在 Edge 启动、每 15 分钟以及目标 Cookie 变化后触发，Cookie 变化还会先合并一小段时间，避免短时间内反复上传。
Native Host是浏览器扩展与本机系统能力之间的桥。扩展不会直接接触 SSH 私钥，也不会把服务器连接信息硬编码进扩展包。Host 只接受经过约束的服务器地址、端口和 ~/.ssh/ 下的一层密钥文件名，再调用系统 OpenSSH。
SSH 受限账号固定为 rsshub-sync。它没有普通 shell，也不在 Docker 组里；服务端通过 forced command 把它限制在同步协议内。Cookie 通过 SSH 标准输入传递，不出现在命令参数中。
服务端负责所有会影响 RSSHub 的决定：校验输入、验证上游、保存候选、更新 live env、检查 Compose、重建目标服务、等待健康检查，以及在失败时回滚。systemd timer 则让这些检查在 Mac 休眠或 Edge 关闭时仍能继续。
为什么不会一失败就换 Cookie
判断登录态时，项目直接探测知乎、微博的登录接口和 RSSHub 健康状态，而不是观察“有没有新文章”。服务端把结果分成认证失败、临时故障和健康状态：明确的认证失败会累计确认；403、429、432、超时和 5xx 则按临时上游故障处理，不会立刻轮换 Cookie。
这一区分很重要。限流时盲目换 Cookie，不仅解决不了问题，还可能把一份可用登录态替换掉。只有 live Cookie 被确认失效、且服务器手里已有验证通过的候选时，自动修复才有意义；没有可用候选时，Bark 会提醒我回到 Edge 重新登录，持续的临时故障和后续恢复也会按策略告警。
知乎和微博的状态彼此独立。一个服务出现问题，不会清空或阻断另一个服务的有效登录态。
更新 RSSHub 时，把失败当作正常分支
首次接入时，安装器会把目标 RSSHub service 中的 ZHIHU_COOKIES、WEIBO_COOKIES 和 TWITTER_AUTH_TOKEN 从 Compose 的 environment 迁移到 Compose 文件旁的 secrets/rsshub.env，并使用 env_file 的 raw 格式加载。这样 Cookie 中的 $、# 等字符不会被 Compose 再解释，secret 文件也会收紧为仅 root 可读。
此后的切换不是“写文件然后祈祷”。服务端会持锁执行事务，原子写入新 env，先检查 Compose 配置，只重建目标 RSSHub service，再轮询健康状态。任何一步失败，都会恢复旧 env 并重新建立原来的运行状态。它不会执行 docker compose down，不会重建 Redis 或 browserless，不会拉取镜像，也不会删除 volume。
这部分比“如何获得 Cookie”更值得写：自动化最危险的地方，往往不是它做不到，而是它在只完成一半时留下一个模糊状态。这里的安装、迁移、切换和卸载都把中断恢复、边界检查与幂等性当成正常路径。
凭据放在哪里
Cookie 本质上就是登录凭证。项目尽量缩短它的暴露路径：
这些措施不能消除宿主机本身的信任边界。拥有 Mac 当前用户权限的程序，仍可能攻击浏览器或读取该用户可读的 SSH 文件；拥有服务器 root 或 Docker 管理权限的人，也能读取 RSSHub 容器中的 Cookie。项目保护的是同步链路，不是对已经失守的操作系统做沙箱逃生。
安装流程
普通安装分三端进行。首先在 Mac 当前用户下安装 Native Host，并复制安装器最后输出的项目公钥：
然后用普通 SSH 首次连接服务器，核对并接受主机指纹。在同一个 root 会话里运行服务端安装器，按提示选择 RSSHub Compose 并粘贴刚才的公钥：
最后从 GitHub Releases 下载扩展 ZIP，在 edge://extensions 中以“加载解压缩的扩展”安装。进入扩展的连接设置，确认 Native Host 可读，填写服务器地址和 SSH 端口，选择 rsshub-cookie-sync 专用密钥，再授权知乎、微博站点权限并执行第一次同步。
不要把 Cookie、Bark Device Key、SSH 私钥、真实服务器地址或未经脱敏的 Compose 输出贴到 Issue、聊天或截图里。Release 同时提供 SHA256SUMS，正式安装前可以校验下载文件。
适用范围与取舍
目前项目面向 macOS、Microsoft Edge Chromium 的 Default Profile，以及使用 Linux、systemd、Docker Engine 和 Docker Compose v2.30+ 的自托管 RSSHub。支持的 provider 是知乎与微博，运行时服务端只依赖 Python 3.9+ 标准库；Node.js 仅用于扩展测试。
它不会自动输入密码，不会绕过验证码或 MFA，也不会凭空延长已经失效的会话。需要人工登录时，正确的动作仍然是回到浏览器完成登录；这个项目负责的是把“什么时候该回来”判断清楚，并把其余机械步骤可靠地完成。
截至本文撰写时，最新版本为 v1.1.3。仓库包含 Edge 扩展、macOS Native Host、Linux 服务端、安装与卸载脚本，以及覆盖协议校验、密钥迁移、事务回滚、Compose 迁移和监控策略的自动化测试。
项目地址
代码、安装文档、故障排查和安全策略都在 GitHub：Jaaayden/rsshub-cookie-sync。项目采用 MIT License。如果你也在自托管 RSSHub，并且经常被登录态过期打断，它也许能省掉一段重复而容易出错的维护工作。