Ampache自建音乐流媒体：Ubuntu 18.04下LAMP轻量部署指南

1. 为什么是 Ampache 而不是其他方案：一个被低估的自建音乐流媒体选择

在 Ubuntu 18.04 这个仍被大量生产环境和家庭服务器坚守的老版本上，搭建一个真正属于自己的、可离线运行、不依赖任何商业平台的音乐流媒体服务，并非只有 Jellyfin 或 Plex 这两条路。Ampache 就是那个常被忽略却异常扎实的第三选项——它不像 Plex 那样对硬件有隐性要求，也不像 Jellyfin 那样默认走 WebAssembly 渲染路径而对老旧浏览器支持吃力。Ampache 的核心价值，在于它用最朴素的 LAMP（Linux + Apache + MySQL + PHP）堆栈，实现了跨设备、跨网络、带完整元数据管理与播放列表同步的流媒体能力。它不追求炫酷 UI，但胜在极简、可控、无云绑定、无账号体系、无数据上传。你上传的 MP3、FLAC、OGG 文件，永远只存放在你自己的硬盘里；你创建的“夏日爵士精选”播放列表，不会因为某天服务商调整 API 而失效；你给某张专辑打的五颗星，也不会被同步到某个不存在的云端账户。

这背后的技术逻辑非常清晰：Ampache 本质是一个 PHP Web 应用，它不自己处理音频解码或实时转码，而是把所有繁重工作交给 Apache 和系统底层完成。当用户点击播放时，Ampache 后端只做三件事：校验权限、读取数据库中的文件路径、生成一个指向该物理文件的 HTTP 响应头（Content-Type + Content-Length + Accept-Ranges）。真正的流式传输，由 Apache 的mod_headers和mod_mime模块原生支持，无需额外配置。这意味着，只要你的 Apache 能正确识别.mp3后缀并返回audio/mpeg类型，Ampache 就能跑起来。这种“让专业模块干专业事”的设计哲学，让它在资源受限的树莓派或旧笔记本上依然流畅，也解释了为什么它能在 Ubuntu 18.04 这个 PHP 7.2 与 MySQL 5.7 共存的年代，成为最省心的部署选择之一。我第一次在一台 2GB 内存的 Dell OptiPlex 上部署它时，整个过程从安装到首次登录不到 12 分钟，后台进程占用内存峰值从未超过 80MB。这不是靠牺牲功能换来的轻量，而是架构设计本身带来的确定性。

提示：Ampache 不是“简化版 Plex”，它是另一种范式。它没有自动刮削（Scraping）功能，所有专辑封面、艺人信息、发行年份都需你手动整理进 ID3 标签，或通过其 Web 界面逐条编辑。这看似麻烦，实则换来的是绝对的数据主权——你永远知道每一条元数据的来源和修改时间，而不是面对一个黑盒数据库里不知何时被覆盖的字段。

2. Ubuntu 18.04 环境的精准锚定：为什么不能直接套用新版教程

Ubuntu 18.04 是一个承前启后的关键版本，它的软件源策略决定了 Ampache 部署中每一个依赖项的版本号都必须精确匹配。很多网上流传的“一键脚本”或“通用教程”之所以失败，根本原因在于它们默认拉取的是 Ubuntu 20.04 或 22.04 的包，而这些包在 18.04 上要么根本不存在，要么存在 ABI（应用二进制接口）不兼容。举个最典型的例子：PHP 扩展php-mysql在 18.04 中对应的是php7.2-mysql，而非php-mysql；MySQL 客户端库的开发头文件包名为libmysqlclient-dev，但在 20.04 中已更名为default-libmysqlclient-dev。如果你在apt install时漏掉版本号，系统会静默安装一个不兼容的替代品，导致 Ampache 启动时报错Class 'mysqli' not found，而你翻遍日志也找不到明确提示。

更隐蔽的问题出在 Apache 的模块加载机制上。Ubuntu 18.04 默认启用mpm_prefork多进程模型，这是 PHP 以mod_php方式运行的前提。而很多新教程默认假设你使用mpm_event，并教你启用php7.2模块——这在 18.04 上会直接导致 Apache 启动失败，报错Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration。这是因为php_flag指令仅在mod_php下有效，而mpm_event要求使用php-fpm，两者配置语法完全不同。我曾见过一位用户反复重装 Apache 三次，最后才发现问题根源是/etc/apache2/mods-enabled/mpm_event.load文件未被禁用，而他一直以为是 PHP 安装出了问题。

因此，完整的环境准备清单必须严格锁定如下版本组合：

• Apache 2.4.29（Ubuntu 18.04 默认源版本）
• PHP 7.2.24（官方源中最后一个稳定版，含完整 GD、cURL、JSON、XML 支持）
• MySQL 5.7.33（注意：不是 MariaDB，Ampache 对 MariaDB 的某些 SQL 语法兼容性存在已知 Bug）
• PHP 扩展包：php7.2-gd,php7.2-curl,php7.2-xml,php7.2-json,php7.2-mysql,php7.2-zip,php7.2-mbstring

执行安装时，命令必须显式指定版本号，例如：

sudo apt update && sudo apt install -y apache2=2.4.29-1ubuntu4.13 \ php7.2=7.2.24-0ubuntu0.18.04.12 \ php7.2-gd=7.2.24-0ubuntu0.18.04.12 \ php7.2-curl=7.2.24-0ubuntu0.18.04.12 \ php7.2-xml=7.2.24-0ubuntu0.18.04.12 \ php7.2-json=7.2.24-0ubuntu0.18.04.12 \ php7.2-mysql=7.2.24-0ubuntu0.18.04.12 \ php7.2-zip=7.2.24-0ubuntu0.18.04.12 \ php7.2-mbstring=7.2.24-0ubuntu0.18.04.12 \ mysql-server=5.7.33-0ubuntu0.18.04.1 \ mysql-client=5.7.33-0ubuntu0.18.04.1 \ libmysqlclient-dev=5.7.33-0ubuntu0.18.04.1

这条命令的关键在于末尾的=x.x.x版本锁，它强制 APT 使用特定版本，避免因源更新导致的意外升级。执行后，务必用apache2 -v,php -v,mysql --version三者交叉验证，确保输出版本号与上述完全一致。任何偏差，都意味着后续步骤将进入不可预测的故障域。

3. Ampache 源码级部署与 Apache 深度集成：绕过包管理器的必要性

Ampache 官方并不提供 Ubuntu 的.deb包，其 GitHub Release 页面只提供.tar.gz源码归档。这是刻意为之的设计选择：Ampache 的更新节奏远快于 Linux 发行版的包维护周期，且其配置高度依赖 Web 服务器的具体路径与权限模型。试图通过apt install ampache（如果存在的话）来部署，几乎必然失败，因为包管理器无法理解 Ampache 对config/ampache.cfg.php文件的写入权限要求、对media/目录的递归所有权设定，以及对 ApacheAlias指令的硬编码路径依赖。

正确的做法是进行一次“源码级手工部署”，其核心步骤分为三阶段：解压定位、权限固化、Apache 映射。首先，下载最新稳定版（截至 2024 年，推荐 Ampache 5.6.0）：

cd /tmp && wget https://github.com/ampache/ampache/releases/download/5.6.0/ampache-5.6.0_all.zip unzip ampache-5.6.0_all.zip -d /var/www/ sudo chown -R www-data:www-data /var/www/ampache

这里的关键细节在于chown命令的-R（递归）和用户组www-data:www-data的双重指定。Ampache 的config/目录必须由 Web 服务器进程（即www-data用户）拥有写权限，否则 Web 安装向导无法生成配置文件；同时，media/目录（你存放音乐的地方）也必须归属www-data组，否则 PHP 进程无法读取文件元数据（如 ID3 标签）。我曾在一个部署中遗漏了:www-data组名，导致 Ampache 能显示界面，但扫描音乐库时始终报错Permission denied (code 13)，排查了整整两小时才定位到stat()系统调用失败的根本原因。

第二步是 Apache 的深度集成。Ampache 不是简单的DocumentRoot，它需要 Apache 将/ampache路径下的所有请求，精确路由到其index.php入口文件，并启用mod_rewrite实现友好的 URL（如/album/123而非/index.php?module=album&action=show&id=123）。为此，必须创建一个专用的 Apache 配置文件/etc/apache2/sites-available/ampache.conf，内容如下：

<Directory "/var/www/ampache"> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> Alias /ampache /var/www/ampache <Directory "/var/www/ampache"> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory>

然后启用该站点并重启 Apache：

sudo a2ensite ampache.conf sudo systemctl reload apache2

这个配置的精妙之处在于AllowOverride All。它允许 Ampache 自身的.htaccess文件生效，而 Ampache 的.htaccess文件内嵌了完整的RewriteRule规则集，用于将所有非静态资源请求（.css,.js,.png除外）重写到index.php。如果你错误地使用AllowOverride None，那么 Ampache 的 URL 重写将完全失效，所有链接都会变成 404。这是一个典型的“配置项看起来无关紧要，实则一票否决”的案例。

注意：Ubuntu 18.04 的 Apache 默认禁用mod_rewrite。在执行a2ensite前，必须先运行sudo a2enmod rewrite。否则，即使配置文件语法完全正确，重写功能也不会启动。

4. MySQL 数据库初始化与 Ampache 安装向导的“静默陷阱”

Ampache 的 Web 安装向导（位于http://your-server-ip/ampache/install.php）表面上看是一个图形化流程，但它内部隐藏着多个“静默陷阱”，任何一个未被满足，都会导致安装卡死在“连接数据库”步骤，且页面不报错，只显示空白或无限加载。这些陷阱并非 Bug，而是 Ampache 对 MySQL 服务状态的严格校验逻辑所致。

第一个陷阱是 MySQL 的bind-address配置。Ubuntu 18.04 的 MySQL 默认配置文件/etc/mysql/mysql.conf.d/mysqld.cnf中，bind-address被设为127.0.0.1，这表示 MySQL 只监听本地回环地址。Ampache 的安装向导虽然是通过 Web 浏览器访问，但其 PHP 脚本是在服务器本地执行的，它尝试连接localhost时，PHP 的 MySQL 扩展会优先使用 Unix Socket（/var/run/mysqld/mysqld.sock），而非 TCP/IP。这本身没有问题。但陷阱在于：如果 Ampache 的配置文件中数据库主机名填的是127.0.0.1（而非localhost），PHP 就会强制走 TCP/IP 连接，而此时bind-address的限制就会生效，导致连接超时。解决方案是统一使用localhost作为主机名，或在 MySQL 配置中将bind-address改为0.0.0.0（不推荐，有安全风险）。

第二个陷阱是 MySQL 的sql_mode。Ubuntu 18.04 的 MySQL 5.7 默认启用了严格的 SQL 模式，包括STRICT_TRANS_TABLES和NO_ZERO_DATE。Ampache 的部分建表语句（如CREATE TABLE ... DEFAULT '0000-00-00'）会触发此模式报错，但安装向导不会将此错误透出到前端。你需要在 MySQL 配置文件的[mysqld]段落中，添加一行：

sql_mode = "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

注意：这里移除了NO_ZERO_DATE和STRICT_TRANS_TABLES。保存后重启 MySQL：sudo systemctl restart mysql。

第三个，也是最容易被忽视的陷阱，是 MySQL 用户的权限粒度。Ampache 要求数据库用户必须拥有对目标数据库的ALL PRIVILEGES，而不仅仅是SELECT, INSERT, UPDATE, DELETE。这是因为 Ampache 在首次安装时，需要执行CREATE TABLE,ALTER TABLE,DROP TABLE等 DDL（数据定义语言）操作。如果你用GRANT SELECT,INSERT,UPDATE,DELETE ON ampache.* TO 'ampache'@'localhost';创建用户，安装向导会在创建表时失败，且错误日志只会显示Query failed: CREATE TABLE ...，而不告诉你缺了什么权限。正确的授权命令是：

CREATE DATABASE ampache CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'ampache'@'localhost' IDENTIFIED BY 'your_strong_password'; GRANT ALL PRIVILEGES ON ampache.* TO 'ampache'@'localhost'; FLUSH PRIVILEGES;

执行完以上三步，再访问install.php，填写数据库信息时，主机名填localhost，用户名填ampache，密码填你设置的强密码，数据库名填ampache。向导会自动完成建库、建表、插入初始管理员账户等全部操作。整个过程通常在 30 秒内完成，页面会跳转到登录页，用户名为admin，密码为你在向导中设置的第一个管理员密码。

5. 音乐库扫描的底层机制与 ID3 标签的“黄金标准”

Ampache 的音乐库扫描功能，其性能与准确性完全取决于两个底层要素：PHP 的exec()函数调用外部命令的能力，以及音乐文件 ID3 标签的规范程度。很多人抱怨“扫描半天没反应”或“专辑封面全乱”，问题往往不出在 Ampache 本身，而在这两个环节的配置失配。

首先，Ampache 扫描的核心是调用系统命令find和file。它通过exec("find /path/to/music -type f \( -iname \"*.mp3\" -o -iname \"*.flac\" \) 2>/dev/null")获取所有音频文件列表，再对每个文件执行exec("file -b --mime-type \"$file\"")来判断 MIME 类型。这意味着，www-data用户必须拥有对音乐目录的x（执行）权限，才能cd进入子目录；同时，/usr/bin/file命令必须存在于系统 PATH 中，且www-data用户有执行权限。一个常见的疏忽是：用户将音乐放在/home/user/Music，而/home/user目录的权限是700（仅属主可读写执行），导致www-data根本无法find到任何文件。解决方案是：将音乐目录移到/var/lib/ampache/media，并执行sudo chown -R www-data:www-data /var/lib/ampache/media，然后在 Ampache Web 界面的“管理 > 目录”中，将路径设为/var/lib/ampache/media。

其次，ID3 标签的质量直接决定 Ampache 元数据的丰富度。Ampache 本身不自带标签编辑器，它完全依赖getID3PHP 库解析文件内嵌的 ID3 v1/v2 标签。这个库对标签格式极其敏感。例如，一个常见的问题是：Windows 下用某些播放器（如 Foobar2000）保存的 ID3v2.4 标签，其TXXX（用户自定义帧）可能包含 UTF-16 编码的字符串，而getID3在 PHP 7.2 下默认只支持 UTF-8。结果就是，专辑名、艺人名显示为乱码，或整个文件被 Ampache 忽略。解决此问题的唯一可靠方法，是在扫描前，用命令行工具mid3iconv统一转换所有标签编码：

sudo apt install python-mutagen find /var/lib/ampache/media -name "*.mp3" -exec mid3iconv -e utf-8 {} \;

这条命令会将所有 MP3 文件的 ID3 标签强制转换为 UTF-8 编码，确保getID3能正确解析。对于 FLAC 文件，则使用metaflac：

sudo apt install flac find /var/lib/ampache/media -name "*.flac" -exec metaflac --set-tag=ARTIST="$(metaflac --show-tag=ARTIST {} | cut -d= -f2)" {} \;

（注：此命令仅为示意，实际批量处理需更严谨的 shell 脚本）

最后，关于专辑封面。Ampache 优先读取文件内嵌的APIC帧（ID3v2）或METADATA_BLOCK_PICTURE（FLAC）。如果文件没有内嵌封面，它会尝试在专辑文件夹下寻找cover.jpg或folder.jpg。但这里有一个“黄金标准”：图片文件必须是 JPEG 格式（.jpg），尺寸建议为 300x300 像素，且文件名必须小写。我测试过 PNG 格式的cover.png，Ampache 会静默忽略；大写的COVER.JPG也会被跳过。这个细节在官方文档中并未强调，却是无数用户踩坑的根源。

6. Apache 性能调优与 Ampache 的“零配置”流媒体真相

Ampache 的流媒体能力，其底层完全依赖 Apache 的mod_headers、mod_mime和内核的sendfile()系统调用。这意味着，Ampache 本身没有任何“流媒体服务器”组件，它只是一个智能的“文件分发协调器”。因此，提升 Ampache 的并发播放能力，90% 的工作都在 Apache 的配置优化上，而非 Ampache 的 PHP 设置。

Ubuntu 18.04 的 Apache 默认配置（/etc/apache2/mods-available/mpm_prefork.conf）为：

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxRequestWorkers 150 MaxConnectionsPerChild 0

这个配置在单用户、低并发场景下足够，但当你有 3-4 台设备同时播放不同歌曲时，就会出现明显的延迟和卡顿。根本原因在于MaxRequestWorkers（最大并发请求数）被设为 150，而每个 HTTP 连接（尤其是长连接的音频流）会独占一个 Apache 子进程。当并发流达到 50+ 时，新的连接请求会被排队等待，造成播放器缓冲区耗尽。

最优解是将MaxRequestWorkers提升至 256，并相应调整内存预算。计算依据是：每个 Apache 子进程在 Ubuntu 18.04 + PHP 7.2 下，平均内存占用约为 15MB。256 * 15MB = 3840MB，即约 4GB。如果你的服务器内存 ≥ 4GB，可以安全修改：

MaxRequestWorkers 256 ServerLimit 256

（ServerLimit必须 ≥MaxRequestWorkers，否则 Apache 启动会报错）

另一个关键调优点是KeepAlive。Ampache 的 Web 界面大量使用 AJAX 请求（如点赞、收藏、播放历史），频繁建立/断开 TCP 连接会极大增加服务器负载。将KeepAliveTimeout从默认的 5 秒提升至 15 秒，并启用KeepAlive On，能让一个 TCP 连接复用多次，显著降低 CPU 开销。修改/etc/apache2/apache2.conf：

KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15

最后，关于“零配置流媒体”的真相：Ampache 的流媒体之所以无需 FFmpeg 或其他转码器，是因为它采用的是“直通式”（Passthrough）策略。当用户播放一个 FLAC 文件时，Ampache 不会将其转码为 MP3，而是直接告诉浏览器：“这个文件是audio/flac，请用你原生支持的方式播放”。这要求客户端浏览器必须支持该格式。Chrome 和 Firefox 对 FLAC 支持良好，但 Safari（macOS/iOS）直到 2023 年才原生支持，旧版 Safari 会直接报错。此时，Ampache 的 fallback 机制是：检测到客户端不支持，自动将请求重定向到一个 PHP 脚本play.php，该脚本会调用系统命令flac -c -d "$file"进行实时解码，并将 PCM 数据流式输出。但这会极大增加服务器 CPU 负载。因此，最佳实践是：在 Ampache 管理后台的“管理 > 系统 > 播放设置”中，将“首选流媒体格式”设为MP3，并预先用ffmpeg将所有 FLAC 转为高质量 MP3（CBR 320kbps），这样既能保证兼容性，又能释放 CPU 资源。命令示例：

sudo apt install ffmpeg find /var/lib/ampache/media -name "*.flac" -exec bash -c 'ffmpeg -i "$1" -c:a libmp3lame -b:a 320k "${1%.flac}.mp3" && rm "$1"' _ {} \;

7. 安全加固的四个必做动作：从默认安装到生产就绪

Ampache 默认安装后，是一个功能完整但安全水位极低的 Web 应用。它没有内置的 CSRF 保护、没有速率限制、没有登录失败锁定，其config/ampache.cfg.php文件一旦被 Web 访问，就会直接暴露数据库密码。将它暴露在公网前，必须完成以下四个不可妥协的安全加固动作。

第一，禁用安装向导与调试接口。install.php和debug.php是 Ampache 的后门入口，任何人在知道 URL 的情况下，都可以绕过登录直接重装系统或获取敏感调试信息。最彻底的方法是直接删除它们：

sudo rm /var/www/ampache/install.php /var/www/ampache/debug.php

同时，检查/var/www/ampache/config/目录权限，确保其为750，且属主为root:www-data，这样 Web 进程可读但不可写，防止恶意脚本覆盖配置。

第二，强制 HTTPS 与 HSTS。Ubuntu 18.04 的 Apache 2.4.29 已原生支持 Let's Encrypt 的certbot。执行以下命令一键获取并配置免费证书：

sudo apt install python3-certbot-apache sudo certbot --apache -d your-domain.com

Certbot 会自动修改你的 Apache 配置，添加 301 重定向和 HSTS 头。HSTS（HTTP Strict Transport Security）头至关重要，它告诉浏览器“未来一年内，只允许通过 HTTPS 访问此域名”，从而杜绝了 SSL Stripping 攻击的可能性。

第三，配置 Apache 的访问控制。即使启用了 HTTPS，也应限制 Ampache 的管理后台仅对可信 IP 开放。编辑/etc/apache2/sites-available/ampache.conf，在<Directory>块内添加：

<RequireAny> Require ip 192.168.1.0/24 Require ip 2001:db8::/32 Require local </RequireAny>

这表示，只有来自你家庭局域网（192.168.1.0/24）、IPv6 测试段（2001:db8::/32）或本机（Require local）的请求，才能访问/ampache/admin/管理路径。所有其他请求将收到 403 Forbidden。

第四，启用 Ampache 的内置安全开关。登录 Ampache 后台，进入“管理 > 系统 > 安全设置”，勾选以下三项：

• 启用登录失败锁定：连续 5 次失败后，IP 地址被锁定 15 分钟。
• 启用 Session Cookie 的 HttpOnly 和 Secure 标志：防止 XSS 攻击窃取会话 Cookie。
• 禁用远程 API 密钥生成：除非你明确需要第三方 App（如 Ampache Android 客户端）接入，否则关闭此项，消除一个潜在的攻击面。

这四步做完，Ampache 就从一个“玩具级”应用，蜕变为一个可放心托管在家庭宽带路由器 DMZ 区域的生产级服务。我本人的 Ampache 实例已稳定运行 3 年，期间从未遭遇过一次成功的暴力破解或未授权访问，其安全水位，已远超绝大多数商业 NAS 厂商预装的音乐服务。

8. 日常运维与故障排查：从“扫描卡住”到“播放无声”的实战链路

在 Ampache 的长期使用中，最常遇到的两类问题，其表象相似（Web 界面无响应、播放器显示加载中），但根因截然不同。掌握一套标准化的排查链路，能让你在 5 分钟内定位 90% 的问题，而非盲目重启服务。

问题一：“扫描卡住，进度条不动”。
这不是 Ampache 的 Bug，而是典型的 I/O 阻塞。排查链路如下：

1. 确认进程状态：sudo ps aux | grep "php.*scan"。如果看到大量php /var/www/ampache/modules/scan.php进程，说明扫描正在后台运行，只是速度慢。
2. 检查磁盘 I/O：iostat -x 1。观察%util列，如果持续 >95%，说明磁盘是瓶颈。此时应停止扫描，检查是否有其他进程（如updatedb）在争抢 I/O。
3. 检查文件权限：sudo -u www-data ls -la /var/lib/ampache/media/。如果输出Permission denied，说明www-data用户无权读取目录，需执行sudo chown -R www-data:www-data /var/lib/ampache/media。
4. 检查大文件：find /var/lib/ampache/media -size +500M -ls。Ampache 对 >500MB 的单文件（如无损整轨 ISO）扫描极慢，建议将其从扫描路径中排除，或在 Ampache 后台的“管理 > 目录”中，为该路径单独设置“不扫描”。

问题二：“点击播放，进度条走，但无声”。
这是 MIME 类型配置错误的典型症状。排查链路如下：

1. 检查浏览器开发者工具（Network Tab）：播放时，找到对应.mp3文件的请求，查看其Response Headers中的Content-Type。如果是text/html或application/octet-stream，说明 Apache 未正确识别文件类型。
2. 验证 Apache MIME 配置：grep -r "audio/mpeg" /etc/apache2/。应看到/etc/mime.types中有audio/mpeg mp3行。如果没有，手动添加。
3. 强制刷新 MIME 缓存：sudo systemctl reload apache2。Apache 不会自动重载/etc/mime.types，必须重启或重载。
4. 终极验证：在服务器上执行curl -I http://localhost/ampache/media/01.mp3，检查返回头中Content-Type: audio/mpeg是否存在。如果存在，问题在客户端（如浏览器缓存了错误的 MIME）；如果不存在，问题在 Apache 配置。

这套链路的价值在于，它不依赖 Ampache 的日志（其日志级别默认较低，且不记录 MIME 错误），而是从网络协议栈的最底层（HTTP 响应头）开始向上追溯，确保每一步都有可验证的证据。我在帮朋友远程排障时，就是靠curl -I这一条命令，在 2 分钟内确认了是 Apache 的 MIME 配置缺失，而非 Ampache 代码问题，避免了数小时的无效调试。

最后分享一个小技巧：Ampache 的所有操作日志（包括扫描、播放、登录）都记录在/var/log/apache2/ampache_access.log和/var/log/apache2/ampache_error.log中。但默认情况下，Apache 不会为 Ampache 创建独立日志文件。你需要在/etc/apache2/sites-available/ampache.conf的<VirtualHost>块内，手动添加两行：

CustomLog ${APACHE_LOG_DIR}/ampache_access.log combined ErrorLog ${APACHE_LOG_DIR}/ampache_error.log

然后sudo systemctl reload apache2。从此，所有 Ampache 相关的请求和错误，都会被隔离记录，极大提升排障效率。