存储型 VPS 能运行媒体服务器吗？

存储型 VPS 能运行媒体服务器吗？

存储型 VPS 可以运行媒体服务器；对于直接播放，通常运行良好。限制通常来自转码：按磁盘容量销售的方案，其 CPU 足以读取文件并将文件发送出去，但通常远远不足以在有人观看时重新编码高码率文件。原样发送字节的开销很低，重写每一帧则不同。

以下 3 个限制决定了你的媒体库是否适用，而且它们会按固定顺序出现。

1. CPU。当客户端无法按文件当前的存储格式直接播放时，CPU 会立即成为限制。
2. 磁盘。它很少会阻止播放，但会使媒体库扫描变得缓慢；视频本身画面正常时，Web 界面也可能响应迟缓。
3. 网络端口。这是真正的上限，也是你在支付任何费用前就能通过计算得出的限制。

按这个顺序逐项检查。最后一项是算术问题，因此它能给出明确答案，而不是主观判断。

存储型 VPS 实际提供什么

在存储型 VPS 上，磁盘才是主要产品。您购买的是普通计算型方案无法匹敌的低价 TB 存储空间，而与这些存储空间配套的 CPU、内存和网络资源，主要用于确保文件安全且可读。低价 TB 存储空间是购买这类 VPS 的充分理由，但不能据此期待它能胜任转码服务器的工作。

方案页面上的两个数字决定了后续的大部分使用体验：端口速度和每月流量额度。请查看当前页面，确认您准备购买的具体方案。不要直接采用评测、论坛帖子或其他供应商页面中的数值，因为在同一页面的各项参数中，这两个数值在不同方案之间的差异通常最大。存储型 VPS 相比普通 VPS 放弃了什么介绍了这项取舍的其他方面，仔细阅读低价 VPS 方案说明则介绍了如何识别隐藏限制的措辞。

限制一：为什么转码是 CPU 瓶颈

媒体服务器向播放器传送文件时，有三种方式。

• 直接播放。 服务器按原样发送文件，由客户端解码。服务器只需从磁盘读取并写入套接字，因此单个 vCPU 就能支持多个流。
• 直接串流，也称为重封装。 服务器重写容器，并逐帧复制视频。开销很小。
• 转码。 每一帧都会被解码，再按新的编码格式或比特率重新编码。开销很大，而且每个流都要重复执行。

转码方式不是由您选择的，而是由客户端选择。出现以下任一情况时，客户端会强制转码。

• 客户端无法解码该编码格式。旧版浏览器无法解码 HEVC（高效视频编码）就是常见情况。
• 字幕轨道是图像而不是文本，例如 Blu-ray 转录文件中的 PGS。字幕必须绘制到画面中，视频也必须围绕字幕重新编码。
• 客户端要求的比特率上限低于文件比特率。使用移动数据的手机默认就可能如此。
• 容器格式无法打开。

请测量您自己的服务器，不要只根据 CPU 型号判断。选择媒体库中负载最高的文件，编码其中两分钟。

ffmpeg -hide_banner -y -i /path/to/movie.mkv -map 0:v:0 -c:v libx264 -preset veryfast -b:v 4M -t 120 -f null -

输出的最后一行以 speed= 字段结尾。speed=1.0x 表示服务器每经过一秒实际时间，就能生成一秒视频，也就是只能支持一个流且没有余量。播放并不是稳定的持续负载：每次跳转都会丢弃编码器已生成的内容并重新开始，因此测得性能低于约 2x 的服务器在正常使用时会反复缓冲。两个并发转码任务大约需要测试值的两倍性能。4K 源文件的实际负载高于该比例所显示的程度，因为编码器开始工作前，解码端的负载就已经随像素数量增长。

然后检查是否有硬件加速可用。

ls -l /dev/dri

在大多数 VPS 方案上，该命令会输出 ls: cannot access '/dev/dri': No such file or directory，因为没有 GPU 直通给虚拟机。没有对应的设备节点，VAAPI（视频加速 API）和 Intel Quick Sync 就无法访问硬件，因此所有转码都会落到 CPU 上。配备 NVIDIA GPU 的服务器上的硬件转码属于另一种价格的不同服务器，应将其视为单独的选择，而不是当前方案的升级路径。

解决这一限制的方法是避免转码。将 H.264 存储为 MP4 或 MKV，将字幕保留为文本，使其与视频并行传输，而不是烧录到画面中，并在每个屏幕上安装能够解码所存格式的客户端应用。这样 CPU 负载会接近于零，问题就转移到了端口上。如果媒体库尚未建立，请从在 VPS 上逐步安装 Jellyfin开始。

限制二：共享磁盘或机械硬盘的实际成本

播放文件时，读取是按照文件码率顺序进行的。25 Mbps 的重混流约为 3.1 MB/s。一块速度较慢的机械硬盘进行顺序读取时，速度也能达到这个数值的 40 倍，因此磁盘通常不会在播放环节成为瓶颈。

磁盘的瓶颈在于小块随机操作，而媒体服务器会执行大量此类操作。首次扫描媒体库时，系统会打开每个文件并读取其文件头。生成预览缩略图时，系统会解码分散在整个文件中的帧，这些缩略图会在拖动进度条时显示。这属于寻道，而不是流式读取。媒体库数据库使用 SQLite；在 Debian 和 Ubuntu 软件包中，数据库位于 /var/lib/jellyfin/data/library.db。每次更新最后都会执行 fsync，等待存储设备确认写入完成。

如果卷与其他租户共享，这些 fsync 操作会排在其他用户的任务后面。其表现很明确，但很容易误判：电影播放完全正常，而 Web 界面需要几秒才能显示页面。这不是网络问题，也不是 CPU 问题，而是数据库在等待磁盘。

请在实际存放媒体的目录中，同时测试这两种访问模式。

sudo apt install -y fio
fio --name=seq --rw=read --bs=1M --size=2G --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting
fio --name=rand --rw=randread --bs=4k --size=1G --iodepth=32 --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting

顺序读取结果表示磁盘可以同时支持多少路流。随机读取结果表示扫描一万个文件需要多长时间。如果 fio 返回 OS does not support direct IO，请删除 --direct=1，并注意此时页面缓存已经影响了结果。删除它生成的 seq.0.0 和 rand.0.0 文件。存储 VPS 应达到的磁盘速度介绍了这些数值的基本范围，可重复的 VPS 基准测试方法则可以让不同服务器上的测试结果保持可比。

还有一个设置比其他设置更重要：转码临时目录不能位于存储卷上。转码过程中，系统会在观看期间持续写入 HLS（HTTP 实时流）分片。对于速度较慢或远程存储，这些写入可能滞后，导致播放器卡顿，即使 CPU 仍有空余。请在播放设置中将该目录指向本地磁盘。

限制三：端口，以及决定结果的计算

[
  {
    "label": "1080p web rip (H.264)",
    "bitrate_mbps": 5,
    "gb_per_hour": 2.25,
    "streams_per_gigabit": 200
  },
  {
    "label": "1080p Blu-ray remux",
    "bitrate_mbps": 25,
    "gb_per_hour": 11.25,
    "streams_per_gigabit": 40
  },
  {
    "label": "4K HDR remux",
    "bitrate_mbps": 60,
    "gb_per_hour": 27,
    "streams_per_gigabit": 16
  },
  {
    "label": "Transcoded 1080p output",
    "bitrate_mbps": 4,
    "gb_per_hour": 1.8,
    "streams_per_gigabit": 250
  }
]

这些是各类文件通常发布时使用的比特率，并不是任何服务商套餐的实测值。规则只有一条：并发流数量乘以比特率，必须低于端口速度。1080p 网页片源的比特率为 5 Mbps，按理论值计算，千兆端口可承载 200 路流。Blu-ray 重封装的比特率为 25 Mbps，可承载 40 路流。4K HDR 重封装的比特率为 60 Mbps，可承载 16 路流；这相当于一个家庭中两台电视同时播放，就会占用千兆端口的大部分带宽。

理论数值偏乐观，原因有两个。协议开销和共享上行链路会占用一部分带宽，而这部分通常不可见。更大的影响来自缓冲：直接播放客户端不会按照文件比特率持续接收数据，而是以链路允许的最大速度提前读取，然后暂停接收。因此，一个人开始播放电影时，端口可能会在数秒内达到饱和。规划时应按远低于理论数值的一半计算。

流量额度是另一项限制，也是家庭用户首先触及的限制。端口速度限制同时观看的人数。流量额度限制整个月的观看总量。

[
  {
    "label": "One stream, 1080p at 5 Mbps, 2 h a day",
    "hours_per_month": 60,
    "gb_per_month": 135
  },
  {
    "label": "Two streams, 1080p at 5 Mbps, 3 h a day",
    "hours_per_month": 180,
    "gb_per_month": 405
  },
  {
    "label": "Two streams, 1080p at 5 Mbps, 6 h a day",
    "hours_per_month": 360,
    "gb_per_month": 810
  },
  {
    "label": "Two streams, remux at 25 Mbps, 6 h a day",
    "hours_per_month": 360,
    "gb_per_month": 4050
  }
]

两个人在普通晚间以 1080p 观看内容，一个月的流量为 810 GB，共计 360 小时的流媒体播放。保持观看时长不变，将媒体库换成 Blu-ray 重封装后，相同的 360 小时将产生 4050 GB 流量，接近 4 TB。你存储内容时使用的比特率，就是你需要支付的流量成本；在这项计算中，这是唯一完全由你控制的变量。

查看套餐页面中的流量额度，再确认超出额度后的处理方式。有些套餐会降低端口速度，有些套餐会对超出部分收费。还要单独确认入站流量是否计入额度，因为填充媒体库会产生一次大规模上传，而不同套餐对这类流量的计量方式不同。

拆分方案：存储盒运行媒体库，性能较强的盒运行应用

可行的方案不是使用一台机器。媒体文件存放在存储 VPS 上。媒体服务器应用、数据库、元数据图片和转码目录存放在一台配备本地 NVMe 的小型高性能 VPS 上。应用通过私有网络挂载媒体库，支持直接播放的文件则原样发送。

使用自动挂载单元，而不是启动时挂载。

10.0.0.10:/srv/media  /mnt/media  nfs4  rw,hard,noatime,rsize=1048576,wsize=1048576,noauto,x-systemd.automount  0 0

noauto,x-systemd.automount会在首次访问时挂载共享目录，而不是在启动时挂载。因此，短暂无法访问的存储盒只会延迟一次目录列表操作，不会阻塞系统启动。使用 findmnt /mnt/media 检查挂载状态，然后使用 sudo -u jellyfin ls /mnt/media 确认服务账户可以读取该目录。若服务账户收到 permission denied，而 root 可以正常列出同一路径，这是用户 ID 不匹配导致的：NFS 比较数字 ID，因此 jellyfin 用户在两台机器上必须使用相同的 UID；默认的 root_squash 导出选项会将 root 映射为 nobody。

数据库应保存在本地磁盘上。SQLite 依赖文件锁，而网络文件系统无法可靠提供这种锁，出现故障时也不会给出明确的错误信息。并发访问时会出现 database is locked，发生不适当的崩溃后会出现 database disk image is malformed；到那时，媒体库就需要从备份恢复。数据库很小，因此在这里使用本地磁盘不会增加实际成本。

下载目录和媒体库应位于同一文件系统中。导入操作如果可以使用硬链接，就能立即完成，而且不占用额外空间。跨两个文件系统导入时，必须完整复制文件；如果目标是网络挂载目录，文件会无必要地跨网络传输两次。实际部署中，这意味着应在存储盒上、文件所在位置旁运行 Docker Compose 中的 arr 套件，只有媒体服务器通过挂载目录读取文件。

这种拆分方案的实际成本是多经过一跳网络。应用从私有链路读取流，然后从应用盒的端口发送出去，因此字节会跨越网络两次，第二次传输会计入流量费用。当两台机器位于同一地点的私有网络中时，第一跳通常速度较快，而且通常不收费。当两台机器不在同一地点时，流量会产生双倍费用，每次拖动播放进度时都能感受到延迟。购买任一台机器前，先确认两台机器可以放置在同一地点。将存储 VPS 与主 VPS 配对会详细介绍挂载和网络配置。

家用 NAS 才是合理选择的情况

如果所有观看者都住在同一所房子里，服务器就应该放在家中。本地网络可提供 1 Gbps 或更高带宽，没有流量计费，也没有月租；播放 4K 重混流时无需计算码率，运行成本只有电费。当您需要在家外观看、与其他家庭的人共享内容、家庭上行带宽连一条视频流都无法承载，或不想让家中设备持续运行时，VPS 才值得使用。请先检查上行带宽：码率为 25 Mbps 的重混流，需要的上行容量可能超过许多家庭网络所能提供的容量。

如果最终选择 NAS，存储 VPS 仍有值得付费的用途。为媒体库保留异地副本，正是廉价大容量存储的适用场景；将 VPS 用作异地备份目标所需的流量只是在线播放的一小部分，因为备份每个文件只需传输一次，而不是每次观看都传输一次。请根据对所需存储空间的真实估算确定容量，不要直接向上取整；在承诺购买一年服务前，先按照存储 VPS 检查清单验证方案。

还有一点与硬件无关：租用服务器后，您需要根据服务商条款对所提供的内容负责。请仅提供您有权提供的内容。

FAQ

存储型 VPS 能将 4K 转码为 1080p 吗？

通常无法实时转码。对 4K 源进行软件编码时，编码器启动前需要解码的像素数量约为 1080p 文件的 4 倍，而容量型方案分配的 vCPU 份额无法满足这一需求。不要凭猜测判断，请进行测试：运行 ffmpeg -hide_banner -y -i /path/to/movie.mkv -map 0:v:0 -c:v libx264 -preset veryfast -b:v 4M -t 120 -f null -，然后读取末行的 speed= 字段。低于 1.0x 时，流完全无法跟上；低于约 2x 时，观看者拖动进度后会重新缓冲。还要运行 ls -l /dev/dri。如果返回 No such file or directory，说明 guest 中没有 GPU，因此该方案无法使用硬件编码。

千兆端口能承载多少路流？

用端口速度除以所提供文件的码率。对于码率为 5 Mbps 的 1080p 网络片源，理论上可承载 200 路流；对于码率为 60 Mbps 的 4K HDR 重封装文件，则为 16 路。实际规划时应明显低于这些数值。端口由多个连接共享，协议开销也会占用带宽。直接播放客户端还会以链路允许的速度提前缓冲，而不是按文件码率匀速读取，因此单个观看者开始播放电影时，可能在几秒内占满整个端口。

在拆分部署中，媒体服务器数据库应放在哪里？

应放在运行应用的机器的本地磁盘上，不能放在网络挂载中。SQLite 依赖文件锁，而网络文件系统不一定能可靠提供文件锁，因此将数据库放在 NFS 共享上会在高负载下产生 database is locked 错误，并在异常崩溃后产生 database disk image is malformed。在 Debian 和 Ubuntu 软件包中，文件位于 /var/lib/jellyfin/data/library.db。元数据图片和转码目录也应保存在本地，只通过挂载访问媒体文件。

转码是否比直接播放占用更少带宽？

是的，但这就是需要权衡的地方。直接播放会以文件存储时的码率发送文件，因此每个观看者播放 25 Mbps 的重封装文件时，都会占用 25 Mbps 的出站流量。将同一部电影转码为 4 Mbps 后，千兆端口才能承载 250 路流。节省的带宽需要以 CPU 资源换取，并且每路流都要消耗 CPU；而 CPU 正是存储型方案缺少的资源。如果直接将文件存储为客户端可接受的码率，就能免费获得同样的带宽节省。

我应该使用家中的 NAS，而不是存储型 VPS 吗？

如果所有观看者都在家中，应该使用 NAS。本地网络没有流量计费，也没有月度账单，因此码率完全不再是限制因素。当你需要从家外观看，或需要与其他家庭共享时，VPS 更合适。多数情况下，决定因素是家庭网络的上行带宽：许多连接甚至无法同时向上游传输一条 25 Mbps 的重封装流。两者也可以配合使用：由 NAS 为家中设备提供服务，由存储型 VPS 保存异地副本。