2026 Navidrome 自建音乐流媒体：Docker 部署打造个人音乐库

一、Navidrome vs 其他音乐服务#

选择 Navidrome 的核心理由：Go 写的，轻量又好部署；生态广，几乎所有流媒体客户端都支持 Subsonic API；你永远不用担心歌单变灰。

二、Docker Compose 部署#

创建一个 navidrome 目录：

1
mkdir -p ~/navidrome && cd ~/navidrome

新建 docker-compose.yml：

1
services:
2
  navidrome:
3
    image: deluan/navidrome:latest
4
    container_name: navidrome
5
    restart: unless-stopped
6
    ports:
7
      - "4533:4533"
8
    volumes:
9
      - ./data:/data
10
      - ./music:/music:ro
11
    environment:
12
      ND_SCANSCHEDULE: "1h"
13
      ND_LOGLEVEL: info
14
      ND_SESSIONTIMEOUT: "24h"
15
      ND_BASEURL: ""
16
      ND_DEFAULTLANGUAGE: zh
17
      TZ: Asia/Shanghai

几个关键配置说明：

• ND_SCANSCHEDULE：音乐库扫描周期，设为 1h 每小时检查一次新文件。如果你频繁往音乐目录里加歌可以调短到 30m，不经常变就设 24h 省资源
• ND_LOGLEVEL：日志级别，info 够用，排查问题时可以临时调成 debug
• ND_SESSIONTIMEOUT：登录会话过期时间，默认 24 小时。自己用不用频繁登录，可以调长一些
• ND_DEFAULTLANGUAGE：界面默认语言，zh 就是中文
• ./music:/music:ro：ro 表示只读挂载，Navidrome 不会修改你的原始音乐文件，只管读取和索引

把音乐文件放进 ~/navidrome/music/ 目录，然后启动：

1
docker compose up -d

访问 http://你的IP:4533，注册第一个账号（谁先注册谁就是管理员）。注册完成后你会看到一张漂亮的海报墙——专辑封面、艺术家图片全部自动加载好。点击任意专辑就能直接播放。

三、音乐文件整理建议#

Navidrome 的刮削依赖于文件名和 ID3 标签。相比 Jellyfin 对文件名规范要求那么严格，Navidrome 主要看音乐文件的内嵌元数据（ID3 标签）。按以下标准整理就没问题：

文件夹结构（推荐）：

1
music/
2
├── 周杰伦/
3
│   ├── 叶惠美/
4
│   │   ├── 01 以父之名.flac
5
│   │   ├── 02 晴天.flac
6
│   │   └── cover.jpg
7
│   └── 七里香/
8
│       ├── 01 我的地盘.flac
9
│       ├── 02 七里香.flac
10
│       └── cover.jpg
11
└── Taylor Swift/
12
    └── 1989 (Taylor's Version)/
13
        ├── 01 Welcome to New York.flac
14
        └── cover.jpg

Navidrome 按 Artist → Album → Songs 的层级自动组织，文件夹命名只是方便人类管理，实际上 Navidrome 通过 ID3 标签来读取艺术家和专辑信息。

ID3 标签必须包含的信息：

• 标题——歌名
• 艺术家——演唱者
• 专辑——所属专辑
• 音轨号——在专辑中的排序
• 专辑艺术家——多艺术家的合辑需要这个字段

封面图： 把 cover.jpg 或 folder.jpg 放在专辑文件夹里，Navidrome 自动读取并显示在专辑封面上。如果文件内有内嵌封面图（大多数正版转出来的 FLAC 都有），Navidrome 也会直接读取。

没有 ID3 标签的文件： 如果你的音乐文件是很多年前的散装 MP3，没有内嵌标签——Navidrome 会以文件名作为标题显示，缺少艺术家和专辑信息。这种情况建议整理工具处理一下（比如 MusicBrainz Picard，免费的标签整理软件，能自动匹配数据库补全标签）。

四、客户端推荐#

Navidrome 的优势在于客户端生态。它用的是 Subsonic API，这是音乐流媒体领域事实上的标准协议——几乎所有第三方客户端都支持它。你不需要用浏览器访问 Navidrome，在各平台装个客户端就行：

个人最推荐 Android 用 Symfonium，iOS 用 play——这两个是付费的但体验确实好，支持离线缓存、睡眠定时、均衡器调节。免费用户直接用 Ultrasonic 或 Navidrome Web 端也完全够用。

五、反向代理和 HTTPS#

Navidrome 默认走的 HTTP，局域网内用没问题。如果想公网访问（出差在外也想听自己的音乐库），配个反向代理加 HTTPS：

Nginx Proxy Manager 方案（最简单）：

如果你已经在用 NPM，在管理后台添加一条代理规则即可：

• 域名：music.你的域名.com
• 转发 IP：http://192.168.1.100:4533（换成你的内网 IP）
• 开启 SSL，申请 Let’s Encrypt 证书
• 勾选 Websockets Support（Navidrome Web 端播放需要）

或者用 Caddy 配置（更简洁）：

1
music.你的域名.com {
2
    reverse_proxy navidrome:4533
3
}

配置好之后在 Navidrome 的环境变量里加上 ND_BASEURL：

1
environment:
2
  ND_BASEURL: "https://music.你的域名.com"

这个变量告诉 Navidrome 它运行在反向代理后面，保证播放链接和重定向地址是正确的。

延伸阅读#

• Docker 换源避坑指南 — 部署前的必备准备
• Nginx Proxy Manager 反代面板 — 统一管理所有服务的访问入口
• 自建 RSS 信息流 — 彻底告别算法推荐

六、常见问题#

Q：为什么扫描完了但有些专辑没封面？ Navidrome 优先读取文件内嵌的 ID3 封面或专辑目录下的 cover.jpg。如果这两者都没有，它会去 Last.fm 等在线源抓取封面——但如果你的服务器无法访问外部网络，封面下载就会失败。解决方案：在专辑目录里放一张 cover.jpg，Navidrome 会直接使用它。

Q：英文文章说 Subsonic API 不支持无损？ 这完全是个误解。Subsonic 协议传输的是原始音频流——如果你的音乐是 FLAC，Navdrome 就直接 stream FLAC 给你。只有带宽不够或选择了压缩传输时才会转码。局域网内听无损完全没问题。

Q：怎么多人共用？各自歌单互不影响？ 每个用户登录后看到的是同一个音乐库（所有文件共享），但各自的收藏、歌单、播放历史、评分完全独立。注册时谁先注册谁是管理员，管理员可以在后台创建其他用户账号。每个人登录自己的账号，听到同样的音乐库，看到自己的歌单。

Q：Navidrome 支持播客吗？ 支持的。在后台可以把 RSS 播客源添加到系统中，然后所有客户端都能订阅和收听播客。播客的播放进度也是跨设备同步的。

Q：音乐太多，扫描会不会慢？ Navidrome 的扫描分为两步。首次扫描会把所有文件的元数据读入 SQLite 数据库，速度取决于文件数量和磁盘 I/O——一万首 FLAC 大约需要 5-10 分钟。之后的增量扫描只会检查新增和变动的文件，几乎秒完成因为 Navidrome 记录了文件的修改时间和校验和，没有变化就不重新读取。

部署完 Navidrome 后，下一步可以把它和 Jellyfin 放在同一台服务器上——两个 Docker 容器、两个端口，构成一套完整的家庭媒体服务器（视频用 Jellyfin，音乐用 Navidrome）。整套方案开销不到几百 MB 内存，0 元月费，歌单永不灰色。

把散落在硬盘和各个流媒体平台之间的音乐集中起来，用 Navidrome 管理之后你可能会发现——原来自己收藏了这么多歌，只是因为之前管理太乱才懒得听。

推荐指数：⭐⭐⭐⭐⭐