多个网盘、一块 NAS、一台常年不关机的小主机，加上手机、平板、电视盒子，这套组合放在一起，最先崩掉的东西往往不是硬件，而是"找文件"这件事。同一个文档在三个地方各存了一份，去年存的照片在某个网盘 App 的第四级目录里，电视上想看个视频还得先下载到 U 盘再插上去。Alist 这类工具能火起来，根子上就是因为它把这种散落状态收敛成了一个入口——跑起来之后给你一个网页，所有接进来的存储变成一棵统一的目录树，浏览器能翻、播放器能读、其他设备能挂载成磁盘。

这篇内容面向的是想在自己机器上把 Alist 跑起来、并且真正用起来的人。完全没接触过的可以照着走一遍，踩过坑想查漏补缺的可以直接跳到部署选型和问题排查那两节。需要先把一件事讲清楚：Alist 不是网盘客户端，也不是下载器，它的定位是"文件列表服务 + 协议网关"，标题里的"下载"更多是指下载安装包、拉取镜像、以及通过它把文件取回本地这一整套动作。搞清楚这个定位，后面很多配置为什么那么设计，就顺了。

1. 先把 Alist 是什么讲透，再谈怎么装

1.1 它的技术形态：一个单文件程序加一个网页

很多人第一次接触会以为 Alist 是个云端服务，其实它是彻头彻尾的自建程序。后端用 Go 写，编译出来就是一个可执行文件，没有任何运行时依赖，扔到 Linux、Windows、macOS、甚至路由器上都能直接跑。前端是一套静态页面，由后端一起提供。数据层默认用 SQLite，一个data.db文件就是全部内容；数据量大或者多人使用时可以换成 MySQL 或 PostgreSQL。

程序启动后会读同目录下的config.json，里面有数据库连接串、监听端口、JWT 密钥、日志级别这些。所有"存储"的配置、用户信息、访问记录都存在数据库里，不在配置文件里。这个划分很关键，备份的时候要备份的是整个 data 目录，不是只拷一个 json。我第一次迁移就只拷了 config.json，结果登录进去所有挂载全没了，重新配了一遍，那一次之后我养成了定时打包 data 目录的习惯。

它的核心抽象只有一个概念：挂载路径。每个存储驱动都被挂到某个虚拟路径上，/是根，你可以挂/本地影视、/团队文档、/归档照片，路径随便起，不用和真实目录名一致。用户看到的是一棵虚拟树，背后可能是本地磁盘、某个 WebDAV 服务、一个 S3 桶，或者某家网盘通过官方开放接口暴露出来的空间。这层抽象带来的好处是：换存储不用改使用习惯，用户的书签、播放器的播放列表、挂载的盘符全都不用动。

1.2 四类真实场景，看看你在不在里面

第一类是多存储聚合。手上有一块 NAS 做冷备、一块移动硬盘做素材库、再加上几个网盘的免费额度，Alist 把它们都挂进来，用一个搜索框跨存储找文件。这个场景的收益不是省事，是省心——你不用再记"那份合同到底在哪个盘"。

第二类是给播放器和电视用。Alist 自带 WebDAV 服务端，开启之后，电视盒子上的播放器、手机上的文件管理器、电脑上的播放软件，都能把它当成一个标准 WebDAV 源。视频不用下载，直接在线拉流，还能记住播放进度。这是它最出圈的一个用法，也是我用得最多的一条。

第三类是临时的文件中转。给外部同事传一批文件，不想让他们登录你的存储，就建一个只读的访客账号，或者直接生成一条带密码和有效期的分享链接。比起用即时通讯软件发压缩包，这条路径在几十上百兆的素材上体验好太多。

第四类是给内部系统做文件后端。Alist 有一套完整的 HTTP API，也有 WebDAV，一些小型的内部工具会把它当成文件存储层，上传下载都走它的接口，省得自己写一套文件管理。

1.3 哪些情况别硬上，提前劝退

有一种情况我见过不少人绕弯路：只想在手机上看自己网盘里的视频。如果就这一个需求，Alist 属于杀鸡用牛刀，中间加了一层转发，播放器兼容性还得调，直接用网盘官方客户端或者官方的 TV 版反而更省事。

还有一种：指望它突破任何服务商的限制。这个念头要不得，Alist 只是把接口包装了一下，底层能跑多快取决于对方给多少。用非官方手段接入第三方网盘接口，一方面随时可能失效，另一方面账号风险自己承担。合规、正规地使用开放接口，是长期跑下去的前提。

最后一种是完全不懂命令行、也没有任何一台常开设备。Alist 需要一个持续运行的载体，电脑关机它就没了。如果没有 NAS、没有小主机、没有云服务器，那这套东西的价值会大打折扣。装之前先想清楚"它跑在哪"，比装的时候纠结参数重要得多。

2. 部署方式怎么选：三条路和一张对比表

2.1 三种主流装法各自适合谁

一键脚本安装是最省事的。官方提供了一段安装脚本，执行完它会自动下载最新二进制、注册成系统服务、配好开机自启。适合的场景是干净的 Linux 服务器，你只想要一个能跑的服务，不想碰容器。缺点是升级要重新跑脚本，而且它默认把文件放在/opt/alist，路径写死在服务文件里，想挪地方得手动改。

Docker 部署是我最推荐的。镜像里已经把运行环境打好了，数据目录挂出来，端口映射出去，升级就是拉新镜像重启容器，回滚就是换回旧 tag。更实际的一点是——它天然隔离，你不用担心程序和系统里其他东西抢依赖。我在三台不同发行版的机器上都用这套，从来没遇到过环境问题。

二进制直接运行适合桌面系统试水。Windows 上双击 exe 就能起，macOS 和 Linux 解压后./alist server也行。这种方式的好处是能直观看到日志和文件结构，适合先摸清楚它怎么工作，再决定要不要正式部署。缺点是关掉终端就停了，不适合长期跑。

2.2 为什么我把 Docker 排在第一

除了升级方便，还有一个容易被忽略的点：权限可控。本地磁盘挂载进容器的时候，如果容器内的用户 ID 和宿主机上文件的所有者不一致，Alist 就会读不到或者写不进去，表现是目录能列出来但打开报错。Docker 部署时可以通过PUID和PGID环境变量指定容器内进程以哪个身份跑，和宿主机上的用户对齐之后，权限问题一次解决。用二进制直接跑反而容易在这里翻车，因为它的运行身份取决于你用哪个用户启动。

数据目录映射也要说清楚。容器里的/opt/alist/data是全部数据所在，必须挂到宿主机的一个持久目录，否则容器一删数据全丢。我一般放在/etc/alist或者/opt/alist/data，前者偏配置、后者偏数据，看个人习惯。真正重要的只有两点：这个目录在宿主机上是持久的，并且有备份。

2.3 端口和目录的规划，别等冲突了才改

默认监听端口是5244。如果这台机器上已经跑了别的东西，先查一下占用：

ss -lntp | grep 5244 # 或者 lsof -i:5244

没有输出就说明空闲。真占用了也别慌，容器部署的话把映射改成15244:5244就行，宿主机端口换了，容器内不变，WebDAV 路径依然是/dav。这里有个小坑：改了宿主机端口之后，Alist 后台里生成的分享链接、WebDAV 地址里带的还是旧端口，需要到"站点设置"里把"站点 URL"改成新的外部访问地址，不然生成的链接点开是 404。

本地磁盘映射目录也要提前想好。如果你要把宿主机上的/mnt/disk1/影视挂进容器，compose 里就得写- /mnt/disk1/影视:/mnt/disk1/影视，两边路径保持一致最省心。容器里看到的路径和宿主机一样，你在后台填路径的时候不容易写错。这个细节很小，但我见过太多人栽在这上面——宿主机路径写对了，容器里没映射，结果 Alist 报"路径不存在"。

2.4 三种方式横向对比

3. 从零跑起来：完整部署实操

3.1 环境检查这几步别省

先在目标机器上确认 Docker 和 Compose 都装了：

docker --version docker compose version

Compose 现在是插件形式，命令是docker compose（有空格），不是老版本的docker-compose（有横线）。这两个混用是很常见的报错来源，写出docker-compose: command not found的时候先看是不是这个原因。

接着确认磁盘空间。Alist 本身很小，几十兆，但它会存元信息、缩略图缓存、日志，长期跑下来也会占几百兆。给它留个 2G 以上的空间比较稳妥：

df -h

最后确认时区。默认镜像里是 UTC，日志时间会差八小时，看着很难受。加一个TZ=Asia/Shanghai环境变量就解决了，属于加一次终身受益的配置。

3.2 编写 compose 文件并启动

找一个目录，比如/opt/alist，新建docker-compose.yml：

services: alist: image: <官方镜像地址>:latest container_name: alist restart: unless-stopped ports: - "5244:5244" volumes: - /opt/alist/data:/opt/alist/data - /mnt/disk1:/mnt/disk1 environment: - PUID=0 - PGID=0 - UMASK=022 - TZ=Asia/Shanghai

镜像地址这一行，建议直接去官方仓库的当前页面复制，因为镜像名和标签会随版本调整，照抄旧教程里的名字经常拉不到。同理，PUID和PGID填0是最省事的（以 root 身份运行），如果你对权限比较在意，就填宿主机上某个普通用户的id -u和id -g。

启动：

cd /opt/alist docker compose up -d docker compose logs -f

日志里出现监听端口的提示，就说明起来了。按Ctrl+C退出日志跟踪，容器还在后台跑。这时候浏览器打开http://机器IP:5244，应该能看到登录页。

3.3 拿到初始密码并登录

新版 Alist 第一次启动时不会在日志里直接打印密码，而是随机生成一个。两种拿法：

# 查看随机生成的初始密码 docker exec -it alist ./alist admin random # 或者直接设一个自己记得住的 docker exec -it alist ./alist admin set 你的新密码

用户名默认是admin。登进去之后第一件事就是改密码，别拖。我见过有人装完就放着，过了两周发现后台多了几个不认识的访客账号——默认配置暴露在公网上就是这样。

提示：如果执行 admin 命令提示文件不存在，先确认容器名对不对，docker ps看一眼。容器名在 compose 里是自己起的，不一定叫 alist。

3.4 登录后立刻要做的四项设置

第一，改端口或者改访问路径。默认 5244 是全网皆知的，扫描器扫这个端口的频率不低。改宿主机映射端口是最快的办法，改成五位数的一个随机端口，安全收益立竿见影。

第二，关掉访客访问。后台"用户"里有个guest账号，默认可能带一些目录的读权限。如果你不是要做公开分享站，直接把它禁用或者清空权限。

第三，配置站点 URL。在"设置 - 站点"里，把"站点 URL"填成你实际访问的地址，比如https://files.example.com。这个值影响所有生成的分享链接和 WebDAV 地址，填错的直接后果是分享出去的文件打不开。

第四，确认存储里的"Web 下载"相关开关。有的存储驱动默认走服务端转发，流量全部压在你这台机器上。如果只是自己用、对端又支持直链，可以按需调整，具体在存储编辑页的"WebDAV 策略"和下载相关选项里，不同驱动的命名略有差异，动之前先记下原值。

3.5 开机自启、日志和升级

restart: unless-stopped已经保证了宿主机重启后容器自动起来，除非你手动 stop 过。日志方面：

docker compose logs --tail=200 alist # 看最近 200 行 docker compose logs -f alist # 实时跟踪

日志级别可以在后台"设置 - 其他"里调，长期运行建议用info，排查问题临时开debug，完事记得调回来，不然日志文件长得很快。

升级我一般手动做，节奏是每月看一次有没有新版本：

cd /opt/alist docker compose pull docker compose up -d

升级前一定要先备份 data 目录。跨大版本升级偶尔会有数据结构调整，备份是唯一的安全绳：

tar -czf /root/alist-data-$(date +%F).tar.gz -C /opt/alist data

4. 挂载存储：把各种空间接进来

4.1 添加存储的统一套路

后台左侧"存储"-"添加"，会弹出一个表单。不管选哪种驱动，填的东西可以归成四类：

挂载路径：这个存储挂在虚拟树的哪个位置，比如/影视。必须以斜杠开头，不能和已有路径重复。我习惯按用途分层，/媒体/电影、/媒体/剧集、/文档/合同，后期好管。

驱动：下拉选类型，本地存储、WebDAV、S3 兼容对象存储、FTP/SFTP 等等。

配置项：每个驱动不一样，本地存储填根文件夹路径，WebDAV 填地址和账号，S3 填 endpoint、bucket、密钥。

排序和备注：多存储时排序值决定目录里谁在前，备注只是给自己看的。

填完点保存，回到首页刷新，路径出现了就成功了。没出现就是配置有问题，去"存储"列表看状态，会显示具体错误原因。

注意：挂载路径最后不要带斜杠，/影视是对的，/影视/有时候会导致目录列表异常。这个坑不常见但确实存在。

4.2 本地存储：路径和权限是全部问题

本地存储的配置项只有一个核心：根文件夹路径。填容器内能访问到的绝对路径，比如/mnt/disk1/影视。前提是这个路径在 compose 的 volumes 里映射过，否则容器里根本看不到。

权限是第二个坎。表现通常是：目录能列出来，点进文件报"permission denied"，或者上传失败。原因是容器内进程身份和宿主机文件所有者不匹配。两种解法：把PUID/PGID改成宿主机文件所有者对应的值，或者在宿主机上把目录权限放开：

chown -R 1000:1000 /mnt/disk1/影视 chmod -R 755 /mnt/disk1/影视

第三种情况更隐蔽：SELinux 或者某些发行版的 AppArmor会拦住容器访问宿主机目录，报错信息看起来像路径不存在。这种时候先临时关掉安全模块验证一下，确认是这个原因再针对性加规则，别急着改程序配置。

还有一个细节值得说：Alist 会对目录做索引和缓存。第一次进一个几万文件的目录会明显卡一下，之后就好了。如果你挂的是移动硬盘这种偶尔插拔的，记得在后台把这个存储禁用，不然每次启动都会尝试连接、超时报错。

4.3 WebDAV 接入：把另一个 Alist 或者 NAS 挂进来

WebDAV 驱动的配置项是：地址、用户名、密码。地址填到根，比如http://192.168.1.10:5005/dav，别带子目录。用户名密码填对端的账号。

这里有两个常见的坑。一是地址末尾的/dav不能漏，漏了会返回 404，报错信息看起来像"账号密码错误"，容易误判。二是对方如果开了访问策略限制，比如只允许特定 User-Agent，那你会一直认证失败。这种情况下换个驱动类型或者调对方的白名单。

WebDAV 挂载还有一个隐藏的价值：它可以用来做级联。比如你有一台机器在内网，另一台在外面，中间用一段可信链路连起来，外网那台就可以通过 WebDAV 把内网的文件树读进来，不需要每个存储都单独配一遍。

4.4 S3 兼容对象存储：备份和冷数据的好去处

对象存储的配置项多几项：Endpoint、Bucket、Access Key、Secret Key、区域（有些服务不需要）、根路径。填完保存，如果能列出来就通了。

这个驱动我主要用于两件事：一是把重要文件的冷备份放上去，二是给一些静态资源做分发。对象存储的好处是不占本地磁盘、按量计费、访问走的是对象存储自己的带宽，压力不会全落在你这台小机器上。

需要注意的是路径风格。有些兼容服务用bucket.endpoint这种虚拟主机风格，有些只支持endpoint/bucket这种路径风格，Alist 里有对应开关，选错了会报"bucket not found"之类的错误。这个问题在自建的对象存储上特别常见，我第一次配的时候在这上面耗了快一个小时。

4.5 网盘接入：走官方开放接口，别碰野路子

主流网盘现在大多提供官方的开放接口或者 WebDAV 能力，Alist 对其中一部分做了适配。接入方式通常是：选择对应驱动、按提示做授权、把拿到的凭证填进去。有些是 OAuth 授权流程，点一下跳转确认就完事；有些需要手动填 token，那就得按官方文档的流程去申请。

这里必须强调一点：只走官方提供的合法接口。网上流传的一些"破解接口""第三方中转"，短期看着能用，实际上要么随时失效，要么把你的账号凭证交到了别人手里。我在自己的机器上从来不碰这类东西，一是账号安全，二是不想哪天早上起来发现整个存储全红。

凭证过期是这类存储的常态。表现是刷新目录时报授权失败，重新走一遍授权流程就好。有些驱动支持自动刷新，有些需要手动，具体看驱动说明。我一般会把这个存储的备注写成"每季度检查一次授权"，提醒自己别等到用的时候才发现挂了。

4.6 挂载失败的通用排查顺序

5. 让它真正好用：进阶配置

5.1 开启 WebDAV，把播放器和文件管理器接上

后台"设置 - 全局"里有个 WebDAV 开关，打开之后访问地址是http://你的地址:端口/dav。账号密码就是你登录 Alist 的那套。

接电视盒子上的播放器时，添加网络存储，协议选 WebDAV，地址填上面那个，端口填 5244（或者你改后的端口），路径留空或者填/。连上之后你会看到整棵虚拟树，包括那些挂在后面的网盘。这是整个 Alist 体验里最爽的一环——视频不用下载，直接拖进度条。

有一个参数值得调：WebDAV 策略。在存储的编辑页里，通常有"使用 302 重定向""使用服务端转发""仅 WebDAV"这几个选项。302 重定向的意思是客户端直接去源地址拉文件，不经过你这台机器，速度快、机器压力小，但对客户端的兼容性要求高；服务端转发是全部流量过一遍 Alist，兼容性好但吃带宽。我的做法是：家里局域网用的存储选 302，公网访问、客户端比较老的场景选转发。

5.2 挂载成本地盘，像本地文件夹一样用

Windows 上映射网络驱动器：资源管理器右键"此电脑"-"映射网络驱动器"，地址填http://IP:5244/dav，勾选"使用其他凭据连接"，输账号密码。第一次连可能会提示不安全连接，因为走的是 HTTP，这个后面加 HTTPS 就解决了。

macOS 用访达的"前往 - 连接服务器"，输入同样的地址。Linux 用davfs2或者直接rclone mount。rclone 的方案更灵活，可以设缓存大小、只读、开机自动挂载，配置文件大概是这样：

rclone mount alist:/ /mnt/alist \ --allow-other \ --vfs-cache-mode writes \ --vfs-cache-max-size 2G \ --daemon

--vfs-cache-mode writes这个参数很关键。不加的话，很多程序（尤其是编辑器和办公软件）在保存文件时会报错，因为它们习惯先写临时文件再重命名，而 WebDAV 对这类操作支持得不好。加上之后，写操作会先在本地缓存里完成再上传，兼容性提升一大截。代价是需要预留缓存空间。

注意：--allow-other需要系统开启user_allow_other，否则会报权限错误。改/etc/fuse.conf取消对应行的注释即可。

5.3 多用户、权限和分享链接

Alist 的用户体系不复杂但够用。每个用户可以设置基础路径（只能看到某个子树）、权限（读、写、删、建目录）、是否允许访问隐藏文件。给家人开一个只读账号，基础路径指向/媒体，他们就看不到你的文档区。

分享链接这块，可以在任意文件或目录上右键"分享"，设置有效期和提取码。分享出去的是个短链，对方不用登录。同样的建议：只分享你有权分享的内容，别把别人给你的资料随手转出去。

有一个细节很多人没注意：分享链接的有效性依赖"站点 URL"配置正确。如果那个值填的是localhost或者内网 IP，生成出来的链接在外面打不开。这就是前面 3.4 里强调要改它的原因。

5.4 元信息、缩略图和索引，决定"好不好看"

Alist 支持给视频加封面、给音乐加歌词、给文件夹加说明，靠的是同目录下的元信息文件。视频封面一般是同名的图片文件，音乐歌词是同名的.lrc。配上之后，网页端列表会好看很多，尤其是影视库。

缩略图方面，图片的缩略图由前端生成，视频的缩略图需要服务端有ffmpeg。如果你用的是 Docker 镜像，官方镜像里通常已经带了；如果是二进制自己跑，得单独装。没装的表现是视频只显示一个默认图标，不影响播放。

索引这个选项在存储配置里，作用是让搜索能覆盖到这个存储。关掉能省内存，但你就搜不到里面的文件了。文件量大的存储建议开着，第一次索引会慢，后面是增量的。

5.5 用 Nginx 统一入口并加上 HTTPS

直接用IP:端口访问有两个问题：地址难记，以及 HTTP 明文传输。前面挂一台 Nginx 就都解决了。核心配置大概是这样：

server { listen 443 ssl; server_name files.example.com; ssl_certificate /etc/nginx/cert/fullchain.pem; ssl_certificate_key /etc/nginx/cert/privkey.pem; client_max_body_size 0; location / { proxy_pass http://127.0.0.1:5244; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 3600s; proxy_send_timeout 3600s; } }

几个参数必须解释一下。client_max_body_size 0是取消上传大小限制，默认 1M，不改的话大文件上传直接 413。proxy_read_timeout和proxy_send_timeout调到 3600 秒，是因为大文件传输往往超过默认的 60 秒，超时会被掐断，表现是下载到一半中断。X-Forwarded-For这几个头是让 Alist 能拿到真实客户端 IP，不然访客记录里全是127.0.0.1。

提示：加了 HTTPS 之后，记得把后台的"站点 URL"同步改成https://开头，否则又是那个分享链接打不开的老问题。

5.6 离线下载：能用，但要知道边界

Alist 内置了对下载器的对接能力，可以挂一个下载工具做离线任务。配置位置在"设置 - 其他"里，填上下载器的地址和密钥。配好之后可以在网页上直接提交任务，文件下完自动出现在对应目录里。

这块我建议只用在自己有权限的内容上，比如自己的备份、公开授权的资源。另外注意下载器的磁盘路径和 Alist 看到的路径要一致，不然任务完成了文件"消失"了——其实是存到了另一个地方。

6. 问题排查实录：这些坑我基本都踩过

6.1 网页打不开，先从三层往下排

第一层，容器在不在。docker ps看状态，如果是Restarting就是启动失败，去看日志。常见原因是端口被占用、数据目录权限不对、compose 文件缩进错。

第二层，端口通不通。在本机curl -I http://127.0.0.1:5244，通了说明服务正常，问题在网络层。不通就是服务没起来或者监听地址不对。

第三层，外部能不能到。从另一台机器curl或者telnet IP 5244。不通的话查防火墙：

# 查看规则 iptables -L -n | grep 5244 # 或者用 firewalld firewall-cmd --list-ports

云服务器还要看安全组，这一层经常被忘掉——本机怎么测都通，外面就是进不来，八成是安全组没放行。

6.2 密码忘了或者登录不上

最直接的办法是用命令行重置：

docker exec -it alist ./alist admin set 新密码

如果提示用户不存在，说明数据库里的 admin 被改过名字，用random子命令会打印出当前所有管理员账号信息，照着改就行。

还有一种情况是能输密码但一直跳回登录页。这通常是 Cookie 或者站点 URL 的问题。清一下浏览器缓存，检查"站点 URL"是否和实际访问地址一致（协议、域名、端口三者都要对）。我遇到过一次，站点 URL 填的是http://，实际用https://访问，登录状态死活保持不住。

6.3 存储挂载失败的定位方法

先看错误提示，Alist 在存储列表里会直接显示失败原因，这个信息比日志还直接。常见几类：

dial tcp: i/o timeout是网络不通，在容器内curl一次目标地址验证。容器内的网络和宿主机不一定一样，尤其是用了自定义网络或者有 DNS 问题的时候。

401 Unauthorized是认证问题，核对账号密码，注意 WebDAV 地址有没有漏/dav。

no such file or directory是路径问题，先确认容器里能不能ls到那个路径：

docker exec -it alist ls /mnt/disk1

列不出来就是 volumes 没映射对。

permission denied是权限问题，回去看 4.2 那一节。

6.4 视频卡顿、拖不动进度条

这个问题的原因通常不在 Alist 本身，而在链路上。判断方法：本地局域网播放同一个文件卡不卡？不卡说明是公网带宽的问题；本地也卡，那就是存储本身或者转发策略的问题。

如果是公网访问，先确认 WebDAV 策略是不是 302 重定向。重定向模式下客户端直连源地址，速度取决于源站；转发模式下所有流量过你的机器，速度取决于你这台机器的上行带宽。家用宽带上行通常很小，转发模式下看高码率视频必然卡。

还有一个容易忽略的点：播放器的缓存设置。有些播放器默认缓存很小，拖动进度条时会重新请求，表现为"拖一下卡三秒"。把缓存调大能明显改善。

6.5 升级之后出问题怎么退

升级前备份 data 目录，出问题就把目录换回去，然后指定旧版本镜像重新起：

docker compose down tar -xzf /root/alist-data-2025-01-01.tar.gz -C /opt/alist # 修改 compose 里的镜像 tag 为旧版本 docker compose up -d

所以我的建议是镜像 tag 不要无脑用latest，可以用具体的版本号，升级时改数字，回滚时改回来，比拉一个不知道是什么的latest可控得多。

7. 长期运行的几个硬要求

7.1 别让它裸奔在公网上

这是我最想强调的一条。Alist 一旦暴露在公网，扫描器几小时内就能找到你。要做的几件事：改掉默认端口、用强密码、开 HTTPS、关掉访客账号、给每个账号设下载速度上限。有条件的话再加一层访问控制，只允许特定来源访问，或者干脆只在内网用，出门靠一条可信通道连回来。

后台还有"登录失败次数限制"和"单 IP 请求频率限制"，都建议打开。这类防护不解决根本问题，但能把大部分自动化尝试挡在门外。

7.2 备份只认 data 目录

前面说过，配置和用户数据都在data目录里（SQLite 模式下是data/data.db）。备份策略我一般这样：每天凌晨打包一次，保留最近七天，扔到另一个物理位置。脚本很简单：

#!/bin/bash DATE=$(date +%F) tar -czf /backup/alist-$DATE.tar.gz -C /opt/alist data find /backup -name "alist-*.tar.gz" -mtime +7 -delete

扔进 crontab 就完事。这套东西的价值不在于备份本身，而在于某天你误删了一个存储配置、或者升级把数据搞坏了，能在十分钟内恢复。

7.3 升级节奏和监控

我的节奏是每月看一次更新，小版本直接升，大版本先看更新说明有没有破坏性改动。升级窗口选在不用的时候，升完立刻验证三件事：能登录、存储列表全绿、随便打开一个文件能下载。

监控方面不用搞得很复杂，一个定时 curl 就够了：

*/5 * * * * curl -sf http://127.0.0.1:5244/ > /dev/null || echo "alist down" | mail -s "alert" you@example.com

返回非 200 就发通知。比装一整套监控系统轻量得多，对个人自建服务来说够用了。

我在几台机器上跑了两年多，最大的体会是：这套东西的稳定性取决于你有没有把边界划清楚。跑在内网、只给自己和家人用、存储全部走官方接口、定期备份——满足这四条，它就是个几乎不用管的工具。反过来，为了多功能去接一些来路不明的接口、为了省事把后台直接扔在公网上、升级前不备份，那迟早要花一个周末去收拾。

还有个小技巧分享一下：把常用的几个路径做成浏览器书签，命名成"影视""文档""备份"，比每次都从根目录点进去快得多。另外给每个存储写一条备注，记清楚它是哪个账号、什么时候授权的、下次该什么时候检查，半年后再看的时候能省掉大量回忆的时间。