自建 Navidrome 音乐库的剧本，通常都是这么写的：把攒了好几年的 FLAC 拖进 NAS，Docker 起一个容器，手机装上客户端，"私人 Spotify"达成，从此告别音乐会员。
但评论区里，剧情经常往另一个方向走。知乎"你们是怎么远程用NAS听歌的？"这类问题常年有人讨论，Navidrome、Jellyfin、Emby 都是常客。知乎B站那条播放量 4 万多的《Navidrome搭配音流》教程底下，有人反馈，服务端搭好了，iOS 客户端用的音流，音质非常差，设置不转码也没用。哔哩哔哩小红书今年 2 月也有笔记吐槽，navidrome 音流网页版播不了 dsf 格式。小红书这些声音都指向同一件事：音质缩水可能不是错觉。
文件是无损的，服务器是开源免费的，按理说全程无中间商，音质到底是在哪一步丢的？我翻了知乎、小红书、B站的相关讨论，再对照 Navidrome 官方文档里的转码机制，把这件事捋清楚了：Navidrome 本身不会主动降你的音质，客户端不要求、格式又能直接播，它就把原始文件原样串流出去。问题基本都出在下面这 4 个环节。
环节一：你被转码了，但你不知道
Navidrome 的行为逻辑其实挺克制：默认原样透传，一个字节都不动。但有三种情况它会默默架起 ffmpeg 开始转码：
第一种，客户端主动要求。 不少 Subsonic 系客户端默认或者不小心被设成了"省流"档。你以为是直出无损，其实服务器正实时把你的 FLAC 压成有损流。按官方文档，客户端请求降采样时如果只给码率不指定格式，Navidrome 默认会转成 Opus。Navidrome 官方文档先去客户端的"音质/串流质量"设置里看一眼，选"原始质量 / Raw / 原码率"这一档。
第二种，管理员给你设了上限。 Navidrome 后台可以按用户设置最大码率（Max Bit Rate），如果当初建用户时顺手设成了 320，那不管客户端怎么请求，出去的都超不过这个数。多人共用一台服务器的，尤其建议互相检查一下对方账户的设置。
第三种，格式逼着它转。 典型就是 DSD。小红书那条"navidrome 音流网页版播不了 dsf 格式"的笔记就是这种情况：文件本身服务器能认，但客户端或协议不支持这个格式，只能靠服务端转成 PCM 之类的通用格式出声——能听，但跟"原生 DSD"是两码事，烧友对这条链路的预期要提前摆正。
顺带一提，转码是要吃 CPU 的，Navidrome 会把转码结果缓存起来，配置项就叫 TranscodingCacheSize。Navidrome 官方文档所以反复测试同一首歌时，注意别把"缓存命中"当成"音质没变"的证据。
环节二：入库的本来就是"假无损"
这个坑最容易被忽略，因为锅根本不在 Navidrome。
知乎"如何辨别无损音乐文件的真假？"下面有专门的高赞讨论：所谓假无损，是拿 mp3、aac 这类有损文件解码后重新封装成 FLAC，后缀看着是无损，但高频信息在当年那次有损压缩时就被永久删掉了，套个壳也补不回来，任何播放器都救不了。知乎自建曲库的音源很大一部分来自下载站、网盘分享、群友互传，这类渠道恰恰是假无损的重灾区。鉴别也不难，用 Spek 之类的工具看频谱：真无损的高频部分通常比较完整，假无损往往在某个频点之上被一刀切齐。小红书如果你发现自己辛苦搭建的"FLAC 曲库"听着还不如流媒体的 320k，先别急着怪服务器，抽几张专辑验一下文件本身。
环节三：出门听歌，带宽逼你"被动降级"
在家听，千兆局域网随便跑，24bit/192kHz 也无压力。真正的瓶颈出现在出门之后——卡的是你家的上行带宽。
大概的账可以这么算：
你听的格式 | 大致码率 | 流畅收听所需上行带宽 |
|---|---|---|
MP3 320k | 约 0.3 Mbps | 几乎随便跑 |
Opus 160–256k | 约 0.2 Mbps | 几乎随便跑，听感已相当好 |
CD 规格 FLAC（16bit/44.1kHz） | 约 0.8–1 Mbps | 建议 2 Mbps 以上稳定上行 |
Hi-Res FLAC（24bit/96kHz） | 约 2–3 Mbps | 建议 6 Mbps 以上稳定上行 |
国内家宽普遍下行几百兆、上行三五十兆，纸面上够，但高峰期会打折扣；切到 5G 流量，能分到多少更看基站脸色。这也是社区里的常见卡点：知乎有专门的帖子复盘"音流连 Navidrome 异地播放"的问题，作者在家里局域网播放正常、公网访问却不对劲的情况下，排查完 NAS、Navidrome 和客户端，最后换成虚拟局域网方案才恢复流畅。知乎说白了，外网听歌先保证链路，再谈码率。
所以社区里比较主流的做法是分级：在外网用低码率转码档（Opus 256k 这一档，大多数人盲听很难分辨出和无损的区别），回家连上 WiFi 再切回原始质量；再配合客户端的缓存和预加载，通勤路上听的基本都是提前缓存好的文件。像维克音乐这类客户端最近就把预加载缓存当成了核心功能，正在播歌曲 A 的时候，歌曲 B 已经悄悄缓存到本地磁盘，下一首直接秒播，对实时带宽的依赖小得多。小红书
环节四：输出链路，最容易被忽视的短板
知乎上有个问题问得很扎心："普通人真的能听出无损音质和普通音质的区别吗？"下面的回答很现实：很多人是手机外放或者蓝牙耳机听歌，蓝牙传输本身就经过有损编码，无损文件推到耳机前已经缩水过一轮了。知乎换句话说：如果你主要用蓝牙耳机听自建曲库，纠结 Raw 还是 320k 意义有限，把转码档配好、缓存开起来，体验反而更稳。真想认真听无损，有线耳机加个小尾巴，或者接到家里的音箱、解码器上，差别才拉得开。
播放端的选择上，社区目前的大致口碑可以参考：Android 上 Symfonium 认可度很高，知乎有答主在推荐 NAS 播放器时直接写，Android 的天花板是 Symfonium。知乎桌面端可以用开源的 Feishin，Navidrome 官方应用列表里收录了它，主打现代 UI 和多后端。Navidrome 官网音流的优势是全平台覆盖和中文体验，iOS、Android、电脑、网页都能用，不过稳定性评价比较两极，B站那条教程的评论区里既有"音流 bug 不要太多"的吐槽，也有人换到别的客户端后才消停。哔哩哔哩选客户端时除了看功能列表，最好翻翻评论区，很多坑只有真实用户会写。
一份按顺序排查的自检清单
如果你现在正对 Navidrome 的音质不满意，建议按这个顺序排查，基本五分钟定位问题：
查文件：抽几首用频谱工具看看，排除假无损；
查客户端：音质选项是不是"原始/Raw"，有没有停在省流档；
查服务端：用户最大码率有没有被设上限，DSF 这类格式本来就要转码、别指望原生；
查网络：外网卡顿就降码率加缓存，先保链路再谈码率；
查输出：蓝牙耳机链路先换设备再谈设置。
说实话，Navidrome 在自建音乐服务器里算是相当克制的一个：默认不动你的文件，所有的"降级"都是某个环节主动要来的。把这条链路理清楚，你就知道力气该往哪使了。
你现在的 Navidrome 用的什么客户端、什么音质配置？有没有遇到过"明明是无损听着却不对"的情况？评论区聊聊，顺便帮后面的值友避避坑。
