电脑里有一批整理过的专辑，手机却只能临时复制几首。换设备时，播放列表、封面和文件又要重新处理。如果手里的音乐本来就是自己购买、制作或有权保存的文件，可以用 Navidrome 建立一个私人音乐库，让浏览器和兼容客户端从同一个服务器读取。
VPS 的作用是提供一个持续在线的入口。它不会替你寻找歌曲，也不会让一块小系统盘装下无限的无损音乐。开始之前先估算文件大小、备份位置和手机访问这台服务器的网络情况，再决定音乐放在哪儿。
先拿两张专辑试，不要立即上传整个硬盘
Navidrome可以索引已有音乐文件，提供 Web 播放界面，也支持兼容 Subsonic 的客户端。它管理的是文件库，与把歌单迁入另一家流媒体服务的做法不同。
适合第一轮试用的样本，是两张标签完整的专辑，再加一张含多位演唱者的合集。这样能同时检查歌曲顺序、专辑归属、封面和中文显示。如果仅上传几个没有标签的 MP3，看到页面能播放，却不知道以后整库为什么会被拆成很多零散专辑。
音乐文件与应用数据分开保存。音乐目录体积大，主要需要读取；数据目录保存数据库、缓存和用户相关状态，需要写入。不要因为都是“音乐服务器的数据”，就把两个目录混在同一个路径中。
容量账也先算清楚：已有文件、未来新增、应用缓存和升级时的临时空间都要留余量。VPS 服务商的快照是否覆盖挂载数据盘，也应单独确认。服务器快照与另一处音乐备份各有用途，不能只看到控制台有“快照”按钮就删除原始文件。
建好目录，再启动容器
假设 VPS 已安装 Docker Engine 与 Compose 插件，运行 docker compose version 可以确认 Compose 是否可用。示例使用当前官方镜像入口，长期运行前应在试用通过后固定版本标签或摘要。
mkdir -p ~/navidrome/data ~/navidrome/music
cd ~/navidrome
id -u
id -g
下面的 1000:1000 是示例 UID/GID，必须改成有权写数据目录、读音乐目录的账户。不要看到教程里是1000就默认自己的账户也是1000。
services:
navidrome:
image: deluan/navidrome:latest
user: "1000:1000"
ports:
- "127.0.0.1:4533:4533"
volumes:
- ./data:/data
- ./music:/music:ro
restart: unless-stopped
配置根据官方 Docker 安装文档调整。音乐目录以只读方式挂载，防止播放器进程改变原文件；应用数据则保留可写权限。先复制试用专辑到 music 下，再运行：
docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 navidrome
ssh -L 14533:127.0.0.1:4533 user@your-server
打开本机 http://127.0.0.1:14533，在私人入口完成初始账户设置。不要在尚未创建自己的账户时，就把新实例直接开放到公网。
若数据目录无法写入，容器可能启动失败；若音乐目录不可读，页面可能正常但曲库为空。检查目录所有者、父目录访问权限和日志，再修正对应路径。官方镜像使用 user 指令，不能靠添加 PUID、PGID 环境变量期待它自动处理账户。
专辑显示乱，先看文件标签
目录名不是所有显示信息的来源。专辑、艺术家、曲目编号、碟号和封面应在文件元数据中对应。某张专辑被拆成多个条目时，先看这些字段是否一致，再研究应用设置。
合集尤其容易出现两种需求：每首歌的演唱者不同，整张合集却希望显示成一个专辑。标签工具中应区分曲目艺术家与专辑艺术家。不同格式与标签字段的对应关系，按 Navidrome 的标签文档核对，别通过批量改文件夹名来掩盖错误。
修标签最好在自己的整理目录完成，保留原文件或可回退记录，再同步到服务器。全库批量修改之前，拿一张专辑验证扫描结果。一次改动几千首，后面很难判断是标签规则错误，还是同步没有完成。
文件从宿主机能看到，而容器曲库没有新增，也可能是挂载路径不对。Compose 左边是宿主机路径，右边是容器路径；相对路径通常相对配置文件所在目录理解。迁移时换了工作目录，可能挂上一个新建的空文件夹。
用手机测试一首歌的完整播放
准备通过手机长期访问时，配置一个 HTTPS 域名，将反向代理指向本机4533端口。以已有 Caddy 为例：
music.example.com {
reverse_proxy 127.0.0.1:4533
}
DNS 指向服务器，80和443端口具备证书签发与访问条件后，再验证公开地址。管理账户完成初始化后，为日常播放建立普通账户，需要分享给家人时各用自己的账号。
客户端填入自托管服务器地址，不要仍然使用家里电脑的 IP 或 SSH 转发地址。先在 Web 页面播放，再在兼容客户端播放同一首歌，能帮助区分服务端问题与客户端设置问题。
实际测试包括开始播放、拖到后半段、切换下一首、暂停再继续。首页能打开并不证明音频请求和拖动播放都正常。Wi-Fi 可用以后，再用移动网络试一次；移动端网络到 VPS 的路径可能不同。
播放缓冲时看三件事：原始文件的码率、服务器出口和实际客户端链路。低码率音频可用，不代表大体积无损文件也会同样顺畅。需要转码时再核对相应客户端与服务器设置，并观察 CPU，不能把“支持播放”理解成小规格 VPS 可以无限并发转码。
更新音乐时保留一个可解释的流程
新增专辑先整理标签，上传到音乐目录，确认文件完整后再扫描。大文件只上传一半时就被扫描，可能出现暂时不可播放的条目。可以先传到库外的临时目录，完成后移入正式音乐路径。
删除音乐也应从源文件策略出发。服务器端删除而本地同步程序下一次又传回来，页面会反复变化。决定本地是主库还是 VPS 是主库，再安排单向同步、版本保留和删除动作。
用户的播放列表与原始音乐不是同一项资产。只有音乐文件备份，可能仍丢掉后来整理的列表和账户状态；只有数据库，也无法凭空恢复音频。迁移要两部分一起检查。
如果服务器磁盘突然增长，先比较音乐目录和数据目录，不要直接清空整个 data。数据库、配置与缓存混在同一个挂载下，删错文件会影响账户或曲库状态。按当前版本文档确认哪些内容可重新生成，再进行有范围的清理。
一张合集中出现重复专辑，可以这样缩小问题
先选中一首显示异常的歌，在本地标签工具中查看专辑名、专辑艺术家、曲目艺术家、碟号和曲目编号。与同一张专辑中显示正常的文件对照，寻找实际差异。有些差异只是多一个空格或不同标点，肉眼看文件名不容易发现。
随后只修改这张专辑的副本，上传到试用库，重新扫描并核对结果。确认规则有效再用于原库。曲库里同时存在不同来源、不同编码版本时，重复条目也可能是真实重复文件，不能一概归咎于扫描器。
新文件放进音乐目录而不出现时，先确认完整文件确实位于挂载来源，再用容器中的目录视角检查。宿主机的软链接如果指向容器外未挂载路径，容器未必能读到目标。目录所有者正确也不代表所有父目录允许进入，应逐级检查路径权限。
| 现象 | 先检查什么 | 不宜直接做的操作 |
|---|---|---|
| 启动后立刻退出 | 数据目录可写性与日志 | 删除数据库再重试 |
| 页面正常但曲库为空 | 音乐挂载、目录读取权限 | 取消用户限制以 root 运行 |
| Web 能播放，手机不能 | 客户端服务器地址与认证 | 再建一套曲库 |
| 拖动播放失败 | 音频请求与代理路径 | 只刷新首页反复点击 |
| 重建后像新实例 | 原数据目录与 Compose 挂载 | 立即重新导入全部文件 |
这些检查只确定问题发生的位置。数据损坏、标签异常与网络失败需要不同处理，没有一个“重新拉镜像”能统一解决的办法。修复后用同一张样本专辑复测，记录改变了哪项配置，避免下一次容器重建又回到原问题。
迁移前，把音乐和应用状态分别验收
小规模实例可在停止服务时离线备份数据目录，原始音乐保留独立副本：
umask 077
docker compose stop navidrome
tar -czf navidrome-data.tar.gz data
docker compose start navidrome
这只备份应用数据，没有打包音乐。实际归档应写入独立备份位置，检查命令退出状态，并保存 Compose 与当前镜像标识。音乐体积很大时，单独采用可校验的文件备份，不必每次重新压缩整个库。
恢复到隔离实例后，检查普通账户登录、专辑、封面和播放列表，再播放试用样本。音乐挂载路径变化时，应按当前版本迁移说明处理，避免曲库关联发生意外变化。确认原文件齐全和应用状态可用后，才切换域名。
VPS 适不适合放音乐，最终要看自己的库和网络。如果曲库很大、家里已有稳定存储，VPS 可以只承担另一种远程访问角色；若只有少量常听专辑，独立音乐服务更容易维护。先用两张专辑把日常播放与恢复走通，再搬完整曲库，能少走很多返工路。