之前在项目里需要临时搭一套RTMP流媒体服务器目标很明确Windows系统Nginx方案能推流能拉流最好还能一键验证。这套环境我实际跑了一段时间中间踩了不少坑今天把完整的搭建过程、所有组件的下载地址、配置细节和验证方法一次性整理出来。为什么是Windows加Nginx而不是其他组合因为那台直播转播设备部署在Windows Server上现场没有专职Linux运维直播规模也不大根本没必要上SRS、Wowza这种重型服务。Nginx配合nginx-rtmp-module在Windows下有现成的预编译包配置文件相对简单我一个人半小时内就能跑通后续维护也方便。这篇文章适合谁看一类是想在实验室、公司内网快速搭一套直播源做摄像头监控、室内活动转播或者软件直播测试的人另一类是刚开始接触RTMP协议想搞明白“推流地址和拉流地址到底是怎么映射的”的开发者。不管之前有没有接触过流媒体下面的内容都会从零开始说清楚。1. 我为什么在Windows上搭这套RTMP环境1.1 从一次直播转播需求说起当时接到一个场馆直播需求现场摄像头信号通过采集卡进一台Windows主机需要把画面实时推到同一内网里的十几台展示终端。第一反应是找云厂商的直播服务但现场网络不允许公网直播只能自建。团队里日常维护Windows的同事最多所以平台选择上没有太多犹豫。真正需要考虑的是服务软件选型。那台机器配置不高双核CPU、8G内存平时还要跑采集卡驱动和播放软件留给流媒体的资源非常有限。我先后试过几个方案SRS功能全但Windows下编译麻烦官方也没有特别好的Windows版本Wowza功能强但商业授权太贵Red5是Java体系内存占用让我直接放弃。最后回到Nginx原因很简单它在Windows下有稳定的预编译版本带上RTMP模块后配置也不复杂跑了几天内存占用一直稳定在几十兆完全符合这个场景。1.2 Nginx在RTMP服务里的角色定位Nginx本身是用来处理HTTP和反向代理的Web服务器本身并不认识RTMP流。让它变成流媒体服务器的是nginx-rtmp-module这个扩展模块。它实现了RTMP服务端能力接收推流端的发布流把流按配置复制给所有正在拉流的播放器。这个过程涉及到的主要协议是RTMPAdobe定义的实时消息传输协议基于TCP默认端口1935。说直白一点Nginx在这里当的是一个“流分发器”。推流端给服务器扔进来一路RTMP流服务器把这路流广播给所有来拉流的客户端。它不会自己去转码也不会改变视频编码格式原模原样转发。这意味着推流端的编码设置必须符合播放端的能力否则就会出现后文会详细说的黑屏、花屏问题。在Windows下使用Nginx做RTMP服务还有一个隐性好处Nginx在Windows上原生支持不需要安装虚拟机或者WSL部署和进程管理对Windows运维人员来说非常友好。配置文件是纯文本改动后重载即可不用编译代码这在这个项目里非常重要。1.3 这套方案能做什么、不能做什么很多教程会把NginxRTMP说成万能直播平台但实际它有很明确的能力边界。我列一下自己测试过的清单。能做的接收OBS、ffmpeg、摄像头推流端发来的RTMP直播流向任意数量的播放端分发RTMP流支持播放鉴权开启HLS封装让浏览器通过HTTP播放m3u8视频流输出流状态统计页面实时查看在线推流和拉流数配合录制定时保存flv文件可以做最基本的录制回放不能做的视频转码比如把H.265转成H.264Nginx自己干不了多码率自适应需要额外的编码和打包服务大规模公网分发单机带宽和连接数有限复杂的DRM版权保护完善的Web管理界面只有状态页没有管理后台搞清楚了边界后续才不会做错误的技术选型。这个项目规模小、场景固定Nginx完全够用。2. 组件清单与下载地址先备齐再动手2.1 核心组件带RTMP模块的Nginx先说一个最容易踩的坑Nginx官网下载的Windows版本是不带RTMP模块的。网上很多教程直接让人去nginx.org下载结果照配置写完启动就报“unknown directive rtmp”这就是模块缺失。Windows下自己从源码编译Nginx太痛苦要装MinGW、MSYS等一整套工具链还有各种依赖问题业余项目完全没必要。我推荐直接用社区维护的Windows预编译包。GitHub上有个项目叫 illuspas/nginx-rtmp-win32里面打包了Nginx和nginx-rtmp-module解压就能用版本是Nginx 1.18.0配nginx-rtmp-module 1.2.1稳定跑过一年以上。下载时认准Release页面里的zip包不要下载源码包。如果你之后想自己编译最新版nginx-rtmp-module的源码也在GitHub上地址是https://github.com/arut/nginx-rtmp-module但新手不建议从这里起步。下载地址汇总组件下载地址用途说明nginx-rtmp-win32https://github.com/illuspas/nginx-rtmp-win32RTMP流媒体服务已含RTMP模块解压即用ffmpeghttps://www.gyan.dev/ffmpeg/builds/命令行推流、拉流验证下载release-essential版本即可OBS Studiohttps://obsproject.com/实际直播推流如果只做测试可以不用VLChttps://www.videolan.org/vlc/拉流播放验证也可以直接用ffplay替代2.2 配套工具各自是干嘛的ffmpeg是做流媒体验证时的“万能测试器”可以用命令生成测试画面、推送RTMP流、拉取RTMP流甚至转码。我平时做链路检查首选ffmpeg而不是OBS因为命令行可以精确控制编码参数和推流时长不会有人为操作变数。OBS是正式直播场景下的推流端界面化操作适合业务方使用。拉流验证方面VLC对RTMP协议支持得很好填入地址就能播但VLC在某些情况下解码延迟大所以我更常用ffplay它和ffmpeg同源启动快、参数多。这三个工具的下载地址见上面的表格。ffmpeg在Windows下不需要安装解压后把bin目录加入系统PATH环境变量或者命令里直接用完整路径。OBS和VLC都提供安装版按向导安装就行。2.3 目录规划与文件校验下载完所有组件后先别急着解压。我强烈建议在D盘根目录建一个 MediaServer 文件夹作为所有流媒体相关工具的容身之处。原因很简单Nginx对路径中的空格支持不太好放在“C:\Program Files”下经常出现路径解析问题而 D:\MediaServer\nginx-rtmp 这种纯英文无空格路径最稳。目录结构可以是这样的D:\MediaServer ├─ nginx-rtmp │ ├─ conf │ ├─ html │ ├─ logs │ └─ nginx.exe ├─ ffmpeg │ ├─ bin │ └─ ... └─ tools解压完成后最好校验一下文件完整性。Windows PowerShell里执行Get-FileHash .\nginx-rtmp-win32.zip -Algorithm SHA256将得到的哈希值和GitHub Release页面给出的SHA256值比对。这一步能避免下载到被篡改或损坏的文件尤其是从第三方镜像下载时很有必要。3. 配置nginx.conf理解RTMP模块的工作方式3.1 先认识两个核心区块打开 D:\MediaServer\nginx-rtmp\conf\nginx.conf默认配置里只有 http 块。我们要做的是在 http 块之外、与它平级的位置新增一个 rtmp 块。很多第一次配置的人会把这个 rtmp 块写成 http 的子级Nginx 启动时直接报错“unknown directive rtmp”原因就是层级错了。http 块用来处理管理监控页面、HLS播放等HTTP流量rtmp块用来处理RTMP直播流。两者互不干扰。RTMP块默认监听1935端口这个端口号后面会频繁用到。HTTP块里的监听端口建议改成8080避开80端口因为很多Windows服务默认占着80没必要去抢。Nginx配置文件的结构是“指令参数分号”每个块结束要有闭合花括号。写RTMP配置时注释用井号开头别写错。3.2 一个能直接跑起来的完整示例我在项目中实际使用的配置是下面这个精简版。去掉了一堆花哨功能只保留最核心、最不易出错的部分。worker_processes 1; error_log logs/error.log info; events { worker_connections 1024; } rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # 允许哪些IP播放这里允许本机和局域网 allow play 127.0.0.1; allow play 192.168.0.0/16; deny play all; } } } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 8080; server_name localhost; # RTMP统计页面方便验证服务是否正常 location /stat { rtmp_stat all; rtmp_stat_stylesheet stat.xsl; } location /stat.xsl { root html; } } }这个配置的关键点worker_processes 1在Windows下建议固定为1不要相信网上说调大数值提升性能Windows版Nginx的多进程模型限制很多设大了反而带来资源竞争。worker_connections 1024这是单个进程允许的最大连接数。并发不大时1024够用如果播放端数量多可以改成2048但受限于系统资源。chunk_size 4096RTMP块大小默认4096没有特殊需求就不要动。application live这里的live就是URL路径里的应用名后面推流地址中的/live/就是对应它。可以改成其他名字但改完推流地址也要跟着变。allow play和deny play控制哪些IP允许拉流。默认如果不写就是允许所有IP拉流。这里我只放行了本机和192.168.0.0/16局域网其他一律拒绝。注意顺序deny all一定要放在最后否则所有IP都被拒绝。把这段配置覆盖到nginx.conf里如果原来有其他server配置根据实际需要决定是否保留。如果只是测试可以全部替换。3.3 推流URL、应用名和流key的关系这是整个搭建过程中最容易混淆的地方。RTMP推流地址的完整格式是rtmp://服务器IP:1935/应用名/流key拿上面的配置举例服务器IP本机用127.0.0.1局域网用网卡IP比如192.168.1.100端口1935对应配置里的listen 1935应用名live对应配置里的application live流key你自己定义的一串字符比如 test、abcd1234所以完整的推流地址是rtmp://127.0.0.1:1935/live/test在OBS里推流时“服务器”填rtmp://127.0.0.1:1935/live“串流密钥”填test。OBS会把这两个部分拼起来生成完整的RTMP URL。很多新人把/live/test全填到服务器的框里结果推流失败。记住服务器框里只到应用名流key单独填。流key建议设置得随机一点比如“a1b2c3d4e5”不要用test、live、stream这种常见词。尤其当服务器暴露在公网时随机流key能大大降低被陌生人扫描到你直播流的概率。应用名和流key的组合就是认领这个流的唯一凭证。4. 启动服务与本地验证从推流到拉流全流程4.1 用命令启动Nginx并确认模块生效配置写好后先别直接双击nginx.exe。正确的是在命令行里进入Nginx目录先做配置语法检查cd /d D:\MediaServer\nginx-rtmp nginx.exe -t -c conf/nginx.conf如果输出是syntax is ok和test is successful说明配置没有语法问题。注意这里只是语法检查模块是否有问题要等启动后看日志。如果中途报错会显示具体行号照着改。确认配置没问题后用下面的命令启动Nginxstart nginx.exe用start而不是直接执行是为了让Nginx在后台运行不占用当前命令行窗口。启动后检查进程和端口tasklist | findstr nginx.exe netstat -ano | findstr :1935 netstat -ano | findstr :8080进程列表里应该有两个nginx.exe进程1935和8080端口处于监听状态。如果只有一个进程或端口没监听大概率是配置有问题去logs/error.log看日志。确认HTTP统计页面能否访问在浏览器打开http://127.0.0.1:8080/stat如果能看到XML格式的统计信息说明HTTP模块正常而且nginx-rtmp-module也被正确加载了。这个页面在推流后还会显示活跃流数量是日常验证的利器。4.2 用ffmpeg命令行推流测试服务启动后先用ffmpeg生成一路测试流推上去。用内置的testsrc测试画面和sine音频源不依赖任何本地文件ffmpeg -re -f lavfi -i testsrcduration30:size1280x720:rate25 -f lavfi -i sinefrequency440 -c:v libx264 -preset ultrafast -tune zerolatency -c:a aac -f flv rtmp://127.0.0.1:1935/live/test解释一下每个关键参数-re按原始帧率实时读取输入源保证推流速度接近真实直播-f lavfi -i testsrc使用ffmpeg虚拟视频源画面是带有时间戳的彩色测试图-f lavfi -i sine使用虚拟音频源产生440Hz正弦波-c:v libx264视频编码为H.264-preset ultrafast编码速度最快占CPU少-tune zerolatency降低编码延迟对直播很友好-c:a aac音频编码为AAC-f flv输出封装格式为FLVRTMP推流用这个如果命令执行后看到不断刷新的进度条没有报错说明这路流已经推到Nginx上了。此时再刷新http://127.0.0.1:8080/stat应该能看到活跃流信息包括流名test、上传码率、连接数等。4.3 用VLC或ffplay验证拉流播放推流成功后开始验证拉流。VLC打开网络串流rtmp://127.0.0.1:1935/live/test在VLC里选择“媒体” - “打开网络串流”把地址粘贴进去点播放。正常情况下几秒钟内就能看到彩色测试画面同时能听到440Hz的蜂鸣声。这个画面就来自ffmpeg刚才推上去的流。如果更习惯命令行用ffplayffplay rtmp://127.0.0.1:1935/live/testffplay的优势是启动快还能在控制台直接看到解码信息比如视频编码格式、关键帧间隔、丢包率。我一般用ffplay做第一轮验证确认流没问题后再让业务方用VLC。注意如果VLC播放黑屏但ffplay正常大概率是VLC解码或硬件加速的问题可以尝试关闭VLC的硬件加速或者把“缓存毫秒数”调到300以上。4.4 局域网/公网地址验证与常见问题本机验证通过之后用同一局域网里的另一台电脑测试。将上面地址里的127.0.0.1换成服务器的实际IP。怎么确认IP在服务器命令行执行ipconfig找到正在使用的网卡IPv4地址比如192.168.1.100。然后在另一台电脑的VLC里打开rtmp://192.168.1.100:1935/live/test如果这台机器不能播放第一步检查能不能ping通服务器IP。能ping通但拉不了流很大概率是Windows防火墙挡了1935端口。需要在服务器上添加入站规则放行TCP 1935端口如果有需要也可以放行8080端口用于HLS和统计页面。关于Windows防火墙放行我习惯用命令行快速完成netsh advfirewall firewall add rule nameRTMP 1935 dirin actionallow protocolTCP localport1935 netsh advfirewall firewall add rule nameHTTP 8080 dirin actionallow protocolTCP localport8080执行完再拉流测试。如果仍然不通再检查路由器和交换机是否有ACL限制这属于网络设备层问题流媒体服务器本身没有日志能看出来。至于公网验证不建议新手直接暴露1935端口。公网环境扫描器非常多几分钟就能扫到开放端口如果推流没有鉴权很容易被恶意盗推。真要公网直播至少在配置里加一层allow play限制和on_publish鉴权这部分后面会讲。5. 常见坑与排查方法我在这个项目里踩过的雷5.1 启动闪退先看端口和日志双击nginx.exe后窗口一闪而过是Windows下Nginx最经典的启动失败现象。很多人以为闪退就是程序坏了其实大部分原因是端口被占用、配置语法错误或日志目录无法写入。排查顺序很重要。第一步在命令行执行nginx.exe -t -c conf/nginx.conf如果有语法错误会直接提示第几行有问题改掉即可。如果显示test successful那就是运行时问题。第二步查看D:\MediaServer\nginx-rtmp\logs\error.log里面会记录真实的错误信息。常见错误包括bind() to 0.0.0.0:1935 failed (10013: An attempt was made to access a socket in a way forbidden by its access permissions)说明端口被占用。emerg] mkdir() D:/MediaServer/nginx-rtmp/nginx-rtmp/temp/client_body failed说明目录权限不足把Nginx放到有写权限的目录或者以管理员身份启动。端口占用用这条命令查netstat -ano | findstr :1935如果看到占用进程PID去任务管理器找到对应进程把它关掉或改Nginx端口。5.2 拉流黑屏/卡顿的编码根因RTMP只是传输封装它不关心里面装的视频编码是什么但播放端很关心。如果推流端用了H.265/HEVC编码很多浏览器和播放器因为版权或解码能力问题直接不支持于是黑屏。同样如果音频用了Opus格式VLC能放但很多播放器会没声音。我踩过的坑是现场采集卡配套的推流软件默认用了H.265编码推流地址填的是RTMP在VLC里黑屏。当时我第一反应是服务器问题排查了很久才发现是编码格式问题。后来让推流端统一改成H.264视频编码AAC音频编码画面立刻正常。另外关键帧间隔也是黑屏和启动慢的重要原因。RTMP拉流播放器需要等到一个关键帧才能开始解码画面如果推流端关键帧间隔设置得太长比如10秒一个GOP播放器打开后可能要等好几秒才能出画面。我习惯在OBS的输出设置里把关键帧间隔设为2秒对应的参数是-g 5025帧率场景50帧即2秒。5.3 跨网段拉流失败的防火墙排查链路有一次客户那边是两个VLAN服务器在A VLAN播放终端在B VLANA VLAN内拉流正常B VLAN怎么都拉不通。当时按照下面的链路一步步排查才找到问题在B VLAN终端上 ping 服务器IP基础网络是否通用telnet测试端口连通性telnet 服务器IP 1935如果连接超时或被拒绝说明端口不通检查Windows防火墙入站规则是否放行了1935端口检查核心交换机VLAN间ACL是否允许B VLAN访问A VLAN的TCP 1935端口最后发现是防火墙入站规则里“作用域”设置成了仅本机子网把作用域改成“任何IP地址”或者把B VLAN网段加进去就通了。Windows防火墙高级设置的入站规则里面默认的“远程IP地址”范围经常被人忽略。很多教程只告诉你放行端口没告诉你默认作用域可能限制了网段导致跨网段拉流失败。5.4 推流中断的稳定性问题再稳的服务器也会被不稳定的推流端搞得像断流。我遇到过的典型情况是OBS推流大约十几分钟到半小时后自动断开Nginx日志里出现writev() failed (10054)这类连接重置错误。这里有两层原因。第一层是网络本身WiFi环境下的RTMP推流稳定性很差网络抖动或短暂断开就会触发TCP重置。解决办法是让推流端改用有线网络或者调整OBS的“网络”设置增加“缓冲区大小”和“重试次数”。第二层是Windows节能策略默认情况下Windows会在一段时间无操作后让网卡进入省电状态导致连接被挂起。在设备管理器里找到网卡把“允许计算机关闭此设备以节约电源”的勾去掉能非常有效地减少这类断流。另一个容易被忽略的点是杀毒软件。像360、电脑管家这类软件会拦截Nginx的端口监听或者进程行为导致看似正常的配置在启动后立刻被清理。如果在生产环境使用建议把Nginx目录加入杀毒软件白名单或者直接用Windows Defender并手动添加排除项。6. 进阶思路从RTMP向HLS和鉴权延伸6.1 开启HLS输出让浏览器直接播放RTMP在浏览器里不能直接播放除非安装Flash插件这个时代已经行不通了。如果需要在浏览器里观看直播更通用的做法是把RTMP流转成HLS切片。在nginx.conf的rtmp区块里新增一个applicationapplication hls { live on; hls on; hls_path html/hls; hls_fragment 5; hls_playlist_length 30; }配置字段含义hls on开启HLS切片功能hls_path切片文件保存目录这里用相对路径对应Nginx目录下的html/hls目录不存在时Nginx会自动创建如果想用绝对路径写成D:/MediaServer/nginx-rtmp/html/hls注意正斜杠反斜杠hls_fragment 5每个切片时长5秒hls_playlist_length 30播放列表保留最近30秒的内容配置完成后重启Nginxnginx.exe -s stop然后再start nginx.exe然后推流到rtmp://127.0.0.1:1935/hls/test稍等几秒浏览器打开http://127.0.0.1:8080/hls/test.m3u8如果配置正确页面会返回一个m3u8播放列表文件里面记录了test-1234.ts之类的切片地址。这个用HLS.js或者其他支持HLS的播放器就能直接播放。注意HLS延迟比RTMP高通常在10到30秒因为播放器需要先下载切片和更新播放列表。如果对实时性要求很高还是用RTMP或WebRTC更合适。6.2 用on_publish做最简推流鉴权默认配置下只要有网络访问权限任何人都可以向你的服务器推流。公网环境下这非常危险。nginx-rtmp-module支持通过on_publish回调做推流鉴权当有推流请求进入时Nginx会向一个HTTP地址发送POST请求附带推流参数如果接口返回2xx状态码就允许推流否则拒绝。配置示例application live { live on; on_publish http://127.0.0.1:9999/auth; }这里需要自己写一个非常简单的校验服务接收POST参数检查流key或者自定义字段。假设用Python Flask写一个最小版本from flask import Flask, request app Flask(__name__) TOKEN some-secret-token app.route(/auth, methods[POST]) def auth(): if request.form.get(key) ! TOKEN: return , 403 return , 200 if __name__ __main__: app.run(host127.0.0.1, port9999)然后在OBS推流时可以在串流密钥后面拼上参数让Nginx把参数转发给鉴权接口。比如串流密钥填写test?keysome-secret-token这样推流地址虽然还是rtmp://ip:1935/live但Nginx会把key参数传给鉴权服务。校验逻辑里不只是查固定token还可以写动态token、验签、过期时间等。这个方案适合内网或小规模场景能挡住大多数扫描和误推。注意鉴权服务不能挂否则推流会被拒我一般会把鉴权服务同一台机器上部署并加一个进程守护。6.3 控制并发和优化worker配置当并发拉流数上来以后Linux下的Nginx会有专门的调优姿势但Windows下可调空间有限。我实测的结论是在Windows Server上Nginx单worker进程大约能稳定支持几十路并发播放瓶颈主要在TCP连接数和带宽CPU反而没那么高。几个可以做的优化把worker_connections从1024改为2048但要同时考虑系统最大TCP连接数限制关闭不用的http server或者把8080端口只绑定内网减少不必要的连接占用如果你开启了HLS注意切片目录的磁盘占用持续直播几小时后旧的切片会被覆盖但临时文件会增多最好定期清理在Windows防火墙里只放行必要的IP范围访问端口减少恶意连接尝试对资源的消耗如果并发超过百路我会果断放弃单机方案认真考虑CDN或者SRS集群。Nginx单机适合的是轻量、内网、可维护性优先的场景别用它硬扛高并发。最后分享一个小经验我把这套Nginx放到了D盘MediaServer目录下ffmpeg和VLC也放在同一个根目录里。平时做流媒体测试我习惯先用ffmpeg推一路带时间戳的测试源确认整个链路通了再让业务方用OBS推真实画面。这样能快速区分是推流端的问题还是服务器/播放端的问题。如果你第一次搭建议严格按上面步骤走一遍等验证通过后再按需加HLS和鉴权不要一开始就把配置搞得很复杂。踩过几次坑之后会发现RTMP流媒体服务器本身并不神秘它就是一台按约定转发光信号的“分线盒”搞清楚推流、拉流和编码格式这三件事大部分问题都能自己排查了。