Windows搭建Nginx流媒体服务器：RTMP与HLS直播配置实战

单位临时要搞内部线上分享会，需要把主讲人的屏幕和画面推给全公司的同事看，又不能把内部内容丢到公网直播平台。最省事的办法，就是直接用一台 Windows 办公电脑，搭一个 Nginx 流媒体服务器。我当时就是这么干的：解压一个带 RTMP 模块的 Nginx 集成版，改十几行配置，再加上 OBS 推流、VLC 拉流验证，前后半小时就把第一场直播跑通。这套方案说白了就是给 Nginx 装上流媒体模块，让它既能接收 RTMP 推流，也能给观看端分发直播流、甚至切出 HLS 给浏览器播放。适合网络管理员、校社团做活动直播、企业内网培训、以及想在家里搞一套私有点播库的朋友，不需要买昂贵的商用视频平台授权，一台普通电脑就够了。

1. 方案选型：为什么在 Windows 上优先选 Nginx 做流媒体

1.1 为什么是 Nginx 而不是其他流媒体方案

Nginx 本身是一个高性能 Web 服务器，但装上 rtmp 模块之后，它会变成一个同时支持 RTMP 直播、HLS 切片、MP4 点播的轻量级流媒体服务器。对中小规模场景来说，它的优势不是功能多，而是“一个进程、一份配置、一套日志”，把 HTTP 服务和流媒体服务合并在一起管理，比单独部署一套流媒体后端要省心得多。

我遇到过不少人第一反应是上更专业的流媒体开源系统，比如 SRS、MediaMTX。这些项目确实功能齐全，但大多以 Linux 为第一优先平台，Windows 下要么需要手动编译，要么依赖 WSL 环境，对于只想“在办公电脑上快速跑起来”的需求来说，反而把简单问题复杂化了。而社区维护的 Nginx RTMP 集成版本直接在 Windows 上用，不用处理交叉编译那套东西，这也是它在 Windows 场景下被广泛使用的原因。

有人会觉得 Nginx 做流媒体不够专业，这里要把定位说清楚：它适合的是几百人以内、局域网或者小范围公网分发的场景。像企业内部培训、校园直播、个人视频分享，这种规模下 Nginx 的稳定性和资源占用都非常理想。如果目标是百万级并发，那肯定要上专门的流媒体集群，但那是另一个量级的问题了。

1.2 Windows 平台的特殊性与性能预期

在 Windows 上搭 Nginx，最大的坑是版本选择。官方发布的 Nginx Windows 版本默认不带 RTMP 模块，官方也没有直接提供带流媒体模块的安装包。如果你想自己编译，还得先把 Visual Studio、Perl 等一整套工具链配齐，对大多数人来说这一步直接劝退。好在社区里有开发者维护了 Windows 可用的 Nginx-RTMP 集成版，下载解压就能用，内置了 rtmp、hls、http-flv 等常用模块，基本覆盖直播与点播的全部需求。

性能这块也要有合理预期。Nginx 在 Windows 上运行采用的是单进程模型，比 Linux 下多 worker 模型的极限吞吐低一些。但在实际测试中，一台普通 i5 主机、16G 内存的办公电脑，支撑六七十人同时观看直播，CPU 占用基本不超过 20%，内存占用也就在几十兆这个量级。如果你只是给部门几十号人做内部直播，性能完全够用。

还有一个重要预期管理：这套方案解决的是“有没有”和“稳不稳”的问题，不是“能不能上公网百万并发”的问题。把它定位为一台“内网点播机+直播分发机”，使用起来心态会好很多。

我用表格对比过常见的几个方案，方便大家按自己的场景选型：

2. 安装准备：找到带 RTMP 模块的版本并完成部署

2.1 集成版从哪里找、怎么判断模块齐全

在搜索引擎里搜“nginx rtmp windows 集成版”，能找到不少社区 release。关键不是版本号多新，而是要看这个集成版到底带了哪些模块。下载页面如果写明了包含 rtmp、http-flv、hls、mp4 这些模块，基本就能满足常规需要；如果只有一个干巴巴的文件，没有模块说明，就要谨慎。

我下载集成版时有一个习惯：先看项目说明里的更新时间和评论区反馈。选择最近一年内仍在维护的版本，能避免碰到一些老版本在 Windows 10 以上系统里的兼容问题。下载后别急着解压运行，先做一次查毒，毕竟第三方编译文件还是要谨慎对待，这个步骤不能省。

另外，解压路径建议是纯英文且不要带空格，比如 D:\nginx-rtmp。Nginx 的配置里大量使用相对路径，如果路径带中文或空格，在 Windows 的命令行和文件系统处理过程中容易出现编码问题，到时候查错半天都找不到根源，干脆一开始就避开。

有些集成版压缩包里会附带一份 README 文件，里面写了编译环境、包含模块、常见命令，花两分钟读一下比盲目试错强很多。我下载的版本里还会把默认监听端口写在说明里，避免一上来就和现有 Web 服务打架。

2.2 解压目录、启动命令与验证流程

解压之后你会看到一个结构清晰的目录，长这样：

nginx-rtmp ├─ conf │ ├─ nginx.conf │ ├─ mime.types │ └─ ... ├─ html │ └─ index.html ├─ logs │ ├─ access.log │ ├─ error.log │ └─ nginx.pid ├─ temp └─ nginx.exe

平时需要关注的其实就四个东西：conf/nginx.conf 是核心配置文件，logs/error.log 是排错第一入口，logs/nginx.pid 记录着当前运行的进程号，temp 目录是 HLS 切片等临时文件的存放位置。

启动、停止、重载的常用命令如下：

# 进入解压目录后执行 nginx.exe # 启动服务 nginx.exe -s stop # 停止服务 nginx.exe -s reload # 重载配置 nginx.exe -t # 检查配置语法

这里有个很重要的操作习惯：每次修改配置文件后，先执行nginx.exe -t检查语法，再执行 reload。如果配置有语法错误还直接 reload，很可能把正在正常服务的旧配置一起弄挂，这就是典型的低级但高发的失误。

启动完成后，浏览器访问 http://localhost/ ，能看到 Nginx 欢迎页就说明基础服务正常。如果页面打不开或者 Nginx 闪退，立刻打开 logs/error.log，里面会写出具体原因，比如端口被占用、缺少系统运行库等等。很多集成版依赖系统运行库，缺了它会闪退，装上对应版本就好。

提示：不要在 nginx 运行状态下直接把解压目录改名或移动，Windows 下文件占用会导致各种奇怪问题。

3. RTMP 直播配置：推流、拉流与点播一条路走通

3.1 RTMP 协议与 Nginx 配置语法入门

RTMP 协议默认走 TCP 1935 端口，它理解起来跟“直播间房间号”这个模型很像：推流端把音视频流送进某个房间，拉流端从同一个房间取流。Nginx 里这个“房间”就叫 application，房间名称由你自己定义，比如 live、hls、vod。

一个最简直播配置长这样：

worker_processes 1; events { worker_connections 1024; } rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; } } }

几个关键参数说明：

• listen 1935：RTMP 协议监听端口，如果没有端口冲突，建议保持默认。
• chunk_size 4096：RTMP 分块大小。直播场景一般用 4096 或 8192，分块太大在高丢包网络下容易出问题，太小则增加协议开销，4096 是一个比较稳妥的中间值。
• application live：定义一个名为 live 的推流/拉流节点，后面所有推流地址都会带这个路径。
• live on：开启直播模式，表示该节点接受实时流。
• record off：默认不录制，避免长时间直播把磁盘写满。

配置写好后，执行nginx.exe -t再 reload。这个时候 Nginx 已经是一台流媒体服务器了，只是还没有人给它推流。

3.2 OBS 推流实战

OBS 是免费的推流工具，配置非常简单：

1. 安装并打开 OBS。
2. 进入“设置 -> 推流”，服务模式选择“自定义”。
3. 服务器填写是rtmp://你的局域网IP/live。
4. 串流密钥填写任意值，比如test1。
5. 添加好画面源，点击“开始推流”。

推流地址中的你的局域网IP可以用localhost在本机测试，也可以填实际局域网 IP。live必须和 nginx.conf 里 application 的名字一致，密钥test1则是用来区分同一节点下不同直播流的标识。只要推流端密钥和拉流端 URL 中的流名一致，就能成功匹配。

OBS 开始推流后，重点关注状态栏里的三项指标：码率、丢包、时间。如果码率稳定、丢包为 0%，说明推流信号已经顺利到达服务器；如果丢包持续攀升，多半是编码负载太高或者网络不稳定，需要适当降低分辨率、帧率或者码率。

还有一个容易踩的坑：串流密钥里不要用中文和特殊符号，尽量只保留字母、数字、下划线。Windows 环境下某些版本的 Nginx 对非 ASCII 字符处理不够稳定，一旦流名出问题，拉流端看到的可能是一直转圈的黑屏。

3.3 VLC 拉流验证

推流是否成功，用 VLC 验证最快。打开 VLC，选择“媒体 -> 打开网络串流”，输入：

rtmp://你的局域网IP/live/test1

画面秒出的话，说明“推流端 -> Nginx -> 拉流端”这条链路全通。

我建议在局域网测试阶段，优先用 RTMP 直拉，而不是直接去看网页播放。因为 RTMP 链路短、延迟低，能最快速定位问题到底出在“推流”“服务器”还是“播放端”。如果一上来就查网页播放失败，干扰因素太多——协议转换、切片延迟、MIME 类型配置都可能掺一脚，排查效率太低。

3.4 顺带配一个点播目录

直播跑通之后，很多人会顺便想做一个私有视频点播库。这个 Nginx 也能做，在 rtmp 区块里加一个 vod 节点：

application vod { play D:/media/videos; }

把视频文件放到 D:/media/videos 目录下，播放端用 VLC 打开：

rtmp://你的局域网IP/vod/视频文件名.mp4

就能直接播放。这里要注意视频编码格式，RTMP 对 MP4、FLV 支持比较友好，如果是某些冷门封装格式可能播放不了，先转成 MP4 最省心。

如果再想用浏览器看目录列表，可以在 http 区块里加一个 location，打开 autoindex：

server { listen 8080; location /videos/ { alias D:/media/videos/; autoindex on; } }

这样同事直接用浏览器访问http://你的IP:8080/videos/就能看到视频文件列表，单击即可播放。这个玩法非常适合内部培训资料的整理，等于一台服务器把“直播分发”和“内网点播”都搞定了。注意这个 server 块我们接下来还会继续用，后面配置 HLS 的 location 时也要放在同一个 server 块中，否则同一个端口重复 listen 会导致 Nginx 启动失败。

4. HLS 切片配置：让浏览器也能直接看直播

4.1 HLS 的价值与原理简述

RTMP 在浏览器里不能直接播放，移动端内置浏览器对 RTMP 的支持也基本为零。HLS 协议则把直播流切成一个个 2 到 6 秒的小片段，生成后缀为 .ts 的视频块，再用一个 .m3u8 的索引文件按顺序指向这些片段。播放端只需要通过普通 HTTP 请求去拉取 m3u8 和 ts，因此任何 Web 服务器都能承担分发工作，兼容性非常强。

Nginx 的 rtmp 模块自带 HLS 切片能力，这是它最实用的一点。不需要额外插件，只需要在配置里声明hls on，它就会自动把接收到的 RTMP 流转成 m3u8 + ts 文件输出。这里的转变过程是把“实时直播流”变成了“一堆文件”，所以天然就延迟更高，但它换来了浏览器和移动端的广泛兼容。

对内部培训这种场景，延迟高几秒完全不影响观看体验，如果要做连麦互动，那就还是老老实实走 RTMP 拉流。

4.2 HLS 切片配置与 HTTP 目录映射

在 rtmp 区块里加一个专门的 hls 节点：

application hls { live on; hls on; hls_path D:/nginx-rtmp/temp/hls/; hls_fragment 2s; hls_playlist_length 6s; }

然后在 http 区块里，把刚才生成切片的目录映射到 HTTP 访问路径。注意把它加进我们已经开好的 8080 端口的 server 块中：

server { listen 8080; server_name localhost; location /videos/ { alias D:/media/videos/; autoindex on; } location /hls { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } alias D:/nginx-rtmp/temp/hls/; } }

location /hls和hls_path要保证指向同一个实际目录，才能让浏览器通过http://IP:8080/hls/xxx.m3u8访问到文件。types 那几行尤其重要，Nginx 默认不会把 .m3u8 映射到正确 MIME 类型，不加这段，播放器可能直接报“格式不支持”。

路径写法上有个细节，配置文件里统一用正斜杠/，比如D:/nginx-rtmp/temp/hls/。Windows 原生路径是反斜杠\，但 Nginx 配置文件用正斜杠最稳，不容易遇到转义问题，这个细节能省下不少排查时间。

4.3 切片参数、延迟与磁盘清理

配置里出现了两个时间参数：hls_fragment 2s表示每个 .ts 片段长度为 2 秒，hls_playlist_length 6s表示 m3u8 索引保留过去 6 秒的切片。两者配合决定 HLS 延迟和稳定性。

想降低延迟，可以把 fragment 调小到 1 到 2 秒，但不要低于 1 秒，否则切片过于频繁，CPU 和磁盘开销都会明显增加。想更流畅，可以让 playlist 保留长一点，比如 10 到 15 秒，这样即使在弱网环境下播放器也有更多缓冲余地。实际延迟通常在 6 到 10 秒之间，这是 RTMP 转 HLS 的正常代价，不是故障。

还有一个经常被忽略的问题：HLS 切片会不断写入临时目录，长时间直播会导致磁盘空间持续增长。我通常加一条计划任务，定时清理过期切片，用 PowerShell 执行：

powershell -Command "Get-ChildItem 'D:/nginx-rtmp/temp/hls/*.ts' | Where-Object {$_.LastWriteTime -lt (Get-Date).AddMinutes(-10)} | Remove-Item"

把这条命令放进任务计划程序，每半小时跑一次，能避免直播挂太久把磁盘写满。虽然 Nginx 的 rtmp 模块在切片管理上已经不错，但 Windows 下文件回收依赖系统自己处理，人工加一道保险更踏实。

4.4 浏览器播放方案

HLS 配置好之后，推流地址变成rtmp://你的局域网IP/hls/stream1，播放地址则变成 HTTP 链接：

http://你的局域网IP:8080/hls/stream1.m3u8

先用 VLC 打开这个链接验证一次，如果 VLC 能播放，后续浏览器问题基本都是前端代码或者跨域问题。

网页端播放最轻量的方式是引入 hls.js，配合原生 video 标签：

<video id="video" controls autoplay></video> <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script> <script> var video = document.getElementById('video'); if (Hls.isSupported()) { var hls = new Hls(); hls.loadSource('http://你的局域网IP:8080/hls/stream1.m3u8'); hls.attachMedia(video); } </script>

如果用 Safari 播放 m3u8，原生 video 标签就直接支持，不需要 hls.js。页面黑屏是这里最高频的问题，排查思路是打开浏览器开发者工具看 Network 面板，检查 m3u8 和 ts 请求的返回码。如果 ts 请求出现 404，多半是alias路径和hls_path不一致；如果 m3u8 正常返回但视频不动，则多半是 MIME 类型没配对。

跨域问题也要提一句：如果你的网页是file://协议或者域名和流媒体端口不一致，hls.js 可能会因为跨域限制拿不到内容。最省事的办法，是把直播播放页面也放到同一个 Nginx 的 web 目录里，从http://IP:8080/player.html打开。

5. 实战排错：端口占用、防火墙与黑屏问题排查

5.1 启动失败与端口占用

Nginx 启动失败，十次有九次是端口被占用。最常见的冲突是 80 端口被其他 Web 程序占用，导致 Nginx 默认 HTTP 服务无法绑定。判断方法先看 Nginx 启动后是否闪退，再打开 logs/error.log，里面会明确提示 Address already in use 或类似信息。

用命令行确认端口占用最直接：

netstat -ano | findstr :80

看到 LISTENING 的 PID，再到任务管理器里查是哪个进程。如果 80 端口确实被占，直接改 Nginx 配置里的 HTTP 监听端口为 8080 或者别的空闲端口。注意 rtmp{} 区块里的 listen 1935 是流媒体端口，http{} 里的 listen 才是网页端口，两者不要搞混。修改后执行nginx.exe -t再 reload。

RTMP 端口 1935 也可能被占，有一些局域网软件会用到 1935。这时可以换一个冷门端口，比如 19350，然后推流地址也要相应改成rtmp://IP:19350/live/stream1。记住一句话：改了端口，所有客户端地址必须同步改。

5.2 防火墙与局域网访问

本机推流、拉流都正常，但其他电脑访问不了，这个问题绝大多数出在 Windows 防火墙。默认情况下 Windows 会拦截其他设备访问本机的 TCP 端口，所以需要手动放行。

操作路径是：控制面板 -> Windows Defender 防火墙 -> 高级设置 -> 入站规则 -> 新建规则 -> 端口 -> TCP，然后填入需要放行的端口。RTMP 放行 1935，HLS/HTTP 放行 8080。如果你改了端口，记得把新端口也加进去。

如果电脑上装的是第三方安全软件，也照做一样的事情：把 Nginx 目录加入信任区，或者放行 nginx.exe 的网络访问。我见过不少案例，配置完全正确，但第三方安全软件在后台拦截了所有对外连接，搞得数据包只进不出，最后把 Nginx 加入白名单马上恢复正常。

测试局域网访问时，别每台设备都跑到最后一刻才发现网段不同。直接用手机开热点让电脑连上，看能不能用 IP 访问，这一步能快速区分“网络隔离问题”和“服务器配置问题”。

5.3 推流拉流与 HLS 常见问题

下面汇总几个高频问题和排查顺序，都是实操里经常遇到的：

有一个实用技巧：把 Nginx 的 access.log 打开。有些集成版默认关闭了访问日志，一旦 404 问题出现时缺少线索。在 nginx.conf 的 http{} 区块加上：

access_log logs/access.log;

这样每一次网页访问都被记录，哪个 ts 文件 404 一目了然，比靠感觉猜快得多。

5.4 用 ffmpeg 快速自测

没有 OBS，或者想自动化测试链路是否通畅时，ffmpeg 是很好的命令行工具。推流命令：

ffmpeg -re -i test.mp4 -c copy -f flv rtmp://127.0.0.1/live/test1

其中-re必须加，它让 ffmpeg 按视频原始帧率推流，不加的话文件会瞬间推完。-c copy表示不转码，直接把原始编码流复制发送，速度快、CPU 占用低。如果你要测试转码能力，可以去掉-c copy，让 ffmpeg 重新编码再推流。

拉流验证命令：

ffmpeg -i rtmp://127.0.0.1/live/test1 -c copy test_out.mp4

能把流存成文件，说明服务器收发链路完全正常。这个方法特别适合排查“推流端没问题但服务器不转发”的奇怪场景，也能用来做无人值守的服务器健康检查脚本。

最后再分享一点实在话

这套配置前前后后我陪朋友也部署过好几次，最大的感想是：Nginx 本身不乱跑，坑都在 Windows 周边环境里。只要版本选对、端口查清楚、防火墙放行，就算第一次接触，半小时也足够把第一路直播跑起来。

我自己有个小习惯：每次改配置前会备份一份 nginx.conf，按日期命名，比如 nginx_20250115.conf。配置折腾坏了随时回滚，比在文件里反复试错踏实得多。还有定时清理 HLS 临时目录的计划任务，一定要随着直播服务一起配好，不然直播挂一个晚上，第二天磁盘空间告警你未必能第一时间反应过来。

再往后如果你想玩得更深，还可以在这个基础上加一个简单的 HTTP 鉴权页面，或者用多机位 OBS 导播，再或者接入内网穿透让外网同事也能看，但核心思路始终是那一条：先把本机的推流和拉流链路跑通，再谈外部接入。链路稳了，剩下的都是锦上添花。