零门槛部署RSSHub到斐讯N1（飞牛NAS+Docker）

我之前写过一篇RSS订阅使用教程，当时主要介绍如何寻找RSS源和选择阅读器，但用久以后会发现一个问题：很多网站根本不提供RSS，即使提供，也可能只有标题和摘要。这时候就需要RSSHub，将原本没有RSS的网站转换为可以订阅的链接。

以前个人部署RSSHub有一道隐形门槛，需要会Linux、Docker、SSH和反向代理，遇到报错还得从日志里猜原因。教程看起来只是复制几行命令，真正出错时，每个人的系统、目录、网络和权限又都不一样，照抄通常只负责把你送到下一个报错。

AI出现以后，这件事发生了变化。它不只是解释命令，还可以先检查设备环境，根据实际情况生成配置，连接终端执行部署，失败以后读取日志继续修复。人需要做的事情，从“理解每一条命令”变成“说清楚自己想要什么，给AI必要权限，最后确认结果”。

本文就是写给AI看的部署说明。开通ChatGPT Plus或更高套餐，在电脑安装ChatGPT桌面端，将这篇文章交给Codex，再提供N1的SSH连接，基本可以让AI完成剩下的部署。如果当前Work会话也有本地终端权限，同样可以使用；网页里的普通对话主要负责指导，不能凭一篇文章直接进入你家里的N1。

ChatGPT的套餐、使用额度和功能入口会调整，本文写于2026年9月。免费版也能上传文件，Codex也可能提供有限额度；但为了减少次数限制和功能差异，本文把Plus或以上套餐作为“零门槛方案”的前提，而不是运行RSSHub的技术条件。

为何购买N1

公共RSSHub实例虽然省事，但热门路线容易限流，冷门路线可能突然失效，需要Cookie的路线又不适合交给陌生服务器。与其不断寻找下一个公共实例，不如在家里放一台长期在线的小主机。

我这台斐讯N1是在闲鱼花80元左右买的，系统刷成了飞牛NAS。买它不是为了当一台性能多强的NAS，而是想给RSSHub和一些轻量服务找个便宜、安静、可以一直开机的落脚点。

80元左右能买到的斐讯N1，配置放在今天已经很老了：晶晨S905D、2GB内存、8GB eMMC、千兆网口和两个USB 2.0。做主力NAS肯定不合适，但拿来跑轻量Docker服务却刚好。

价格低，我这台闲鱼入手约80元；
体积小，无风扇，放在路由器旁边不会增加多少存在感；
功耗低，适合RSSHub这种需要24小时在线、实际负载又不高的服务；
有千兆网口，比许多百兆电视盒子更适合长期作为网络节点；
社区资料多，飞牛也已经提供ARM版本并把斐讯N1列入支持设备；

它的缺点同样明显：只有2GB内存，8GB eMMC也很局促，USB还是2.0。我的定位很明确，N1只是轻服务器，不承担重要数据的唯一备份，不做高清视频转码，也不往里面塞几十个容器。系统和Docker数据最好放到可靠的外接存储，重要配置另外备份。

零门槛部署需要什么

斐讯N1和飞牛NAS

我使用的是飞牛NAS，也就是fnOS ARM版。刷机过程涉及固件、U盘启动和写入eMMC，操作错误有变砖风险，本文不展开。官方已经列出斐讯N1，但不同批次、引导和旧系统状态可能不同，刷机前先看对应版本的官方说明。

进入飞牛NAS后，在应用中心安装Docker，再到系统设置开启SSH。到这里为止需要自己点击，因为AI无法替你给一台尚未联网的机器刷系统，也不应该替你猜管理员密码。

ChatGPT会员和桌面端

按本文的省事方法，建议准备：

ChatGPT Plus或更高套餐；
Windows或macOS版ChatGPT桌面应用；
桌面端Codex，或者具备本地终端权限的Work；
N1的局域网IP、SSH用户名和密码；
允许AI读取本文，并在你确认后使用终端；

密码不要粘贴进文章或长期保存到提示词里。需要登录时，优先由自己在系统登录窗口输入，或者先在本机配置只用于这台N1的SSH密钥。Cookie、Token、代理订阅和RSSHub访问密钥同样不要发到公开聊天或截图中。个人套餐还应先检查ChatGPT的数据控制设置，再决定提供哪些日志和配置文件。

把这篇文章交给GPT

将本文保存为Markdown，或者直接把博客链接发给GPT，然后使用下面这段提示词：

我有一台斐讯N1，安装了飞牛NAS ARM版，已经安装Docker并开启SSH。
请根据我提供的《零门槛部署RSSHub到斐讯N1》完成部署。

要求：
1. 先只读检查，不要立刻修改系统；
2. 确认CPU架构、Docker、Docker Compose、剩余磁盘、内存和目标目录；
3. 发现已有RSSHub时先报告，不覆盖现有配置；
4. 使用适合2GB内存N1的精简方案，只部署RSSHub本体，使用内存缓存；
5. 自动生成高强度ACCESS_KEY，保存在权限为600的.env中，不要在回复里完整显示；
6. 限制容器内存，开启Docker日志轮转；
7. 不开放fnOS、Docker或其他管理页面到公网；
8. 每一步失败后先读取错误和日志，再针对原因修复，不要反复执行同一条命令；
9. 部署完成后检查容器状态、健康检查、首页和一条实际RSS路线；
10. 最后告诉我访问地址、更新方法、备份位置和回滚方法，密钥只告诉我去哪个文件查看。

N1地址：<填写局域网IP>
SSH用户：<填写用户名>
目标目录：不知道，请先检查飞牛NAS的数据盘再决定。

现在只执行只读检查，列出检查结果和部署计划，等我确认后再修改。

最后一句很重要。先让AI检查，再让它动手，这样它会根据真实环境选择目录，而不是把教程里的/vol1/1000/rsshub生搬硬套到所有机器。

第一步：让AI体检N1

AI连接N1后，应当先执行类似下面的只读检查：

uname -m
docker --version
docker compose version
df -h
free -h
docker ps -a

正常情况下，uname -m应当显示aarch64。RSSHub官方镜像支持linux/arm64，N1可以直接使用；如果显示32位ARM，AI应停止部署并说明原因，因为RSSHub已经停止提供arm/v7镜像。

还要让AI检查三件事：

Docker是否真的可以运行，而不是只安装了图标；
数据盘是否有足够空间，Docker目录是否误放在8GB eMMC；
1200端口和准备使用的目录是否已经被占用；

如果检查通过，再回复：

同意按计划部署。修改前备份同名目录；如涉及删除数据、覆盖已有配置、开放公网或修改防火墙，先停下来询问我。其他必要步骤可以继续执行，直到验证通过。

第二步：让AI生成并部署RSSHub

RSSHub官方推荐Docker Compose。官方示例还包含Redis和Browserless，功能更全，但N1只有2GB内存，第一次部署没必要全装。先使用内存缓存，只启动RSSHub本体；以后真遇到依赖浏览器的路线，再单独添加Browserless。

AI应当完成这些操作：

在飞牛数据盘创建独立的rsshub目录；
生成.env，写入随机访问密钥并设置600权限；
创建docker-compose.yml；
设置restart: unless-stopped；
给RSSHub设置合理的内存上限；
将Docker日志限制为单文件5MB、最多2个文件；
检查Compose配置后拉取镜像并启动；
等待健康检查完成，而不是看到容器启动就宣布成功；

AI最终生成的Compose结构大致如下。普通读者不必手动输入，这段主要用于约束AI，防止它部署一套不适合N1的重型配置：

name: rsshub

services:
  rsshub:
    image: ghcr.io/diygod/rsshub:latest
    container_name: rsshub
    restart: unless-stopped
    mem_limit: 768m
    ports:
      - "1200:1200"
    environment:
      NODE_ENV: production
      CACHE_TYPE: memory
      ACCESS_KEY: "${RSSHUB_ACCESS_KEY}"
    healthcheck:
      test: ["CMD-SHELL", "curl -f \"http://127.0.0.1:1200/healthz?key=$$ACCESS_KEY\""]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s
    logging:
      driver: json-file
      options:
        max-size: "5m"
        max-file: "2"

这里限制内存不是说RSSHub一定会吃满768MB，而是防止异常路线把整台N1拖死；日志轮转则是为了保护本来就不宽裕的存储空间。

第三步：让AI验证结果

部署完成不等于能用。让AI依次检查：

docker compose ps
docker compose logs --tail=100 rsshub
docker stats --no-stream rsshub

然后验证四个结果：

容器状态为healthy；
N1本机健康检查返回成功；
局域网电脑能打开RSSHub首页；
至少一条实际路线能返回包含条目的XML；

可以先用少数派Matrix路线测试：

http://N1的局域网IP:1200/sspai/matrix?key=你的访问密钥

将完整链接添加到ReadYou、Reeder或者Fluent Reader。其他网站先在RSSHub文档中找到路线，再让AI根据官方示例生成自己的订阅链接。

浏览器能打开RSSHub首页，只代表容器活着，不代表所有路线都能用。微博、X、酷安等路线可能依赖Cookie、Token、代理或者特殊请求方式，源站规则一变也可能暂时失效。遇到问题时，把错误链接、RSSHub日志和预期结果交给AI，不要只说一句“不能用”。

可以继续使用下面的提示词：

这个RSSHub路线无法正常返回内容。请先复现并查看RSSHub最近日志，判断是路线参数、源站反爬、登录态、网络、缓存还是镜像版本问题。不要直接关闭安全设置，不要把Cookie或Token打印到回复中。修复后重新验证HTTP状态、Content-Type和RSS条目数量，并说明修改了什么。

AI能做什么，不能做什么

在已经安装好飞牛NAS、开启SSH并授予终端权限的前提下，AI可以完成环境检查、编写Compose、生成密钥、上传文件、启动容器、查看日志和验证路线。配置与设备不一致时，它也比静态教程更容易继续排错。

但“基本不用自己操作”不等于把机器完全交出去。下面几件事仍然需要人决定：

是否允许AI连接这台N1；
什么时候输入密码、批准修改或开放网络；
哪些Cookie和Token可以放进私有配置；
是否将服务开放到公网；
验证结果是否真的满足自己的使用需求；

AI会犯错，也可能误解目录和网络。先检查、再修改、最后验收，比一句“帮我全部装好”更加省时间。

更新、备份和回滚也交给AI

以后更新不需要重新找教程，直接把原对话继续下去：

请更新N1上的RSSHub。更新前备份docker-compose.yml和.env，记录当前镜像摘要与容器状态；拉取新镜像后重新创建容器，验证健康检查和我常用的订阅路线。验证失败就回滚到更新前镜像，不要删除旧备份。

AI最终执行的核心命令通常只是：

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 rsshub

重点不在这四条命令，而在更新前记录、更新后验证、失败时回滚。过去最考验经验的恰恰是这些步骤，现在可以让AI负责盯完整个过程。

外网访问

我不建议直接在路由器上把1200端口暴露到公网。管理N1和访问内部服务，我更偏向使用Tailscale：设备加入同一个Tailnet后，使用Tailscale IP访问，省去公网IP、DDNS和端口转发。

这里有一个容易混淆的地方：ReadYou这类本地阅读器可以访问Tailnet地址，运行在云端的RSS阅读器服务器却不在你的Tailnet里，它无法抓取这个私网链接。如果确实要给云端阅读器使用，就需要HTTPS反向代理或Tailscale Funnel，并且必须保留ACCESS_KEY。可以让AI设计和部署，但公网只开放RSS订阅入口，飞牛NAS、Sun-Panel和其他管理页面仍然留在内网。

N1推荐安装什么

N1资源有限，安装顺序比安装数量更重要。我目前认为值得保留的服务有下面几个。

RSSHub

购买N1最主要的原因。它弥补了许多网站不提供RSS的问题，也让我不必依赖不稳定的公共实例。普通路线只跑RSSHub本体就够了；需要登录态或特殊网络的路线再单独配置，别把Cookie和Token写进公开文章。

AI最大的作用不只是安装RSSHub，而是自定义路由。以前要自己看网页结构、写抓取和RSS输出代码，现在可以把目标网页、希望保留的字段和更新频率告诉AI，让它先分析现有RSSHub路线；没有现成路线时，再生成独立转换服务或路由代码，并用真实页面做测试。不会JavaScript不再是绝对门槛，但仍要检查生成内容是否合法、稳定，不能绕过网站权限或高频抓取。

Tailscale

用于远程访问N1、飞牛NAS和其他私网服务。它的价值不是让所有东西都公开，而是让自己的设备像在同一个局域网里。管理页面不必暴露公网，手机在外面也能连接。

Sun-Panel

服务多以后，用一个导航页记录入口，比记端口方便。Sun-Panel本身很轻，但不要为了自动发现容器就把/var/run/docker.sock随便挂进去，一个导航页没必要获得宿主机最高权限。

QD-lite

适合运行少量个人签到和定时任务。我使用的是lite版本，并限制任务数量和内存。它不是批量请求工具，高频签到只会给自己和网站找麻烦，需要Cookie的任务也要考虑泄露风险。

sing-box（按需）

只有RSSHub某些路线确实需要特殊出站网络时再安装。我将代理限制在Docker内部，不映射到宿主机端口，并让RSSHub优先直连，失败后才走备用代理。代理不是RSSHub的必装组件，更不能解决失效Cookie和源站规则变化。

不建议在N1上硬塞的东西

N1不是一台缩小版高性能服务器，2GB内存和8GB eMMC决定了它更适合“小而专”。下面这些用途我不会交给它：

Jellyfin实时转码和重型影音刮削；
大量下载任务和高频写盘；
大型数据库、搜索引擎和本地AI模型；
同时运行多个Chromium、Browserless之类的重服务；
保存没有其他备份的重要文件；

服务不是装得越多越值。内存被占满、eMMC被日志写爆，最后每个服务都半死不活，还不如只留下每天真正会用的几个。

PS

如果只是为了体验RSSHub，电脑上运行Docker会更简单，没有必要专门购买N1。只有当你确认RSS已经进入自己的日常阅读流程，需要一个长期在线、自己控制的实例时，N1才真正有价值。

过去部署服务的门槛，是人必须先学会机器的语言；现在借助AI，人只需要把目的、条件和不能越过的边界讲清楚。技术并没有消失，只是从必须背在每个人身上的行李，变成了可以随时调用的工具。

RSS让我从算法推荐中拿回了选择信息的权力，RSSHub进一步把“网站是否愿意提供订阅”的决定权拿回来，而AI则把部署和修改RSSHub的能力交给了更多普通人。N1在这套系统里并不耀眼，它只是安静地待在角落，把这些链接每天准时送到阅读器里。对我来说，这正是它最适合做的事情。

参考链接：

RSSHub部署文档

RSSHub官方Docker Compose

飞牛fnOS ARM版与支持设备

ChatGPT Work和Codex官方说明

Codex与ChatGPT套餐说明