Blog

alist：我装了一台，但决定不把网盘账号喂给它

August 5, 2026 6 min read
自托管NAS安全
alist 网盘聚合器家庭服务器部署

家里 Docker 宿主上，alist 已经跑了大半年。这篇把完整过程写下来：为什么装、怎么部署、怎么反代、怎么加固、怎么挂载，以及最后我为什么决定——不给它喂任何重要的网盘账号。

先给结论：alist 是聚合器，不是存储。它能让你在一个页面里浏览、搜索、下载十几个网盘和本地目录的内容，但回收站、版本、同步这些"文件管理"该干的事，它一件都干不好。把它当只读的消费入口，它是神器；把它当主力网盘，迟早出事。

部署：Docker Compose 三步起服务

alist 跑在 lab-core 上——2018 年的 i5-8500 小主机，Ubuntu Server 24.04，Docker 加 1Panel 管容器，compose 项目都收在 /opt/stack/ 下。alist 官方就推荐 Docker 部署，一条 compose 文件的事：

services:
  alist:
    image: xhofe/alist:latest
    container_name: alist
    volumes:
      - ./data:/opt/alist/data
    ports:
      - "5244:5244"
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=022
      - TZ=Asia/Shanghai
    restart: unless-stopped

两个细节值得说。一是数据目录单独挂出来：alist 的全部状态——SQLite 数据库、配置、日志——都在 data 目录里，备份它一个目录就够了。二是 PUID/PGID 用普通用户：官方示例喜欢写 0（root），但一个握着所有网盘 Token 的进程没有理由跑在 root 上，这一步后面还会展开。

起容器后第一次要设管理员密码：

docker exec -it alist ./alist admin set 你的强密码

然后打开 http://服务器IP:5244 登录，先把站点的 site_url 填上（管理后台 → 设置 → 站点 URL）。这是后面反代不踩坑的前提，现在留空，一会儿反代完就要回来补。

反代：别让 5244 裸奔到公网

家里没有稳定的公网 IP——运营商 CGNAT 时好时坏，端口映射的教训我写过一篇，结论是入站洞越少越好。对外统一走 Cloudflare Tunnel：出站连接，家里不用开任何入站端口。但无论走哪条路，第一步都是先把 alist 绑回内网：compose 里把端口映射改成 127.0.0.1:5244:5244，只让本机访问，公网入口交给反代。

这样拓扑就清晰了：公网 → Cloudflare Tunnel → 家里的反代（我的在 /opt/stack/proxy 栈里）→ 127.0.0.1:5244。反代配置以 Nginx 语法为例，Traefik、Caddy 同理，关键是下面这些头：

location / {
    proxy_pass http://127.0.0.1:5244;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Range $http_range;
    proxy_set_header If-Range $http_if_range;
}

注意 Range / If-Range 两个头必须透传——alist 的视频预览靠 HTTP 分段请求，不透传 Range，大文件播放会出各种灵异问题（点了播放没反应、拖进度条从头加载）。这是反代 alist 最常踩的坑，没有之一。

还有一件必须做的事：site_url 必须设成完整的公网地址（比如 https://pan.example.com，结尾不要斜杠）。alist 生成直链、重定向、预览地址都以它为基准，留空的话，反代之后"看起来能登录，但下载和预览全是错的"。

alist 属于"私人但常用"那类服务，我在 Tunnel 上套了 Access：未登录直接挡在边缘，连登录页都不该随手刷到。反代层再开 HTTPS、加一层基础限流——公网上被扫描器扫是常态，登录页这种位置尤其要防暴力破解。

加固：六个动作，半小时

  1. 非 root 运行：compose 里 PUID/PGID 换成专用用户，别用官方示例的 0；
  2. 端口只绑 127.0.0.1，公网一律走反代 + HTTPS（入口配置参考之前那篇 Traefik 的）；
  3. ufw 只放行反代需要的端口，5244 和 S3 用的 5246 对公网关闭；
  4. 用最新稳定版镜像，关注 GitHub 安全公告——路径遍历和 TLS 校验默认关闭这两个洞，都是 v3.57.0 才修掉的（安全公告）；
  5. 数据目录定期备份：data 目录整个打包进备份任务，数据库和配置都在里面；
  6. 管好管理员面：强密码、关掉不需要的 S3/FTP 等额外入口。

这六条看着多，实际第一次做半小时内能完。做完之后，这台 alist 才敢算"部署完成"——不是"能登录"，是"下线路径和加固项都清过了"。

挂载：按需，别集邮

挂载是 alist 的核心功能：本地目录、阿里云盘、百度、OneDrive、S3，几十种驱动。我的原则是三条：

  • 按需挂：每个挂载都是一份 Token、一个 API 调用面。网盘侧限流、封号、撤销权限，任何一个挂了，统一入口就缺一块。
  • 只读假设：聚合器不承担文件管理，挂载的存储默认当"内容源"用，重要文件永远有另一份在 TrueNAS 存储层。
  • Token 最小化：能只读授权就不用读写，定期检查有效性和授权范围。

挂载之前先问一句：这个盘是"要浏览的内容"还是"要管理的文件"？前者挂给 alist，后者留在存储本体。

信任：2025 年易主之后，账要重算

比技术更大的变量是项目本身。2025 年，alist 原开发者 xhofe 把项目出售给了贵州不够科技（BugoTech），官网从 alist.nn.ci 迁到 alistgo.com。新东家接手后提交过包含遥测采集的代码（PR 后来撤回），随后阿里云盘、123 云盘、115 等多家网盘先后撤销了对 alist 的 API 权限。社区的回应是 OpenList——一个强调治理透明、无隐藏遥测的 fork。

这一连串事件说明一件事：聚合器的价值来自"集中"，风险也来自"集中"。把十个网盘的 Token 放进一个进程，等于把十个门的钥匙挂在一根钥匙链上。钥匙链值不值得信任，和它好不好用是两回事。

我的处理是：继续用，但只挂只读内容源，重要账号不喂。想继续用聚合器、又对易主有顾虑的，可以评估 OpenList。

什么时候别用 alist

决策表贴在下面，原则一句话：内容进自托管，账号只读聚合。

场景 选什么
浏览、下载、分享直链（只读消费） alist / OpenList，够用
文件是唯一副本，要版本和回收站 NAS 存储层 + Nextcloud / Seafile
多个网盘要统一入口 alist 可以，但按"只读"假设用
需要双向同步 原生客户端或 Syncthing，别用聚合器
对项目易主敏感，要长期信任 OpenList，或干脆不聚合

常见问题

alist 和 OpenList 选哪个？

2026 年中这个时间点，新部署我倾向 OpenList：治理更透明，没有遥测争议。还在用旧版 alist 的，关注安全公告、及时升级，不必急着迁移。

alist 支持哪些网盘？

阿里云盘、百度、OneDrive、Google Drive、123、115 等几十种，但 2025 年后多家已撤销 API 权限，具体以官方文档为准——这也是"按需挂载"的另一个理由。

反代之后视频播不了怎么办？

九成是 site_url 没设，或反代没透传 Range / X-Forwarded 头。先把 site_url 填对，再检查反代配置，别急着动 alist 本体。

alist 是好用的，家里这台到现在还在跑，当只读浏览入口用得很顺手。但"好用"和"该把身家放进去"是两件事。聚合器的正确姿势是分工：自托管存内容，网盘账号只读接入，Token 按需给，信任按年审。我给它留的位置，是客厅里那台"想看什么都能翻到"的电视，不是保险柜。

← Back to Blog