1. 先把问题说清楚Server上“播放视频”和“显示网页”其实是两件事我见过太多朋友第一次接触 Ubuntu Server 时被这个标题搞晕。一台默认连桌面环境都没有的服务器怎么“播放视频”怎么“显示网页”两句话听起来像两个独立需求但实际操作中它们往往是一件事的两种表达把服务器变成一台能出画面、能出声音的媒体设备或者变成一台能通过浏览器远程看视频的网页服务。本文把这整条链路拆开讲清楚并给出可复现的部署过程。先说结论Ubuntu Server 本身不提供图形界面想让它“播放视频”要么你给它接显示器再装一套播放器要么你让视频文件通过网络以网页形式输出用户在任意设备的浏览器里打开一个地址就能播放。第二种才是绝大多数人的真实诉求——比如家里闲置的旧电脑装 Ubuntu Server想当成家庭媒体中心比如公司内网的服务器需要提供培训视频点播比如开发环境里要快速验证一段视频能不能被网页正常拉流播放。而且顺着“播放视频”这个需求的延伸你会不可避免地碰到 nginx、nodejs、HTML5 video 标签、m3u8 切片、转码、硬解这些词这些都是同一个生态里的东西。顺便提一句很多人在搜索“ubuntu server 播放视频显示网页”时其实真正想要的是“我做了一个网页里面嵌了视频放到 Ubuntu Server 上之后怎么让访问者能看到”。这个问题就不是播放器的问题了而是 Web 服务配置和视频流格式的问题。1.1 无头服务器为什么不能直接“看”视频大多数 Ubuntu Server 安装完的状态是没有桌面、没有 HDMI 输出渲染、连声卡都可能没被初始化。运行一个startx都会直接报错更别说双击打开一个 mp4 文件。很多新手在这里会卡很久以为是自己装错了版本。根本原因在于服务器版的定位它被设计用于长期运行服务而不是交互式操作。图形界面相关组件默认不安装连显卡驱动都不一定加载。这带来一个很实际的影响你需要明确自己的目标模式。模式A本地播放。服务器本身接了一台显示器你在服务器上操作界面播放视频。这种情况建议直接装桌面版或者补装一个轻量桌面环境。模式B远程网页播放。服务器只负责通过网络提供视频内容用户在自己电脑或手机浏览器里打开网页观看。这是绝大多数实际需求。模式C两者结合。服务器接显示器但只显示一个自动打开的网页全屏循环播放视频相当于一个“信息发布终端”。本文主要围绕模式B和模式C展开因为模式A直接装桌面版就行没什么好讲的。1.2 整个技术链路的真实形态媒体服务 Web前端理清需求后你会发现真正要构建的是一条媒体链路而不是装一个“万能视频播放器”。这套链路从下往上看是三层第一层是媒体源。也就是你的视频文件放在服务器的哪个目录权限对不对文件名有没有中英文问题视频编码是 H.264、H.265 还是老旧的 MPEG-4。这些因素直接决定后续步骤的复杂程度。第二层是媒体服务。它负责把视频“喂”给浏览器。最简单的做法是用 nginx 直接把 mp4 文件当静态资源提供进阶做法是用 nginx 的 HLS 模块把视频切片成 ts 文件浏览器端通过 m3u8 播放列表拉流更彻底的做法是上 Jellyfin、Emby 这类媒体服务器它们自带转码能力能把不兼容的视频格式实时转换成浏览器能播的格式。第三层是 Web 前端。一个最简单的 HTML 页面里放一个video标签src指向服务器上的视频地址就完成了“显示网页”的使命。别小看这一步自动播放策略、跨域问题、浏览器对视频格式的支持范围都会在这一层暴露。2. 先从本地把视频播起来无桌面环境下的播放器选型不管最终目标是网页播放还是本地输出我都推荐先在服务器上把视频“播出声”一次。这么做不是为了追求播放本身而是为了验证底层依赖缺失了哪些。比如编解码器、显卡驱动、音频服务这些缺了任何一个网页流程里迟早会给你脸色看。2.1 三种播放器怎么选ffplay、mpv、Chromium在无桌面环境下常用的本地播放工具有三个我分别给你它们的定位和典型使用场景ffplayFFmpeg 自带的播放器参数简单适合快速验证一个视频能不能正常解码。它不做任何界面美化输出直接刷新到命令行窗口配合 SDL 渲染画面。在服务器场景里它是调试第一工具。mpv更现代的命令行播放器支持硬件解码、各种滤镜、脚本扩展。它也有自己的 OSC 界面比 ffplay 好用而且对 H.265 的支持更好。需要输出到真实显示器时首选。Chromium 无头模式或 kiosk 模式这不是用来“播放本地视频文件”的而是用来“显示网页”的。你可以让 Chromium 启动后自动打开一个指向本机 nginx 的页面页面里嵌一段视频最终效果就是服务器接的显示器上出现了一个自动播放视频的网页。这个方案常被用在数字标牌、信息发布屏上。另外还有一个容易混淆的点Node.js 本身不能播放视频但可以用它快速起一个 HTTP 服务把视频文件从磁盘流传出去浏览器拿到流自己解码。所谓“nodejs播放视频”本质上是“nodejs搭建视频服务”。它跟 nginx 静态文件服务的区别在于Node.js 方案更容易嵌入业务逻辑比如按用户权限过滤视频、动态拼接视频列表但性能和稳定性不如 nginx。2.2 本地播放实测从装包到出画面的每一步我在一台干净的 Ubuntu Server 22.04 上做了完整实测。这台机器没有安装任何桌面环境只有一个 4K 显示器通过 HDMI 接着这个条件在服务器场景里已经算“豪华”了很多人连显示器都不接。第一步是安装基础工具。apt install ffmpeg mpv vlc一条命令装上 FFmpeg、mpv 和 VLC 备用。装完后先用一个测试视频验证解码链路ffprobe /data/videos/sample.mp4这个命令输出视频的编码格式、分辨率、码率、音频轨道信息。如果输出里出现Video: h264 (High)或者Video: hevc说明文件本身没问题。如果报错找不到解码器说明你装的 FFmpeg 版本太老或缺少对应扩展仓库。第二步是试着播放。直接执行ffplay -fs /data/videos/sample.mp4这个场景下如果屏幕没有反应先别急着怀疑播放器。大概率原因有两个一是当前用户没有权限访问显卡驱动节点/dev/dri二是没有初始化图形会话。服务器初始状态连DISPLAY变量都不存在播放器根本不知道往哪输出画面。解决办法是给当前用户加入 video 组并设置自动登录和图形会话。在/etc/gdm3/custom.conf或者/etc/lightdm/lightdm.conf里启用自动登录然后安装一个轻量窗口管理器apt install lightdm xserver-xorg-video-intel重启后如果显示器能出现登录界面再切换到 tty 终端执行export DISPLAY:0然后重新运行 ffplay。这次应当能看到视频窗口。这一步实测中最大的坑是即使你装了轻量桌面startx在部分服务器内核上也会因为缺少 firmware 文件报错干脆用 lightdm 的自动登录最省事。2.3 无显示器时怎么验证播放成功如果服务器没有接显示器也不用灰心。可以用 Xvfb 建立虚拟屏幕再用 VNC 远程查看画面。这套组合是服务器排障的经典方案我验证码率、字幕加载、颜色空间这些细节时经常用。apt install xvfb x11vnc mpv Xvfb :1 -screen 0 1280x720x24 export DISPLAY:1 mpv --vox11 /data/videos/sample.mp4 x11vnc -display :1 -forever -shared -rfbauth ~/.vnc/passwd用 VNC 客户端连上 5900 端口就能看到 mpv 渲染出来的画面了。这一步的意义在于它验证了视频解码、音频输出、颜色渲染这条链路是完整的后面网页播放环节无论出什么问题你都能确认问题不在源文件和解码器层。3. 网页显示的核心环节让浏览器能把视频拉起来“显示网页”这件事落到实际操作上就是服务器上跑一个 Web 服务浏览器访问某个 URL回车页面上出现一个视频播放器点播放按钮画面出来。这里面有三个关键点静态文件服务怎么配、视频流怎么给、浏览器策略怎么绕过。3.1 最简单的方案nginx 静态目录 HTML video 标签如果你视频文件是 mp4 且编码为 H.264浏览器原生就能播放不需要任何转码。此时 nginx 只做一件事把视频目录暴露出去。server { listen 80; server_name video.example.internal; root /data/videos; autoindex on; autoindex_exact_size off; autoindex_localtime on; location /videos/ { alias /data/videos/; add_header Accept-Ranges bytes; add_header Cache-Control no-transform; } }这里有两个细节容易踩坑。第一个是alias的路径末尾必须带/否则 nginx 会把 URL 路径直接拼在 alias 后面导致文件查找失败。第二个是Accept-Ranges bytes响应头nginx 默认就会加但如果你用了add_header覆盖了全局配置要确保没有把它挤掉。Range 请求是浏览器拖进度条的根基没有它视频只能从头播到尾用户一拖进度条整个播放器就卡死。前端页面极度简单一个文件搞定!DOCTYPE html html body video controls autoplay muted width1280 height720 source src/videos/sample.mp4 typevideo/mp4 /video /body /html把这段存成/data/www/index.html浏览器打开http://服务器IP/就能看到播放器。这里有个规律muted属性加上后 autoplay 才能生效这是 Chrome 的自动播放策略。如果你不加 muted页面打开后视频是不动的必须手动点一下播放按钮很多新手在这里误以为 nginx 没配对。3.2 需要拖进度条和兼容老格式时HLS 切片方案mp4 直接播放解决不了两个问题一是视频文件特别大比如几个 GB 的超清资源浏览器需要支持 Range 请求才能随机拖动od HTML5 播放器对这个支持还算好但部分播放器插件不支持二是视频编码不是 H.264比如很多设备拍出来的是 H.265Chrome 和 Firefox 默认都不支持点开页面直接黑屏。这时候要用 HLS 协议。HLS 的原理简单说就是把视频切成一小段一小段的 ts 文件一般每段两到十秒再生成一个 m3u8 播放列表文件。播放器拿到 m3u8一个一个地拉取 ts 分段来播。这样做的另一个好处是支持“直播式”的视频流很多监控摄像头的流就是这个格式你用播放器打开 CCTV 之类的直播 m3u8 地址时画面花屏往往就是切片参数和你播放器不对付。手动切片的命令是这样的ffmpeg -i /data/videos/sample.mp4 \ -codec: copy -start_number 0 -hls_time 10 \ -hls_list_size 0 -hls_segment_filename /data/www/hls/segment_%04d.ts \ /data/www/hls/playlist.m3u8如果不想每次手动切片可以装 nginx 的 rtmp 模块或者用 ffmpeg 常驻服务实时转码。但小规模自用场景我更推荐一次性切片到位因为切片后的目录结构固定nginx 配置简单访问压力也小。切片完成后网页里把 video 标签的 src 指向.m3u8文件即可。如果浏览器不支持 m3u8 原生播放需要引入 hls.js 播放器库在页面里写几行 JavaScript 加载它具体代码网上很多不多赘述。3.3 跨域、端口、文件权限三个最隐蔽的坑网页显示视频时最常见的三个隐蔽问题我逐个说清楚。跨域问题。前端页面在 80 端口视频文件在 8080 端口浏览器会认为这是两个不同的源。如果 nginx 默认不返回Access-Control-Allow-Origin播放器在拉取分片时会被 CORS 策略拦下来表现就是视频转圈圈但不播放。解决办法是在 nginx 配置里加一行add_header Access-Control-Allow-Origin *;端口问题。如果只监听 80 端口一切正常如果你为了调试临时用了 8080 或者其他端口记得防火墙放行。Ubuntu Server 默认 ufw 状态可能是开着的不开端口怎么都访问不到。ufw allow 80/tcp ufw allow 443/tcp文件权限问题。nginx 以 www-data 用户运行视频目录权限必须保证该用户可读。我见过很多次chmod 777依然打不开的因为父目录的x权限丢了。快速排障命令namei -l /data/videos/sample.mp4输出每一级路径的权限归属一眼看出哪一层卡住。4. 升级做法Jellyfin 媒体服务器解决“多格式、多端、转码”痛点nginx 加 HTML 的方案适合视频文件不多、格式较统一、用户就是你自己。一旦家里或者团队里设备多了有人用手机、有人用电视、有人用 iPad不同设备对视频格式支持差异很大你会被 H.265 和 H.264 之间谁是默认格式的问题搞得焦头烂额。这时直接上 Jellyfin 这类现成媒体服务器能省下非常多时间。4.1 Jellyfin 的部署和使用逻辑Jellyfin 是开源免费的媒体服务器它的核心价值在于自动扫描你的视频目录把视频信息整理成媒体库自带 Web 管理界面和播放页面内置 FFmpeg能实时转码成目标设备支持的格式还支持外挂字幕、多音轨、倍速播放这些细节功能。安装不算复杂curl -fsSL https://repo.jellyfin.org/ubuntu/jellyfin_team.gpg.key | gpg --dearmor -o /etc/apt/trusted.gpg.d/jellyfin.gpg echo deb [signed-by/etc/apt/trusted.gpg.d/jellyfin.gpg] https://repo.jellyfin.org/ubuntu $(lsb_release -cs) main | tee /etc/apt/sources.list.d/jellyfin.list apt update apt install jellyfin装完访问http://服务器IP:8096跟着向导添加媒体库把视频目录指过去Jellyfin 会自动生成海报墙。之后所有设备访问同一个地址服务器端根据设备类型决定是直接推流还是转码。值得说明的是Jellyfin 默认自带了一个精简版网页服务不再依赖 nginx。但如果你的服务器前面还有一层域名和 HTTPS 证书建议用 nginx 反向代理一下 8096 端口这个属于常规操作。4.2 为什么我推荐小规模自用先跑 Jellyfin我给朋友部署过多次家庭媒体中心经验是如果就一台 Ubuntu Server视频文件就几十部电影直接 Jellyfin 起步别从 nginx 静态文件方案开始折腾。原因有三点第一Jellyfin 自动转码解决格式兼容问题。你下载一部 H.265 10bit 的片子用 nginx 方案投到电视上电视播放器大概率黑屏没声音。Jellyfin 检测到设备不支持 H.265会自动转成 H.264虽然 CPU 占用高一点但至少能看。第二Jellyfin 的播放进度同步功能其实挺实用。你在客厅看了一半回卧室打开同一部电影问你“继续观看还是从头播放”这个体验对比静态页面的裸播差距太明显。第三它自带多用户管理。家里人多的情况下可以给每个人开账号控制谁能看哪些内容。静态 nginx 方案做不到这层控制。4.3 用 Node.js 快速搭一个极简播放页的场景有一种需求介于“静态 nginx”和“完整 Jellyfin”之间你有一个业务系统本身基于 Node.js 开发现在要在某个页面上嵌入一段视频。这种情况再起一个 nginx 服务很笨直接在 Node.js 里用express.static挂载视频目录就行const express require(express); const path require(path); const app express(); const port 3000; app.use(express.static(path.join(__dirname, public))); app.use(/videos, express.static(/data/videos, { setHeaders: (res) { res.setHeader(Accept-Ranges, bytes); res.setHeader(Cache-Control, no-transform); } })); app.listen(port, () { console.log(Media web server running at http://0.0.0.0:${port}); });这个方案能满足动态鉴权需求比如只允许登录用户访问视频。原理上依然是静态文件服务只是从 nginx 换成了 Node.js。别再搜什么“nodejs播放视频”的库了Node.js 不参与解码它只负责把文件流传出去。5. 硬解、软解、转码服务器端最容易被忽略的瓶颈网页播放方案部署完成后最常见的性能问题是 CPU 占用率飙高。这里面的根本原因需要分角色看如果视频直接以原始文件形式发给浏览器那么解码工作全部在客户端设备服务器只承担文件传输CPU 占用几乎可以忽略。如果客户端设备不支持某种编码格式服务器需要先转码再发送这才会消耗大量 CPU。5.1 软解与硬解的适用边界FFmpeg 转码默认走软件解码和软件编码纯靠 CPU 算。一台普通的四核服务器转 1080p H.265 到 H.264 时 CPU 占用基本 100%而且可能只有十几帧的实时转码速度播放会卡。如果服务器有 Intel 核显并支持 Quick Sync可以开启硬解硬编转码速度能快很多倍CPU 占用大幅下降。启动硬解需要装对应驱动以最常见的 Intel Quick Sync 为例apt install intel-media-va-driver-non-free vainfo vainfo看到输出里有H264和HEVC编码支持说明硬解路径已就绪。Jellyfin 里配置转码时勾选硬件加速即可。nginx 方案的转码一般用 ffmpeg 命令行示例如下ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \ -i input.mp4 -c:v h264_vaapi -b:v 2M -c:a aac output.mp4从实践看硬解不是没有代价。首先是稳定性部分驱动版本在转码长视频时可能崩溃表现为输出文件突然中断或花屏其次是画质硬编码的压缩效率在同等码率下比软件编码略差新闻资讯类视频无所谓纪录片、球赛这种高动态画面能看出区别。所以我的经验是服务器 CPU 强就软编CPU 弱就硬编画质优先级低于流畅度。5.2 浏览器端的硬解与服务器无关很多文章讲“Chrome 视频硬解”那是客户端浏览器的事跟服务器端没有任何关系。浏览器能不能硬解取决于用户设备的显卡、浏览器设置、以及视频编码是否匹配。服务器唯一能做的就是选择浏览器兼容性最好的视频编码。H.264 是全设备的“公约数”H.265 虽然体积小一半但 Safari 支持、Chrome 部分版本支持、Firefox 默认不支持所以做分享场景时优先 H.264。5.3 转码参数怎么给才不卡转码不是参数越多越好我提供一组经过多次实测的保守参数组合适合大多数 1080p 视频转码ffmpeg -i input.mp4 \ -c:v libx264 -preset veryfast -crf 23 \ -vf scale-2:720 \ -c:a aac -b:a 128k \ -movflags faststart \ -threads 0 output.mp4-preset veryfast牺牲一点压缩率换速度-crf 23是 H.264 的默认质量档画质损失不明显-vf scale-2:720把视频压到 720p 播放码率需求降低网页加载更快-movflags faststart把 moov 原子信息挪到文件头部浏览器打开视频时不用等待整个文件加载就能快速起播。最后这条对网页播放体验的影响是最直观的不加的话大文件在浏览器里点开往往要转圈很久才能出现画面。6. 从零到网页播放的完整部署流程一台全新 Ubuntu Server 的实操记录理论部分讲了不少下面把我最近一次在干净环境下部署的完整过程呈现出来。这是一台 Ubuntu Server 24.04 LTS1G 内存、单核 CPU 的云服务器视频文件放在/data/videos目录下。因为机器性能和存储都很弱我选择 nginx 静态方案而非 Jellyfin。6.1 环境准备与依赖安装登录服务器后第一步是更新软件源和安装必要的包apt update apt upgrade -y apt install -y nginx ffmpegnginx 装完默认会自动启动并监听 80 端口。用systemctl status nginx确认状态为 active。ffmpeg 是为了验证视频信息和后续可能的转码操作。然后创建目录并放入测试视频。这里刻意用了一个中文文件名测试视频.mp4来验证中文字符在 URL 中的表现。实际经验是中文文件名在浏览器和 nginx 之间容易出现编码不一致的问题轻则无法访问重则 404更稳妥的做法是统一用拼音或者数字命名。操作中我将文件重命名成了test.mp4。检查文件完整性ls -lh /data/videos/ ffprobe /data/videos/test.mp4正常输出里能看到Duration: 00:02:13.14和Video: h264 (High)这类信息。6.2 nginx 配置与目录权限nginx 的默认站点配置文件在/etc/nginx/sites-available/default我直接修改它server { listen 80 default_server; listen [::]:80 default_server; root /data/www; index index.html; server_name _; location /videos/ { alias /data/videos/; autoindex on; } }注意这里 root 指向的是/data/www视频访问走/videos/子路径通过 alias 映射到真实视频目录。创建前端页面/data/www/index.html!DOCTYPE html html langzh-CN head meta charsetutf-8 title视频演示站/title /head body h2测试播放/h2 video controls width640 height360 source src/videos/test.mp4 typevideo/mp4 你的浏览器不支持 video 标签。 /video /body /html检查语法并重载服务nginx -t systemctl reload nginx权限方面/data目录本身如果是 root 创建的nginx 的 www-data 用户需要至少拥有r-x权限。我习惯的做法是给/data设置755权限视频文件设644然后立即用curl验证curl -I http://localhost/videos/test.mp4看到返回200 OK且响应头包含Content-Length说明文件可以被正常访问。如果返回 403多半是目录权限问题返回 404多半是 alias 路径配置错误。6.3 防火墙和远程访问验证服务器在云环境时安全组和系统防火墙都要放行 80 端口。Ubuntu 自带的 ufw 如果启用执行ufw allow 80/tcp ufw status从另一台电脑的浏览器访问http://服务器IP/页面打开视频可以播放标题这就算跑通了。要提醒的是如果你用 HTTPS 访问服务器需要把视频服务也配置到 443 端口并挂证书否则浏览器会因混合内容拦截视频加载。这一环节我顺手验证了自动播放策略页面里的 video 标签没加 muted 属性时Chrome 会忽略 autoplay视频处于暂停状态加上 muted 后打开页面即自动播放。这是浏览器层面的规则和服务器无关但你做“数字标牌”类项目时一定要知道。7. 实测中遇到的花屏、无声和 CPU 飙升排障经验与根治办法部署完成不是结束恰恰是踩坑的开始。我把自己在 Linux 服务器播放和网页播放场景里踩过的三类问题整理一遍每个都给出排查路径和根因分析。7.1 播放 m3u8 直播流时画面花屏这个坑的典型表现为网页播放器能加载画面却是一块块破碎的绿色和灰色色块声音正常。很多人在打开 CCTV 之类的直播地址时遇到过这个问题。根因通常是视频源输出的视频帧编码格式和你播放器期望的不一致。直播流大多是 H.264但部分源会用 B 帧和参考帧数量较多的配置而低端播放器或者浏览器解码器没有正确处理导致参考帧缺失、画面花屏。另外 ts 分片边界如果和 GOP 边界不对齐也可能导致关键帧缺失。排障流程是先用 ffprobe 查看流的编码参数ffprobe -show_streams http://example.com/live/stream.m3u8重点看codec_name、profile、level三个字段。如果 profile 是 High 而 level 是 4.0 以上老设备花屏概率大。解决办法有两个一是在服务端转码成 Baseline profile 再输出二是前端播放器强制设置软解。Jellyfin 里可以在转码设置中指定 h264 baseline profile纯前端 hls.js 场景可以设置hls: { enableSoftwareMSE: true }尝试。7.2 网页播放器没有声音这个问题的排查范围比很多新手想象中大。如果是“本地点开 ffplay 有声音但网页里没声音”那问题处在浏览器自动播放策略和音频上下文未激活上。Chrome 要求页面在用户点击页面任意位置以后媒体元素才能输出声音。如果你希望打开页面就能直播有声视频最佳做法是页面加载后显示一个“点击进入”按钮用户点击后自动播放。如果是“所有播放方式都没声音”则要检查系统音频服务。服务器版默认没有安装 PulseAudio我因为没声卡这个细节排查过挺长时间。装法如下apt install pulseaudio pulseaudio --start --exit-idle-time-1然后用speaker-test验证声音输出。服务器接显示器但没接音箱自然没有声音输出这属于最容易被忽略的环境因素。7.3 CPU 占用飙升与转码瓶颈nginx 直接推流模式几乎不消耗 CPU。如果你发现 CPU 占用从正常 5% 跳到 90%肯定走转码通路了。常见原因是你配置了 HLS 实时切片而 ffmpeg 是常驻转码进程。判断方法top -c找出 CPU 占用高的进程如果进程名是 ffmpeg确认它在转码哪个视频。解决思路是把视频预先转码成 H.264 主流的 mp4避免实时转码。你真的需要实时转码的场景只有两个直播流转发或者多设备同时访问且源文件编码过于特殊。还有一个经常被忽略的因素如果视频文件存储在网络盘或机械硬盘上读取速度跟不上也会造成播放卡顿表现为播放器转圈但 CPU 不高。这个问题的排查方法是看iostat -x 1r/s 和 w/s 数值异常高时考虑把视频文件迁移到本地 SSD。7.4 远程访问时常断流的问题网页播放时断时续第一反应是网络带宽不够但有时候服务器带宽明明很大WiFi 也满格。我的实测经验是问题往往出在 TCP 拥塞控制和 MTU 上。部分云服务器的默认 MTU 是 1500而内网环境实际 MTU 小于这个值出现分片丢包导致播放器缓冲不稳。排查命令ping -M do -s 1472 网关IP如果报错说明 MTU 需要调整改为 1400 即可。云服务器一般在控制台修改网络配置物理机可以修改/etc/network/interfaces或者 netplan 文件。这个坑排查成本低但收益高很多人断流排查根本不看 MTU导致一直找不到原因。8. 写在最后根据实际场景选方案别被“高大上”带偏整个流程跑下来我的体会是Ubuntu Server 上“播放视频显示网页”这件事真正难的不是某个技术点而是先想清楚自己的场景。如果只是自己家里一两台设备看装 Jellyfin 一个服务完事如果是临时演示给同事看某个视频文件nginx 静态目录加一个 HTML 页面最简单如果是业务系统集成Node.js 静态挂载或者 Nginx 子路径顺手就能接进去。一个容易被忽略却影响体验的地方是视频文件的预处理。无论你选哪种方案装完 FFmpeg 之后先把所有视频检查一遍for f in /data/videos/*.mp4; do echo 检查: $f; ffprobe -v error -show_entries streamcodec_type,codec_name $f 2/dev/null | paste - -; done列出每个文件的编码格式。假如你要批量播放一批老视频编码可能是 MPEG-2 或者 DivX直接丢到网页里必然黑屏提前用 FFmpeg 转成 H.264 格式能省掉后面所有烦恼for f in /data/videos/*.avi; do ffmpeg -i $f -c:v libx264 -c:a aac ${f%.avi}.mp4; done个人经验告诉我不要盲目追求“一劳永逸”的万能方案因为媒体生态太分裂设备差异、浏览器差异、编码差异每一层都能折腾出问题。先把最小可用的链路跑通再根据实际需要决定是否引入 Jellyfin、是否开启硬解、是否需要 HLS 切片这才是 Ubuntu Server 上做视频应用最务实的路径。